VS2013使用winsock.h和winsock2.h发生冲突后的终极解决方法

问题:彻底无语了,不小心某个文件包含了windows.h头文件,而windows.h文件里面包含着winsock.h文件,

如果你下次使用winsock2.h文件时,位置不对,然后编译器会给你一大堆重定义错误问题。

初级解决办法

把winsock2.h文件放在任何可能包含winsock.h文件(尤其是windows.h文件,它就包含了winsock.h文件)的前面,因为winsock2.h头文件有这样的宏定义:

#ifndef _WINSOCK2API_
#define _WINSOCK2API_
#define _WINSOCKAPI_ /* Prevent inclusion of winsock.h in windows.h */

如果在winsock2.h之后再引用winsock.h头文件,那么winsock.h文件并没有什么卵用。

 

在生成应用程序时,即使不是MFC应用程序,也有有这个东西:

而网上对stdafx.h文件的解释是:把一个工程(Project)中使用的一些MFC标准头文件(如Windows.H、Afxwin.H)预先编译,以后该工程编译时,不再编译这部分头文件,仅仅使用预编译的结果。这样可以加快编译速度,节省时间。

可怕的是它包含了windows.h文件,然而并不可怕的是:当我们使用AppWizard来自动生成某些项目的时候,系统会自动把所需要include的头文件在stdafx.h中先include一下,这样,我们只需要直接include这个stdafx.h文件即可。只在使用AppWizard来自动生成项目的时候,才出现.否则,就没有必要include此头文件stdafx.h了。参考网页。

所以如果是MFC等windows窗口项目,需要把stdafx.h预编译头删掉,否则其它应用删不删都无所谓了。

但是……但是……但是……即使我采取了以上办法,并一一追踪我自己写的头文件,看了看winsock.h和winsock2.h包含的先后关系,都满足了winsock2.h在前的关系了,但是仍然有重定义,这个时候我看到另外一篇文章,里面提到【但当我在一个wxWidgets中调用它时,又出现那个让人厌烦的错误 ““sockaddr”: “struct”类型重定义,明显是wxWidgets先包含了windows.h,现在头都大了,楞想不到怎么解决,在所有文件最开头定义_WINSOCK2API_都没用】,只想说呵呵了。人家要是愣是在最初给你先包含了windows.h文件(就譬如MFC中的stdafx.h头文件),那你也没辙了是吧。

终极办法:

然而,天无绝人之路,终极办法是:添加WIN32_LEAN_AND_MEAN宏定义,直接在vs的设置里预先添加这个宏定义就ok啦:

那么,这个奇怪的宏定义是干嘛的,查了一些资料后,是这么说的【 不加载MFC所需的模块。在编译链接时,以及在最后生成的一些供调试用的模块时,速度更快,容量更小。】好多地方都是这么说的,就不给链接了,有兴趣的自己搜搜这个宏吧。

然而,我仍然疑惑的是,我在哪里加载MFC所需的模块了,其实我挺好奇上面那个图中_WINDOWS这个宏是干嘛,但是暂时没有搜到相关资料。

总结:其实大家也看到了,其实所谓的终极办法也只能解决这种非MFC的应用程序的问题,至于其他情况出现这种问题的话,我还没有去探索,毕竟还没有遇到嘛。

感慨:下面这些选项在不了解情况的时候不要瞎选哈:

还有那个SDL检查,个人建议不要选,因为windows上有它自己的一套_s的安全函数,否则,你就各种编译不通过,还得改为它的_s(safe)函数,这个时候你要修改的东西多了。当然,这个sdl检查还是有用的,毕竟人家的函数毕竟比较safe嘛,然而上次使用vsnprinf_s函数的时候,因为它提供额外参数问题,这个参数的错误导致我的程序里出现了莫名其妙的错误,都是泪。

要不是因为被要求使用vs做开发,我也不会去用它,个人还是钟情于linux平台的东西。vs开发为了让开发更简单,更傻瓜式,它默默的帮你干了很多事情,等你出错的时候,你就干瞪眼吧。也因为各种IDE的使用,很多程序员不了解整个编译流程,总是习惯一键build。当然,各有各的好,各有各的适用情况,我个人偏好使用gcc罢了。

 

转载于:https://www.cnblogs.com/Shirlies/p/5137548.html

你可能感兴趣的:(VS2013使用winsock.h和winsock2.h发生冲突后的终极解决方法)