Subject: Re: [boost] Concept Traits Library
From: Vicente Botet Escriba (vicente.botet_at_[hidden])
Date: 2010-07-10 11:05:59
Edward Diener-3 wrote:
> I discovered, from asking a question on the user NG, the Concept Traits
> Library ( mentioned at
> ) 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.
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)."
you can find
"Things you can't detect (without specialising the traits for the types in
- 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
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
-- 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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk