Re: [boost] [Smart Ptr] make_shared slower than shared_ptr(new) on VC++9 (and 10) with fix

Subject: Re: [boost] [Smart Ptr] make_shared slower than shared_ptr(new) on VC++9 (and 10) with fix
From: Dave Abrahams (dave_at_[hidden])
Date: 2012-04-28 22:42:39

on Sat Apr 28 2012, Mathias Gaunard <mathias.gaunard-AT-ens-lyon.org> wrote:

> On 27/04/12 01:59, Peter Dimov wrote:
>> Mathias Gaunard wrote:
>>
>>> I suppose you probably want to say that the type you're accessing the
>>> object with is actually the dynamic type of the object, but that idea
>>> is not supported anywhere in the standard.
>>
>> 3.8, object lifetime.
>
> In lack of a proper explanation, I will assume that your argument is
> that the array member lifetime has ended and you're re-using its
> storage to store an object of a different type.

That sounds about right.

> Is that what you meant?
>
> Assuming this is true (which I'm not entirely sure of, the fact that
> it is a subobject might be a problem), there still is 3.8/7 to
> consider, which does not allow you to re-use the storage for any other
> type if there is any reference to the original object.

I don't see anything that I can interpret as "if there is any reference
to the original object" in 3.8/7

But I read "is" to mean "exists" in your statement.  It's possible that
you meant "occurs"

> I don't see how the copy constructor of the class could avoid
> referring to the original object.

It needn't refer to the original sub-object, which is the thing whose
lifetime has ended and whose storage has been reused.

I'm pretty certain it's possible to implement optional while staying
strictly within the letter of the standard.  I'm also pretty certain
that the intent of the standard is to allow it... and intent trumps the
actual wording in matters like this.  However, to be sure of the intent
requires consulting with CWG, which I will do next.

-- 
Dave Abrahams
BoostPro Computing
http://www.boostpro.com