Re: [boost] Re: what happened to allocators in boost?

From: Peter Dimov (pdimov_at_[hidden])
Date: 2003-08-27 13:19:51

E. Gladyshev wrote:
> --- Gregory Colvin <gregory.colvin_at_[hidden]> wrote:
>
>>> Would not it be better to remove the Deleter from shared_ptr and
>>> always require to use 'new' just to be consistent
>>> and not to fool users? :)
>>
>> No, it would not.
>
> Why not? It is consistent with Peter's and David's view of
> Java-like memory policies.

No, it is not consistent with anyone's expressed view.

My Java-beats-C++ argument can be summarized as: Java the language does not
tolerate broken implementations, whereas C++ does; as a result, Java
implementations get fixed faster.

This of course has nothing to do with shared_ptr's Deleter. The Deleter
argument allows shared_ptr to adapt to different kinds of pointers. See the
Techniques page for details; I'll use a simple example for illustration
purposes:

class X;
X * create();
void destroy(X * px);

This is a hypothetical library interface. You call create() to get a X and
then you must call destroy() when finished. The Deleter feature allows you
to encapsulate the above as:

shared_ptr<X> px(create(), destroy);

Note that we are dealing with library _interfaces_ here.

This thread is not about library interfaces. Interfaces describe what a
library does. It is about implementation details: _how_ a library does it.
How does shared_ptr allocate memory? How does function<> allocate memory? Do
they allocate memory at all? The interface is not affected by these details;
in a perfect world the user should not need to worry about them either.

In the real world the library designer may need to compromise the design and
to let these implementation details show through. Key word: compromise. Make
it worse.