6

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.

Alon Gubkin
  • 56,458
  • 54
  • 195
  • 288
  • 1
    Can I ask what this library is for? There are probably already cross platform libraries for just about everything. – jmucchiello Jun 03 '10 at 17:27

7 Answers7

5

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 (i.e. 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 (i.e. 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.

Mark Rushakoff
  • 249,864
  • 45
  • 407
  • 398
  • True. Also [http://www.gtk.org/download-windows.html glib] has abstractions for all the lowest-level C-like stuff such as malloc and strcmp. – Pat Wallace Jun 03 '10 at 16:35
  • As an addendum, I would add that it is typically useful to have your platform-specific code (if there is any) separated into its own module. The rest of your code is platform-agnostic and can perform platform-specific tasks by calling interface functions. That way, porting your library simplifies down (for the most part) into porting that one single module. – bta Jun 03 '10 at 17:13
  • 1
    The only thing I would point out is that you do not necessarily want to force the need for another library. One might want it to work independently (STL being an exception because it is part of the C++ standard). – Alerty Jun 03 '10 at 18:07
  • @Mark how are multi platform libraries made ? how can they be cross platform , do they use each platform API (e.g the boost fileystem does it use each system API ti manage files because I can't see an other way to do it as the c++ language does not understand what directories even are ) ? – AnotherOne Apr 10 '16 at 12:50
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.

Community
  • 1
  • 1
Alerty
  • 5,945
  • 7
  • 38
  • 62
1

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.

Fanatic23
  • 3,378
  • 2
  • 28
  • 51
0

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.

Ben Burnett
  • 1,554
  • 10
  • 17
0

question as stated is bit abstract.but you can give QT a consideration

pushkarpriyadarshi
  • 41
  • 5
-2

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.

Rakis
  • 7,779
  • 24
  • 25
  • 1
    -1: You can use platform specific code. One simply needs to put the necessary measures so that this code is not compiled for a certain environment. – Alerty Jun 03 '10 at 18:01
  • The first thing you suggest is to not use platform specific code. Not to mention that you are suggesting to use existing libraries when it is not necessarily the best course of action. Of course, you are saying that it is possible to use platform specific code. The problem is that you are defining this has being a rare but occasional case without knowing what type of library Alon is doing. – Alerty Jun 03 '10 at 19:06
  • @Alerty You're right. I'm just one of those crazy people that think *general* questions merit *general* answers. Not to worry though, through the magic combination of origami and tin foil, my mind-reading device will be ready in no time :) – Rakis Jun 03 '10 at 19:55
  • @Rakis how are multi platform libraries made ? how can they be cross platform , do they use each platform API (e.g the boost fileystem does it use each system API ti manage files because I can't see an other way to do it as the c++ language does not understand what directories even are ) ? – AnotherOne Apr 10 '16 at 12:51
  • @Mekacher Cross-platform libraries use platform-specific APIs when necessary but they abstract them so as to insulate the library consumer from the platform-specific differences. Often, this results in a lowest-common-denominator, problem where features cannot be exposed for which support does not exist on every library-supported platform. The directory issue you point out is a good example as not all systems have a similar definition of what constitutes a "directory" though all platforms have a concept of a named, sequential series of bytes, aka a "file". Though even then the specifics differ – Rakis Apr 21 '16 at 05:14
-3

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.

Edward Strange
  • 40,307
  • 7
  • 73
  • 125