C++ Standard Library Portability

Question

I work on large scale, multi platform, real time networked applications. The projects I work on lack any real use of containers or the Standard Library in general, no smart pointers or really any "modern" C++ language features. Lots of raw dynamically allocated arrays are common place.

I would very much like to start using the Standard Library and some of the C++11 spec, however, there are many people also working on my projects that are against because "STL / C++11 isn't as portable, we take a risk using it". We do run software on a wide variety of embedded systems as well as fully fledged Ubuntu/Windows/Mac OS systems.

So, to my question; what are the actual issues of portability with concern to the Standard Library and C++11? Is it just a case of having g++ past a certain version? Are there some platforms that have no support? Are compiled libraries required and if so, are they difficult to obtain/compile? Has anyone had serious issues being burnt by non-portable pure C++?

Answer 1

Library support for the new C++11 Standard is pretty complete for either Visual C++ 2012, gcc >= 4.7 and Clang >= 3.1, apart from some concurrency stuff. Compiler support for all the individual language features is another matter. See this link for an up to date overview of supported C++11 features.

For an in-depth analysis of C++ in an embedded/real-time environment, Scott Meyers's presentation materials are really great. It discusses costs of virtual functions, exception handling and templates, and much more. In particular, you might want to look at his analysis of C++ features such as heap allocations, runtime type information and exceptions, which have indeterminate worst-case timing guarantees, which matter for real-time systems.

It's those kind of issues and not portability that should be your major concern (if you care about your granny's pacemaker...)

Answer 2

Any compiler for C++ should support some version of the standard library. The standard library is part of C++. Not supporting it means the compiler is not a C++ compiler. I would be very surprised if any of the compilers you're using at the moment don't portably support the C++03 standard library, so there's no excuse there. Of course, the compiler will have to be have been updated since 2003, but unless you're compiling for some archaic system that is only supported by an archaic compiler, you'll have no problems.

As for C++11, support is pretty good at the moment. Both GCC and MSVC have a large portion of the C++11 standard library supported already. Again, if you're using the latest versions of these compilers and they support the systems you want to compile for, then there's no reason you can't use the subset of the C++11 standard library that they support - which is almost all of it.

C++ without the standard library just isn't C++. The language and library features go hand in hand.

There are lists of supported C++11 library features for GCC's libstdc++ and MSVC 2012. I can't find anything similar for LLVM's libc++, but they do have a clang c++11 support page.

Answer 3

The people you are talking to are confusing several different issues. C++11 isn't really portable today. I don't think any compiler supports it 100% (although I could be wrong); you can get away with using large parts of it if (and only if) you limit yourself to the most recent compilers on two or three platforms (Windows and Linux, and probably Apple). While these are the most visible platforms, they represent but a small part of all machines. (If you're working on large scale networked applications, Solaris will probably be important, and Sun CC. Unless Sun have greatly changed since I last worked on it, that means that there are even parts of C++03 that you can't count on.)

The STL is a completely different issue. It depends partially on what you mean by the STL, but there is certainly no portability problem today in using std::vector. locale might be problematic on a very few compilers (it was with Sun CC—with both the Rogue Wave and the Stlport libraries), and some of the algorithms, but for the most part, you can pretty much count on all of C++03.

And in the end, what are the alternatives? If you don't have std::vector, you end up implementing something pretty much like it. If you're really worried about the presence of std::vector, wrap it in your own class—if ever it's not available (highly unlikely, unless you go back with a time machine), just reimplement it, exactly like we did in the pre-standard days.