[boost] Re: shifted_ptr<> w/ lock mechanism

From: Philippe A. Bouchard (philippeb_at_[hidden])
Date: 2003-01-29 23:23:57

"Andrei Alexandrescu" <andrewalex_at_[hidden]> wrote in message
news:b1a0uv$lju$1_at_main.gmane.org...

[...]

> My understanding is that shifted_ptr mandates allocating *your* objects
> inside *its* "doped memory" area by using placement new. (Phillippe,
please
> correct me if I'm wrong.)

No, it works exactly this way.  The reference count is allocated at the same
time the object is.  The returned pointer is shifted to the starting address
of the object in question.

> This slashes many good uses of smart pointers,
> which include, but are not limited to (damn, I feel I talk like a lawyer
> :o)): object factories (unless they use shfted_ptr from the get-go), the
> Template Method pattern (ditto), cross-DLL communication, object brokers
> (COM/CORBA), working nicely with other allocators. All these idioms
require
> you to grab a pointer to an object that was constructed elsewhere. If my
> understanding is correct, shifted_ptr is not able to do that, while
> shared_ptr is.

shifted_ptr only works with "shifted objects" allocated with placement
operator new (size_t, shifted_type const &).  In theory it would be possible
to displace operator delete (void *) to handle properly addresses not
pointing to the beginning of a block (hack); to implement this directly in a
compiler; etc.

> These are use cases that I personally find important, so, although there
> existed some precedent back in 1999, I did not consider using a custom
> allocator (that would allocate the object plus extra memory for
> bookkeeping) in mc++d. At any rate, anyone comparing shifted_ptr with
> shared_ptr should keep in mind that one has an apple flavor and the other
> an orange flavor.

Yes, exactly.  shared_ptr has its advantages and so is shifted_ptr.  I am
not a judge either.  I like shifted_ptr because the only cost involves the
placement operator new usage.

> It would be interesting to see how much the implementation of shifted_ptr
> is simplified if it's put into an Ownership policy of the Borg, er,
> loki::smart_ptr. I guess a lot. That would nicely let the users decide
> whether they can do with allocating objects with placement new and enjoy
> the additional performance. Of course, all that *after* fixing smart_ptr's
> buggy constructor :o).

That would be great, agreed.  But I thinly think it would require additional
policies...  @:)

Regards,

Philippe A. Bouchard