From: Terje Slettebø (tslettebo_at_[hidden])
Date: 2004-10-04 11:40:31
>From John Maddock <john_at_[hidden]>:
> > The library will be put in a CVS at the http://www.neoscientists.org/
> > server, and we're not sure how to deal with the maximum filename length.
> > The
> > current directory structure is, e.g.:
> > #include <boost/concept_traits/std/is_default_constructible.hpp>
> > #include <boost/concept_traits/std/is_random_access_container.hpp>
> > #include <boost/concept_traits/std/is_random_access_iterator.hpp>
> > #include <boost/concept_traits/std/is_generator.hpp>
> Not good examples - those are all under the limit :-)
I know. :) (They were, however, good examples for the alternative directory
structure.) Here are the problematic ones:
is_hashed_associative_container.hpp (35) [*]
[*] Ok, not standard yet, but used in the N1443 proposal.
As you can see, it's mostly the associative containers that has a problem.
Perhaps shorten the filename (and trait?) "associative" -> "assoc"? That
keeps it just under the limit. Then what about the two first?
>From the MPL concept traits:
> If possible I would prefere the filename and trait name to be the same
> there any way we can shorten the problem names without messing the whole
> thing up?
Well, any suggestions for that is welcome.
I'm just concerned with that if some of the traits use a shortened name
(compared to the concept name), then the user may have to look up each
trait, to find the filename, rather than using the concept name for the
Granted, that may happen with the alternative directory structure, as well.
For comparison, here's how it might be done with that:
To me, "boost/mpl/sequence/extensible_associative.hpp" looks a little
backwards (and no mentioning that the trait is actually named
"is_extensible_associative_sequence"), but if the alternative is to go
beyond the filename limit... :/
Thanks for the feedback.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk