What are the practical differences in C and C ++ code portability?

Navigation
6

I've been reading some open-source C code lately and I've noticed that a lot of them have become quite complex with a lot of #ifdef to make the code as portable as possible between various platforms and * NIX. Some even support different libraries in the same program.

I would like to ask if in practice, C ++ can override this kind of portability problem. An example code to have the command mkdir portable: 

// Try to bring in unistd.h if possible
#if !defined(__TURBOC__) && !defined(_MSC_VER)
#include <unistd.h>
#endif

// Bring in direct.h if we need to; sometimes mkdir/rmdir is defined here
#if defined(__WATCOMC__) || defined(_MSC_VER)
#include <direct.h>
#endif

// Fill in S_ISDIR
#if !defined(_POSIX_VERSION) && !defined(S_ISDIR)
#define S_ISDIR(m) (((m) & S_IFMT) == S_IFDIR)
#endif

#if defined(__TURBOC__) || defined(__WATCOMC__) || defined(__MINGW32__) || defined(_MSC_VER)
//
// Already have a single-argument mkdir()
//
#else
//
// Provide a single-argument mkdir()
//
#define mkdir(a) mkdir(a, S_IRWXU | S_IRWXG | S_IRWXO)
#endif

Code taken from common.h of the cmdpack package (apt-get install cmdpack on Debian-like systems)

In practice, can C ++ be more portable? I understand that the standard C ++ library should offer all the necessary resources (considering C ++ 11) to program on any platform, not needing this kind of code. What is the programmer's real intention in doing this type of code and, mainly, how does C ++ solve (or try to solve) this type of situation?

    
asked by anonymous 09.10.2014 / 01:40

1 answer

6

Preprocessor

This is how you solve the different parts for each platform. I do not know how much you know the languages, but this is part of the preprocessor.

These preprocessor directives help translate the code even before compiling the program, so everything in a #if (which is not part of program building) of that platform is simply ignored even by the compiler. This translation is a simple way of modifying the code. Although it is part of the process of building the program and is done by the compiler it is not exactly the compilation process itself that handles this. Hence there are even some criticisms that its use can bring problems since this translation is "dumb", does not understand much what is doing. But it works fine when the programmer knows how to use it correctly and there is no universally better solution.

This makes compilation faster (it has less code to compile effectively), and of course the generated machine code gets smaller and faster, after all it does not have to decide at runtime whether that is relevant to that platform or not.

Probably the alternative would be to solve this at runtime in some way. It will not be good for most programs. At the very least the program will be bigger without need, after all there are things in it that will never be used on that platform on which it is running (remember that a program generated for one platform does not run on another platform). Depending on the technique used to select which code to run it may even slow down (theoretically, because no one will get there at this point).

This is true for C and for C ++. C ++ is essentially C with some extra features (I'll leave aside some irrelevant details for this question). These features can greatly reduce the need to use the preprocessor but in this case selecting the platform-specific code does not get any better.

Of course, you do not know this, but your question does not seem to make much sense. One of the reasons that you might think this is that you do not have much experience with both then understand:

  • Codes can be more or less portable.

    C ++ has more features. For this reason, it is more likely that they will be poorly used, making portability difficult. But this is code, programmer, not language problem.

  • Languages at most may have more or less facilities for separating code for different platforms (not the case of C ++ over C).

    In terms of having more features that help portability, even those that go beyond the preprocessor, if there is something more, it is very little. He would have to make creative use of some things. It will often bring more problems than benefits.

    You can use templates , for example, but it will hardly bring any real benefit. I do not see this being used in the codes I read (which is different from not existing).

  • Implementations of a language can serve more or less platforms.

    In practice it is often said that C ++ is slightly less portable because there are no good implementations for all platforms. But there is controversy as to whether this is an absolute truth.

  • Library is something other than language

    What C ++ certainly has the by default , especially C ++ 11, C ++ 14, C ++ 17, etc., are libraries that already treat different platforms for you. But it is not a feature of language. There you will see how these libraries were written and you will probably find a lot of #if there. That is, the advantage is that someone has already made it for you.

    Of course, in C you have libraries that handle platform differences and make the programmer's life easier, but very little is in the library that is considered the language standard.

Someone can come here and answer that it makes a lot of difference for portability to use C or C ++. This may be because I do not know any little known technique or because some people are so fond of using a particular feature that they prefer it more than any other. There are people who have so much hatred for using the preprocessor that they may prefer all the difficulties of the template , for it will be easier ( The best tool is one that you know and do well ).

Both have another problem that makes portability difficult between language versions or libraries or even implementations (compilers). Probably C ++ suffers more from this, but I think it's not quite what you're asking.

    
09.10.2014 / 02:37
JAX-RS Resource as Session Bean or CDI Managed Bean? Controlling Serial Port using Web Application