7

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?

Walt Sorensen
  • 381
  • 3
  • 14
JesseTG
  • 2,025
  • 1
  • 24
  • 48
  • 1
    People designing for embedded environments sometimes avoid the STL. Relevant: http://stackoverflow.com/questions/2226252/embedded-c-to-use-stl-or-not – cf- Apr 30 '16 at 05:30
  • @computerfreaker True, but I'm concerned about libraries that aim to *support* embedded systems, but not to the detriment of support desktop platforms or similar. – JesseTG Apr 30 '16 at 05:38
  • The games industry is worried about performance regressions caused by heap allocation. They often avoid standard library usage. And we're talking here about tiny overheads like the one allocation in shared pointer for the ref count .. – Alexander Oh Apr 30 '16 at 07:34
  • It is mostly not very difficult to port the stl partly for a specific target. E.g. for avr 8 bit it can be done with a few lines of code for the g++ stl implementation. Using std::vector here is stupied but std::tuple std::array and all the MTP stuff like std::enable_if makes g++ on 8 bit devices powerful! Using std::string is working but it makes only sense if you really! need the overhead :-) – Klaus Apr 30 '16 at 09:47
  • This is often [NIH](https://en.wikipedia.org/wiki/Not_invented_here). – Pete Becker Apr 30 '16 at 11:29

3 Answers3

5

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.

Sam
  • 3,320
  • 1
  • 17
  • 22
1

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.

rems4e
  • 3,112
  • 1
  • 17
  • 24
benzeno
  • 661
  • 1
  • 6
  • 13
-3

The Simple Answer is, when you choose not to include STL packages.

With most IDE's if your project has no #include <package_name> items that are calling to the STL, then the STL is not included at compile time.

Although there may be cases where you have to specifically exclude STL through the IDE/compiler

One of the big reasons to avoid the STL is to reduce the final compiled file size.

Walt Sorensen
  • 381
  • 3
  • 14
  • 1
    I'm asking about specific C++ environments (compilers, OSes, hardware, etc.) for which there's no standard library (e.g. "x version of gcc for the Nintendo 3DS"). – JesseTG Apr 30 '16 at 06:10