I discovered, from asking a question on the user NG, the Concept Traits Library ( mentioned at https://svn.boost.org/trac/boost/wiki/LibrariesUnderConstruction#Boost.Conce... ) in the Boost sandbox by Terje Slettebø and Tobias Schwinger last dated almost 6 years ago. From e-mailing Terje Slettebø I discovered that he did not have time to work on it further or submit it to Boost, since he has been working in other areas for many years as part of his job. Tobias Schwinger's e-mail address was not in the documentation so I was not able to contact him. Other Boost TMP programmers also seemed to have helped to contribute to this library. How did this library slip under the raider, so to speak ? This is a fantastic library with many useful metafunctions for the TMP programmer. For my own particular use the operator metafunctions alone are incredibly useful, but there are many more metafunctions testing for many concepts covering the STL and MPL. The documentation is also very good and there is a complete set of tests. Have I missed anything in terms of other later libraries superceding the functionality that was in this one ? Are the techniques used in this library flawed in any way ? I would love to see this library as part of Boost, if just for the operator metafunctions, and have told Terje Slettebø so.
Le 10/07/2010 12:50, Edward Diener a écrit :
Have I missed anything in terms of other later libraries superceding the functionality that was in this one ? Are the techniques used in this library flawed in any way ? I would love to see this library as part of Boost, if just for the operator metafunctions, and have told Terje Slettebø so.
C++0x has more or less "native" support to do these things better, so I suppose that might have influenced the decision to not continue the work on that library.
On 10 Jul 2010, at 12:55, Mathias Gaunard wrote:
Le 10/07/2010 12:50, Edward Diener a écrit :
Have I missed anything in terms of other later libraries superceding the functionality that was in this one ? Are the techniques used in this library flawed in any way ? I would love to see this library as part of Boost, if just for the operator metafunctions, and have told Terje Slettebø so.
C++0x has more or less "native" support to do these things better, so I suppose that might have influenced the decision to not continue the work on that library.
No, concepts are not in the final version of C++0x, due to (in my opinion) insufficent experience of implementation and usage. Chris
On 7/10/2010 7:55 AM, Mathias Gaunard wrote:
Le 10/07/2010 12:50, Edward Diener a écrit :
Have I missed anything in terms of other later libraries superceding the functionality that was in this one ? Are the techniques used in this library flawed in any way ? I would love to see this library as part of Boost, if just for the operator metafunctions, and have told Terje Slettebø so.
C++0x has more or less "native" support to do these things better, so I suppose that might have influenced the decision to not continue the work on that library.
Just the operator metafunctions in the CTL are useful even without the attempts to add concepts in the form of metafuncions. I do not think C++0x, which is still a year or more away, has any "native" support which would allow me to determine whether a type has an operator. There are also useful metafunctions in the CTL which extend type_traits in type_traits_ext unless these exist somewhere else in Boost I do not know about.
AMDG Edward Diener wrote:
Just the operator metafunctions in the CTL are useful even without the attempts to add concepts in the form of metafuncions. I do not think C++0x, which is still a year or more away, has any "native" support which would allow me to determine whether a type has an operator.
I believe that extended SFINAE makes it a lot easier. In Christ, Steven Watanabe
On 7/10/2010 10:57 AM, Steven Watanabe wrote:
AMDG
Edward Diener wrote:
Just the operator metafunctions in the CTL are useful even without the attempts to add concepts in the form of metafuncions. I do not think C++0x, which is still a year or more away, has any "native" support which would allow me to determine whether a type has an operator.
I believe that extended SFINAE makes it a lot easier.
Thanks for the information. Does Boost currently have a macro which checks for extended SFINAE for any compilers which may support it ?
Le 10/07/2010 18:13, Edward Diener a écrit :
On 7/10/2010 10:57 AM, Steven Watanabe wrote:
AMDG
Edward Diener wrote:
Just the operator metafunctions in the CTL are useful even without the attempts to add concepts in the form of metafuncions. I do not think C++0x, which is still a year or more away, has any "native" support which would allow me to determine whether a type has an operator.
I believe that extended SFINAE makes it a lot easier.
Thanks for the information. Does Boost currently have a macro which checks for extended SFINAE for any compilers which may support it ?
I introduced it a while ago but I'm not certain it works correctly. BOOST_NO_SFINAE_EXPR should be defined when the compiler doesn't support it. Note it works in GCC, without the need for the C++0x mode, since 4.4, though 4.5 seems to solve a few bugs related to it.
On 7/11/2010 4:37 AM, Mathias Gaunard wrote:
Le 10/07/2010 18:13, Edward Diener a écrit :
On 7/10/2010 10:57 AM, Steven Watanabe wrote:
AMDG
Edward Diener wrote:
Just the operator metafunctions in the CTL are useful even without the attempts to add concepts in the form of metafuncions. I do not think C++0x, which is still a year or more away, has any "native" support which would allow me to determine whether a type has an operator.
I believe that extended SFINAE makes it a lot easier.
Thanks for the information. Does Boost currently have a macro which checks for extended SFINAE for any compilers which may support it ?
I introduced it a while ago but I'm not certain it works correctly.
BOOST_NO_SFINAE_EXPR should be defined when the compiler doesn't support it.
Is this for lack of support of extended SFINAE in C++0x ? If so, why is listed in the Boost Macro Reference in the Config documentation as a macro which indicates a defect from the current C++ standard ?
Le 12/07/2010 17:34, Edward Diener a écrit :
On 7/11/2010 4:37 AM, Mathias Gaunard wrote:
Le 10/07/2010 18:13, Edward Diener a écrit :
On 7/10/2010 10:57 AM, Steven Watanabe wrote:
AMDG
Edward Diener wrote:
Just the operator metafunctions in the CTL are useful even without the attempts to add concepts in the form of metafuncions. I do not think C++0x, which is still a year or more away, has any "native" support which would allow me to determine whether a type has an operator.
I believe that extended SFINAE makes it a lot easier.
Thanks for the information. Does Boost currently have a macro which checks for extended SFINAE for any compilers which may support it ?
I introduced it a while ago but I'm not certain it works correctly.
BOOST_NO_SFINAE_EXPR should be defined when the compiler doesn't support it.
Is this for lack of support of extended SFINAE in C++0x ? If so, why is listed in the Boost Macro Reference in the Config documentation as a macro which indicates a defect from the current C++ standard ?
It's not C++0x-specific. Albeit C++0x explicitly mandates this feature, it was a fairly fuzzy area in C++03, and wasn't implemented mainly due to name mangling problems.
Edward Diener wrote:
Just the operator metafunctions in the CTL are useful even without the attempts to add concepts in the form of metafuncions. I do not think C++0x, which is still a year or more away, has any "native" support which would allow me to determine whether a type has an operator.
I believe that extended SFINAE makes it a lot easier.
Thanks for the information. Does Boost currently have a macro which checks for extended SFINAE for any compilers which may support it ?
BOOST_NO_SFINAE :-) John.
On 7/11/2010 4:59 AM, John Maddock wrote:
Edward Diener wrote:
Just the operator metafunctions in the CTL are useful even without the attempts to add concepts in the form of metafuncions. I do not think C++0x, which is still a year or more away, has any "native" support which would allow me to determine whether a type has an operator.
I believe that extended SFINAE makes it a lot easier.
Thanks for the information. Does Boost currently have a macro which checks for extended SFINAE for any compilers which may support it ?
BOOST_NO_SFINAE :-)
Doesn't this only flag lack of support for SFINAE rather than the extended SFINAE in C++0x ?
Edward Diener-3 wrote:
I discovered, from asking a question on the user NG, the Concept Traits Library ( mentioned at https://svn.boost.org/trac/boost/wiki/LibrariesUnderConstruction#Boost.Conce... ) in the Boost sandbox by Terje Slettebø and Tobias Schwinger last dated almost 6 years ago. From e-mailing Terje Slettebø I discovered that he did not have time to work on it further or submit it to Boost, since he has been working in other areas for many years as part of his job. Tobias Schwinger's e-mail address was not in the documentation so I was not able to contact him. Other Boost TMP programmers also seemed to have helped to contribute to this library.
How did this library slip under the raider, so to speak ?
This is a fantastic library with many useful metafunctions for the TMP programmer. For my own particular use the operator metafunctions alone are incredibly useful, but there are many more metafunctions testing for many concepts covering the STL and MPL. The documentation is also very good and there is a complete set of tests.
Have I missed anything in terms of other later libraries superceding the functionality that was in this one ? Are the techniques used in this library flawed in any way ? I would love to see this library as part of Boost, if just for the operator metafunctions, and have told Terje Slettebø so.
Hi, Here are some reasons Terje give me after July 14, 2008: "Regarding submitting it to Boost: That was something I and the co-author (Tobias Schwinger) at least wanted to keep the option open to, which is why it was made using the Boost library guidelines and conventions. It was mainly made as an experiment in how far you may get with a library approach to concept checking, and in some respects, it does more than the Boost Concept Check Library, in that it allows you to overload on concepts. However, there are a number of limitations on what it's able to detect. For example, it can't detect constructors/destructors (because these have no name, and need to be member functions), and ditto for some other operators, such as function call (it has to be a member function). As you may know, in the coming C++0x standard, support for concepts will be included in the language, making libraries like this (and BCCL) obsolete, so I've found it wouldn't be much use to submit something to Boost that would be obsolete quite soon (although I've heard that the next C++ standard may well be delayed beyond 2009, in order to get the concept proposal right)." In <http://old.nabble.com/Overloading-on-concepts-tt17104187.html#a17104187> you can find "Things you can't detect (without specialising the traits for the types in question): - Constructors and destructors (they don't have a name, so can't be detected using traits detecting member functions) - Operators that has to be class members, such as assignment operator, member access operator, subscript operator and function call operator. It seems like a rather arbitrary restriction to me that these have to be member functions, and it greatly reduces the ability to perform concept checks where they are involved. - Since name lookup is performed before access check, you may get a compile-time error, rather than SFINAE, if a type has a required member, but where the member is inaccessible (private or protected). Also, concept checking using enable_if is an all-or-nothing affair (either it matches or it doesn't), so if you want to implement concept overloading based on best match (for example with regard to the iterator concepts), you have to perform the ordering, yourself. There's an included example demonstrating this (in the original version of the library, this is located in libs/concept_traits/example/std_advance.cpp). " Even if the library doesn't provides an approach that works to define all the concepts, it has a lot of useful things. I also suggested to Terje at least to add the mpl and type traits extensions of the library. I think that someone interested should take the library and make a proposal to Boost. Best, Vicente -- View this message in context: http://old.nabble.com/Concept-Traits-Library-tp29125621p29126502.html Sent from the Boost - Dev mailing list archive at Nabble.com.
Even if the library doesn't provides an approach that works to define all the concepts, it has a lot of useful things. I also suggested to Terje at least to add the mpl and type traits extensions of the library.
Agreed - in fact I don't see why we can't just add the new traits direct to the type_traits library? Certainly if someone would like to package these up as direct additions to type_traits (so I don't have to do much!) then I'd certainly look favorably on adding them. John.
On 7/10/2010 11:47 AM, John Maddock wrote:
Even if the library doesn't provides an approach that works to define all the concepts, it has a lot of useful things. I also suggested to Terje at least to add the mpl and type traits extensions of the library.
Agreed - in fact I don't see why we can't just add the new traits direct to the type_traits library?
Certainly if someone would like to package these up as direct additions to type_traits (so I don't have to do much!) then I'd certainly look favorably on adding them.
I will work on doing so if it is OK with the original authors of the library. I can do this for the type_traits_ext in the CTL. I would also like to see the operator detection in the CTL added to Boost, even with the known limitations for operators which must be member functions, but I do not know if you feel this would also be an addition to the type traits library ? I know that Frederick Bron has added some traits to the type_traits in the sandbox which are a subset of all the operator traits in the CTL but he appears to have stopped with what he was doing because he found out the CTL already existed.
I would also like to see the operator detection in the CTL added to Boost, even with the known limitations for operators which must be member functions, but I do not know if you feel this would also be an addition to the type traits library ? I know that Frederick Bron has added some traits to the type_traits in the sandbox which are a subset of all the operator traits in the CTL but he appears to have stopped with what he was doing because he found out the CTL already existed.
I was very near submitting the operator traits but was stopped when someone suggested to check before it it was not already in the CTL. I checked and saw that it was included in it (however with less flexibility). The conclusion was that the CTL was much larger library and was very interesting but I did not have enough time to revive it. What I can say is that there is some differences between the traits I proposed and the one of the CTL: in CTL, there is no check of return type. We had quite a long dicussion about this and ended to a nice solution which is to check or not (optional) for the return type to be convertible to a given type. If we agree to add only the operator traits to the type_traits library separatly from the CTL, I think that my proposal is nearly ready and I can do the extra work. If we want to add the CTL, it is better if someone else does it as it would be too much work for me. However, if Edward would like to finish my work, I have also no objection. Cheers, Frédéric
On 7/10/2010 12:49 PM, Frédéric Bron wrote: [...]
What I can say is that there is some differences between the traits I proposed and the one of the CTL: in CTL, there is no check of return type. We had quite a long dicussion about this and ended to a nice solution which is to check or not (optional) for the return type to be convertible to a given type.
I've found all 3 of the following options to be useful in my own (C++03) implementation of operator traits: (i) ignore the return type of the operator entirely (ii) check that the return type of the operator is convertible to a given type (iii) check that the return type of the operator satisfies a given MPL metafunction class or MPL lambda expression As a result, the trait's signature looks something like template< class T, class Result = void, class ResultCond = mpl::always< true_type >
struct my_trait; The trait evaluates to true if the result type of the operator - is convertible to Result or Result is void; and - satisfies ResultCond. Of course, option (iii) is a generalization of (ii), but (ii) (along with (i)) would be the common case (and hence providing an interface specifically for (ii) would be more client-friendly). A use case for (iii) might be to check that the return type is *precisely* the given type, or if the return type is one of many compatible-but-not-necessarily-interconvertible types.
If we agree to add only the operator traits to the type_traits library separatly from the CTL, I think that my proposal is nearly ready and I can do the extra work. If we want to add the CTL, it is better if someone else does it as it would be too much work for me.
Is your proposal available for inspection at the moment? I don't recall recently running across a link that you've provided. Sorry if I missed it :/ - Jeff
On 7/10/2010 3:49 PM, Frédéric Bron wrote:
I would also like to see the operator detection in the CTL added to Boost, even with the known limitations for operators which must be member functions, but I do not know if you feel this would also be an addition to the type traits library ? I know that Frederick Bron has added some traits to the type_traits in the sandbox which are a subset of all the operator traits in the CTL but he appears to have stopped with what he was doing because he found out the CTL already existed.
I was very near submitting the operator traits but was stopped when someone suggested to check before it it was not already in the CTL. I checked and saw that it was included in it (however with less flexibility). The conclusion was that the CTL was much larger library and was very interesting but I did not have enough time to revive it.
What I can say is that there is some differences between the traits I proposed and the one of the CTL: in CTL, there is no check of return type. We had quite a long dicussion about this and ended to a nice solution which is to check or not (optional) for the return type to be convertible to a given type. If we agree to add only the operator traits to the type_traits library separatly from the CTL, I think that my proposal is nearly ready and I can do the extra work.
That would be great. I am willing to help any way I can as needed. I would love to see operator traits added to Boost. The improvement of the check on the return type is definitely a good feature.
If we want to add the CTL, it is better if someone else does it as it would be too much work for me.
I completely agree with you. Adding the CTL is really up to the CTL developers. In the last e-mail I received from Terje Slettebo he indicated that he might be willing to re-visit the CTL again now that Concepts will no longer be in C++0x. He said he is currently on vacation but I hope to hear from him when he gets back as I sent him a message in reply. If anyone knows how to contact Tobias Schwinger I would be glad to get his feelings about the CTL, since he is listed along with Terje Slettebo as the co-author.
However, if Edward would like to finish my work, I have also no objection.
I would like to see some of the type_traits_ext metafunctions in the CTL also added to Boost, unless of course their functionality is going to be surfaced in what you have been doing or the CTL authors revive their efforts. I feel that they would be very useful in general as metafunctions for discovering whether a type has members of certain types, data, or functions. Covering these possibilities seems to me potentially very useful on its own, even with the current limitations regarding these metafunctions. Joel Falcou also has some similar metafunctions along the same lines, but slightly different, for his introspection library and I think combining the CTL's and introspections metafunctions into a little more flexible set would be advantageous as a separate library, or as an addition to the type_traits library. I am willing to wait to hear from Terje Slettebo and Tobias Schwinger to see whether or not they are willing to work on and submit the CTL again, but I will also work on my own in the meantime to combine type_traits_ext and the two introspection type discovery metafunctions. I do not flatter myself that I can necessarily improve what is already there, but I do have a good sense of how to present things to be easier and/or clearer for end-users to use.
Certainly if someone would like to package these up as direct additions to type_traits (so I don't have to do much!) then I'd certainly look favorably on adding them.
I will work on doing so if it is OK with the original authors of the library. I can do this for the type_traits_ext in the CTL.
I would also like to see the operator detection in the CTL added to Boost, even with the known limitations for operators which must be member functions, but I do not know if you feel this would also be an addition to the type traits library ? I know that Frederick Bron has added some traits to the type_traits in the sandbox which are a subset of all the operator traits in the CTL but he appears to have stopped with what he was doing because he found out the CTL already existed.
It was the operator detection that I was particularly thinking of. However, I'd like to mainly restrict additions to type_traits to those traits that do actually work without user specialization if possible. IMO that would be more in keeping with the rest of the library... on the other hand we do have is_union... so I guess some non-functional traits could be added if they "complete the picture" as it were (and particularly if some kind soul would write them up for possible TR2 additions :-) HTH, John.
On 7/10/2010 11:05 AM, Vicente Botet Escriba wrote:
Edward Diener-3 wrote:
I discovered, from asking a question on the user NG, the Concept Traits Library ( mentioned at https://svn.boost.org/trac/boost/wiki/LibrariesUnderConstruction#Boost.Conce... ) in the Boost sandbox by Terje Slettebø and Tobias Schwinger last dated almost 6 years ago. From e-mailing Terje Slettebø I discovered that he did not have time to work on it further or submit it to Boost, since he has been working in other areas for many years as part of his job. Tobias Schwinger's e-mail address was not in the documentation so I was not able to contact him. Other Boost TMP programmers also seemed to have helped to contribute to this library.
How did this library slip under the raider, so to speak ?
This is a fantastic library with many useful metafunctions for the TMP programmer. For my own particular use the operator metafunctions alone are incredibly useful, but there are many more metafunctions testing for many concepts covering the STL and MPL. The documentation is also very good and there is a complete set of tests.
Have I missed anything in terms of other later libraries superceding the functionality that was in this one ? Are the techniques used in this library flawed in any way ? I would love to see this library as part of Boost, if just for the operator metafunctions, and have told Terje Slettebø so.
Hi,
Here are some reasons Terje give me after July 14, 2008: "Regarding submitting it to Boost: That was something I and the co-author (Tobias Schwinger) at least wanted to keep the option open to, which is why it was made using the Boost library guidelines and conventions.
It was mainly made as an experiment in how far you may get with a library approach to concept checking, and in some respects, it does more than the Boost Concept Check Library, in that it allows you to overload on concepts. However, there are a number of limitations on what it's able to detect. For example, it can't detect constructors/destructors (because these have no name, and need to be member functions), and ditto for some other operators, such as function call (it has to be a member function).
As you may know, in the coming C++0x standard, support for concepts will be included in the language, making libraries like this (and BCCL) obsolete, so I've found it wouldn't be much use to submit something to Boost that would be obsolete quite soon (although I've heard that the next C++ standard may well be delayed beyond 2009, in order to get the concept proposal right)."
In<http://old.nabble.com/Overloading-on-concepts-tt17104187.html#a17104187> you can find "Things you can't detect (without specialising the traits for the types in question):
- Constructors and destructors (they don't have a name, so can't be detected using traits detecting member functions) - Operators that has to be class members, such as assignment operator, member access operator, subscript operator and function call operator. It seems like a rather arbitrary restriction to me that these have to be member functions, and it greatly reduces the ability to perform concept checks where they are involved. - Since name lookup is performed before access check, you may get a compile-time error, rather than SFINAE, if a type has a required member, but where the member is inaccessible (private or protected).
Also, concept checking using enable_if is an all-or-nothing affair (either it matches or it doesn't), so if you want to implement concept overloading based on best match (for example with regard to the iterator concepts), you have to perform the ordering, yourself. There's an included example demonstrating this (in the original version of the library, this is located in libs/concept_traits/example/std_advance.cpp). " Even if the library doesn't provides an approach that works to define all the concepts, it has a lot of useful things. I also suggested to Terje at least to add the mpl and type traits extensions of the library.
I think that someone interested should take the library and make a proposal to Boost.
Thanks for the information. I am willing to work to add the mpl and traits extensions as well as the operator traits to Boost, as long as the original authors of the library approve. Terje suggested to me in an e-mail that maybe operator traits could be submitted separately. I would very much like to see it happen because I can use them in a TMP library I am working on.
I also have some traits liek this like checkign for belongign to a namespace and such in the vault under intrispection.zip Maybe it coudl be nice to merge these too ?
Edward Diener wrote:
On 7/10/2010 3:06 PM, joel falcou wrote:
I also have some traits liek this like checkign for belongign to a namespace and such in the vault under intrispection.zip Maybe it coudl be nice to merge these too ?
Would you put a link to this please ? http://www.boostpro.com/vault/index.php?action=downloadfile&filename=introspection.zip&directory=&PHPSESSID=991f7863a845fa8ea77aaa35a8dc8742
participants (10)
-
Christopher Jefferson -
Edward Diener -
Frédéric Bron -
Jeffrey Lee Hellrung, Jr. -
joel falcou -
John Maddock -
Mathias Gaunard -
Mathieu - -
Steven Watanabe -
Vicente Botet Escriba