Boost logo

Boost :

From: E. Gladyshev (egladysh_at_[hidden])
Date: 2003-10-10 11:36:07

--- Douglas Paul Gregor <gregod_at_[hidden]> wrote:
> >
> > It says an object *has* storage duration.
> >
> > My interpretation was that by "reusing" the storage
> > you end object's storage duration by ending its storage
> > duration you end the object's lifetime.
> Okay, but is there any evidence of that? There is evidence to the
> contrary:
> 3.7 defines the 3 types of storage duration: static, automatic, and
> dynamic. Static storage duration is equivalent to the duration of the
> program (3.7.1/1), automatic storage duration lasts until the block in
> which the object was created exits (3.7.2/1), and dynamic storage duration
> lasts from new to delete (somewhere in 3.7.3; I'm lazy).
> There is nothing in there that says or hints that storage duration is
> affected by reusing storage, yet there are specific descriptions of what
> the storage duration is. "Reusing storage" only comes into play when we
> talk about lifetimes (in fact, the substring "reus" only shows up in
> section 3.8).
> Look at the example in 3.8/5. At the line:
> new (this) D2;
> This reuses the storage at *this, but the storage duration of the memory
> at *this is dynamic (because it was allocated with malloc), so it does not
> expire until that memory is freed. If reusing the memory at *this ended
> the storage duration, it would contradict 3.7.3.

I agree with all that. My assumption about
"reusing" storage -> end object's storage duration
doesn't have a ground in the standard.

I thought of it as a way to deduce what
"reusing" storage really mean.

reusing (?) = end of object's storage duration (1.7.1) -> end lifetime


reusing (?) -> end lifetime

But you are right there is nothing to support it.

In the following code:

struct my_type
   int x;
   int y;

my_type m;

new( &m.x ) int[2];

Are we reusing 'm' storage and ending its lifetime?


Do you Yahoo!?
The New Yahoo! Shopping - with improved product search

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