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: Mathias Gaunard (mathias.gaunard_at_[hidden])
Date: 2012-04-26 19:45:51

On 26/04/12 23:08, Peter Dimov wrote:
> Mathias Gaunard wrote:
>> On 26/04/12 22:08, Jeffrey Lee Hellrung, Jr. wrote:
>>
>> > Doesn't the same thing happen in boost::optional and boost::variant?
>>
>> Yes, their code is arguably ill-formed, but I'm sure some people claim
>> otherwise.
>
> No, it's not. Provide the standard text that, in your opinion, makes
> them ill-formed.

3.10/10.

If a program attempts to access the stored value of an object through a
glvalue of other than one of the following types the behavior is undefined:

— the dynamic type of the object,
— a cv-qualified version of the dynamic type of the object,
— a type similar (as defined in 4.4) to the dynamic type of the object,
— a type that is the signed or unsigned type corresponding to the 
dynamic type of the object,
— a type that is the signed or unsigned type corresponding to a 
cv-qualified version of the dynamic type
of the object,
— an aggregate or union type that includes one of the aforementioned 
types among its elements or non-
static data members (including, recursively, an element or non-static 
data member of a subaggregate
or contained union),
— a type that is a (possibly cv-qualified) base class type of the 
dynamic type of the object,
— a char or unsigned char type.

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.

The only mechanism that supports the necessary logic for optional and 
variant are the new unrestricted unions, where explicit destructor and 
placement new calls effectively change the active member of the union.