Work on the cross-platform library

Question

What are the best methods for writing a cross-platform C ++ library?

My development environment is Eclipse CDT for Linux, but my library should be able to compile natively on Windows (e.g. from Visual C ++).

Thanks.

Answer 1

To some extent, this will depend on what your library should do.

If you were developing a GUI application, for example, you would like to focus on using a well-tested cross-platform framework like wxWidgets .

If your library is primarily dependent on File IO, you would like to make sure that you are using the existing well-tested abstraction library for a multi-platform file system, such as the Boost Filesystem .

If your library is not one of the above (i.e. for you there are no valid proven cross-platform frameworks), it is best to make sure that you adhere to standard C ++ as much as possible (this means that Don’t #include <linux.h> or <windows.h> , for example). If this is not possible (i.e. your library reads raw audio data from a microphone), you should make sure that the implementation details for this platform are sufficiently abstracted so that you minimize the work involved in moving your library to another platform.

Answer 2

As far as I know, there are a few things you can do:

• You can split platform specific code into different namespaces.

• You can use PIMPL idiom to hide specific platform code.

• You can use macros, you know which code to compile (in this case, the code will be platform specific). See the link for more details.

• Test your library in several environments.

• Depending on what you are doing, it may be useful to use libraries like Boost because this is not platform specific. The downside (or perhaps the good side) is that you force the libraries you included.

Answer 3

A few suggestions from my practical experience:

1) Make sure to regularly compile sources on your target platforms. Do not wait until the end. This will help to quickly find errors. Use a continuous assembly system - it makes life easier.

2) Never use platform specific headers. Even for writing your own code - for everyone you know, some things in the Windows header can expect some line that was ABC in XP, but was changed to ABC.12 in Win7.

3) Use ideas from STL and BOOST, and then build on top of them. Never consider them as a panacea for problems, although STL is easy to send with code, but BOOST is not.

4) Do not use compiler-specific constructs such as __STDCALL. It asks for hell.

5) The same code when compiling with similar compiler options in g ++ and cl can lead to behavior. Please attach a copy of your compiler guide very conveniently.

Answer 4

Anytime when I work on something similar, I try to create it in different environments that I want to support. Similarly, if you created a web page and you wanted to make sure that it works in IE, Firefox and Chrome, you will check it in all three browsers. Test it in different environments that you want to support, and you will learn which systems you can confidently say that it works.

Answer 5

the question, as indicated, is a bit of abstract.but you can give QT consideration

Answer 6

It really is as simple as "not using anything specific to the platform." Nowadays, a wealth of freely available tools allows you to write cross-platform C ++ code. For those rare but occasional occasions when you really need to use platform-specific APIs, just be sure to separate them through #defines or, better, in my opinion, different .cpp files for each platform.

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

• GUI: Qt
• OS abstraction (although Qt does it all by itself): Boost
• Cross-platform Makefiles: CMake

The latter, CMake, has helped me tremendously over the past few years to keep the build environment working while doing dual development on Windows and Linux. It has a pretty steep learning curve, but once it works and works, it works exceptionally well.

Answer 7

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

No, I can’t think of anything.