Joel de Guzman wrote:
No, of course not. But was has boost/shared_ptr got to do with this? wow - this is the iconic example of a violation of "standard practice" Why are you saying that while insisting that there's no "standard practice"?
There is none - that's why I put it in quotes. "standard practice" is a fluid definition in this context. The latest version cited now seems to depend on something referred to as "core libraries" whatever that means.
We can't argue that way. Give me your definition of "standard practice" first. Seems I'm looking at Mars and you might be looking at Jupiter.
I'm not the one claiming there there exists an unambiguous definition of "standard practice" in this context so that's why I haven't claimed I followed it. My claim is that its undefined and being stretched and distorted to fit with every post on this thread. I don't know what it is. I don't know where its defined. That's why I had to try to extract from the example of the way boost was organized at the time. Given that is the way I had to do it, its no wonder at least some people think I got it wrong. Given the lack of definition - its inevitable that there is going to be disagreement on some decision which is supposedly based upon it. And BTW - boost is riddled with this problem. The same sorts of issues plague documentation standards, usage of boost/detail, release and testing procedures.
So, I'm curious. Is there a precedent that prompted you to place static_warning in the root boost directory and in namespace boost?
I just followed the example of static_assert.hpp. I was new to boost so I wasn't aware of any precedent. I followed what seemed to me to be an inescapably obvious pattern. Also the WHOLE serialization library was subject to review. Everything was open to question. The first review produced a rejection and a very long list of things that were unacceptable. The next version addressed all the issues raised and the library was accepted with very little change. It was my understanding that the review was to cover all aspects of the library. I could just as well argue that those components were reviewed. I'm not going to do that however. The serialization library is a large library and really needed some things that boost didn't have like strongtypedef, extended_typeinfo, static_warning, and a couple of others I forgot. They really arn't part of the library - just things boost was missing. So I put them where other similar components were found and no one objected neither then nor for years afterwards. And these things weren't hidden. They were prominantly featured in the documentation as separate components with links to the true path.
It's not perfect, for sure. Discussions like this, hopefully, should get the issues straightened. Again, I'm curious, it seems (you say) that you based your judgement from discerning standard practice from existing libraries. So which is it that you based placing static_warning in the root boost directory and in namespace boost on? Please understand that I want to look at this constructively and objectively.
I appreciate that. See above. Also consider the context. Source code, headers, test programs and documentation of the serialization library I believe is on the order of 30,000 lines of text. (we'll exclude the email discussions, reviews etc.) A header like static_warning is maybe 100 lines. I saw a very close analogy, leveraged on it, and moved on. Without clearer more explicity policy, one doesn't have much other alternative. Actually, considering the scale of what was involved, the possible misplacement of a small number of headers (8?) is very small potatoes and has been blown way out of proportion. And considering boost's other problems, release procedures, documentation build, out of date documentation standards, components used but not formally tested, testing on just a subset of build combinations, bjam, etc. It's microscopic potatoes.
So for me, its not a question so much of this or that directory structure but the whole idea that its ok to change the rules in the middle of the game. It wastes huge amounts of time.
I disagree. IMO, no-one is changing the rules in the middle of the game. It's just that you did something that slipped the radar screen.
LOL - we could disagree on this, but as a practical matter the effect is the same.
Our task now is to make sure that this does not happen. And, I agree with you that we should have some kind of policy written.
Halleluhuh How about this as a policy: a) No new headers in boost/... Boost is too big for this b) small libraries can be placed in boost/utility and ancillary files such as tests, source code, documentation, etc be placed in the same spots they are as other libraries c) No concept of "core libraries" vs "non-core" libraries d) exception to a) one convenience header per library e) documentation in boost/libs/utility/doc/... same as other libraries f) library authors encourged to move components over time out of boost. This would include ALL the ones I posted before (except for those which are convenience headers).
Hmmm - well, maybe we'll just submit static_warning.hpp for a fast track review and be done with it.
I haven't done this up until now for a couple of reasons. I thought it mostly redundant. It takes a lot of time on my part. It would take time from other things I thought were alot more urgent and important. these would be state_saver.hpp, static_warning.hpp, strongtypedef.hpp. The other ones of mine are pfto.hpp, smart_cast.hpp, and I would be inclined to migrate them out at a convenient time in the future. So you would only have about 100 others to deal with. Robert Ramey
Cool!
Regards,