Robert Ramey wrote:
Joel de Guzman wrote:
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.
Well, this IMO has got to stop.
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?
No, of course not. But was has boost/shared_ptr got to do with this?
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.
It went unnoticed at least for me. I would have objected otherwise.
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.
I don't think anyone is pinpointing you as unwilling to respect "standard practice".
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.
Yes, because boost/detail is not public API and the stuff there is implementation 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
I'm lost again. boost/utility/multi-pass is non-existent.
index. Then there is utility.hpp which is a convenience header for a group of otherwise separate library - not including mult-index.
If a particular utility is useful for many libraries, then one of the libraries can host it prior to it getting reviewed independently and becoming a full-fledged boost citizen. That's the policy that we've been following with the synergy between xpressive and spirit, for example. Case in point: fusion, proto, multi_pass, and many more smaller utilities and stuff. fusion was hosted by spirit before it was reviewed and was used by xpressive even before spirit did. Now that fusion passed the boost review, it has become a full-fledged boost citizen.
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.
That's a good start. Regards, -- Joel de Guzman http://www.boost-consulting.com http://spirit.sf.net