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
> 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.)
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk