Joel de Guzman wrote:
Robert Ramey wrote:
A little greping reveals the following headers which would seem to violate "standard practice". I've tried to exclude those which are "convenience headers" which do nothing but call a bunch of includes for some library.
[...]
Lots of these have been there for years. So I'm not sure where the idea that there exists a "standard practice" comes from.
First, define "standard practice". I can't say that all the files you listed violates the "standard practice" if we haven't defined it yet.
aaaaaaaa - that's my point. There has never been any "standard practice defined"
In my particular case, I had a need for some things like static_warning and strong_typedef which didn't exist. I didn't put them where they are currently found by accident. I knew they didn't fit in the serialization library and it seemed they were very similar to other files in the above list. I made
So, if I decide that some parts of spirit (a lot! e.g. multi_pass iterator) is useful outside spirit and does not really belong in spirit, I'm free to put that outside the spirit sphere and into boost?
Up until now that's been the case.
Why not put it in serialization "misc" then? In my libraries, we have such utilities in "support".
To make such a move at this point it would be an interface breaking change. How much code would break if boost/shared_ptr (and boost::shared_ptr etc) is changed at this point? Do you really think that all these changes should be made now?
The serialization library was reviewed TWICE and no one ever mentioned this.
It's unfortunate that this has gone unnoticed from 2 reviews. Perhaps it didn't matter much at the time, or simply it slipped from the radar screen. Nevertheless, that does not make it right.
I doubt it went unnoticed. I suspect that it was percieved as the "standard practice" at the time.
So rather than saying that authors have refused to follow "standard practice", it would be more accurate to say that there has been no definition of "standard practice" and many authors have interpreted it in the most logical way given the current situation.
Agreed. I'm not quite sure about the "most logical" way though. For me, it's pretty clear that free-for-all addition of just about anything in the boost root directory and the boost namespace is not good. There are namespaces and subdirectories.
As I said, I don't object to establishing a "standard practice". But it's really annoying to be characterised as being unwilling to respect a "standard practice" when no such thing has been established.
While we're at it, there is also the question of boost/utility. Clearly there is useful stuff in there. I've used it myself. But non of it has any documentation nor separate tests as far as I can tell. (ucs code cvt facet is tested and documented in the serialization library).
My mistake - I meant boost/detail.
Really? enable_if, addressof, result_of, at least, have docs and tests.
LOL - yeah but the directory structure doesn't respect the practice used by other libraries. And that's only 3 modules about of
I do not see ucs code cvt facet there. What am I missing?
the header is in boost/detail. It should have gone into boost/utility but there was a hassle because it wasn't reviewed. Before that the same code was in multiple libraries and there was an objection to that. No matter what - we can't get a break. So it went into boost/detail and guess what - there is no place to put documentation or tests for anything in boost/detail. Now I see that boost/utility/multi-pass has a documentation page but no way to get to by following the links in the documentation index. Then there is utility.hpp which is a convenience header for a group of otherwise separate library - not including mult-index. So any kind of "standard practice" should also normalize all of this as well. Fine by me.
I think the only practical thing to do at this point is
a) debate and establish a policy for using boost/ and boost::
and boost/detail and boost/utility
b) enforce it for new additions
Encourage developers of libraries in violation of the policy to do the right thing.
c) hope that over time the current contents migrate out
So I guess we're in agreement. Robert Ramey