5 ms·

Now this has me a bit confused, why no love for STL ? I wish Linus had added more detail. Is the complaint that the binaries are too big (not quite, if you str

by srean 15y ago

Now this has me a bit confused, why no love for STL ? I wish Linus had added more detail. Is the complaint that the binaries are too big (not quite, if you strip them of the unnecessary symbols) ? or is it that it can be a tedium to go over the reams of error messages that compilers spit out when things go wrong. The second point I am willing to concede, it requires you to read messages inside out, which lisp does train you into doing. Or is the complaint about something else entirely ? Something else that I hear often that bothers me is the claim that STL adds huge runtime overhead. Maybe it was true with the old compilers, but with the current ones, GCC4.5, Intel its not true at least not in a noticeable way. The whole point of STL was the ability to generate optimized code. I have actually verified that the iterator based access patterns on vectors for instance gets optimized away into simple pointer based indexing into memory blocks. I like STL, in fact I will go so far and admit that I will not code in C++ unless I sense that I will benefit from STL and or templates. Though STL gets used often merely as a container library I think you get more out of it when you use its algorithms. I really like it that I do not have to write for loops (and potentially get the indexing wrong). If one squints the right way, it has map, reduce, filter and map-reduce all built in (transform, accumulate, innerproduct) though I miss a vararg zip function. An un-ignorable side benefit to using the STL primitives is that if a parallelized version comes along the way, you get a fairly painless way to make your code parallel. You do have force some of your snippets to be sequential to account for the fact that there is not enough work to parallelize. This is the direction were GCC's STL library is headed with its parallel_mode. http://gcc.gnu.org/onlinedocs/libstdc++/manual/parallel_mode.html http://gcc.gnu.org/onlinedocs/libstdc++/manual/parallel_mode... @cube Appreciate your comment. For writing kernels and VMs I gladly buy your argument, to add to what you said there is the ABI mess.

cube13 15y ago
There are a few problems with STL when writing kernel or API code. One is due to it's completely generalized nature. Since it's not heavily optimized for either speed or memory use, it tends to perform rather poorly in both areas. Not that acceptable when you're making kernel code, where it's often better to write optimized data structures for the problem at hand rather than just relying on templated code. In that situation, where performance is king, you want to tailor your data structures to fix your problems, rather than the other way around. STLPort and Boost fare better in this respect, but STLPort in particular leads to the second problem. The second problem is due to the std namespace. Using the std namespace means things that link in your code, even dynamically, cannot necessarily use other STL implementations. So if the kernel uses STLPort, that means that every other program written on top of the kernel needs to use it.
- wmf 15y ago
  So if the kernel uses STLPort, that means that every other program written on top of the kernel needs to use it. The Linux module API/ABI has worse problems than that already.
  - neohaven 15y ago
    Oh sure, "We have problem A, let's add problem B, while solving nothing." Please explain to me how this would fix anything? ;)
huhtenberg 15y ago
STL containers are essentially the opposite of what's used in many C programs, Linux kernel included. In C, in order to string several data items into a collection one would add a container-specific control element to the data item, and then feed a pointer to this element to the container code. Container sees only these elements, and nothing else. On one hand, accessing actual data item obviously requires casting and offsetof'ing, but on other hand it allows placing the same data item into multiple containers, and this is great. Think - multiple key-value stores, each keyed by a different field in data item. Generally speaking, the paradigm is that there are THE data items, and there are miscellaneous supporting structures that help organizing tehm. In C++, container is the ultimate destination for a piece of data. It is the owner of a data item. If I want a piece of data to be on a list and in a tree, I must decide which will be the "primary" container. Alternatively, I can store a pointer to an item, but this effectively negates safety benefits of STL containers. [0] http://kernelnewbies.org/FAQ/LinkedLists http://kernelnewbies.org/FAQ/LinkedLists
- sc68cal 15y ago
  That was a fantastic link. I love the kernelnewbies site.
- chancho 15y ago
  Boost.Intrusive does this, without the casting or offsetof'ing. http://www.boost.org/doc/libs/1_47_0/doc/html/intrusive.html http://www.boost.org/doc/libs/1_47_0/doc/html/intrusive.html Not that most of what you said isn't true. Just picking the nit that 'the container owns the data' holds only for the STL, not C++ in general.
