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 http://lists.boost.org/Archives/boost/2006/05/105195.php
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.
from http://lists.boost.org/Archives/boost/2006/05/105200.php
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 time 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. Robert Ramey