Boost logo

Boost :

From: Joel de Guzman (joel_at_[hidden])
Date: 2007-12-02 21:28:04

Robert Ramey wrote:
> Joel de Guzman wrote:
> For non-core libraries, it is always better
>> to use boost/<library>/detail and boost::<library>::detail
>> as many libraries are already doing. If they need to be used
>> by other libraries, then my thinking is that they ought not to
>> be in detail, but rather, hosted by a parent library, just
>> like that suggested in the last item in the list of current
>> "practices". Then, the natural place for its documentation is
>> the host library (e.g. The proto docs are currently in xpressive,
>> the pre-review of fusion was once in spirit).
> The case of codecvt_utf8 is interesting in his regard.
> In the course of development, we ended up with
> one copy in the serialization library and another
> identical copy in the program options library.
> Strenuous objections were raised about this. So
> it was "moved" to boost/detail - only because
> of these objections. It was never reviewed as
> a separate entity. It had its own tests and documentation
> page - but there was no place to put this
> in boost/detail. Perhaps boost/utility would
> be better - but then it would have had to suffer
> a review and no one wanted to take ownership.
> And recently I discovered that I forgot to take it
> out of the serialization library in any case. So
> a strict adherence to the proposed policy will
> result in duplicated code - not the end of the world -
> but some are going to object to that.
> As an aside, I noticed a talk titled something
> like "hidden boost gems" where codecvt_utf8
> was specifically mentioned. So some things end
> up being quasi-official by default.

What's wrong with having one of the interested parties host it?
What's wrong with having it in, say, boost/serialization/support
and have it included by the other library using it? Sure, that
is not ideal, but that practice ultimately avoids having boost
detail crowded.


Joel de Guzman

Boost list run by bdawes at, gregod at, cpdaniel at, john at