Boost logo

Boost :

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?


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