Boost logo

Boost :

From: David Abrahams (david.abrahams_at_[hidden])
Date: 2002-03-08 10:33:16


----- Original Message -----
From: "Howard Hinnant" <hinnant_at_[hidden]>
> On Friday, March 8, 2002, at 08:31 AM, Toon Knapen wrote:
>
> > On Friday 08 March 2002 13:46, you wrote:
> >>
> >> 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?

After the call, the vector.

> If vector, how does vector free
> the memory? With allocator::deallocate()?

Yes.

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

Using uninitialized_flag allows people to make vectors with broken
invariants, and the invariants stay broken for an arbitrary amount of
time. The memory adoption suggestion keeps the vector invariants intact,
assuming that the user doesn't lie to the vector when she tells it to
adopt (and that's just the usual danger that the user must not break her
end of the contract).

I think that's a big advantage, assuming that the other needs are met.

-Dave


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk