Re: [boost] [lib maintainers] Please identify headersinboost-root/boost

From: Robert Ramey (ramey_at_[hidden])
Date: 2007-11-17 21:33:25

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
> ;-)