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. boost/aligned_storage.hpp boost/any.hpp boost/array.hpp boost/assert.hpp boost/bind.hpp boost/blank.hpp boost/blank_fwd.hpp boost/call_traits.hpp boost/cast.hpp boost/checked_delete.hpp boost/concept_archetype.hpp boost/concept_check.hpp boost/config.hpp boost/cstdint.hpp boost/current_function.hpp boost/dynamic_bitset_fwd.hpp boost/dynamic_property_map.hpp boost/enable_shared_from_this.hpp boost/function.hpp boost/function_equal.hpp boost/functional.hpp boost/get_pointer.hpp boost/implicit_cast.hpp boost/indirect_reference.hpp boost/int_iterator.hpp boost/integer.hpp boost/integer_fwd.hpp boost/integer_traits.hpp boost/intrusive_ptr.hpp boost/io_fwd.hpp boost/iterator.hpp boost/iterator_adaptors.hpp boost/last_value.hpp boost/lexical_cast.hpp boost/limits.hpp boost/math_fwd.hpp boost/mem_fn.hpp boost/next_prior.hpp boost/non_type.hpp boost/noncopyable.hpp boost/nondet_random.hpp boost/none.hpp boost/operators.hpp boost/optional.hpp boost/pfto.hpp boost/pointee.hpp boost/preprocessor.hpp boost/property_map.hpp boost/property_map_iterator.hpp boost/random.hpp boost/ref.hpp boost/regex.hpp boost/scoped_ptr.hpp boost/shared_array.hpp boost/shared_ptr.hpp boost/smart_cast.hpp boost/smart_ptr.hpp boost/static_assert.hpp boost/static_warning.hpp boost/strong_typedef.hpp boost/throw_exception.hpp boost/tokenizer.hpp boost/type.hpp boost/type_traits.hpp boost/utility.hpp boost/variant.hpp boost/version.hpp boost/visit_each.hpp boost/weak_ptr.hpp Lots of these have been there for years. So I'm not sure where the idea that there exists a "standard practice" comes from. 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 a manual page for each of them. There wasn't a convenient place to put the documenation so I left it as "misc" in the serialization documentation. The serialization library was reviewed TWICE and no one ever mentioned this. 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. Now if one want's to define a "standard practice" that's fine. And clearly boost is a lot bigger than it used to be so the best practice may well be different than it used to be. But it has to be recognized that this is a whole new thing. And its not clear what that new thing should be? 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). I think the only practical thing to do at this point is a) debate and establish a policy for using boost/ and boost:: b) enforce it for new additions c) hope that over time the current contents migrate out Robert Ramey David Abrahams wrote:
on Sat Nov 17 2007, Joel de Guzman <joel-AT-boost-consulting.com> wrote:
Beman Dawes wrote:
Robert Ramey wrote:
smart_cast.hpp state_saver.hpp strong_typedef.hpp pfto.hpp The above are documented in the serialization library. Each one has its own page.
Thanks, Robert.
SVN updated.
This is somewhat discomforting. Isn't there a policy for placing headers in the root boost directory?
There is a standard practice that was established by tradition and consensus, but no written policy.
Can anyone simply place whetever he/she wants there? The files above look like small utilities. As such, they are not fast track reviewed, AFAICT.
Unfortunately, the standard practice was not followed by everyone, and although moderators have made explicit requests that these headers be brought into conformance with that practice, our requests have been ignored.
That goes the same for the boost namespace. IMO, we need a clear policy on what goes there. Lest, we'll have it filled up and polluted with lotsa stuff before we know it.
Yes, well, now we have a precedent that violates what is, IMO, the only reasonable policy. That makes it a little harder to make the policy official. But anyway, I have a strong suspicion that you and I substantially agree on that policy, so I would be very happy if you'd write something up. Then we have something concrete to argue about ;-)