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