- helmut_hed 15y ago
  I don't see this. You can have a container of pointers in C++ just as you can in C. No special ownership semantics is assumed, nor do you have to decide which is the "owner" any more than you do in C. Or the problem is the same, at any rate. Plus you're not constantly casting <void*> to things. You can have a container of smart pointers, too, if you really don't want to think about ownership.
groby_b 15y ago
Instead of writing an endless reply, I suggest you read the EASTL white paper: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2271.html http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n227... Essentially, listing all the hoops EA went through to have a useable STL for games. (And for programming purposes, AAA console games and OS kernels are pretty close)
- acqq 15y ago
  And also what Bloomberg saw C++ lacking: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1850.pdf http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n185... I'd still like to see how both these papers influenced last C++ standard at the end (I admit I didn't try to follow) -- is there finally a "standard" way to do all that?
  - cageface 15y ago
    Notice the dates on these papers though. 2005 and 2007 are a long time ago in C++ compiler land. I'm using the STL in very low latency DSP code with zero problems. You have to make sure you don't allocate memory in realtime callbacks but that's just as true of malloc.
    - acqq 15y ago
      Dates are irrelevant if you really want to control where something gets allocated. Last time I've checked there weren't the level of control described in the linked articles in "standard" C++. If you know how I can achieve it, please write, but please don't dismiss my need with "you wouldn't notice everything is fast enough it's 2012."
      - deleted 15y ago
        [deleted]
      - cageface 15y ago
        Can you name any language that does give you that level of control in its standard collection classes? At least C++ gives you the power to define your own if you really need to.
jlarocco 15y ago
The STL is a huge leap over C, but it could be so much better. On one hand, it's not particularly good for really low level coding, as other people have explained. But on the other hand, it's not really convenient for higher level coding, either. To see what I mean, compare the interfaces of std::string [1] and Qt's QString [2]. Common, simple things like converting numeric data to/from string, splitting into substrings, and find/replace are a PITA in the STL. The containers are nice, but even they could use some work. I know it'd never happen, but I think the non-GUI parts of Qt would make a really nice standard library. [1] http://www.cplusplus.com/reference/string/string/ http://www.cplusplus.com/reference/string/string/ [2] http://developer.qt.nokia.com/doc/qt-4.8/qstring.html http://developer.qt.nokia.com/doc/qt-4.8/qstring.html
- tspiteri 15y ago
  I think that std::string does not support conversions as part of the class because those operations do not need direct access to the internal data of the string class. They could be written as helper functions (as opposed to member functions) easily without loss in efficiency. Member functions are used when they need direct access to the private fields. For example, C++11 has a new group of functions, std::to_string(...), and their counterparts std::sto*(...), which are not member functions [1]. [1] http://en.cppreference.com/w/cpp/string/basic_string http://en.cppreference.com/w/cpp/string/basic_string

by srean 15y ago

cube13 15y ago

There are a few problems with STL when writing kernel or API code. One is due to it's completely generalized nature. Since it's not heavily optimized for either speed or memory use, it tends to perform rather poorly in both areas. Not that acceptable when you're making kernel code, where it's often better to write optimized data structures for the problem at hand rather than just relying on templated code. In that situation, where performance is king, you want to tailor your data structures to fix your problems, rather than the other way around. STLPort and Boost fare better in this respect, but STLPort in particular leads to the second problem. The second problem is due to the std namespace. Using the std namespace means things that link in your code, even dynamically, cannot necessarily use other STL implementations. So if the kernel uses STLPort, that means that every other program written on top of the kernel needs to use it.

wmf 15y ago
So if the kernel uses STLPort, that means that every other program written on top of the kernel needs to use it. The Linux module API/ABI has worse problems than that already.
- neohaven 15y ago
  Oh sure, "We have problem A, let's add problem B, while solving nothing." Please explain to me how this would fix anything? ;)

huhtenberg 15y ago

