General C++ Linux-to-Windows porting questions

Background: A network-based service (tcp+udp, not http) exists with a soon-to-be public published C++ linux client API. This client API Uses normal tcp sockets, udp sockets, C++ namespaces and parts of the stl like std::map and std::vector, and will be published as a set of header files and .a and .lib files to link against.

Questions: Just starting to look into what it would take to port this C++ cli开发者_StackOverflow社区ent API to Windows. Does it make sense to use gcc/g++ under Windows? My first inclination is this wouldn't work since developers on Windows typically use the Microsoft Visual Studio suite, and they wouldn't be able to link against the library produced by gcc. Is this a correct assumption, or does gcc provide some nifty switches which produces Microsoft-compiler and Microsoft-linker compatible output files?

I'd recommend making the public API standard C since C++ libraries are not even portable across different compilers on windows. If C++ is required, build a small C++ wrapper on top of the C API and distribute the wrapper source with your library.

If you want a pure C++ API, you could distribute the source if you don't want to build a version for every compiler (or distribute Visual C++ library only). Depends on whether distributing source is acceptable though...

As long as the compiler you're using produces genuine .dll or .lib files, you shouldn't have an issue linking them with a standard linker in Windows. However, only either unmanaged development (meaning classic Win32 API development) or C++/CLI will be able to link against these .dlls. If you compile to a .dll (not a .lib), you can target this assembly from within a managed context (C#, VB.NET, etc.) using P/Invoke syntax, but if all you're doing is standard socket read/write operations, you're probably better off writing a fully-managed implementation in .NET.

In the end it comes down to what audience you want to target: for classic Win32, you're fine. For managed targets (anything .NET, aside from C++/CLI) then you're better off writing a managed implementation in C# or VB.NET instead.

Why don't you just create a dll and make a header file with GetProcAddress and functionpointers ?

Then you can compile your API with MinGW (g++/gcc) on Windows using msys. The only thing you need to do is adding some windows code, e.g. the network headers and wsastartup, linking to libwsock32.

And besides, porting your code to VC++ shouldn't be a problem, it just needs a project and some ifdefs for windows specific code.

Is this a correct assumption, or does gcc provide some nifty switches which produces Microsoft-compiler and Microsoft-linker compatible output files?

That is a correct assumption, for C++ compiled files. I've seen some conversations on what it would take to add that to GCC, and the conclusion was that it would be possible but quite a lot of work.

However, that is far less true with C libraries; those should be much more portable. One option that may well be feasible for you is to convert all of the things that you distribute as precompiled code into C, and then put the things that need to be C++ into header files that the user compiles.

The problem is that there is no standard for name-mangling in C++, and even if there was, linking C++ code from different compilers would be problematic. This is actually an issue on Linux too, except that most people there use the same compiler.

Libraries produced with MinGW g++ (get it at http://tdragon.net/recentgcc, not the MinGW SF page) are compatible with Microsoft code, but you will need to provide a C interface.