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: Matthew Chambers (matthew.chambers_at_[hidden])
Date: 2009-10-23 11:23:14

Christopher Jefferson wrote:
>>> 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).
I'll put in a vote for the directory+.hpp style. Tab-completability does 
not bother me, especially when it will complete all the way to the 
extension and then it's a matter of picking '/' or '.' and doing another 
completion. That's much better than any change which would break 
existing code.

-Matt