STL containers are essentially the opposite of what's used in many C programs, Linux kernel included. In C, in order to string several data items into a collection one would add a container-specific control element to the data item, and then feed a pointer to this element to the container code. Container sees only these elements, and nothing else. On one hand, accessing actual data item obviously requires casting and offsetof'ing, but on other hand it allows placing the same data item into multiple containers, and this is great. Think - multiple key-value stores, each keyed by a different field in data item. Generally speaking, the paradigm is that there are THE data items, and there are miscellaneous supporting structures that help organizing tehm. In C++, container is the ultimate destination for a piece of data. It is the owner of a data item. If I want a piece of data to be on a list and in a tree, I must decide which will be the "primary" container. Alternatively, I can store a pointer to an item, but this effectively negates safety benefits of STL containers. [0] http://kernelnewbies.org/FAQ/LinkedLists http://kernelnewbies.org/FAQ/LinkedLists

sc68cal 15y ago
That was a fantastic link. I love the kernelnewbies site.
chancho 15y ago
Boost.Intrusive does this, without the casting or offsetof'ing. http://www.boost.org/doc/libs/1_47_0/doc/html/intrusive.html http://www.boost.org/doc/libs/1_47_0/doc/html/intrusive.html Not that most of what you said isn't true. Just picking the nit that 'the container owns the data' holds only for the STL, not C++ in general.
helmut_hed 15y ago
I don't see this. You can have a container of pointers in C++ just as you can in C. No special ownership semantics is assumed, nor do you have to decide which is the "owner" any more than you do in C. Or the problem is the same, at any rate. Plus you're not constantly casting <void*> to things. You can have a container of smart pointers, too, if you really don't want to think about ownership.

groby_b 15y ago

Instead of writing an endless reply, I suggest you read the EASTL white paper: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2271.html http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n227... Essentially, listing all the hoops EA went through to have a useable STL for games. (And for programming purposes, AAA console games and OS kernels are pretty close)

acqq 15y ago
And also what Bloomberg saw C++ lacking: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1850.pdf http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n185... I'd still like to see how both these papers influenced last C++ standard at the end (I admit I didn't try to follow) -- is there finally a "standard" way to do all that?
- cageface 15y ago
  Notice the dates on these papers though. 2005 and 2007 are a long time ago in C++ compiler land. I'm using the STL in very low latency DSP code with zero problems. You have to make sure you don't allocate memory in realtime callbacks but that's just as true of malloc.
  - acqq 15y ago
    Dates are irrelevant if you really want to control where something gets allocated. Last time I've checked there weren't the level of control described in the linked articles in "standard" C++. If you know how I can achieve it, please write, but please don't dismiss my need with "you wouldn't notice everything is fast enough it's 2012."
    - deleted 15y ago
      [deleted]
    - cageface 15y ago
      Can you name any language that does give you that level of control in its standard collection classes? At least C++ gives you the power to define your own if you really need to.

jlarocco 15y ago

The STL is a huge leap over C, but it could be so much better. On one hand, it's not particularly good for really low level coding, as other people have explained. But on the other hand, it's not really convenient for higher level coding, either. To see what I mean, compare the interfaces of std::string [1] and Qt's QString [2]. Common, simple things like converting numeric data to/from string, splitting into substrings, and find/replace are a PITA in the STL. The containers are nice, but even they could use some work. I know it'd never happen, but I think the non-GUI parts of Qt would make a really nice standard library. [1] http://www.cplusplus.com/reference/string/string/ http://www.cplusplus.com/reference/string/string/ [2] http://developer.qt.nokia.com/doc/qt-4.8/qstring.html http://developer.qt.nokia.com/doc/qt-4.8/qstring.html

tspiteri 15y ago
I think that std::string does not support conversions as part of the class because those operations do not need direct access to the internal data of the string class. They could be written as helper functions (as opposed to member functions) easily without loss in efficiency. Member functions are used when they need direct access to the private fields. For example, C++11 has a new group of functions, std::to_string(...), and their counterparts std::sto*(...), which are not member functions [1]. [1] http://en.cppreference.com/w/cpp/string/basic_string http://en.cppreference.com/w/cpp/string/basic_string