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]
> 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,
-- Felipe Magno de Almeida
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk