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: Stephan T. Lavavej (stl_at_[hidden])
Date: 2012-04-26 16:17:50

[Mathias Gaunard]
> Explicit destructor calls on memory that doesn't come from the free store?
> Sounds like there are potential strict aliasing problems there.

First, that would be perfectly cromulent on the stack (as long as you're using aligned_storage to ward off alignment demons).  According to my understanding, VC doesn't aggressively optimize based on the strict aliasing rules like GCC does, so I have a relatively poor understanding of the issues involved, but sufficient casting (in particular, static_cast to void * and then static_cast to T *) will ensure correctness.

Second, make_shared/allocate_shared dynamically allocate their control blocks, and then construct the object within the control block.  This happens even for implementations that store the object within a custom deleter within the control block.  (And it is very similar to how vector explicitly constructs and explicitly destroys elements.)

STL