Re: [boost] [pool] future directions

From: Michael Gopshtein (mgopshtein_at_[hidden])
Date: 2007-05-10 00:09:26

"Andrey Semashev" <andysem_at_[hidden]> wrote in message 
news:135894700.20070510002632_at_mail.ru...
> Hello Michael,
>
> Thursday, May 10, 2007, 12:13:18 AM, you wrote:
>
>> "David Abrahams" <dave_at_[hidden]> wrote in message
>> news:87lkfyklpu.fsf_at_grogan.peloton...
>>>
>>> on Tue May 08 2007, "Michael Gopshtein" <mgopshtein-AT-gmail.com> wrote:
>>>
>>>> "Atry" <pop.atry_at_[hidden]> wrote in message
>>>> news:fd8b80680705080147t5c561dd8l9fc0ee8ede2120c7_at_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_at_[hidden]
>
> _______________________________________________
> Unsubscribe & other changes: 
> http://lists.boost.org/mailman/listinfo.cgi/boost
>