Working on a cross platform library

Question

What are the best practices on writing a cross platform library in C++?

My development environment is Eclipse CDT on Linux, but my library should have the possibility to compile natively on Windows either (from Visual C++ for example).

Thanks.

Answer 1

To some extent, this is going to depend on exactly what your library is meant to accomplish.

If you were developing a GUI application, for instance, you would want to focus on using a well-tested cross-platform framework such as wxWidgets .

If your library depends primarily on File IO, you would want to make sure you use an existing well-tested cross-platform filesystem abstraction library such as Boost Filesystem .

If your library is none of the above (ie there are no existing well-tested cross-platform frameworks for you to use), your best bet is to make sure you adhere to standard C++ as much as possible (this means don't #include <linux.h> or <windows.h> , for instance). When that isn't possible (ie your library reads raw sound data from a microphone), you'll want to make sure the implementation details for a given platform are sufficiently abstracted away so that you minimize the work involved in porting your library to another platform.

Answer 2

To my knowledge, there are a few things you can do:

1. You can divide the platform specific code into different namespaces.

2. You can use the PIMPL idiom to hide platform specific code.

3. You can use macros do know what code to compile (in this case the code will be platform specific). Check this link for more information.

4. Test your library in multiple environments.

5. Depending on what you are doing it might be good to use libraries such as Boost because it is not specific to a platform. The downside (or possibly the good side) is that you will force the use of the libraries you included.

Answer 3

Couple of suggestions from my practical experience:

1) Make sure of regular compilation of sources in your targeted platforms. Don't wait till the end. This'd help point to errors early. Use a continuous build system -- it makes life a lot easier.

2) Never use platform specific headers. Not even for writing native code -- for all you know some stuff in a windows header might expect some string which was ABC in XP but got changed to ABC.12 in Win7.

3) Use ideas from STL and BOOST and then build on top of them. Never consider these to be a panacea for problems though -- STL is easy to ship with your code but BOOST is not.

4) Do not use compiler specific constructs like __STDCALL. This is asking for hell.

5) The same code when compiled with similar compiler options in g++ and cl might result in different behavior. Please have a copy of your compiler manual very handy.

Answer 4

Anytime I work on something like this I try and build it in the different environments that I want to be supported. Similarly if you were making a web page and you wanted to make sure it worked in IE, Firefox, and Chrome you'd test it in all three of those browsers. Test it in the different environments you want to support, and you'll know what systems you can safely say it works for.

Answer 5

如上所述的问题有点抽象。但你可以考虑QT

Answer 6

It's really just as simple as "don't using anything platform specific". The wealth of freely available tools availalble these days makes writing cross-platform code in C++ a snap. For those rare but occasional cases where you really do need to use platform specific APIs, just be sure to separate them out via #defines or, better in my opinion, distinct .cpp files for each platform.

There are many alternatives for cross platform libraries but my personal preferences are:

• GUI: Qt
• OS abstraction (though Qt does a great job of this all by itself): Boost
• Cross-platform Makefiles: CMake

The last one, CMake, has been a tremendous help for me over the last few years for keeping my build environment sane while doing dual-development on Windows & Linux. It has a rather steep learning curve but once it's up and running, it works exceptionally well.

Answer 7

You mean besides continuous integration and testing on target platforms? Or besides using design to abstract away the implementation details?

No, can't think of anything.