Re: [boost] [Modularization] A new approach to header modularization

Subject: Re: [boost] [Modularization] A new approach to header modularization
From: Stewart, Robert (Robert.Stewart_at_[hidden])
Date: 2009-05-29 07:52:53

Beman Dawes wrote
On Thursday, May 28, 2009 5:07 PM
> On Thu, May 28, 2009 at 10:53 AM, troy d. straszheim
> <troy_at_[hidden]> wrote:
> >
> > - There is still the toplevel filesystem.hpp and friends to
> > deal with.
>
> The way to deal with that is to migrate those to within the library's
> header directory.

+1

> As boost grows, filling the boost/ with headers becomes less and less
> attractive. Of course we have to leave the current headers there for
> compatibiltiy, but that location could be deprecated and eventually
> only <boost/filesystem/filesystem.hpp> supported.

Rather than being redundant, why not make it <boost/library/all.hpp>, where "library" varies?

> > You can't move libraries around as a unit (which is the desired
> > capability, right?).
>
> You can except for the current boost/ .hpp files. Whether that's a
> problem or not depends on whether we are willing to move to all
> headers in the library's home. That may well be an eventual need
> regardless of the modularization approach.

Those wanting to take advantage of the modularization will change their include directives from boost/library.hpp to boost/library/all.hpp.

> >  There is also the potential for name
> > collisions between directories under libs/X and boost/X,
> > You would want some naming convention:
> >
> > boost/
> >  filesystem.hpp
> >  filesystem/
> >     O_o/         <----
> >        build/
> >        test/
> >        doc/
>
> Yes, you could do that. But we can also reserve certan names
> (doc/src/test/example/build). That would go a long way.

+1

> > or maybe something pythonic like __src__/.

-1

> > - Users expect headers under include/ and source under
> > src/, this will surprise them.
>
> Yep. Just like it surprises them now that there is no include/.  They
> get over it.

It never hurts to follow convention when possible and reasonable.

_____
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.