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

From: Gregory Colvin (gregory.colvin_at_[hidden])
Date: 2003-08-28 15:40:44

On Thursday, Aug 28, 2003, at 10:46 America/Denver, E. Gladyshev wrote:
> --- Peter Dimov <pdimov_at_[hidden]> wrote:
>>
>> You can use all smart pointers except shared_ptr and shared_array as 
>> they do
>> not allocate any memory. In particular, intrusive_ptr is a good 
>> candidate if
>> memory is a concern as it has smaller memory footprint than 
>> shared_ptr.
>
> Thanks, I'll consider it next time.
> However if Boost doesn't have a clear memory management
> concept, how can I guarantee that the next time around,
> intrusive_ptr or something else in boost
> won't start allocating memory under the covers.
> It is perfectly legal in Boost.

Of course future releases of Boost are free to change in completely
arbitrary ways that break anything we want.  The same is true of
the C++ standard, operating system APIs, CPUs, and everything else.
So there are no guarantees that you can release a library today
and have it keep working with all future releases of Boost, C++,
etc.

Nonetheless, backwards compatibility matters, and Boost is no more
likely to change in ways that break your code than anything else.
And to the extent you remain active in Boost, you can help see to
it that such changes don't happen.

> How will I even know it, the documentation is completely
> ignorant on the memory issues.

Perhaps because you work with the authors of the documentation to
make it sure it says what needs saying?

>> You can also use Boost.Regex, it is completely allocator-enabled. ;-)
>
> I never said that I am a huge allocators fan but at least
> it seems that regex has one of the most consistent memory
> management concepts in the library. :)

And I have no objection myself to adding an allocator parameter
to the shared_ptr constructor, or to making some other change that
serves the purpose.  So if you need a change, why not just do it,
try it out, and submit a patch?

I also have no objection, and much sympathy, for having a clear
memory management policy for Boost libraries.  But again, it is a
matter of people who care about and understand the issue doing the
necessary work, just like everything else here at Boost.