Den 30-01-2011 17:55, Domagoj Saric skrev:
"Thorsten Ottosen" <nesotto@cs.aau.dk> wrote in message news:4D3F6599.3090108@cs.aau.dk...
Den 26-01-2011 00:07, Domagoj Saric skrev:
Nice. It would be useful if it could do something similar for non-POD types, i.e. it would take a functor in the constructor which it would then 'walk' through the N entries and let it in-place construct them (to avoid the usual default construction then assignment procedure)...
well, you can just do that post-construction wise. No need for another constructor.
How would you do that in an exception-safe way (you need to correctly 'roll-back'/unwind the construction if any of the constructors fail...)?
Not that hard, just do some cleanup in the catch-clause.
That would be ugh-ly... It would be akin to something like expecting users to manually predestruct a std::string before assigning a new one to it...And wouldn't work anyway...for example what would happen in the auto_buffer destructor in this case: { boost:.auto_buffer<std::string, N> buffer( n, boost::dont_initialize ); throw std::exception(); } how would it know how many (if any) of the N std::strings it holds have been constructed and need to be destroyed?
And, regardless of the above, if it is a common task why not provide it in the library?
Could be. We still have algorithms like std::uninitalized_copy() for this case.
Futhermore, you may use
buffer.unchecked_push_back( x );
to avoid code that checks for a full buffer and subsequent expansion.
AFAICT there is no ('unchecked') resize equivalent...
unitialised_resize() ?
Is this also 'unchecked'?
no, IIRC.
Then it is not an unchecked_push_back() equivalent...
I agree unchecked_resize() should be added. -Thorsten