Den 26-01-2011 00:07, Domagoj Saric skrev:
"Thorsten Ottosen" <nesotto@cs.aau.dk> wrote in message
For one, the container will allow you to do
boost:.auto_buffer<T,N> buffer( n, boost::dont_initialize );
to make it avoid initialization.
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.
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.
...Perhaps it would be a 'happier' solution to go with only one option (policies/tags) or to replace both with a proxy 'unchecked' class...So that when you want 'unchecked' access you call the proxy getter and in effect get different semantics through an identical interface...This would also 'play better' with Boost.Range and <algorithms>...
How? Range algorithms use iterators and not much else.
boost::push_back( cont, range )
By calling/passing boost::push_back( cont.unchecked(), range ) or boost::push_back( cont.uninitialised(), range ) ;)
boost::push_back( cont, range )
does not call cont.push_back(), and is the preferred way compared to using copy().
Yes, it calls insert() which still benefits from 'unchecked' resizing...
so you want to save one if-statement in this rather expensive operation? If so, you can just use copy().
For example, if the buffer does not need to be expanded, then it is likely the compiler can determine that the capacity_ member is not used.
From my experience I'd consider that (highly) unlikely (if any resizing function is called)...
but why do you want to call a resizing operation? I assume in this case that the buffer is fixed after construction.
nor do I see how one can avoid it when we need to go for the heap in certain cases.
Exactly, that's why I asked for a no-heap policy...however now I think its better to model each of the different 'variants' with a separate type/template...
Seems like a big step. Let's see what the assembly analysis comes up with. In the mean time it would help if you could write some small use cases explaining which functions you want to call in the different scenarios (this would also make the discussion more concrete). -Thorsten