C ++: is there "magically"? always?

Question

As a C ++ entry level programmer, I noticed that no matter which IDE / compiler you use, you do not need to explicitly enable stl (the standard template library). Does this mean that I can rely on stl to be "always available"?

I mean, if I want to use std::cout , for example, I just include the iostream part in stl:

 #include <iostream> 

... and you don’t need to do something like #include <std> in the first place to continue something like:

 std::cout << "Hello world!" << std::endl; 

Also: can I rely on the sequence for stl? Does any stl function / method always behave the same? Or are there any changes between C ++ versions, operating systems or compilers?

I ask about this because sometimes other libraries can be painful when you are not aware of some traps. For example, Eigen (for material with linear algebra) was very difficult for me to achieve this, and I noticed a change in behavior between some releases ...

Answer 1

Yes, despite special discounts on standalone implementations that are allowed to provide only a subset, the C ++ standard library should come with every C ++ compiler, as it is part of the language specification. (What started as an extension for C ++ was originally called the standard template library, but now the best term is the standard C ++ library.)

The C ++ Standard Library is very well specified - you always need to include various header files to add standard library components. The headers you need do not change from compiler to compiler. In this regard, it is independent of the machine.

As the standard develops, the philosophy is to minimize the compatibility gap, but there were some: for example. overriding the auto keyword in C ++ 11 and abandoning std :: auto_ptr from this standard and beyond.

Most components are actually in the reserved std namespace - some functions are not for obsolete reasons. Finally, it is better to use std :: explicitly, rather than contributing the entire std namespace to the global using

 using namespace std; 

otherwise, you render your code vulnerable to namespace ambiguity.

Answer 2

Almost all C ++ compilers will ship with the standard C ++ library. They are called "hosted implementations." A library is well defined, and although it is growing, it rarely changes in ways that could break old code. This is the main goal of the standardization committee to maintain backward compatibility.

The standard also allows for "standalone implementations" that come with a very stripped down library, fully implemented in headers. You may encounter this when developing code for an embedded system, especially if this system does not have a basic operating system. They are rare, but they exist. (Section 7.6.1.13 talks about stand-alone implementations.)

Answer 3

Does this mean that I can rely on stl to be "always available"?

Yes, the standard library is part of the C ++ language. Thus, it is guaranteed that it will be "always available" with any C ++ compiler.

Is it possible to rely on the sequence for STL?

Yes, definitely. The C ++ Standard Library is the distilled effort of brilliant minds who have suffered for us, so that we do not have to reinvent the wheel or trust third-party libraries each time that could eventually drown you from behind. It is as general as possible and as general as possible.

Does every STL function / method always behave the same? Or are there any changes between C ++ versions, operating systems or compilers?

The C ++ standard library is described in C ++ standard . Thus, it is guaranteed that among C ++ compatible compilers, the functionality of the C ++ standard library achieves the same behavior, that is, standard behavior. There are changes between C ++ releases (e.g. additional features), but backward compatibility is guaranteed. That is, code written in C ++ 98 can still be compiled using modern C ++ compilers that support C ++ 17 (with a few exceptions).

I ask about this because sometimes some libraries can be painful when you are not aware of some traps.

As a rule, it is recommended to use the standard C ++ library, wherever you are, and to avoid third-party libraries that offer the same functions as standard libraries. This is due to many reasons, some of which are:

• Readability : The C ++ Standard Library is a lingua franca in C ++. That is, using the standard library, you make your code more readable, and you reduce the learning curve for others who will support your code.
• Stability : the standard library is extremely stable, using it, you make your code base more stable.
• Guaranteed lifespan support . A standard library will exist and be maintained as C ++ continues to exist.
• Interaction . The standard library is a cross platform.

Answer 4

All C ++ compilers come with some versions of the standard template library available to them. Different compilers will support different versions of the standards (e.g. C ++ 98, C ++ 11, C ++ 14, C ++ 17), but you can expect all of them to be sent with headers such as vector , iostream and etc. This is all for you! The standardization process is an attempt by many compiler providers to determine the functionality of these headers and make them available to the programmer in a standard way, that is, on each platform there is a compatible compiler for.

Answer 5

The standard template library is part of the standard. Therefore, it should be available for all standard compatible compilers, if you have a standard distributor implementation (more on this).

The standard template library is processed "specially" according to the literature for historical reasons, C ++ was "born" in 1983, but the first standard was not released until 1998.

The first implementation of STL was also in 1983, but for the ADA language. The first port for C ++ was not completed until 1992 by HP.

In 1993, it was proposed to be included in the ANSI standard and was adopted in 1994 after some changes.

This makes STL on stdlib the fork of the original STL.

In the early days, some people used STL only to reference the original HP library, later supported by SGI, while other people used STL to refer to a subset of containers on stdlib.

The external behavior of the STL should be “the same” for all implementations, but memory packaging may differ from one implementation to another.

Today, the original C ++ STL is no longer supported and talks about STL should refer to stdlib containers, although the standard itself does not use the abbreviation STL.

Finally, stdlib containers use a standard allocator to manage memory. In the Linux GCC provided by libstdC ++, for embedded systems you need to implement the standard distributor yourself, since you do not have an OS that manages memory for you.

This also applies to other functions that rely on system calls. std::cout will not be available on an open metal system unless you define an implementation for it.