5

We our going to start a new project in our small team:

  • It's a library which will be used by our other projects (in Linux and Windows).
  • It's not platform dependent logically (it's not using any system calls or anything like that).
  • It has to be compiled on various platforms (including Windows and Linux at least).

Unfortunately, non of our developers ever wrote any code in any other platform than Windows! Therefore, I have to give them a "code like this" or "not code like this" list, so the code will stay cross platform.

any guidance?

MBZ
  • 26,084
  • 47
  • 114
  • 191

7 Answers7

10

One way of increasing portability is to use the same compiler, GCC, on both platforms. If you also use the same compiler version, you will probably avoid most, if not all C++ language and Standard Library incompatibilities. You can also use the same build tools, such as GNU make, which means the build process is the same on both platforms.

As for platform incompatibilities - check that their code does not contain includes like:

#include <windows.h>
#include <unistd.h>
#include <sys/almost_anything.h>

unless this is done via conditional compilation.

  • 7
    This might make it easier to make your code work on both platforms, but it does have the danger that you can accidentally make your code _less_ portable by relying on something non portable in GCC for example. It could bite you badly when you come to port to a 3rd platform where you can't use exactly the same tools. Not saying it's a bad idea, just be careful :) – jcoder Aug 10 '10 at 17:30
  • @John True enough - but a judicious use of compiler flags can detect most of this. You could of course say "we only support GCC", which would not limit portability much. –  Aug 10 '10 at 17:41
  • Indeed. I only mention it because I've had experience of "You know the program we said only needed to work on windows and unix?? Well now we need it on ibm mainframe"... And the compilers and environment there are not even remotely similar – jcoder Aug 10 '10 at 17:42
  • 1
    @Neil: Unfortunately, saying "only on gcc" does limit portability. Very likely somebody will want to link in the library from a Visual C++ project. I've cursed libraries before for only running with certain versions of certain compilers. – David Thornley Aug 10 '10 at 19:46
  • @David The MinGW port of GCC (which is the one they would probably be using) produces libraries compatible with the Microsoft linker and C ABI, though not with Microsoft C++ name-mangling. –  Aug 10 '10 at 19:54
  • @Neil: I wouldn't consider that good enough. If I can't directly link a C++ library into my C++ project, that's a problem. I'd much rather be able to link with my gcc project on Linux and MacOSX and my Visual C++ project on Windows. – David Thornley Aug 10 '10 at 20:06
  • @David well, you can't be guaranteed to do that with different compiler versions from the same provider on the same platform. –  Aug 10 '10 at 20:09
  • @Neil: Sure - some of my cursing was at a library that would only link with an older version of the compiler we were using. However, if the library is available as source (and this appears to be an internal library) or the distributor makes enough versions available, that doesn't need to be a problem. – David Thornley Aug 10 '10 at 20:25
7

Make sure that you have automated build processes on all platforms, and write unit and automated functional tests. If possible run automated nightly builds and tests. It's much more important when you are writing cross platform libraries.

I would do the opposite of one of the other answers (Not that i think it's wrong, just a different approach) and if you can choose your platforms make them as different as possible. For example make one 32 bit MCVC and the other 64 bit gcc on unix. If you can have automated tests and builds then this will show up portability issues quickly.

If possible have some developers working on one platform and some on another rather than finishing the code on one platform and then "porting" it to the other. That way they'll learn very quickly what not to do when their co workers come over to complain they broke something.

Technically things to watch out for are

  • Don't assume ints are 32 bits
  • Don't assume char's are signed or unsigned
  • Don't assume characters are in ASCII
  • Don't assume anything about data byte order or alignment
  • Minimize pointer arithmetic. You'll only get it wrong when you make assumptions that fail.
  • Remember file and directory names work differently on different platforms. If you only have to port to windows and unix you might get awayy with it but once you've ported to two platforms then the next port might be to z-series or VMS where these things work quite differently.
jcoder
  • 29,554
  • 19
  • 87
  • 130
6

Most importantly: have automatic builds and tests running on all supported platforms, all the time, to pick up most non-portable (or just wrong) code straight away.

The language itself, the Standard Library, and Boost should be portable to any widely-used platform (certainly modern versions of Linux/GCC and Windows/MSVC). Be suspicious of any system header file that ends with .h, and check other libraries for portability before deciding to use them.

Maintain a document of all the incompatibilities you encounter, so hopefully you'll only make each mistake once.

Mike Seymour
  • 249,747
  • 28
  • 448
  • 644
5

Just tell them not to use Windows API and they should be good to go.

I'd also suggest increasing your warning/error level, if developing in Visual Studio, as it will prevent you from doing some things that gcc (normally) won't allow, assuming you're using gcc to compile for Linux. You can also disable Visual Studio extensions in project settings.

Evidently if someone needs to use something platform-specific, they should use defines that replace the platform-specific code depending on which platform it's being compiled on.

Collin Dauphinee
  • 13,664
  • 1
  • 40
  • 71
2

Compile with as many compilers as possible, even if only on a limited number of platforms. Off the top of my head, VC, gcc, intel, pgi. If you can get older versions of some of them, that would help as well. All of the developers don't need to use these, but run them nightly with the results available to all of the developers. Its much easier to fix problems as they come up, rather than trying to fix all of the issues when you are trying to release.

KeithB
  • 16,577
  • 3
  • 41
  • 45
1

Some suggestions:

  • Use static_cast<>, dynamic_cast<> and const_cast<> instead of C-style casts. If reinterpret_cast<> has to be used, review it, and surround that code with careful unit tests. (The point of this rule is to prohibit clever bit-twiddling and reliance on sizes or alignments.)

  • Use modern standard C++ libraries only: no MS-specific libraries like (brrr!) MFC and its CString.

You might add some of the recommendations here, but be aware that some are a bit too pessimistic for reasonably modern compilers (e.g. recommendation #16 on temporary objects, and #18 is directly in conflict with the STL parts of the library).

Pontus Gagge
  • 17,166
  • 1
  • 38
  • 51
0

From experience of developing on Linux amongst Windows developers the main issue normally (provided you really are not using platform dependent code as you say) is just that of case sensitivity in #include file names. Apart from that you will find that gcc is, by default, stricter than MSVC and so you may need to tighten up a few things up but they are usually quite straightforward.

One particular thing to watch out for is that std::map::erase does not return an iterator.

Community
  • 1
  • 1
Troubadour
  • 13,334
  • 2
  • 38
  • 57