背景：基于networking的服务（ tcp+udp ，不是http ）存在即将公开发布的C++ linux客户端API。 这个客户端API使用普通的tcp套接字，udp套接字，C ++命名空间和部分stl std::map和std::vector ，并将作为一组头文件和.a和.lib文件进行链接。
问题：刚开始考虑将这个C ++客户端API移植到Windows将需要什么。 在Windows下使用gcc / g ++有意义吗？ 我的第一个倾向是这是行不通的，因为Windows上的开发人员通常使用Microsoft Visual Studio套件，他们将无法链接到由gcc生成的库。 这是一个正确的假设，还是海湾合作委员会提供一些漂亮的开关，产生微软编译器和微软链接器兼容的输出文件？
只要您使用的编译器生成真正的.dll或.lib文件，就不应该在Windows中将它们与标准链接程序链接起来。 但是，只有非托管开发（意味着经典的Win32 API开发）或C ++ / CLI才能够链接到这些.dll。 如果您编译为.dll（不是.lib），则可以使用P / Invoke语法在托管上下文（C＃，VB.NET等）中定位此程序集，但是如果您只是使用标准套接字读/写操作，你可能最好在.NET中编写一个完全托管的实现。
最后，它归结为你想要的目标观众：对于经典的Win32，你没事的。 对于托管目标（任何.NET，除了C ++ / CLI），最好用C＃或VB.NET编写托管实现。
我建议制作公共API标准C，因为C ++库甚至不能跨Windows上的不同编译器移植。 如果需要C ++，则在C API之上构建一个小型C ++包装器，并将包装器源代码与您的库一起分发。
如果您想要一个纯粹的C ++ API，如果您不想为每个编译器构建版本（或仅分发Visual C ++库），则可以分发源代码。 取决于分发源是否可以接受，但…
你为什么不创建一个DLL，并使用GetProcAddress和函数指针创建一个头文件？
然后你可以用msys在Windows上用MinGW（g ++ / gcc）编译你的API。 你唯一需要做的就是添加一些windows代码，例如网络头文件和wsastartup，链接到libwsock32。
此外，将代码移植到VC ++应该不成问题，只需要一个项目和一些针对特定于Windows的代码的ifdefs。
这是一个正确的假设，还是海湾合作委员会提供一些漂亮的开关，产生微软编译器和微软链接器兼容的输出文件？
对于C ++编译的文件，这是一个正确的假设。 我已经看到了一些关于将GCC添加到GCC中的讨论，结论是这将是可能的，但是还有很多工作要做。
但是，对于C库来说，情况就不那么简单了。 那些应该更便携。 一个对你来说可能是可行的选择是将你分发为预编译代码的所有东西都转换成C，然后把需要成为C ++的东西放到用户编译的头文件中。
问题是在C ++中没有标准的名称修改，即使存在，从不同编译器链接C ++代码也是有问题的。 这实际上也是Linux上的一个问题，除了大多数人使用相同的编译器。
使用MinGW g ++（ http://tdragon.net/recentgcc而不是MinGW SF页面）生成的库与Microsoft代码兼容，但是您需要提供一个C接口。