Is there any magic in STL?

Question

Let me begin by explaining what I mean by “magic.” I will use two examples from Java:

• Each class inherits (directly or indirectly) the class Object .
• Operator overloading is not supported by Java, but the + operator is defined for String objects.

This means that it is not possible to implement the implementation of the Object and String classes in pure (*) Java. Now this is what I mean by “magic”: to implement these classes you will need special support from the compiler.

What I always liked about C ++ was that, as far as I know, there is no such “magic” in STL, i.e. can implement STL in pure C ++.

Now my question is: is this true? Or are there parts of the STL that cannot be implemented in pure C ++ and need some “magic” / special compiler support?

---

(*) With "clean", I mean without using any class libraries.

Answer 1

In other words, was anything done for the compiler to resolve the “special case” that the STL was supposed to work?

No.

All of this was implemented as "clean" C ++ code using template magic.

Some work has been done with compilers to improve the STL (I think of various optimizations), but otherwise, you could write the whole STL if you want. Some people did - STLPort is an implementation that did not have the support of any compiler manufacturer.

Answer 2

As gbjbaanb correctly says, STL can be implemented in simple C ++ without relying on any kind of magic compiler.

However, if you go to the STL source code for your compiler, you are likely to see code that is either not standard or that you should not write yourself.

STL can be fully implemented in standard C ++, but this does not mean that the compiler authors are not allowed to improve it sometimes, using extensions for the compiler. For example, they can embed non-standard code that provides better error messages or perhaps works with some flaws in their compiler, or perhaps includes special optimizations using additional functions of this particular compiler.

They also consistently use names that you are forbidden to use. For example, template parameters are usually referred to as _Type , which, starting with an underscore followed by a capital letter, are reserved for implementation. The standard library is allowed to use them, but we are not. Therefore, if you are going to write your own implementation of STL, you will have to make small changes, but this is not due to any magic, but simply to avoid name collisions between the standard library and user code.

Answer 3

As others have said, STL is implemented in pure standard C ++ 98. What has not been said is that the development of STL was parallel to the development of the C ++ template engine and to a large extent led to the inclusion of certain functions. I believe that the “Search for Dependent Arguments” (ADL, aka Koenig Lookup) , template template parameters, and default template arguments all came in C ++ to serve Stepanov’s STL development.

So, with STL, they transferred magic to the language itself. It's nice that the standards committee recognized that if these functions were useful for what would become a standard library, they could be useful for all of us!

Answer 4

If by STL you mean only part of the standard C ++ library template, then it is quite possible to implement it without any “magic”. Regardless of whether each particular implementation uses any “magic”, the other question is (there are parts of the STL where “magic” could help, but not necessarily).

Now, if you are talking about the entire C ++ standard library, it really has a bit of “magic”. A classic example would be the implementations ::operator new and ::operator delete implemented in the library. We often call them “overloaded” in the ordinary language, while formally they are removable. C ++ does not provide users with such functionality. User cannot write plug-in function.

Another example would be the offsetof macro (inherited from the C standard library). Although it is usually implemented in pure C, the popular implementation is actually illegal from a pedantic point of view (causes undefined behavior). I have not seen formally legal implementations of offsetof , so I'm not sure if they are even possible.

Another example would be (again, inherited from C) macros for working with variable arguments. Obviously, they cannot be implemented in pure C or C ++.

Answer 5

I am sure that some type_traits require compiler magic, for example has_trivial_constructor , has_virtual_destructor or is_pod .

Answer 6

std::initializer_list needs compiler support and cannot be redefined as another class (as far as I know), although I'm not sure what it counts, since it is in C ++ 0x.

Answer 7

C ++ 0x is going to standardize some de facto "magic" type traits.

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2984.htm

"Additional type types for C ++ 0x"

This contains a few notes, such as "XXXX is considered to require compiler support."

see also

http://gcc.gnu.org/onlinedocs/gcc-4.3.2/gcc/Type-Traits.html#Type-Traits

http://msdn.microsoft.com/en-us/library/ms177194(v=vs.80).aspx

Answer 8

As gbjbaanb correctly said, there is no magic in the STL implementation. It is written in pure C ++. You could implement it yourself, but were easily available as a library to make your life easier.

Answer 9

STL standard (standard template library). The standard defines requirements for STL implementations. In terms of use, there is no “magic”, no particular dependencies you have to take care of. It can be used on any major C ++ compilers on all platforms supported by these compilers.