[FoRK] C++11 / STL, Re: Raspberry Pi + Qt5 + OpenGL = awesome

J. Andrew Rogers andrew at jarbox.org
Sat Apr 13 01:20:41 PDT 2013


On Apr 12, 2013, at 7:00 PM, Stephen Williams <sdw at lig.net> wrote:
> 
> A) I don't see how that's possible besides return value optimization.  B) Move semantics (and by implication rvalue references) solve the main performance problem with C++ and template libraries, extra temporary objects created all over, so I don't see how it is a micro-optimization.


There were other ways to do it and consequently it usually amounted to some extra stack shuffling that disappeared with various optimizations like RVO. It is not obligatory to write naive C++ if you are comfortable with more sophisticated forms. 

Move semantics are an optimization only if you were not bothering to do any optimization in the first place. In that sense, it improves performance for people that do not care about performance. For people that care about performance this was accounted for long ago. A compiler tweak that only benefits people that make no effort to write high-performance code is not much of an argument for why C++11 improves performance for people that care about performance. It is a non sequitur.


> While I see how container allocators could be useful, and I've used that kind of mechanism sometimes, it isn't that helpful most of the time.


Allocators are used for both performance and memory management reasons. However, since most people that care about performance do not use the STL much, the first case is less common. And people that do not care about performance often do not have a problem using the default allocator.  

The two main use cases for them that I've seen in various code bases:

1) A bit of STL is being used in a context that manages its own memory. You see this quite a bit in server code.
2) It is used to do additional runtime integrity checking of code behavior that is otherwise vanilla STL.

I agree with you that it is not that helpful in that people that would be prone to using allocators are unlikely to use STL but that does not exactly support the argument you seem to be making.


> I have a hard time finding comments bout missing allocator features in current-version libraries.


It is easy to find; the link was posted on this very thread earlier and it showed up on the GCC site with a trivial google search:

http://gcc.gnu.org/onlinedocs/libstdc++/manual/status.html#status.iso.2011

"only vector and forward_list meet the requirements relating to allocator use and propagation"

I only know about it because these defects have manifested themselves in a real system, so it is not all that rare. We work around it now.





More information about the FoRK mailing list