问题描述
- 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
解决方案
现在的问题是，单独情况下可以放在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等类来扩展