The Concept Traits Library: naming - opinions sought
Hi all. In the operator/concept traits library (now renamed Concept Traits Library) that I posted about a while ago, there were, as Tobias Schwinger pointed out in a mail, several filenames that were longer than then Boost 31 character maximum. I was aware of this, but didn't know how stringent this requirement was (7 of 37 standard concept traits have more than 31 characters, the maximum being 37 characters). However, as I understand, it's not just platforms, but also things like media (such as CDs) that may impose this limit, making it more serious. 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> Tobias suggested the following (the "model" part is still not decided, and may be considered separately): #include <boost/concept_traits/model/std/constructbility/default.hpp> #include <boost/concept_traits/model/std/container/random_access.hpp> #include <boost/concept_traits/model/std/iterator/random_access.hpp> #include <boost/concept_traits/model/std/function/generator.hpp> The traits would still retain their names, so <boost/concept_traits/model/std/iterator/random_access.hpp> would have is_random_access_iterator<T>. To consider the issue, we looked at Boost's type_traits, where all the traits are in the same directory, as well as libraries like MPL, where it appears to move to <boost/mpl/arithmetic/plus.hpp> (from <boost/mpl/plus.hpp>) - at least, the "arithmetic" directory is there. The same goes for PP-lib. However, in the case of CTL, the components would then have a different name than the source file, so I felt like getting some more opinions on the subject. What do you think? Opinions on whether or not "model" should be included in the path is also welcome. Bear in mind in that case that the "concept_traits" directory will also contain the "operator" (for the operator traits) and "utility" (for components to define new traits), so "model" might more clearly separate out that these are the concept traits, themselves. Also, what is the opinion on singular/plural? Boost's type_traits is plural (and this is quite similar to them), but there are otherwise mostly singular names in Boost (and the library requirements states that libraries should usually be singular). Regards, Terje
Just one quick note: Terje Slettebø wrote:
The library will be put in a CVS at the http://www.neoscientists.org/
Boost specific information can be found here: http://tinyurl.com/5jg8c The CVS currently only contains the merged contents of two archives available for download there. The current content will be replaced after restructuring. Regards, Tobias
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 :-) If possible I would prefere the filename and trait name to be the same, is there any way we can shorten the problem names without messing the whole thing up? John.
From John Maddock <john@johnmaddock.co.uk>:
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_adaptable_binary_function.hpp (32) is_adaptable_binary_predicate.hpp (33) is_hashed_associative_container.hpp (35) [*] is_multiple_associative_container.hpp (37) is_pair_associative_container.hpp (33) is_simple_associative_container.hpp (35) is_sorted_associative_container.hpp (35) is_unique_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:
is_nullary_metafunction_class.hpp (33) is_binary_metafunction_class.hpp (32) is_extensible_associative_sequence.hpp (38)
If possible I would prefere the filename and trait name to be the same
Me too.
is 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 filename. Granted, that may happen with the alternative directory structure, as well. For comparison, here's how it might be done with that: std/function/adaptable_binary.hpp std/predicate/adaptable_binary.hpp std/container/hashed_associativer.hpp std/container/multiple_associative.hpp std/container/pair_associative.hpp std/container/simple_associative.hpp std/container/sorted_associative.hpp std/container/unique_associative.hpp boost/mpl/metafunction_class/nullary.hpp boost/mpl/metafunction_class/binary.hpp boost/mpl/sequence/extensible_associative.hpp 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. Regards, Terje
I know. :) (They were, however, good examples for the alternative directory structure.) Here are the problematic ones:
is_adaptable_binary_function.hpp (32) is_adaptable_binary_predicate.hpp (33)
Do we need the "adaptable" bit? If yes, then how about: is_adaptable_binary_func.hpp is_adaptable_binary_pred.hpp Maybe not ideal, but as long as you are consistent it should be OK.
is_hashed_associative_container.hpp (35) [*] is_multiple_associative_container.hpp (37) is_pair_associative_container.hpp (33) is_simple_associative_container.hpp (35) is_sorted_associative_container.hpp (35) is_unique_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?
"assoc" sounds good to me. BTW, don't get too hung up on names it could be a bicycle shed issue again :-) John.
From: "John Maddock" <john@johnmaddock.co.uk>
I know. :) (They were, however, good examples for the alternative directory structure.) Here are the problematic ones:
is_adaptable_binary_function.hpp (32) is_adaptable_binary_predicate.hpp (33)
Do we need the "adaptable" bit?
I found it harder to abbreviate "adaptable" than "function", though.
If yes, then how about:
is_adaptable_binary_func.hpp is_adaptable_binary_pred.hpp
Maybe not ideal, but as long as you are consistent it should be OK.
Yeah.
is_hashed_associative_container.hpp (35) [*] is_multiple_associative_container.hpp (37) is_pair_associative_container.hpp (33) is_simple_associative_container.hpp (35) is_sorted_associative_container.hpp (35) is_unique_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?
"assoc" sounds good to me.
Me too.
BTW, don't get too hung up on names it could be a bicycle shed issue again :-)
Don't worry; we have, after all, working code, and the naming issue is not what is most important. However, I think you'll agree that names _are_ important, and we're talking about the public interface, here, not some obscure implementation component. Recall (or browse) the long discussion to determine the Boost naming standard, and other requirements, the very same requirements that lead to the considerations in this thread. I don't think anyone would call the discussions at the time "bicycle shed"-discussions, either, and for good reason: they had profound consequences. I'm not making a big thing out of this - I merely asked, to get some input from the esteemed members of the Boost community, as it can help to get more views on an issue, and avoid doing something stupid. To put this in context: This discussion has spanned a total of 9 messages, involving postings from 5 people, and responses, over several days. What is at stake is the names for about 60 type traits - 60 public names, a little less than the number of traits in the Boost type traits library. In contrast, the equally recent "Renaming "c++boost.gif"" has spanned _34_ postings, thus far! What is it about? It's about that logo image we have, its filename and filetype. It might be called "foobar.gif", and hardly anyone would notice, and it certainly won't break any code. But if you change the name of 60 traits that are in use, someone _will_ notice, because their systems no longer work - and neither will any other system using it. Yet, I don't think the "logo"-discussion is a case of "bicycle shed", either; just careful attention to detail and portability. As for the names for the concept traits and "bicycle shed" - I think not! Anyway, we're keeping the names as they are, for now (except moving to a single top-level directory "concept_traits"). We didn't really come to an agreement on whether to shorten the names over directories, or use abbreviated names for the files. Regards, Terje
"Terje Slettebø" <tslettebo@broadpark.no> wrote in message news:044f01c4adf0$ab9fcf30$0300000a@pc...
From: "John Maddock" <john@johnmaddock.co.uk> Me too.
BTW, don't get too hung up on names it could be a bicycle shed issue again :-)
Don't worry; we have, after all, working code, and the naming issue is not what is most important.
FWIW I have been reading the previous discussion and found the function style filters , whatever v. interesting, but Possibly like others I havent really got any constructive suggestions.... I am just voyuerising. Most important thing seems to be the pragmatic one... compile times, and that the mechanisms involved in the library may turn out to be as useful as the end result. The big question (Which I hope will be dicussed at the next big C++ meeting?) is what will compiler authors make of Concepts with a big C. IOW Are they ever going to be practical. (It seems that decltype, which IMO Everyone wants, too may need similar heavyweight speculative instantiation,backout etc.) The library here certainly has some flavour of something to focus those discussions on. regards Andy Little
From: "Andy Little" <andy@servocomm.freeserve.co.uk>
By the way, in my recent reply to John Maddock, the next last paragraph may have seemed harsher than it was meant (due to the exclamation mark). I wasn't upset, or anything; it was just meant for emphasis. Now to your posting.
"Terje Slettebø" <tslettebo@broadpark.no> wrote in message news:044f01c4adf0$ab9fcf30$0300000a@pc...
From: "John Maddock" <john@johnmaddock.co.uk> Me too.
BTW, don't get too hung up on names it could be a bicycle shed issue again :-)
Don't worry; we have, after all, working code, and the naming issue is not what is most important.
FWIW I have been reading the previous discussion and found the function style filters , whatever v. interesting, but Possibly like others I havent really got any constructive suggestions.... I am just voyuerising. Most important thing seems to be the pragmatic one... compile times, and that the mechanisms involved in the library may turn out to be as useful as the end result. The big question (Which I hope will be dicussed at the next big C++ meeting?) is what will compiler authors make of Concepts with a big C.
Yes, that's a very good question. It seems we've only started on that journey, with the three papers by Bjarne Stroustrup and Gabriel Dos Reis (at the C++ standards site). As you know from the comp.std.c++ discussion about this a while ago (http://www.google.com/groups?selm=2873fa46.0407311135.33810bdb%40posting.go ogle.com), one of the open questions may be - if the "usage" way of specifying concepts is used - to quote from the thread: --- Start quote --- Howard Hinnant: | > At the time I asked for my "compile time bool", compiler writers assured | > me that they can not back out of arbitrarily complex expressions when a | > compile time error is met. And I believe them. Gabriel Dos Reis: At the Kona meeting, someone (unfortunately I cannot remember the name) pointed out that that problem has a solution: just dump the current state before doing a speculative instantiation! Yes, you don't want your C++ compiler do that often :-) :-) --- End quote --
IOW Are they ever going to be practical. (It seems that decltype, which IMO Everyone wants, too may need similar heavyweight speculative instantiation,backout etc.)
Yes, for the SFINAE part of that proposal.
The library here certainly has some flavour of something to focus those discussions on.
Thanks. One idea is to have something to experiment on, so to speak, so that we can determine what is needed, to do robust concept checking. For example, there are several remainding issues in the library/language: - Classes with overloaded function call operator can only be detected with an exact match signature (no implicit conversions permitted), since operator() have to be member functions, unlike most of the operators. The same goes for the member access (operator->) and index operator (operator[]). So one step might be to allow them to be free functions. - Constructors can't be detected, because, they, too, have to be member functions, and are unnamed. The assignment operator has similar issues, including compiler-generated defaults, which also goes for the address-of and comma operator (some of this is considered by the standards committee with an "explicit" class - http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2004/n1582.pdf). These are certainly smaller changes than adding support for concepts in the language, and they might be useful, anyway, for introspection purposes. Another way of approaching this, rather than stretching SFINAE way beyond what it was intended for, :) is with a compile-time introspection framework (like that being worked on by Daveed Vandevoorde - http://www.vandevoorde.com/Daveed/News/Archives/000014.html). As you see, many approaches. :) Regards, Terje
Terje Slettebø writes:
In the operator/concept traits library (now renamed Concept Traits Library) that I posted about a while ago, there were, as Tobias Schwinger pointed out in a mail, several filenames that were longer than then Boost 31 character maximum. I was aware of this, but didn't know how stringent this requirement was (7 of 37 standard concept traits have more than 31 characters, the maximum being 37 characters). However, as I understand, it's not just platforms, but also things like media (such as CDs) that may impose this limit, making it more serious.
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>
Tobias suggested the following (the "model" part is still not decided, and may be considered separately):
#include <boost/concept_traits/model/std/constructbility/default.hpp> #include <boost/concept_traits/model/std/container/random_access.hpp> #include <boost/concept_traits/model/std/iterator/random_access.hpp> #include <boost/concept_traits/model/std/function/generator.hpp>
I would keep the "is_" part and try to keep the general purpose traits intact: #include <boost/concept_traits/model/std/is_default_constructible.hpp> #include <boost/concept_traits/model/std/container/is_random_access.hpp> #include <boost/concept_traits/model/std/iterator/is_random_access.hpp> #include <boost/concept_traits/model/std/function/is_generator.hpp> "constructbility/default.hpp" is simply confusing.
The traits would still retain their names, so <boost/concept_traits/model/std/iterator/random_access.hpp> would have is_random_access_iterator<T>.
To consider the issue, we looked at Boost's type_traits, where all the traits are in the same directory, as well as libraries like MPL, where it appears to move to <boost/mpl/arithmetic/plus.hpp> (from <boost/mpl/plus.hpp>) - at least, the "arithmetic" directory is there.
Actually, it's the other way around -- they *used* to reside inside the directory, but at some point were moved to the top level. There are pros and cons to both ways.
The same goes for PP-lib.
However, in the case of CTL, the components would then have a different name than the source file, so I felt like getting some more opinions on the subject.
What do you think?
Opinions on whether or not "model" should be included in the path is also welcome. Bear in mind in that case that the "concept_traits" directory will also contain the "operator" (for the operator traits)
Understand this one, ...
and "utility" (for components to define new traits),
... but not this.
so "model" might more clearly separate out that these are the concept traits, themselves.
IMO just "std" is enough.
Also, what is the opinion on singular/plural? Boost's type_traits is plural (and this is quite similar to them), but there are otherwise mostly singular names in Boost (and the library requirements states that libraries should usually be singular).
IMO this one should be plural ("concept_traits"). -- Aleksey Gurtovoy MetaCommunications Engineering
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>
Tobias suggested the following (the "model" part is still not decided, and may be considered separately):
#include <boost/concept_traits/model/std/constructbility/default.hpp> #include <boost/concept_traits/model/std/container/random_access.hpp> #include <boost/concept_traits/model/std/iterator/random_access.hpp> #include <boost/concept_traits/model/std/function/generator.hpp>
I would keep the "is_" part and try to keep the general purpose traits intact:
#include <boost/concept_traits/model/std/is_default_constructible.hpp> #include <boost/concept_traits/model/std/container/is_random_access.hpp> #include <boost/concept_traits/model/std/iterator/is_random_access.hpp> #include <boost/concept_traits/model/std/function/is_generator.hpp>
This silly filename length limit. :) Maybe if we wait long enough, it will go away? ;) This was only halfway a joke: 1. While the ISO 9660 CD-ROM standard has a maximum of 31 characters for filenames, the Joliet extension supports up to 64 characters. 2. While MacOS 9 has the same maximum as ISO 9660, MaxOS X supports up to 255 characters. Some problems _do_ go away "by themselves"... ;)
To consider the issue, we looked at Boost's type_traits, where all the traits are in the same directory, as well as libraries like MPL, where it appears to move to <boost/mpl/arithmetic/plus.hpp> (from <boost/mpl/plus.hpp>) - at least, the "arithmetic" directory is there.
Actually, it's the other way around -- they *used* to reside inside the directory, but at some point were moved to the top level. There are pros and cons to both ways.
Ok. Thanks for the update on that.
Opinions on whether or not "model" should be included in the path is also welcome. Bear in mind in that case that the "concept_traits" directory will also contain the "operator" (for the operator traits)
Understand this one, ...
and "utility" (for components to define new traits),
... but not this.
Maybe it's too vague.
so "model" might more clearly separate out that these are the concept traits, themselves.
IMO just "std" is enough.
Also, what is the opinion on singular/plural? Boost's type_traits is plural (and this is quite similar to them), but there are otherwise mostly singular names in Boost (and the library requirements states that libraries should usually be singular).
IMO this one should be plural ("concept_traits").
Agreed. Thanks for your comments. Regards, Terje
From: "Aleksey Gurtovoy" <agurtovoy@meta-comm.com>
Terje Slettebø writes:
To consider the issue, we looked at Boost's type_traits, where all the traits are in the same directory, as well as libraries like MPL, where
it
appears to move to <boost/mpl/arithmetic/plus.hpp> (from <boost/mpl/plus.hpp>) - at least, the "arithmetic" directory is there.
Actually, it's the other way around -- they *used* to reside inside the directory, but at some point were moved to the top level. There are pros and cons to both ways.
Has there been a discussion about this on Boost or elsewhere, in the past, and if so, do you have a subject line I could search for? It could be helpful, to review those pros and cons. Regards, Terje
From: =?iso-8859-1?Q?Terje_Sletteb=F8?= <tslettebo@broadpark.no>
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>
Tobias suggested the following (the "model" part is still not decided, and may be considered separately):
#include <boost/concept_traits/model/std/constructbility/default.hpp> #include <boost/concept_traits/model/std/container/random_access.hpp> #include <boost/concept_traits/model/std/iterator/random_access.hpp> #include <boost/concept_traits/model/std/function/generator.hpp>
The traits would still retain their names, so <boost/concept_traits/model/std/iterator/random_access.hpp> would have is_random_access_iterator<T>.
While the Boost penchant is for everything in its own header, what about grouping them into common headers? You could put the implementation of each in a separate, cryptically named header included in the common one, too. (The cipher for the included filenames doesn't have to be strong, just enough to encode things in the maximum filename length limit without much worry about readability.) Thus: #include <boost/concept_traits/model/std/is_default_constructible.hpp> #include <boost/concept_traits/model/std/container.hpp> #include <boost/concept_traits/model/std/iterator.hpp> #include <boost/concept_traits/model/std/function.hpp> -- Rob Stewart stewart@sig.com Software Engineer http://www.sig.com Susquehanna International Group, LLP using std::disclaimer;
participants (6)
-
Aleksey Gurtovoy -
Andy Little -
John Maddock -
Rob Stewart -
Terje Slettebø -
Tobias Schwinger