Re: [boost] Re: container design (Was: std::complex design (Was: N-Dimensional array))

From: Howard Hinnant (hinnant_at_[hidden])
Date: 2002-03-08 09:53:30

On Friday, March 8, 2002, at 08:31  AM, Toon Knapen wrote:

> On Friday 08 March 2002 13:46, you wrote:
>> ----- Original Message -----
>> From: "rwgk" <rwgk_at_[hidden]>
>>
>>> Without this back door only friend functions could use the
>>> mechanism that I just explained. I have no clue how the
>>> same effect could be achieved without violating the
>>> principle of encapsulation. Personally I have no problem
>>> with this pragmatic approach, but as I said, I am not going
>>> to argue the case with respect to a standard container.
>>
>> Here's a thought:
>>
>> Suppose we could hand vector<T> a chunk of memory and tell it "this
>> contains memory for N instances of T, the first M of which have been
>> constructed", and have it use that memory?
>>
> Yesterday I also posted something similar to solve it, in the short 
> term,
> with soth like :
> double* uninitialised = new double[ ncomplexes * 2 ]
> std::vector< complex< double > > v(ncomplexes, uninitialised);
>
> the vector constructor will still need to cast the array to an array of
> complexes (not that this also relies on the discussed layout of a 
> complex)
>
> But once layout and initialisation is covered, what about copying for
> intstance. If I std::copy( complex1_begin, complex1_end, 
> complex2_begin),
> is the compiler able to use memcpy (AFAIK it will call the assignment 
> op for
> every one of them)

Who owns the memory?  vector?  client?  If vector, how does vector free 
the memory?   With allocator::deallocate()?  If client, we've probably 
just bumped the vector overhead by 33% to hold a flag saying who owns 
the memory.

What problem does this solve that vector<T>(n, uninitialized_flag) 
doesn't solve?

-Howard