Boost logo

Boost :

Subject: Re: [boost] [cpo-proposal] presentation of the idea
From: Larry Evans (cppljevans_at_[hidden])
Date: 2013-08-22 23:32:17


On 08/22/13 21:54, Ben Pope wrote:
> On 23/08/13 00:27, Larry Evans wrote:
>> On 08/22/13 10:38, Thorsten Ottosen wrote:
>> [snip]
>>>
>>>> OTOH, if only offsets were used, then wouldn't simply using
>>>> the vector<char>::swap work?
>>>
>>> Doesn't that have the same problems as memcpy'ing? That is, if we don't
>>> call the constructor, we don't get the implicit stuff inside the
>>> classes properly constructed.
>>
>> OK. Maybe so. I was still under the impression that the only
>> problem with simply copying the old std::vector<char>::data() to
>> a new std::vector<char>::data() is that this could copy the
>> raw pointers verbatim which would mean those raw pointers
>> in the new std::vector<char>::data() would point somewhere
>> still in the old std::vector<char>::data(), which would be
>> invalid after the resize. OTOH, with offsets instead of
>> raw pointers, the offsets would be w.r.t. the
>> existing std::vector<char>::data(); hence, would still be
>> valid since offsets would remain invariant.
>
> But how can you be sure an arbitrary non-POD object in the vector
> doesn't hold a pointer to itself?

Raw pointers would be outlawed by the class' documentation.
Instead, offsets would be used. In the case of container[i]
containing a pointer to itself, this would be implemented
as just something like container_offset_ptr(i). Now, as mentioned
in the post you responded to, there's the boost::offset_ptr:

http://www.boost.org/doc/html/interprocess/offset_ptr.html

which would simply contain a zero offset representing
a pointer to self. This is a much more elegant solution,
AFAICT, than using offsets in the whole container.

>
> Also, this problem has just been found in Folly fbvector:
> https://github.com/facebook/folly/issues/35
>

That doesn't use boost::offset_ptr. Could that problem
be solved using boost::offset_ptr?

-Larry


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk