#3541 Support <boost/ptr_map.hpp>

[Olaf van der Spek-2]

Hi,

https://svn.boost.org/trac/boost/ticket/3541

Could a forward header file be created such that #include
<boost/ptr_map.hpp> works? The extra ptr_container directory is hard
to remember..., I always have to look it up. boost/ptr_* looks much
more natural.

Greetings,

Olaf
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Thorsten Ottosen-3]

Olaf van der Spek skrev:
> Hi,
>
> https://svn.boost.org/trac/boost/ticket/3541
>
> Could a forward header file be created such that #include
> <boost/ptr_map.hpp> works? The extra ptr_container directory is hard
> to remember..., I always have to look it up. boost/ptr_* looks much
> more natural.

I'm not against it, but I feel we should agree on some common principle
about when to put stuff directly in boost/.

My own feeling is that we don't want to put everything in this
directory. What does people think?

regards

-Thorsten
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Scott McMurray-2]

2009/10/23 Thorsten Ottosen <thorsten.ottosen@...>:
>
> I'm not against it, but I feel we should agree on some common principle
> about when to put stuff directly in boost/.
>
> My own feeling is that we don't want to put everything in this directory.
> What does people think?
>

I remember discussions about implications for ease of merging, clarity
of ownership, and other such things that say we want as little as
possible outside of library-specific directories.

(The one possible exception being one header with the same name as the
directory that includes almost everything, primarily for getting
started purposes.)
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Olaf van der Spek-2]

On Fri, Oct 23, 2009 at 2:57 PM, Scott McMurray <me22.ca+boost@...> wrote:

> 2009/10/23 Thorsten Ottosen <thorsten.ottosen@...>:
>>
>> I'm not against it, but I feel we should agree on some common principle
>> about when to put stuff directly in boost/.
>>
>> My own feeling is that we don't want to put everything in this directory.
>> What does people think?
>>
>
> I remember discussions about implications for ease of merging, clarity
> of ownership, and other such things that say we want as little as
> possible outside of library-specific directories.
>
> (The one possible exception being one header with the same name as the
> directory that includes almost everything, primarily for getting
> started purposes.)

Would a boost/ptr_container.hpp that includes all containers make sense?
I don't think every container needs it's own header file.

Olaf
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Frank Mori Hess]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Friday 23 October 2009, Olaf van der Spek wrote:
> On Fri, Oct 23, 2009 at 2:57 PM, Scott McMurray <me22.ca+boost@...>
wrote:

> > 2009/10/23 Thorsten Ottosen <thorsten.ottosen@...>:
> >
> > I remember discussions about implications for ease of merging, clarity
> > of ownership, and other such things that say we want as little as
> > possible outside of library-specific directories.
> >
> > (The one possible exception being one header with the same name as the
> > directory that includes almost everything, primarily for getting
> > started purposes.)
>
> 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.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEARECAAYFAkrhrUAACgkQ5vihyNWuA4V+4QCglIDW5SoE9S1WHinhBN3xct/E
4c4Ani716TTl5OSL+VHIUCY7J0YXhmIT
=+EuF
-----END PGP SIGNATURE-----
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Olaf van der Spek-2]

On Fri, Oct 23, 2009 at 3:18 PM, Frank Mori Hess <frank.hess@...> 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.

Olaf
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Stewart, Robert]

Olaf van der Spek wrote:

> On Fri, Oct 23, 2009 at 3:18 PM, Frank Mori Hess
> <frank.hess@...> 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."

_____
Rob Stewart                           robert.stewart@...
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.
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[troy d. straszheim]

Stewart, Robert wrote:

> Olaf van der Spek wrote:
>> On Fri, Oct 23, 2009 at 3:18 PM, Frank Mori Hess
>> <frank.hess@...> 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,

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/

the files D.hpp could be automatically generated and/or checked.  There
are implications for 'modularization'... note that this supports
single-header projects as well as projects with subdirectories.

-t


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Olaf van der Spek-2]

On Fri, Oct 23, 2009 at 3:39 PM, Stewart, Robert <Robert.Stewart@...> wrote:

> Olaf van der Spek wrote:
>> On Fri, Oct 23, 2009 at 3:18 PM, Frank Mori Hess
>> <frank.hess@...> 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."

Doesn't boost/ptr_container.hpp mean the same?
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Stewart, Robert]

Olaf van der Spek wrote:

> On Fri, Oct 23, 2009 at 3:39 PM, Stewart, Robert
> >> On Fri, Oct 23, 2009 at 3:18 PM, Frank Mori Hess
> >> <frank.hess@...> wrote:
> >> >> Would a boost/ptr_container.hpp that includes all
> >> >> containers make sense?
> >> >
> >> > One suggestion I liked that came up earlier was using
> >> > all.hpp, for example boost/ptr_container/all.hpp.
> >
> Doesn't boost/ptr_container.hpp mean the same?

Yes, but the idea of all.hpp was to avoid adding to boost/.

_____
Rob Stewart                           robert.stewart@...
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.
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Olaf van der Spek-2]

On Fri, Oct 23, 2009 at 4:33 PM, Stewart, Robert <Robert.Stewart@...> wrote:

> Olaf van der Spek wrote:
>> On Fri, Oct 23, 2009 at 3:39 PM, Stewart, Robert
>> >> On Fri, Oct 23, 2009 at 3:18 PM, Frank Mori Hess
>> >> <frank.hess@...> wrote:
>> >> >> Would a boost/ptr_container.hpp that includes all
>> >> >> containers make sense?
>> >> >
>> >> > One suggestion I liked that came up earlier was using
>> >> > all.hpp, for example boost/ptr_container/all.hpp.
>> >
>> Doesn't boost/ptr_container.hpp mean the same?
>
> Yes, but the idea of all.hpp was to avoid adding to boost/.

