Boost logo

Boost :

From: Gregory Colvin (gregory.colvin_at_[hidden])
Date: 2003-08-27 15:39:00


On Wednesday, Aug 27, 2003, at 13:40 America/Denver, E. Gladyshev wrote:
> --- Gregory Colvin <gregory.colvin_at_[hidden]> wrote:
>>> My immediate problem is to ship a C++ template library.
>>> I'd like to have my users be able to customize
>>> memory policies (w/o overloading new/delete)
>>> and I'd like to use boost in my implementation.
>>> What are my options?
>>
>> For now, the two I just told you. Since you don't want to ship
>> your modifications to Boost
>
> No, I certainly cannot ship Boost with my library.
> The user may already have Boost installed
> and configured and there are many other issues
> with this approach as well...
>
>> the specialization approach may be
>> best.
>
> However if you ever change the details, my specialization
> may stop working or worse become unstable. In general,
> it is not a safe approach for a professional library.

So Boostify your library and you can make sure that future
releases won't break it. Short of that there is *always* a
danger of future releases breaking your code.

> Also different users may have different boost
> installations and the list goes on...

It's not ideal, as I said. But I see little problem with
trying this approach first. If it works, you can push to
have the sp_counted_base_impl template documented, or for
some other change that works for you and your customers.

You seem to forget that Boost is an open project whose
future you can influence.

> I guess I am out of luck with Boost here. :(

Good luck finding a suitable replacement ;->

> You cannot make everybody happy anyway.

Nope. That's why engineering compromises are so difficult.

> BTW:
> I'd a bit suprised if the C++ committe
> accepts Boost memory management concept
> (or a complete lack of such) as
> an industry standard.

It already has:

http://std.dkuug.dk/JTC1/SC22/WG21/docs/library_technical_report.html


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk