Finally, good STL replacement?

A quite interesting document for everyone who programs in C++:

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2271.html

I’m even tempted to switch to it when/if it becomes available.

This entry was posted in Programming. Bookmark the permalink.

2 Responses to Finally, good STL replacement?

  1. Johan says:

    I don’t know. On the one hand if they’ve implemented the full standard library as they claim, they should understand how to use it. At the same time I don’t get that impression from a number of their grievances with it. For example, how can an allocator not be made to take alignment into account when it is in fact a template argument, i.e. you can make it literally any type that you want as along as it implements the necessary functions.
    I don’t get their sorting examples either. Why are they trying to put a (heavy) computation in the constructor of predicates and why doesn’t the constructor take a const reference instead? I’m not saying they’re wrong, but it would be nice to see an explanation.
    Template based code does indeed rely heavily on inlining. Keeping in mind that members defined in a class definition are implicitly declared inline, which of course is different from actually being inlined by the compiler, this should not be an issue. I’m not sure that a poor (in this respect) compiler is a good excuse to redesign one of the most well-proven and above all flexible libraries in existence. That the compiler is an open source compiler shouldn’t be an argument for not getting it fixed.
    Finally, I don’t really see a typical multi-MB game executable requiring a GPU upgrade as being a lot more constrained than most embedded devices, a field where heavily templated C++ is used extremely successfully by some. Does financial analysis software eating millions and millions of transactions really handle data that is less expensive to construct or copy or are they just not using gcc?
    While the C++ standard library isn’t perfect and far from complete, tuning the STL portion of it to a particular compiler (version) is almost certainly not time well spent. It’s extremely unlikely that any change made to the STL is going to improve what it already does. Given it’s unrivaled extendability extending it is probably a much, much better idea.

  2. Ilfak Guilfanov says:

    Thanks for the detailed comment, Johan.
    It seems that all other factors are insignificant compared the fact that EASTL is not available for public. We can not take it into account if it stays so.
    In my initial excitement I thought that it would eventually become public but there are no signs of that.