|
Boost : |
Subject: Re: [boost] Stack-based vector container
From: Thorsten Ottosen (nesotto_at_[hidden])
Date: 2011-01-30 15:20:06
Den 30-01-2011 17:55, Domagoj Saric skrev:
>
> "Thorsten Ottosen" <nesotto_at_[hidden]> wrote in message
> news:4D3F6599.3090108_at_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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk