Re: [boost] [shared_ptr] dangerous implementation of move constructor

From: Felipe Magno de Almeida (felipe.m.almeida_at_[hidden])
Date: 2007-04-16 14:34:55

On 4/16/07, Ion Gaztañaga <igaztanaga_at_[hidden]> wrote:
>
> [snip Ion arguments]

Hi Ion,

> For objects that have no such default-state, and have no resource
> reassignment functions (like reset() or similar) there is no problem
> because there is no interface to reuse the object. For objects that
> don't have default-constructor but have resource reassignment functions,
> the state might be undefined, but I would require object reuse
> capability. In any case, you need to internally maintain the "moved"
> state so that the destructor does not crash the program. Since we have
> to pay some price (the zombie state, if you want to call it), let's take
> something in return.

You seem to have arguments for both sides, undefined and usable
object. I believe for most  we want that move-constructors imply in
almost-zero overhead, after all which is the benefit of moving a
temporary if it has significant overhead?
You have written a lot of allocators for the shmem library, and you
probably had to workaround the many copies that the standard allows.
Wouldnt it be better to have:

std::list<std::vector<...> > foo();

Have almost 0 overhead instead of guaranteed usability of moved objects?
IMHO, have assignment and destruction guaranteed to work on a moved
object is guarantee enough. You seem to be proposing creating a new
move-constructor, which I believe is now too late and a little bit
more complex than needed. A simple moving + assignment is enough to
have the object usable again.
I would support, though, better assertions inside shared_ptr for using
a moved shared_ptr. That way we have the better of two worlds.

> My 2 cents,
>
> Ion

Best regards,
-- 
Felipe Magno de Almeida