Re: [boost] Boost policy for putting headers in boost/ Was: #3541 Support <boost/ptr_map.hpp>

Subject: Re: [boost] Boost policy for putting headers in boost/ Was: #3541 Support <boost/ptr_map.hpp>
From: Christopher Jefferson (chris_at_[hidden])
Date: 2009-10-23 10:55:17

On 23 Oct 2009, at 15:41, Stewart, Robert wrote:

> troy d. straszheim wrote:
>> Stewart, Robert wrote:
>>> Olaf van der Spek wrote:
>>>> On Fri, Oct 23, 2009 at 3:18 PM, Frank Mori Hess
>>>> <frank.hess_at_[hidden]> wrote:
>>>>>> Would a boost/ptr_container.hpp that includes all containers
>>>>>> make sense? I don't think every container needs it's own header
>>>>>> file.
>>>>> One suggestion I liked that came up earlier was using all.hpp,
>>>>> for example boost/ptr_container/all.hpp.
>>>> All seems a bit redundant, the standard is just <lib>.hpp AFAIK.
>>>
>>> Redundancy occurs with boost/ptr_container/ptr_container.hpp, not
>>> boost/ptr_container/all.hpp.  Using all.hpp means that all libraries
>>> use the same header name and the library name isn't repeated.
>>> "all.hpp" is as short as you can get and still mean "give me
>>> everything."
>>
>> My inclination is to standardize on existing practice rather than
>> inventing a standard.   So I'd suggest that at any level of the
>> directory tree,
>
> That's a reasonable default position.
>
>> File D.hpp is either standalone (if no directory D exists) or  
>> includes
>> all files in subdirectory D.  This way your abstraction gets you more
>> than just information on how to negotiate the toplevel boost/
>> directories, and it matches current practice fairly well.  Fusion has
>> always struck me as quite clean:
>>
>> % ls boost/fusion
>> adapted/       container.hpp   iterator.hpp  support/   view.hpp
>> adapted.hpp    functional/     mpl/        support.hpp
>> algorithm/     functional.hpp  mpl.hpp             tuple/
>> algorithm.hpp  include/        sequence/     tuple.hpp
>> container/     iterator/       sequence.hpp  view/
>
> I like your point about D.hpp being all there is for "D" or being a  
> header that includes everything in the corresponding "D"  
> subdirectory.  However, look at the fallout illustrated by the  
> directory listing you show: each "D" is duplicated.  There's  
> "adapted" and "adapted.hpp," "functional" and "functional.hpp,"  
> etc.  The directory listing is complicated by this approach.
>
> I find navigating such directory structures needlessly annoying: I  
> can't use filename completion easily.  With all.hpp, the directory  
> name completes, with a trailing "/", and then I can type "all" and  
> complete that.  (Yes, I can get completion up to the "/" or "." and  
> then type whichever I want to complete the header name or navigate  
> into the subdirectory, but the partial completion can also mean that  
> there are other files that begin with what I typed.  I can't  
> navigate as easily unless I already know the directory contents.)
>
> I understand that switching to <libdir>/all.hpp is a breaking change  
> for those libraries neatly arranged like Fusion, but I think the  
> result will be cleaner.  If the end result is thought sufficiently  
> valuable, then the sooner the change is made, the fewer libraries  
> will be broken.  Delay just means more libraries may follow Fusion's  
> lead and there will be more breakage.  Thus, Boost needs to choose  
> sooner than later.

I would like to strongly vote against all.hpp, in favour of fusion's  
approach :)

I very rarely tab-complete header file names, and I suspect most users  
don't either. Using 'all.hpp' means that when listing header files  
(for example because I want to know what file a particular function  
came from), you need more text to distinguish the file you are  
refering to. Having many identically named headers in different  
directories sounds to me like a recipe for confusion.

Further, I would STRONGLY disagree against needlessly breaking  
libraries. There is no reason that libraries can't, for a few  
versions, or even forever, support both versions (although this would  
break your tab-completing thing). There is nothing more annoying than  
boost libraries where it's almost impossible to write code that works  
over the set of versions users can reasonably be expected to have  
(which in our case is the latest versions in ubuntu, cygwin, and from  
the boost website).

Chris
Chris