#3541 Support <boost/ptr_map.hpp>
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
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
2009/10/23 Thorsten Ottosen <thorsten.ottosen@dezide.com>:
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.)
On Fri, Oct 23, 2009 at 2:57 PM, Scott McMurray <me22.ca+boost@gmail.com> wrote:
2009/10/23 Thorsten Ottosen <thorsten.ottosen@dezide.com>:
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
-----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@gmail.com> wrote:
2009/10/23 Thorsten Ottosen <thorsten.ottosen@dezide.com>:
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-----
On Fri, Oct 23, 2009 at 3:18 PM, Frank Mori Hess <frank.hess@nist.gov> 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
Olaf van der Spek wrote:
On Fri, Oct 23, 2009 at 3:18 PM, Frank Mori Hess <frank.hess@nist.gov> 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@sig.com 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.
Stewart, Robert wrote:
Olaf van der Spek wrote:
On Fri, Oct 23, 2009 at 3:18 PM, Frank Mori Hess <frank.hess@nist.gov> 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
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@nist.gov> 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@sig.com 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.
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@nist.gov> 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
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@sig.com 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.
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
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@sig.com 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.
On 23 Oct 2009, at 16:39, Stewart, Robert wrote:
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.
Stepping back for a moment, I think we both (certainly I have) may have read a stronger claim into your e-mails then you intended to make. In particular, I think I may well have seen red at the words "breaking change" in regards to changing libraries, because we came within a thin margin of throwing boost out of an open source project I work on about a month ago. Boost can be quite hard to use in open source projects, where a user might have some version of boost installed by their packaging manager (which might be yum, apt-get, macport, cygwin,etc), and not want to go and have to install another version manually if it can be avoided. However, the issue of if any changes are made gradually, or in one break, is different from what kind of include names are used. It is unfortunate that it is perhaps not advisable to use both at once, as one of the major arguments in favour of all.hpp is that the alternative breaks tab completion. I do hope, modulo phasing in over a number of versions to minimising breaking, that one standard can be agreed on. In general I prefer one standard over several! Chris
On Fri, Oct 23, 2009 at 5:04 PM, Stewart, Robert <Robert.Stewart@sig.com> 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.
Olaf van der Spek wrote:
On Fri, Oct 23, 2009 at 5:04 PM, Stewart, Robert <Robert.Stewart@sig.com> 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?
User.
As user the version without /all seems better.
We disagree, then. _____ Rob Stewart robert.stewart@sig.com 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.
Olaf van der Spek wrote:
On Fri, Oct 23, 2009 at 5:04 PM, Stewart, Robert <Robert.Stewart@sig.com> 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.
This user would prefer the lib/all.hpp, so that when compile times get egregious I can quickly track down the overzealous */all.hpp's and replace them with the minimal includes. Jeff
On 23 Oct 2009, at 16:57, Jeff Flinn wrote:
Olaf van der Spek wrote:
On Fri, Oct 23, 2009 at 5:04 PM, Stewart, Robert <Robert.Stewart@sig.com
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.
This user would prefer the lib/all.hpp, so that when compile times get egregious I can quickly track down the overzealous */all.hpp's and replace them with the minimal includes.
I have a project which includes the global headers for gil, variant, type_traits, thread, function, signals, any, bind and preprocessor, and with a pre-compiled header can compile small files including these headers in (just checking) < 0.25s real time, 0.13s CPU time. I find this acceptable, and saves me time have to look up what is in each header. Of course, we should not require the use of 'all' headers, but they can be useful. Chris
On Fri, Oct 23, 2009 at 5:57 PM, Jeff Flinn <TriumphSprint2000@hotmail.com> wrote:
As a Boost dev or as a user? As user the version without /all seems better.
This user would prefer the lib/all.hpp, so that when compile times get egregious I can quickly track down the overzealous */all.hpp's and replace them with the minimal includes.
How's that related to this discussion? It's not about the contents of the file, right? Olaf
Olaf van der Spek wrote:
On Fri, Oct 23, 2009 at 5:57 PM, Jeff Flinn <TriumphSprint2000@hotmail.com> wrote:
As a Boost dev or as a user? As user the version without /all seems better. This user would prefer the lib/all.hpp, so that when compile times get egregious I can quickly track down the overzealous */all.hpp's and replace them with the minimal includes.
How's that related to this discussion? It's not about the contents of the file, right?
I don't understand what 'that', and 'it' refer to in these questions? I don't know what you are asking me to clarify. Jeff
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
on Fri Oct 23 2009, "Stewart, Robert" <Robert.Stewart-AT-sig.com> wrote:
I understand that switching to <libdir>/all.hpp is a breaking change for those libraries neatly arranged like Fusion,
It doesn't have to be. boost/fusion.hpp could be left in place as a backward compatibility measure.
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 agree. We need to make sure we've thought the problem through, but after that, if we agree on a change, we should move boldly. -- Dave Abrahams Meet me at BoostCon: http://www.boostcon.com BoostPro Computing http://www.boostpro.com
troy d. straszheim wrote:
Stewart, Robert wrote:
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."
I don't like the idea of a boost/<lib>/all.hpp header. Does that really drag in everything? Debug utilities? Boost.Python integration? Boost.Serialization support? Typeof registrations? Support for Zlib and Bzip compression that will require downloading, configuring, building, and linking to additional external libraries? I find all.hpp headers generally useless.
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.
+1. Thanks, Troy. I agree completely. -- Eric Niebler BoostPro Computing http://www.boostpro.com
Eric Niebler wrote:
I don't like the idea of a boost/<lib>/all.hpp header. Does that really drag in everything? Debug utilities? Boost.Python integration? Boost.Serialization support? Typeof registrations? Support for Zlib and Bzip compression that will require downloading, configuring, building, and linking to additional external libraries? I find all.hpp headers generally useless.
If you don't want everything, you wouldn't include the all.hpp header. Such headers are a convenience, particularly for those just learning to use a library (when the constant compilation failure because yet another include directive is needed can turn off a new user). This is no different from what is already happening, except the name of the header would be standardized and its location relative to the library directory would be standardized. It doesn't preclude you from including only the headers you want. What we're trying to address is whether the "include all" header should be boost/<libname>.hpp, boost/<libname>/<libname>.hpp, or boost/<libname>/all.hpp. There are examples of the first two already -- and perhaps even slight variations of those. _____ Rob Stewart robert.stewart@sig.com 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.
Hi, ----- Original Message ----- From: "Stewart, Robert" <Robert.Stewart@sig.com> To: <boost@lists.boost.org> Sent: Friday, October 23, 2009 5:56 PM Subject: Re: [boost] Boost policy for putting headers in boost/ Was: #3541 Support <boost/ptr_map.hpp>
Eric Niebler wrote:
I don't like the idea of a boost/<lib>/all.hpp header. Does that really drag in everything? Debug utilities? Boost.Python integration? Boost.Serialization support? Typeof registrations? Support for Zlib and Bzip compression that will require downloading, configuring, building, and linking to additional external libraries? I find all.hpp headers generally useless.
If you don't want everything, you wouldn't include the all.hpp header. Such headers are a convenience, particularly for those just learning to use a library (when the constant compilation failure because yet another include directive is needed can turn off a new user).
This is no different from what is already happening, except the name of the header would be standardized and its location relative to the library directory would be standardized. It doesn't preclude you from including only the headers you want.
What we're trying to address is whether the "include all" header should be boost/<libname>.hpp, boost/<libname>/<libname>.hpp, or boost/<libname>/all.hpp. There are examples of the first two already -- and perhaps even slight variations of those.
I think the main problem with standardizing boost/<lib>/all.hpp is could clash with a feature named all for a particular domain. Best, Vicente
vicente.botet wrote:
I think the main problem with standardizing boost/<lib>/all.hpp is could clash with a feature named all for a particular domain.
Aside from my not envisioning anything named "all" being useful, your argument is reasonable. If "all" is considered too inclusive, as Eric suggests, then another name is possible. How about "_"? Is "_.hpp" legal in all supported filesystems? Since we're talking about libraries, and not applications, how about "main.hpp?" "main" is still very short and would be consistent. _____ Rob Stewart robert.stewart@sig.com 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.
Hi, On Sat, Oct 24, 2009 at 1:02 AM, Stewart, Robert <Robert.Stewart@sig.com> wrote:
Aside from my not envisioning anything named "all" being useful, your argument is reasonable.
I recall boost::algorithm::all, but admittedly it resides in boost/algorithm/string/predicate.hpp so it is not actually a problem. Regards, Eugene
Stewart, Robert wrote:
vicente.botet wrote:
I think the main problem with standardizing boost/<lib>/all.hpp is could clash with a feature named all for a particular domain.
Aside from my not envisioning anything named "all" being useful, your argument is reasonable.
If "all" is considered too inclusive, as Eric suggests, then another name is possible. How about "_"? Is "_.hpp" legal in all supported filesystems? Since we're talking about libraries, and not applications, how about "main.hpp?" "main" is still very short and would be consistent.
To be honest, I find the lib/main.hpp idea not bad at all (except for the extra typing involved vs. lib.hpp). However, following existing practice, and not breaking existing code, IMO, far outweigh the problem you have with tab completion: that can never be a valid rationale for breaking existing code. 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. Regards, -- Joel de Guzman http://www.boostpro.com http://spirit.sf.net http://www.facebook.com/djowel Meet me at BoostCon http://www.boostcon.com/home http://www.facebook.com/boostcon
Joel de Guzman wrote:
Stewart, Robert wrote:
How about "_"? Is "_.hpp" legal in all supported filesystems? Since we're talking about libraries, and not applications, how about "main.hpp?" "main" is still very short and would be consistent.
To be honest, I find the lib/main.hpp idea not bad at all (except for the extra typing involved vs. lib.hpp). However, following
lib.hpp works fine, too.
existing practice, and not breaking existing code, IMO, far outweigh the problem you have with tab completion: that can never be a valid rationale for breaking existing code.
I agree. However, the tab completion problem merely highlights the noisiness of the directory plus like-named header approach. That also affects directory listings and directory navigation dialogs.
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.
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. #include <boost/libname.hpp> is simpler than #include <boost/libname/libname.hpp> or #include <boost/libname/lib.hpp> but that's not the whole story. Adopting a single approach will break existing libraries: 1. Suppose libname/lib.hpp is the choice. Existing libraries would add libname/lib.hpp and later remove libname.hpp or libname/libname.hpp. 2. Suppose libname + libname.hpp is the choice. Libraries using libname/libname.hpp must add libname.hpp and later remove libname/libname.hpp. 3. Suppose libname/libname.hpp is the choice. Libraries using libname + libname.hpp must add libname/libname.hpp and later remove libname.hpp. The question, then, is which approach is the most helpful across the use cases, when ignoring the breakage? As noted above, referencing the "all" headers in include directives is simplest in #2; is that a sufficient justification for that approach over the others? It doesn't address tab completion or the find-uses-of-lib.hpp-to-improve-build-times use cases, but perhaps those are less important. _____ Rob Stewart robert.stewart@sig.com 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.
2009/10/23 Stewart, Robert <Robert.Stewart@sig.com>
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. -- Nevin Liber <mailto:nevin@eviloverlord.com> (847) 691-1404 Sent from Chicago, IL, United States
On Fri, Oct 23, 2009 at 12:45 PM, Nevin Liber <nevin@eviloverlord.com> wrote:
2009/10/23 Stewart, Robert <Robert.Stewart@sig.com>
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.
Stewart, Robert wrote:
Joel de Guzman wrote:
Stewart, Robert wrote:
How about "_"? Is "_.hpp" legal in all supported filesystems? Since we're talking about libraries, and not applications, how about "main.hpp?" "main" is still very short and would be consistent. To be honest, I find the lib/main.hpp idea not bad at all (except for the extra typing involved vs. lib.hpp). However, following
lib.hpp works fine, too.
existing practice, and not breaking existing code, IMO, far outweigh the problem you have with tab completion: that can never be a valid rationale for breaking existing code.
I agree. However, the tab completion problem merely highlights the noisiness of the directory plus like-named header approach.
It's noisier, true. If we were to rewrite Boost all over again, or if we were to restart from 1999, I'd vote for something unified, similar to your suggestion. But this is 2009. It's too late for that. We can't break the code base.
That also affects directory listings and directory navigation dialogs.
Hmm, never had a problem with that. How is that a problem?
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.
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.
Here's my thoughts on this: * IMO, we can't break the code for just the reason of wanting a cleaner include structure. That is simply not acceptable. * We can't add yet another header policy. Doing so will only add to the confusion. * Newer libraries should pick only one style, and that style, IMO is the fusion style. No, I did not invent that. Since day one, that has been the predominant header organization style of boost. We should dissuade newer libraries from using the other header style (libname/libname.hpp). Again, this should apply to newer libraries only. We can't gratuitously break existing libraries just for the sake of neatness. Regards, -- Joel de Guzman http://www.boostpro.com http://spirit.sf.net http://www.facebook.com/djowel Meet me at BoostCon http://www.boostcon.com/home http://www.facebook.com/boostcon
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Friday 23 October 2009, Eric Niebler wrote:
I don't like the idea of a boost/<lib>/all.hpp header. Does that really drag in everything? Debug utilities? Boost.Python integration? Boost.Serialization support? Typeof registrations? Support for Zlib and Bzip compression that will require downloading, configuring, building, and linking to additional external libraries? I find all.hpp headers generally useless.
How do these objections to boost/D/all.hpp not also apply when it is called boost/D.hpp?
File D.hpp is either standalone (if no directory D exists) or includes all files in subdirectory D. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux)
iEYEARECAAYFAkrh0x4ACgkQ5vihyNWuA4XUJQCbB8wxUTum3dmqzs1W8Xb+JkZk xKkAnjb58qdQwfGf3OVVNpRMzTwZI3wJ =FQaP -----END PGP SIGNATURE-----
2009/10/23 Frank Mori Hess <frank.hess@nist.gov>:
How do these objections to boost/D/all.hpp not also apply when it is called boost/D.hpp?
Presumably the argument is that if "all" doesn't include every single header in the library, then it's misleading, whereas D.hpp can be the "author's cut" of functionality.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Friday 23 October 2009, Scott McMurray wrote:
2009/10/23 Frank Mori Hess <frank.hess@nist.gov>:
How do these objections to boost/D/all.hpp not also apply when it is called boost/D.hpp?
Presumably the argument is that if "all" doesn't include every single header in the library, then it's misleading, whereas D.hpp can be the "author's cut" of functionality.
If you go back and reread the posts I was replying to (or the quote in my post), you'll see exactly what D.hpp was laid out to be: "File D.hpp is either standalone (if no directory D exists) or includes all files in subdirectory D." -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkrh1nMACgkQ5vihyNWuA4Va8QCggfztmH4wn0MlVeGkF0aScVmx ua0An1Mqr/KNWbmaaR6dur5DWTWnT35s =iYNK -----END PGP SIGNATURE-----
Scott McMurray wrote:
2009/10/23 Frank Mori Hess <frank.hess@nist.gov>:
How do these objections to boost/D/all.hpp not also apply when it is called boost/D.hpp?
Presumably the argument is that if "all" doesn't include every single header in the library, then it's misleading, whereas D.hpp can be the "author's cut" of functionality.
Yes. That's the case for proto.hpp. It includes everything except debug utilities and typeof registrations. If I were to add serialization or python support, that would also be left out. A proto/all.hpp would either be inefficient and largely useless or else misleading. I imagine the same is true for most libraries. -- Eric Niebler BoostPro Computing http://www.boostpro.com
----- Original Message ----- From: "Eric Niebler" <eric@boostpro.com> To: <boost@lists.boost.org> Sent: Friday, October 23, 2009 6:56 PM Subject: Re: [boost] Boost policy for putting headers in boost/ Was: #3541 Support <boost/ptr_map.hpp>
Scott McMurray wrote:
2009/10/23 Frank Mori Hess <frank.hess@nist.gov>:
How do these objections to boost/D/all.hpp not also apply when it is called boost/D.hpp?
Presumably the argument is that if "all" doesn't include every single header in the library, then it's misleading, whereas D.hpp can be the "author's cut" of functionality.
Yes. That's the case for proto.hpp. It includes everything except debug utilities and typeof registrations. If I were to add serialization or python support, that would also be left out. A proto/all.hpp would either be inefficient and largely useless or else misleading. I imagine the same is true for most libraries.
I agree with you. boost/<libname>.hpp don't needs to include all the public files. In addition to * typeof registration * serialization * phyton support I will add every 'decoration' to existing types, either from STL or from Boost. In Boost.Synchro I have files defining traits for thread mutex (from Boost.Thread) and for process mutex (from Boost.Interprocess). I as a user don't expect that boost/synchro.hpp will include all the traits files. IMO, it is up to the user to include the specific file. In Boost.Conversion, boost/conversion.hpp includes all the core files, but don' include every specific STD or Boost conversion. If some one needs to use conversions from chrono::duration to posix::time_duration he needs to include explicitly <boost/conversion/boost/chrono_duration_to_posix_time_duration.hpp> Best, Vicente
on Fri Oct 23 2009, Eric Niebler <eric-AT-boostpro.com> wrote:
Scott McMurray wrote:
2009/10/23 Frank Mori Hess <frank.hess@nist.gov>:
How do these objections to boost/D/all.hpp not also apply when it is called boost/D.hpp?
Presumably the argument is that if "all" doesn't include every single header in the library, then it's misleading, whereas D.hpp can be the "author's cut" of functionality.
Yes. That's the case for proto.hpp. It includes everything except debug utilities and typeof registrations. If I were to add serialization or python support, that would also be left out. A proto/all.hpp would either be inefficient and largely useless or else misleading. I imagine the same is true for most libraries.
It's not true for any of my libraries. I think boost/D/all.hpp is a fine idea for those libraries where having a single #include pull in 100% of all headers makes sense. Other libraries shouldn't use it, IMO. They can create their own appropriately-named aggregates with different subsets. It'd be nice --- though not necessary --- to come up with a standard name for the kind of aggregate you'd use for proto.hpp. My intuition tells me that Boost's future health depends on improved modularization, and that getting (non-deprecated) headers out of boost/, so the _official_ interfaces live in library-specific subdirectories, is key to that modularization. -- Dave Abrahams Meet me at BoostCon: http://www.boostcon.com BoostPro Computing http://www.boostpro.com
David Abrahams wrote:
on Fri Oct 23 2009, Eric Niebler <eric-AT-boostpro.com> wrote:
Yes. That's the case for proto.hpp. It includes everything except debug utilities and typeof registrations. If I were to add serialization or python support, that would also be left out. A proto/all.hpp would either be inefficient and largely useless or else misleading. I imagine the same is true for most libraries.
It's not true for any of my libraries. I think boost/D/all.hpp is a
I don't think it is true for proto.hpp either. I'm working on an embedded port and ran into the boost/proto/debug.hpp include just this past weekend. Eric, am I looking at the wrong thing? (boost_1_40_0 release) michael -- ---------------------------------- Michael Caisse Object Modeling Designs www.objectmodelingdesigns.com
on Fri Oct 23 2009, "troy d. straszheim" <troy-AT-resophonic.com> 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/
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.
Fusion is very clean, but I have a problem remembering where to find various files. For that reason, I prefer the MPL's organization, where component xxx can always be used after #include <boost/mpl/xxx.hpp>. There is lower-level modularization, but for the most part the public interfaces are in boost/mpl and subdirectories are reserved for implementation details. -- Dave Abrahams Meet me at BoostCon: http://www.boostcon.com BoostPro Computing http://www.boostpro.com
David Abrahams wrote:
on Fri Oct 23 2009, "troy d. straszheim" <troy-AT-resophonic.com> 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/
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.
Fusion is very clean, but I have a problem remembering where to find various files. For that reason, I prefer the MPL's organization, where component xxx can always be used after #include <boost/mpl/xxx.hpp>. There is lower-level modularization, but for the most part the public interfaces are in boost/mpl and subdirectories are reserved for implementation details.
FWIW, we've solved that by having a flat include directory. It's the include/ dir you see up there. The directory contains all forwarding headers. For instance, see http://tinyurl.com/yj86r8v. You have: #include <boost/fusion/include/deref.hpp> in addition to the modular: #include <boost/fusion/iterator/deref.hpp> Regards, -- Joel de Guzman http://www.boostpro.com http://spirit.sf.net http://www.facebook.com/djowel Meet me at BoostCon http://www.boostcon.com/home http://www.facebook.com/boostcon
Joel de Guzman wrote:
David Abrahams wrote:
on Fri Oct 23 2009, "troy d. straszheim" <troy-AT-resophonic.com> 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/
Fusion is very clean, but I have a problem remembering where to find various files. For that reason, I prefer the MPL's organization, where component xxx can always be used after #include <boost/mpl/xxx.hpp>. There is lower-level modularization, but for the most part the public interfaces are in boost/mpl and subdirectories are reserved for implementation details.
FWIW, we've solved that by having a flat include directory. It's the include/ dir you see up there. The directory contains all forwarding headers. For instance, see http://tinyurl.com/yj86r8v. You have:
#include <boost/fusion/include/deref.hpp>
in addition to the modular:
#include <boost/fusion/iterator/deref.hpp>
That's just confusing. Why would you want multiple copies of the same header or multiple ways to include the same functionality? Besides, wouldn't the equivalent to what Dave noted be the following? #include <boost/fusion/deref.hpp> _____ Rob Stewart robert.stewart@sig.com 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.
Stewart, Robert wrote:
Joel de Guzman wrote:
FWIW, we've solved that by having a flat include directory. It's the include/ dir you see up there. The directory contains all forwarding headers. For instance, see http://tinyurl.com/yj86r8v. You have:
#include <boost/fusion/include/deref.hpp>
in addition to the modular:
#include <boost/fusion/iterator/deref.hpp>
That's just confusing.
It's not for me and for fusion users (never had a complaint).
Why would you want multiple copies of the same header or multiple ways to include the same functionality? Besides, wouldn't the equivalent to what Dave noted be the following?
#include <boost/fusion/deref.hpp>
Then you defeat the neat, modular *and consistent* layout. Regards, -- Joel de Guzman http://www.boostpro.com http://spirit.sf.net http://www.facebook.com/djowel Meet me at BoostCon http://www.boostcon.com/home http://www.facebook.com/boostcon
on Mon Oct 26 2009, Joel de Guzman <joel-AT-boost-consulting.com> wrote:
FWIW, we've solved that by having a flat include directory. It's the include/ dir you see up there. The directory contains all forwarding headers. For instance, see http://tinyurl.com/yj86r8v. You have:
#include <boost/fusion/include/deref.hpp>
in addition to the modular:
#include <boost/fusion/iterator/deref.hpp>
Oh yeah, I forgot about that. Not bad, but the problem is... I tend to forget it. So I reach for boost/fusion/deref.hpp as though all libraries use that convention, and I am slowed down until I can remind myself that fusion is different. Consistency in these little things goes a long way toward ease-of-use. -- Dave Abrahams Meet me at BoostCon: http://www.boostcon.com BoostPro Computing http://www.boostpro.com
David Abrahams wrote:
FWIW, we've solved that by having a flat include directory. It's the include/ dir you see up there. The directory contains all forwarding headers. For instance, see http://tinyurl.com/yj86r8v. You have: #include <boost/fusion/include/deref.hpp> in addition to the modular: #include <boost/fusion/iterator/deref.hpp>
Oh yeah, I forgot about that. Not bad, but the problem is... I tend to forget it. So I reach for boost/fusion/deref.hpp as though all libraries use that convention, and I am slowed down until I can remind myself that fusion is different. Consistency in these little things goes a long way toward ease-of-use.
Just tossing my own experience here. In my own projects I am following this structure: * all public files in a given module is in #include <lib/module/file.hpp> * all implementation details files in a given module are in #include <lib/module/impl/file.hpp> * there is a short-cut header that includes all mandatories (but not the optional) files of a given module in a include/ folder #include <lib/include/module.hpp> I never had the need to have a repeat of each include file of module fil into include tough. -- ___________________________________________ Joel Falcou - Assistant Professor PARALL Team - LRI - Universite Paris Sud XI Tel : (+33)1 69 15 66 35
David Abrahams wrote:
on Mon Oct 26 2009, Joel de Guzman <joel-AT-boost-consulting.com> wrote:
FWIW, we've solved that by having a flat include directory. It's the include/ dir you see up there. The directory contains all forwarding headers. For instance, see http://tinyurl.com/yj86r8v. You have:
#include <boost/fusion/include/deref.hpp>
in addition to the modular:
#include <boost/fusion/iterator/deref.hpp>
Oh yeah, I forgot about that. Not bad, but the problem is... I tend to forget it. So I reach for boost/fusion/deref.hpp as though all libraries use that convention, and I am slowed down until I can remind myself that fusion is different. Consistency in these little things goes a long way toward ease-of-use.
It's always a balance. I advocate a clean modular structure as much as I advocate ease of use. I think the clean layout of Fusion is one of the reasons why people easily get what's going on and the barrier to contributing back to the code-base is lower. If one wants to understand iterators or sequences, they need to look at the headers in only one directory, not distributed all over the place. I also advocate consistency. That is why I chose that structure. It's not different at all, if you think in terms of modularity. Boost is a set of libraries; each library is composed of smaller sub-libraries or components, and so on. The (outermost) main boost goes like this: boost/ libx/ liby/ libx.hpp liby.hpp Some libraries, especially the bigger ones really ought to be broken down into sub-libraries or modules. Following the main header convention, it goes the same for sub-libraries, e.g.: boost/ libx/ modx/ mody/ modx.hpp mody.hpp liby/ libx.hpp liby.hpp You only have one consistent header policy (i.e sub-modules are no different than main modules). If you think about it in that regard, boost/fusion/deref.hpp is actually inconsistent. A header such as boost/libname/foo.hpp is only consistent if libname is monolithic (does not comprise of smaller modules or sub-libraries). IMHO, that is good only for small libraries. Regards, -- Joel de Guzman http://www.boostpro.com http://spirit.sf.net http://www.facebook.com/djowel Meet me at BoostCon http://www.boostcon.com/home http://www.facebook.com/boostcon
Joel de Guzman wrote:
on Mon Oct 26 2009, Joel de Guzman <joel-AT-boost-consulting.com> wrote:
FWIW, we've solved that by having a flat include directory. It's the include/ dir you see up there. The directory contains all forwarding headers. For instance, see http://tinyurl.com/yj86r8v. You have:
#include <boost/fusion/include/deref.hpp>
in addition to the modular:
#include <boost/fusion/iterator/deref.hpp> [snip] I also advocate consistency. That is why I chose that structure. It's not different at all, if you think in terms of modularity. Boost is a set of libraries; each library is composed of smaller sub-libraries or components, and so on. The (outermost) main boost goes like this:
boost/ libx/ liby/ libx.hpp liby.hpp
Some libraries, especially the bigger ones really ought to be broken down into sub-libraries or modules. Following the main header convention, it goes the same for sub-libraries, e.g.:
boost/ libx/ modx/ mody/ modx.hpp mody.hpp liby/ libx.hpp liby.hpp
That is reasonable and defensible, but argues against your include directory. _____ Rob Stewart robert.stewart@sig.com 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.
Stewart, Robert wrote:
Joel de Guzman wrote:
on Mon Oct 26 2009, Joel de Guzman <joel-AT-boost-consulting.com> wrote:
FWIW, we've solved that by having a flat include directory. It's the include/ dir you see up there. The directory contains all forwarding headers. For instance, see http://tinyurl.com/yj86r8v. You have:
#include <boost/fusion/include/deref.hpp>
in addition to the modular:
#include <boost/fusion/iterator/deref.hpp> [snip] I also advocate consistency. That is why I chose that structure. It's not different at all, if you think in terms of modularity. Boost is a set of libraries; each library is composed of smaller sub-libraries or components, and so on. The (outermost) main boost goes like this:
boost/ libx/ liby/ libx.hpp liby.hpp
Some libraries, especially the bigger ones really ought to be broken down into sub-libraries or modules. Following the main header convention, it goes the same for sub-libraries, e.g.:
boost/ libx/ modx/ mody/ modx.hpp mody.hpp liby/ libx.hpp liby.hpp
That is reasonable and defensible, but argues against your include directory.
To be very honest with you, I don't quite like flat includes. That's a bit short of saying, I agree with you. But it's a reasonable compromise, I would say. Some folks just don't want the burden of having to think in terms of modules and includes. Regards, -- Joel de Guzman http://www.boostpro.com http://spirit.sf.net http://www.facebook.com/djowel Meet me at BoostCon http://www.boostcon.com/home http://www.facebook.com/boostcon
on Wed Oct 28 2009, Joel de Guzman <joel-AT-boost-consulting.com> wrote:
#include <boost/fusion/include/deref.hpp>
in addition to the modular:
#include <boost/fusion/iterator/deref.hpp>
Oh yeah, I forgot about that. Not bad, but the problem is... I tend to forget it. So I reach for boost/fusion/deref.hpp as though all libraries use that convention, and I am slowed down until I can remind myself that fusion is different. Consistency in these little things goes a long way toward ease-of-use.
It's always a balance. I advocate a clean modular structure as much as I advocate ease of use. I think the clean layout of Fusion is one of the reasons why people easily get what's going on and the barrier to contributing back to the code-base is lower. If one wants to understand iterators or sequences, they need to look at the headers in only one directory, not distributed all over the place.
Of course I understand the rationale.
I also advocate consistency. That is why I chose that structure. It's not different at all, if you think in terms of modularity.
I have a hard time swallowing that assertion. Your organization makes sense, but please don't deny reality by claiming it's not different from other Boost libraries that established precedent. If you really wanted to be consistent with type_traits, MPL, Bost.Python, et. al., you could have kept all your nice modular structure but moved the headers that are in boost/fusion/include into boost/fusion. Your organization may in fact be superior from a logical standpoint, but the difference from precedent has downsides.
Boost is a set of libraries; each library is composed of smaller sub-libraries or components, and so on. The (outermost) main boost goes like this:
boost/ libx/ liby/ libx.hpp liby.hpp
Some libraries, especially the bigger ones really ought to be broken down into sub-libraries or modules. Following the main header convention, it goes the same for sub-libraries, e.g.:
boost/ libx/ modx/ mody/ modx.hpp mody.hpp liby/ libx.hpp liby.hpp
You only have one consistent header policy (i.e sub-modules are no different than main modules). If you think about it in that regard, boost/fusion/deref.hpp is actually inconsistent.
inconsistent with what?
A header such as boost/libname/foo.hpp is only consistent if libname is monolithic (does not comprise of smaller modules or sub-libraries). IMHO, that is good only for small libraries.
Works for MPL. Nobody ever wonders where to find anything in MPL. I doubt you can say the same for Fusion. There's an extra learning hump to get over and more information to absorb. Not only do I have to know about boost::fusion::invoke if I want to use it, but I either to remember that Fusion has a funky include/ subdirectory where I can find invoke.hpp, or I need to remember that invoke is part of the "functional" module and include fusion/functional.hpp, or that it's in fusion/functional/invocation.hpp, or finally in fusion/functional/invocation/invoke.hpp. I don't care (very much) which convention we choose, but I would very much prefer, for our users' sake, to choose one uniform #include convention that works for all the libraries. -- Dave Abrahams Meet me at BoostCon: http://www.boostcon.com BoostPro Computing http://www.boostpro.com
A header such as boost/libname/foo.hpp is only consistent if libname is monolithic (does not comprise of smaller modules or sub-libraries). IMHO, that is good only for small libraries.
Works for MPL. Nobody ever wonders where to find anything in MPL.
Having just included a bunch of mpl header without looking at the manual once, I agree with that. And no I don't happen to have the names memorized (!), I just thought... "I wonder if the #includes are logical enough that they're called boost/mpl/and.hpp" so I tried it and it all worked first time :-) That said there may be a case to be made for splitting into sub-libraries - we did that with Boost.Math to avoid confusion between a distribution called X and a special function called X. Non-the-less I hope the divisions are obvious enough that most people won't need to look at the manual. So +1 for a mpl/type_traits style of organization from me too, Completely biased yours, John.
John Maddock skrev:
So +1 for a mpl/type_traits style of organization from me too,
+ 1 Given that I pull in <boost/lib/foo.hpp>, we might also consider to require that namespace match: boost::lib::foo f; Given that there are a number of old libraries that does follow this, is there any backwards compatible way to achieve this? -Thorsten
John Maddock wrote:
A header such as boost/libname/foo.hpp is only consistent if libname is monolithic (does not comprise of smaller modules or sub-libraries). IMHO, that is good only for small libraries.
Works for MPL. Nobody ever wonders where to find anything in MPL.
Having just included a bunch of mpl header without looking at the manual once, I agree with that. And no I don't happen to have the names memorized (!), I just thought... "I wonder if the #includes are logical enough that they're called boost/mpl/and.hpp" so I tried it and it all worked first time :-)
That said there may be a case to be made for splitting into sub-libraries - we did that with Boost.Math to avoid confusion between a distribution called X and a special function called X. Non-the-less I hope the divisions are obvious enough that most people won't need to look at the manual.
So +1 for a mpl/type_traits style of organization from me too,
For the record, I am not against this. It is in IMO the logical choice for most libraries. What I am saying is that for bigger libraries, it is logical to organize in modules. When you have modules then that flat organization will start to break. E.g. if "x.hpp" is a header of module "foo" of library "lib", then, the logical structure is: boost/ lib/ foo/ a.hpp foo.hpp lib.hpp Notice that the header for module has the correct header: <boost/lib/foo.hpp> However, components of foo (a.hpp) cannot be hoisted outside its module. Thus, in this case, this is wrong: <boost/lib/a.hpp> Your example is a prime symptom of the breakage: "That said there may be a case to be made for splitting into sub-libraries - we did that with Boost.Math to avoid confusion between a distribution called X and a special function called X.". When a library is modular, clashes are typical, e.g.: boost/ lib/ foo/ a.hpp bar/ a.hpp foo.hpp bar.hpp lib.hpp So, now you have two headers "a.hpp" under different modules, sharing the same name. It then becomes obvious why this is wrong: <boost/lib/a.hpp> Regards, -- Joel de Guzman http://www.boostpro.com http://spirit.sf.net http://www.facebook.com/djowel Meet me at BoostCon http://www.boostcon.com/home http://www.facebook.com/boostcon
on Thu Oct 29 2009, Joel de Guzman <joel-AT-boost-consulting.com> wrote:
So +1 for a mpl/type_traits style of organization from me too,
For the record, I am not against this. It is in IMO the logical choice for most libraries. What I am saying is that for bigger libraries, it is logical to organize in modules.
As I've been saying, that practice doesn't have to be incompatible with the mpl/type_traits style of organization
When you have modules then that flat organization will start to break. E.g. if "x.hpp" is a header of module "foo" of library "lib", then, the logical structure is:
boost/ lib/ foo/ a.hpp foo.hpp lib.hpp
Notice that the header for module has the correct header:
<boost/lib/foo.hpp>
I don't even see x.hpp there.
However, components of foo (a.hpp) cannot be hoisted outside its module. Thus, in this case, this is wrong:
<boost/lib/a.hpp>
Your example is a prime symptom of the breakage: "That said there may be a case to be made for splitting into sub-libraries - we did that with Boost.Math to avoid confusion between a distribution called X and a special function called X.".
When a library is modular, clashes are typical, e.g.:
boost/ lib/ foo/ a.hpp bar/ a.hpp foo.hpp bar.hpp lib.hpp
So, now you have two headers "a.hpp" under different modules, sharing the same name. It then becomes obvious why this is wrong:
<boost/lib/a.hpp>
There are several ways to deal with that. Aside from renaming one of the submodules, you could also have boost/lib/a.hpp #include boost/lib/foo/a.hpp and boost/lib/bar/a.hpp. It's not aesthetically ideal, but it's consistent and easier for users. Those who want to be more selective can still always reach for boost/lib/bar/a.hpp, for example. Have you actually got a name clash situation like that one, BTW? -- Dave Abrahams Meet me at BoostCon: http://www.boostcon.com BoostPro Computing http://www.boostpro.com
David Abrahams wrote:
on Thu Oct 29 2009, Joel de Guzman <joel-AT-boost-consulting.com> wrote:
So +1 for a mpl/type_traits style of organization from me too, For the record, I am not against this. It is in IMO the logical choice for most libraries. What I am saying is that for bigger libraries, it is logical to organize in modules.
As I've been saying, that practice doesn't have to be incompatible with the mpl/type_traits style of organization
When you have modules then that flat organization will start to break. E.g. if "x.hpp" is a header of module "foo" of library "lib", then, the logical structure is:
boost/ lib/ foo/ a.hpp foo.hpp lib.hpp
Notice that the header for module has the correct header:
<boost/lib/foo.hpp>
I don't even see x.hpp there.
Ooops. I meant a.hpp, of course :)
However, components of foo (a.hpp) cannot be hoisted outside its module. Thus, in this case, this is wrong:
<boost/lib/a.hpp>
Your example is a prime symptom of the breakage: "That said there may be a case to be made for splitting into sub-libraries - we did that with Boost.Math to avoid confusion between a distribution called X and a special function called X.".
When a library is modular, clashes are typical, e.g.:
boost/ lib/ foo/ a.hpp bar/ a.hpp foo.hpp bar.hpp lib.hpp
So, now you have two headers "a.hpp" under different modules, sharing the same name. It then becomes obvious why this is wrong:
<boost/lib/a.hpp>
There are several ways to deal with that. Aside from renaming one of the submodules, you could also have boost/lib/a.hpp #include boost/lib/foo/a.hpp and boost/lib/bar/a.hpp. It's not aesthetically ideal, but it's consistent and easier for users. Those who want to be more selective can still always reach for boost/lib/bar/a.hpp, for example.
Have you actually got a name clash situation like that one, BTW?
Yes. Spirit2 includes both "classic" and "qi" in there as well as "karma". There are lots of similar names such as rule.hpp, grammar.hpp that are found in each of the modules. In our flat include, we have to prepend them with "classic", "qi" and "karma" to disambiguate. Compare these (flat vs. modular) files for instance: #include <boost/spirit/qi/nonterminal/grammar.hpp> #include <boost/spirit/include/qi_grammar.hpp> And this: #include <boost/spirit/karma/nonterminal/grammar.hpp> #include <boost/spirit/include/karma_grammar.hpp> Such a workaround is reminiscent of pre namespace C++. John Maddock hints at a similar scenario that prompted them to make Boost.Math modular "to avoid confusion between a distribution called X and a special function called X". The same underlying reasons why we use namespaces apply to header files. IMHO, it is for the best interest of Boost to evolve from being flat to being more modular. I am lobbying for that. It's just the "right" way to go! :-) Regards, -- Joel de Guzman http://www.boostpro.com http://spirit.sf.net http://www.facebook.com/djowel Meet me at BoostCon http://www.boostcon.com/home http://www.facebook.com/boostcon
-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Joel de Guzman Sent: Friday, October 30, 2009 1:33 AM To: boost@lists.boost.org Subject: Re: [boost] Boost policy for putting headers in boost/ Was: #3541Support <boost/ptr_map.hpp>
header files. IMHO, it is for the best interest of Boost to evolve from being flat to being more modular. I am lobbying for that.
It's just the "right" way to go! :-)
+1 --- Paul A. Bristow Prizet Farmhouse Kendal, UK LA8 8AB +44 1539 561830, mobile +44 7714330204 pbristow@hetp.u-net.com
Joel de Guzman wrote:
David Abrahams wrote:
Have you actually got a name clash situation like that one, BTW?
Yes. Spirit2 includes both "classic" and "qi" in there as well as "karma". There are lots of similar names such as rule.hpp, grammar.hpp that are found in each of the modules. In our flat include, we have to prepend them with "classic", "qi" and "karma" to disambiguate. Compare these (flat vs. modular) files for instance:
#include <boost/spirit/qi/nonterminal/grammar.hpp> #include <boost/spirit/include/qi_grammar.hpp>
And this:
#include <boost/spirit/karma/nonterminal/grammar.hpp> #include <boost/spirit/include/karma_grammar.hpp>
That makes the "include" subdirectory that much worse. There should only be one way to find the required header contents. I don't have a problem with the general idea of modularizing a library. It does follow the top level directory pattern nicely. I still would rather have less clutter in a given directory by pushing something akin to "all.hpp" into the subdirectory rather than near-duplicating the directory name, but the alternative is consistent and usable. _____ Rob Stewart robert.stewart@sig.com 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.
David Abrahams wrote:
on Wed Oct 28 2009, Joel de Guzman <joel-AT-boost-consulting.com> wrote:
#include <boost/fusion/include/deref.hpp>
in addition to the modular:
#include <boost/fusion/iterator/deref.hpp>
Oh yeah, I forgot about that. Not bad, but the problem is... I tend to forget it. So I reach for boost/fusion/deref.hpp as though all libraries use that convention, and I am slowed down until I can remind myself that fusion is different. Consistency in these little things goes a long way toward ease-of-use. It's always a balance. I advocate a clean modular structure as much as I advocate ease of use. I think the clean layout of Fusion is one of the reasons why people easily get what's going on and the barrier to contributing back to the code-base is lower. If one wants to understand iterators or sequences, they need to look at the headers in only one directory, not distributed all over the place.
Of course I understand the rationale.
I also advocate consistency. That is why I chose that structure. It's not different at all, if you think in terms of modularity.
I have a hard time swallowing that assertion. Your organization makes sense, but please don't deny reality by claiming it's not different from other Boost libraries that established precedent.
I'm not sure I can swallow that either. AFAIR, it was spirit that was one of the first libraries to include sub-libraries. At that time, there was no established precedent yet (for non monolithic libraries). That was roughly at the same time when MPL was taking shape IIRC. Fusion just followed through the spirit organizational structure and at the same time borrowed/stole much of the best from MPL.
If you really wanted to be consistent with type_traits, MPL, Bost.Python, et. al., you could have kept all your nice modular structure but moved the headers that are in boost/fusion/include into boost/fusion. Your organization may in fact be superior from a logical standpoint, but the difference from precedent has downsides.
Boost is a set of libraries; each library is composed of smaller sub-libraries or components, and so on. The (outermost) main boost goes like this:
boost/ libx/ liby/ libx.hpp liby.hpp
Some libraries, especially the bigger ones really ought to be broken down into sub-libraries or modules. Following the main header convention, it goes the same for sub-libraries, e.g.:
boost/ libx/ modx/ mody/ modx.hpp mody.hpp liby/ libx.hpp liby.hpp
You only have one consistent header policy (i.e sub-modules are no different than main modules). If you think about it in that regard, boost/fusion/deref.hpp is actually inconsistent.
inconsistent with what?
A header such as boost/libname/foo.hpp is only consistent if libname is monolithic (does not comprise of smaller modules or sub-libraries). IMHO, that is good only for small libraries.
Works for MPL. Nobody ever wonders where to find anything in MPL. I doubt you can say the same for Fusion. There's an extra learning hump
I agree, and it's a trade off. That is why we introduced the include directory of flat includes.
to get over and more information to absorb. Not only do I have to know about boost::fusion::invoke if I want to use it, but I either to remember that Fusion has a funky include/ subdirectory where I can find invoke.hpp, or I need to remember that invoke is part of the "functional" module and include fusion/functional.hpp, or that it's in fusion/functional/invocation.hpp, or finally in fusion/functional/invocation/invoke.hpp.
Agreed. Again, this is the point where modularity and ease of use are counteracting forces. Yet, we just can't throw one for the other. I still believe a good compromise is the include directory.
I don't care (very much) which convention we choose, but I would very much prefer, for our users' sake, to choose one uniform #include convention that works for all the libraries.
Much of this is highly subjective. I tried once to formulate a header/namespace policy that will be uniform for all. What I found is that a consensus is very difficult to reach. It's almost the same as naming guidelines. Tough! Some folks are very religious on this, even. I can be ok with whatever is consensus as long as you don't force me to give up the modular structure of the libraries I am concerned with. Regards, -- Joel de Guzman http://www.boostpro.com http://spirit.sf.net http://www.facebook.com/djowel Meet me at BoostCon http://www.boostcon.com/home http://www.facebook.com/boostcon
Am Wednesday 28 October 2009 18:44:30 schrieb David Abrahams:
Works for MPL. Nobody ever wonders where to find anything in MPL.
...
I don't care (very much) which convention we choose, but I would very much prefer, for our users' sake, to choose one uniform #include convention that works for all the libraries.
from the users perspective alone, you'd expect directories to match namespaces and filenames.hpp to match classes (or something that identifies > 1 classes). i.e. boost::mpl::and is in boost/mpl/and.hpp this would overcrowd some directories, especially boost/*, but since identifiers in namespace boost are already unique that isn't a problem from the user's perspective. it might create all sorts of maintenance issues though, having files from dozends of different boost libraries in the same directory.
On Fri, Oct 23, 2009 at 3:39 PM, Stewart, Robert <Robert.Stewart@sig.com> wrote:
Olaf van der Spek wrote:
On Fri, Oct 23, 2009 at 3:18 PM, Frank Mori Hess <frank.hess@nist.gov> 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?
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@nist.gov> 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@sig.com 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.
On Fri, Oct 23, 2009 at 4:33 PM, Stewart, Robert <Robert.Stewart@sig.com> 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@nist.gov> 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.
Olaf van der Spek wrote:
On Fri, Oct 23, 2009 at 4:33 PM, Stewart, Robert <Robert.Stewart@sig.com> 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@sig.com 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.
-----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@sig.com> wrote:
Olaf van der Spek wrote:
On Fri, Oct 23, 2009 at 3:18 PM, Frank Mori Hess
<frank.hess@nist.gov> 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-----
participants (21)
-
Christopher Jefferson -
David Abrahams -
Eric Niebler -
Eugene Wee -
Frank Mori Hess -
Jeff Flinn -
joel -
Joel de Guzman -
John Maddock -
Matthew Chambers -
Michael Caisse -
Nevin Liber -
Olaf van der Spek -
OvermindDL1 -
Paul A. Bristow -
Scott McMurray -
Stefan Strasser -
Stewart, Robert -
Thorsten Ottosen -
troy d. straszheim -
vicente.botet