
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
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