Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

What actively-used C++ environments lack support for (most, if not all) of the standard library? [closed]

Looking for specific C++ environments (compilers, OSes, hardware, etc.) for which there's no standard library (e.g. "x version of gcc for the Nintendo 3DS")

Some C++ libraries such as Box2D or TinyXML2 that aim to be uber-portable use very little of the standard library, if at all. I don't fully understand this approach, however. What actively-used C++ environments lack support for (most, if not all) of the standard library?

like image 578
JesseTG Avatar asked Apr 30 '16 05:04

JesseTG


Video Answer


2 Answers

C++ standard library support can vary between different compiler vendors and even between different versions of the same compiler. This is especially true on embedded systems and on the various consoles.

By "vary" I mean there can be bugs, features implemented differently, or even missing features. Android for example has a very minimal C++ standard library implementation.

There are many weird and wonderful C++ compilers out there; it's not just GCC and Visual Studio. Nintendo for example uses the Green Hills compiler.

So because of the variety of compilers out there, the best way to support a large number of them is to stick to only the features provided by the C standard library. Many portable libraries even avoid using more modern C++ features.

like image 180
Sam Avatar answered Oct 28 '22 05:10

Sam


The only environments that I can think of are freestanding ones (operating system and single process embedded programs). Of course, some developers actively avoid using the STL, but this is more a design decision than a lack of support in the environment. I believe the biggest hurdle in these constrained environments is exception support (which many STL functions throw). To get support for these one has to port a C++ ABI and unwind library (to do stack unwinding and goto to the catch statement). There is nothing stopping one from implementing these required bits, but it is more dependencies which obviously result in bloat just for basic support for something like linked lists. To port the ABI see the OSDEV wiki entry.

There are other dependencies for the newer C++ standards (C++11 onwards). I can imagine std::thread requires a threading implementation such as pthreads. std::chrono will probably need some intermediate layer implemented between it and C standard library time. There are probably more STL functionalities that require operating system support.

The Template part of STL is also quite important. Templates often increase final binary size quite substantially. In the case of a std::list for instance, std::list<MyClass1> and std::list<MyClass2> will result in the specialisation of two different containers. The code will look very similar but will be duplicated to handle their element type specifically. Other implementations of linked lists often use a void pointer to link nodes and then cast it to the appropriate class when required. In this way, there is one instantiated list class for ints, char *, MyClass1, etc. The increased binary size is often unacceptable in embedded environments, but it must be noted that it also becomes a problem when LibA implements LibA::LinkedList and LibB LibB::LinkedList.

The quality of implementations has become less of a problem these days. It is also helpful that GCC targets many architectures so that the new compiler standards are available (as above, you still need to port some functionalities of the STL). The oldest GCC I have used was GCC v4.3 or something like that for an embedded PowerPC device. That was released in 2010 and had full STL support.

In summary, the need for libraries with a very focused functionality set can still help, but in my opinion they decrease how many platforms your project targets if they provide functionalities which wrap OS-dependent behaviour. For raw data structure and algorithm support you can't go wrong. In the end, you have to target some subset of platforms. In C++11 I believe you target 99% of used desktop/server operating systems and 99% of embedded Linux devices. As highlighted in another answer, Android has been a problem but this page seems to highlight to get all the bits required to get a really modern environment.

like image 20
benzeno Avatar answered Oct 28 '22 06:10

benzeno