C++中Winodows.h包含在namespace与map以及mutex冲突的原因是什么?

#include
int main()
{
return 0;
}
可以正常编译运行

namespace win
{
#include
}
int main()
{
return 0
}
也可以正常编译运行,经过测试,是可以成功创建窗体的

另外
#include
#include
int main()
{
return 0;
}
也是可以编译运行的

但是,问题是但是……
namespace win
{
#include
}
#include
int main()
{
return 0;
}
却无法通过编译

把mutex换成map也是和上面一样的情况
哪位大神能告诉下小弟这个究竟是什么原因?
如果我继续使用
namespace win
{
#include
}
除了上述的编译冲突以外,还会有一些其他的什么隐患吗?
能具体的说一下这些隐患是什么吗?造成这种隐患的本质原因是什么呢?
更多 0

c++

6个回答

现在的问题是,单独情况下可以放在namespace里,但是一旦调用map、mutex这些头,就会出现问题
导致这一个问题的原因是什么
头文件不需要放在namespace里的前提是你没遇到Windows.h这么犯贱的头文件,尼玛几乎把所有常用的类名全部给你定义了一个遍,动辄就跟一些其他
头文件所定义的类冲突

虽然这是一种解决方法,但是却没有解决问题的本质,那就是为什么会发生冲突。
Windows确实提供了很多类库,但是它提供不了能解决我所有问题的类库
说的具体点,我需要的是一个自带各种方法的可扩展为无穷维的POINT类,而不是Windows提供的那个只有整数X、Y坐标并且没有法线信息,纹理坐标,颜色信息的不解决我实际问题的POINT类
我的需求Windows并不能很好的满足——更重要的如果我依赖于Windows或者其他微软库提供的POINT类的话,我的程序想要移植到其他的操作系统上,所需要付出的代价就过于高昂了,毕竟POINT类
对我的程序来说,还是一个调用相当频繁的类,如果这个类不以跨平台的要求去构建的话,那之后代码移植起来的麻烦就更大了
我没有选择的余地

这个估计得像教科书一样,什么都得前面加上命名空间了?我猜测

头文件不需要放到namespace。

你用了windows.h,那么最好用MFC提供的类库,或者boost
活用VS2013等,对map,mutex支持很好

如果需要考虑可移植性,同时有希望扩展POINT,那么最好的方式就是自己定义POINTEX等类来扩展

Csdn user default icon
上传中...
上传图片
插入图片
抄袭、复制答案,以达到刷声望分或其他目的的行为,在CSDN问答是严格禁止的,一经发现立刻封号。是时候展现真正的技术了!
立即提问
相关内容推荐