Re: [boost] Stack-based vector container

Subject: Re: [boost] Stack-based vector container
From: Thorsten Ottosen (nesotto_at_[hidden])
Date: 2011-01-25 19:06:49

Den 26-01-2011 00:07, Domagoj Saric skrev:
>
> "Thorsten Ottosen" <nesotto_at_[hidden]> 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