Boost logo

Boost :

Subject: Re: [boost] [cpo-proposal] presentation of the idea
From: Larry Evans (cppljevans_at_[hidden])
Date: 2013-08-19 09:57:38

On 08/19/13 08:44, Thorsten Ottosen wrote:
> On 19-08-2013 15:10, Larry Evans wrote:
>> On 08/19/13 07:54, Larry Evans wrote:
>>> On 08/19/13 06:59, Thorsten Ottosen wrote:
>>>> cont.push_back<Derived>( x, y );
>>> Using a templated push_back, IIUC, would require some sort of
>>> container, such as std::vector<char> cont, which contains contigous
>>> storage, and the push_back should find the next location, i_aligned,
>>> in std::vector<char> which is at alignment, alignof(Derived).
>>> and would then push_back i_aligned chars, then further push_back
>>> sizeof(Derived) char's, the new inplace at cont.begin()+i_aligned.
>>> Does that make sense?
>> OOPS. If all those push_back's of a char causes the vector to be
>> resized in placed in a different location, then wouldn't that require
>> all the realignments for each element to be recalculated :(
>> Hmmm. Not if &cont[0] is stored at a max aligned location,
>> which I assume it would be since the storage would be created
>> on the heap with new[] which, according to the c++ standard
>> ( can't remember which page or section), returns a maximally
>> aligned storage location.
> Exactly. The relative locations should stay the same, only the start
> address would change.
>> And since the start of cont
>> is maximally aligned, any offsets in that cont with a given
>> alignment would have the same alignment when moved, IIUC.
> Yes, at this level it is nice to take advantage of the memcopying built
> into vector<char>.
> I guess the above means that the idea of letting push_back return the
> address of the object is not going to work /unless no reallocation
> happens/. This may be too fragile, so maybe we should embed a singly
> linked list directly together with the DerivedX instances and update it
> on copying. This seems to contradict the use of memcpy. Hm.
> Maybe we can avoid storing the linked list al together. Forward
> iteration would find the next element by asking the current element by
> its size and by computing i_aligned (somehow). Maybe that's the way to go.
OR, by having the container also contain a
  std::vector<std::size_t> offsets;//offsets of values stored.
as well as:
  std::vector<char> storage;//for storing values at offsets.

This would trade space for time, but it would also allow random access.


Boost list run by bdawes at, gregod at, cpdaniel at, john at