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::vectorstd::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. -regards, Larry