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.