As the file has the same name as the directory, I don't see the
advantage of that.
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Stewart, Robert]

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@...> 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@...
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.
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Frank Mori Hess]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Friday 23 October 2009, Olaf van der Spek wrote:
> On Fri, Oct 23, 2009 at 3:39 PM, Stewart, Robert <Robert.Stewart@...>
wrote:
> > Olaf van der Spek wrote:
> >> On Fri, Oct 23, 2009 at 3:18 PM, Frank Mori Hess
> >>
> >> <frank.hess@...> wrote:

> >> > 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."
>
> Doesn't boost/ptr_container.hpp mean the same?

As another example, boost/thread.hpp (catch-all) is easily confused with
boost/thread/thread.hpp (boost::thread class), whereas boost/thread/all.hpp
is not.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEARECAAYFAkrhwPoACgkQ5vihyNWuA4XWsgCcDwBtb7S9CyMJckOay+w8Ft4r
b/cAoM1nVkNtCtu+mea2cFS4eR+r5rPE
=u2qF
-----END PGP SIGNATURE-----
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Stewart, Robert]

Olaf van der Spek wrote:

> On Fri, Oct 23, 2009 at 4:33 PM, Stewart, Robert
> <Robert.Stewart@...> wrote:
> > Olaf van der Spek wrote:
> >> >
> >> Doesn't boost/ptr_container.hpp mean the same?
> >
> > Yes, but the idea of all.hpp was to avoid adding to boost/.
>
> As the file has the same name as the directory, I don't see the
> advantage of that.

all.hpp goes in the <libname> subdirectory, <libname>.hpp adds to the noise in boost/.

_____
Rob Stewart                           robert.stewart@...
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.
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Christopher Jefferson]

On 23 Oct 2009, at 15:41, Stewart, Robert wrote:

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

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

Chris
Chris
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Stewart, Robert]

Christopher Jefferson wrote:

> On 23 Oct 2009, at 15:41, Stewart, Robert wrote:
> > troy d. straszheim wrote:
> >>
> >> % 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 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 very rarely tab-complete header file names, and I suspect most users

Your usage patterns are limited to your coworkers and your environment.  Mine suggests that there are a great many people who use tab completion constantly.  Consequently, we can't favor one over the other if a neutral solution is possible.

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

My current emacs settings would make all.hpp less than ideal, too, *if* I had more than one open because I don't include the directory name in the buffer names.  That means I could have multiple "all.hpp" buffers open at once, making switching among them more difficult than necessary.

However, I really can't imagine having all.hpp files open for more than a moment to determine the headers they include.  Likewise, there aren't any symbols defined in such headers -- they only include other headers -- so you wouldn't find them in your symbol search results either.

_____
Rob Stewart                           robert.stewart@...
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.
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Matthew Chambers-3]

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
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Christopher Jefferson]

On 23 Oct 2009, at 16:04, Stewart, Robert wrote:

> Christopher Jefferson wrote:
>> On 23 Oct 2009, at 15:41, Stewart, Robert wrote:
>>> troy d. straszheim wrote:
>>>>
>>>> % 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 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 very rarely tab-complete header file names, and I suspect most  
>> users
>
> Your usage patterns are limited to your coworkers and your  
> environment.  Mine suggests that there are a great many people who  
> use tab completion constantly.

Out of interest, why do you assume I only know about my coworkers and  
environment, whereas you know about a great many people who are  
annoyed by tab completion failing? I don't think the majority of boost  
users would ever look inside the boost include directory from the  
command line, any more than they would look at their standard  
library's headers.

>  Consequently, we can't favor one over the other if a neutral  
> solution is possible.

What is the neutral solution?

Chris
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Olaf van der Spek-2]

On Fri, Oct 23, 2009 at 5:04 PM, Stewart, Robert <Robert.Stewart@...> wrote:
>> I very rarely tab-complete header file names, and I suspect most users
>
> Your usage patterns are limited to your coworkers and your environment.  Mine suggests that there are a great many people who use tab completion constantly.  Consequently, we can't favor one over the other if a neutral solution is possible.

As a Boost dev or as a user?
As user the version without /all seems better.
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Stewart, Robert]

Christopher Jefferson wrote:

> On 23 Oct 2009, at 16:04, Stewart, Robert wrote:
>
> >> I very rarely tab-complete header file names, and I suspect most
> >> users
> >
> > Your usage patterns are limited to your coworkers and your
> > environment.  Mine suggests that there are a great many people who
> > use tab completion constantly.
>
> Out of interest, why do you assume I only know about my
> coworkers and
> environment, whereas you know about a great many people who are
> annoyed by tab completion failing?

I made no such claim.  I asserted my annoyance.  You claimed to know that most users would not do so.  I refuted your claim as being based upon your personal experience.  I then asserted my own personal experience as being at least partly contrary to your own.

> I don't think the majority of boost
> users would ever look inside the boost include directory from the
> command line, any more than they would look at their standard
> library's headers.

I don't know why you think you can make such a claim.  I know that I have done so on many occasions.  As you might have gleaned from my previous posts, the tab completion functionality is not limited to command lines anyway.

> >  Consequently, we can't favor one over the other if a neutral
> > solution is possible.
>
> What is the neutral solution?

I'm not sure, but I was arguing against your claims that using all.hpp was the better solution and for considering all issues when making a choice.

_____
Rob Stewart                           robert.stewart@...
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.
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost