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: Stewart, Robert (Robert.Stewart_at_[hidden])
Date: 2009-10-23 10:41:41

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.

_____
Rob Stewart                           robert.stewart_at_[hidden]
Software Engineer, Core Software      using std::disclaimer;
Susquehanna International Group, LLP  http://www.sig.com

IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.