>> I've worked a little bit with C++ using unboxed objects, that
>> is without introducing pointers (similar to boxing) in templates,
>> like list<figure> instead of list<figure*>, and passing them
>> as value in parameters, or returning them,
>> and it was far less efficient because there was lots of copy,
>> and you could not use then virtual method on them. So in the
>> end the C++ programmer I thing manually re-introduce boxing
>> when using STL if he wants good performance, and he can not really
>> rely either on the default copy/equal implementation provided
>> by those templates. So, yes STL makes it possible to do things,
>> but programmers don't want them, or only in very few cases where
>> one need extreme performance.
>
> The STL is extremely slow. If you want fast code in C++ then you  
> drop to the C
> subset. Alex Stepanov tried and failed to implement efficient  
> constructs in
> the STL. Furthermore, the memory consumption of his library is  
> awful. OCaml's
> GC is far more efficient with memory whilst permitting easy sharing.

I don't think that STL is generally slow. There are corner cases where  
you'd do
well to use a custom allocator or somesuch, but in methinks  
contemporary STL
implementations have performance on par with C.

If you code using STL in a way which copies data all around, it will  
be no slower
than doing all the copying in C. Otherwise known as comparing apples  
to apples.

Cheers, Kuba