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: OvermindDL1 (overminddl1_at_[hidden])
Date: 2009-10-23 14:49:34

On Fri, Oct 23, 2009 at 12:45 PM, Nevin Liber <nevin_at_[hidden]> wrote:
> 2009/10/23 Stewart, Robert <Robert.Stewart_at_[hidden]>
>
>> Joel de Guzman wrote:
>> > Fusion simply follows existing practice and
>> > extends it to
>> > the next level of modularity. There were two existing practice at the
>> > time when I wrote fusion:
>> >
>> > Â  Â  Â lib/
>> > Â  Â  Â lib.hpp
>> >
>> > and
>> >
>> > Â  Â  Â lib/
>> > Â  Â  Â lib/lib.hpp
>> >
>> > I find the latter redundant. I chose to follow the first.
>>
>
> +1, if I had to pick.
>
> I really dislike things like all.hpp, as they end up turning into misnomers.
> Â I am willing to reconsider this position when gcc -Wall gets fixed into
> showing all warnings. :-)
>
>
>> IOW, there isn't one approach now. Â If we adopt a single approach, some
>> code will break. Â Granted, in the latter case, lib/lib.hpp can be copied to
>> lib.hpp and thus make it like the former, but at some point, lib/lib.hpp
>> should be removed, and that will be a breaking change.
>>
>
> Why should it be removed? Â I can see picking a convention for future
> libraries and having a passionate volunteer (any takers? :-)) adding that
> convention to the current libraries, but I don't think cleaning up minor
> clutter is a good enough reason to break compatibility.

If you *really* have to have an all for whatever reason, why not
follow the Python naming convention and name it __all__.hpp since it
is something that includes everything and is easily factored out of
tab expressions (which I use a *lot*) and is very noticeable.