From: Robert Ramey (ramey_at_[hidden])
Date: 2007-11-18 12:19:40
David Abrahams wrote:
> In general, no, it has not been the case. This may not be a perfect
> arrangement, but with very few exceptions:
> * Core libraries whose documented public interface fits in just a few
> headers and a few pages of documentation have been able to put all
> their public headers in boost/ and their components in boost::.
Ahh - "Core libraries" - perhaps that's the missing link. So
static_assert.hpp would be a "core library" but static_warning.hpp
would be a ..... non-core library?
> * 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
Which is another problem in my view. If they're meant to be used
by more than one library they should have a documented and tested
interface. Otherwise, they should be in the particular library even
at the cost of code repetition.
> I explained most of this in
and I responded at the time.
well, as far as pfto.hpp is concerned, I concede an error in foresight
on my part. I envisioned that as a general fix for those compilers
which failed to correctly implement partial function template ordering
and thought it orthogonal to the serialization library as a whole. As
the whole serialization library was subject to review - including this point
and no objection was raised at the time - i left it there. BTW it IS
documented and its NOT really part a part of serialization per se.
Had I known that boost would relatively soon start restricting itself
to compilers which don't manifest this problem, I would have taken
a different decision.
>> So rather than saying that authors have refused to follow "standard
>> practice", it would be more accurate to say that...
> Nobody said that.
>> These unconventional moves are at best confusing for users and other
>> maintainers. The Boost source base is hard enough to control without
>> library authors inventing their own new rules for organizing things.
>What I said was that some people have ignored
> direct (public and private) appeals from moderators to bring their
> headers into conformance with the standard practice, and that is
> exactly correct.
a) There is no stated "standard practice" so it cannot be correct.
b) There is no obvious "convention" in many areas
c) Authors are left to try to decipher intent from the current hodgepodge.
I believe that all authors have tried to do this
d) One purpose of the review process is to raise these issues at a proper
e) Authors (including myself) have been very willing to address all issues
raised during a review. The can't be faulted years later for failing to
adhere to some undefined "standard practive" or "convention" which
has never been stated nor is obvious.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk