Re: [boost] [cpo-proposal] presentation of the idea

Subject: Re: [boost] [cpo-proposal] presentation of the idea
From: Larry Evans (cppljevans_at_[hidden])
Date: 2013-08-20 07:55:44

On 08/20/13 04:23, Thorsten Ottosen wrote:
> On 20-08-2013 11:04, Rob Stewart wrote:
>> On Aug 19, 2013, at 9:44 AM, Thorsten Ottosen
>> <thorsten.ottosen_at_[hidden]> wrote:
> 
>>> Yes, at this level it is nice to take advantage of the memcopying
>>> built into vector<char>.
>>
>> Here's the problem. Replicating the bits of and object isn't the same
>> as copying it. Many classes store a this pointer or rely on a data
>> member address as a unique key, etc. Copy constructors must run.

Good catch. Thanks Rob.

> 
> OK. :-) I was waiting for an expert to join the discussion.
> 
>> If the container manages the reallocations by noticing when it is
>> about to occur, creates a new vector with greater capacity, clones
>> each element into the new vector, destroys the elements in the old
>> vector, then swaps the two vectors, it can work.
> 
> Yeah, ok. I guess there will a need for one or two virtual functions
> in a base class after all. Copy-construction is one way,
> move-construction probably better.
> 
>> I should think a deque would be better as it doesn't require all of
>> that work.
> 
> Well, if we had a deque with better control over the chuck size, then
> perhaps. But I doubt it's a good idea.

I had thought about deque; however, I couldn't think of how
a deque<char> would work because the chuck size would have to
be large enough to handle the largest size of the elements
placed in the container.  Since, IIUC, that's not known until
the actual container.push_back<Field>(a_field) is run,
and can change each time container.push_back is called,
deque couldn't work.

I also did study briefly the segmented sequences idea
discussed in thread:

http://article.gmane.org/gmane.comp.lib.boost.devel/142262

However, I did not study long enough to see if it would solve
the problem :(

[snip]

-Larry