"Andrey Semashev" <andysem@mail.ru> wrote in message news:135894700.20070510002632@mail.ru...
Hello Michael,
Thursday, May 10, 2007, 12:13:18 AM, you wrote:
"David Abrahams" <dave@boost-consulting.com> wrote in message news:87lkfyklpu.fsf@grogan.peloton...
on Tue May 08 2007, "Michael Gopshtein" <mgopshtein-AT-gmail.com> wrote:
"Atry" <pop.atry@gmail.com> wrote in message news:fd8b80680705080147t5c561dd8l9fc0ee8ede2120c7@mail.gmail.com...
Yes, "defragment" or other automation memory management is useful, but the existing code depends on native pointer would be very hard to work together, almost all C++ code need to recode if they want to use these futures.
I do "feel" that just moving object's memory is not safe, but can't find explanation why it will cause problems. Can you give an example of a class for which this will not work?
struct B;
struct A { A(B*p) : p(p) {} B* p; };
struct B : noncopyable { B() : px(new A(this)) {} auto_ptr<A> px; // invariant: px->p == this };
So, basically, it's any case where the object has pointers to it's internal members, right?
Are there other cases that the object can't be "moved" (it's more of a theoretical interest)?
In general, if there is anywhere in the Universe a pointer or reference to the object or its part, the object cannot be moved.
That I understand, but in current context I'm talking about internal members only - assuming that all external classes access the "moving" class though special wrapper (and not directly by pointer), which is also updated.
Best regards, Andrey mailto:andysem@mail.ru
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost