On 4/16/07, Ion Gaztañaga <igaztanaga@gmail.com> 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