Boost logo

Boost :

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.


Boost list run by bdawes at, gregod at, cpdaniel at, john at