Re: smart pointer clarifications
On Aug 20, 4:26 am, "Phil Bouchard" <p...@fornux.com> wrote:
"mlimber" <mlim...@gmail.com> wrote in message
news:e81efb23-61bc-4b34-bc3f-b3e0c9ffb03f@x35g2000hsb.googlegroups.com...
[...]
Perhaps I'm missing something. Smart pointers generally take over
ownership AFTER allocation, e.g.:
tr1::shared_ptr<int> spi1( new int(42) );
tr1::shared_ptr<int> spi2( FactoryFunction() );
A shared_ptr's deleter can tell it how to do some special release
procedure, e.g.:
tr1::shared_ptr<FILE> file( fopen( "some.txt", "r" ), &fclose );
Why do allocators need to become aware of smart pointers?
Well the idea of having of defining an allocator is to centralized in one
class instanciation everything related to memory management. If the
allocator have to be explicitly shared between the container and the smar=
t
pointer itself then the idea becomes pointless. The allocator should b=
e
responsible for all types of deallocations, including smart pointers.
I still don't get it. Let's say you're designing std::vector, which
has an allocator template parameter. It doesn't matter if the user-
defined class or a smart pointer (as long as it has value semantics).
Given this code:
class C { */...*/ };
// ...
std::vector<C> v1( 10 );
std::vector< std::tr1::shared_ptr<C> > v2( 10 );
Under the hood, each of the latter two lines will use vector's
(default) allocator to grab memory for the 10 instances of the
contained type and then placement-new to construct the instances in
that memory. (Note that all the shared_ptr's pointees are null at this
point.) Why does the allocator care if it's making a C or a
shared_ptr<C>?
Cheers! --M