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