Boost logo

Boost :

From: David Abrahams (dave_at_[hidden])
Date: 2007-12-01 09:06:21

on Sat Dec 01 2007, "Robert Ramey" <> wrote:

> Joel de Guzman wrote:
>>> * Un-reviewed implementation details of libraries have been placed in
>>> boost/detail if they need to be used by other libraries and a
>>> subdirectory of boost/<libraryname>/ otherwise. Their documented
>>> public components are placed in boost/detail and namespace
>>> boost::detail.
> I think the current situation is a little problematic.
> If there in boos/detail, presumable its because they might be
> useful accross more than one library.

Not usually. Usually it's because they *have* been useful across more
than one library. In general, nobody sticks stuff in boost/detail
just because they think it might have a use elsewhere. Components
migrate there.

> However,
> There is no place for documentation of these things.

Sure there is. Comments work.

> So there is no guarenteed interface.
> And of course no separate tests.

Not necessarily. I always write tests for my library's implementation
detail components.

> No guarentee that the interface won't change - after all
> its an implementation detail. So it can change without
> warning an break other libraries.
> So, one has a lot of reservations about depending upon these
> modules. On the other hand, they have proved very useful so for the
> sake of expediency they're going to get used - leading to surprise
> breakages.

That's more of a theoretical problem than a real one. It has never
been an issue in the past. Most people realize that once a component
moves into boost/detail, other people may be depending on it, so they
make an effort to coordinate if there are any breaking changes (which,
to my knowledge, there have never been in a boost/detail component).

> So I think those things that have been going to boost/detail should
> just go into boost / utility. Approval for this would be part of
> the review process for the library which needed them.

Implementation details get invented and shared as part of a library's
evolution, so that would never work

> I realise some might find this bothersome, but its much better the
> the current situation.

I don't see why. A little common sense is all it takes to make this
work out, and it has worked very well so far.

Dave Abrahams
Boost Consulting

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