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
-- Joel de Guzman http://www.boost-consulting.com http://spirit.sf.net
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk