[mailto:boost-bounces@lists.boost.org] On Behalf Of Douglas Gregor
Type traits are already in TR1 and in the C++0x working paper, in the
I forgot until after I sent the email :/ More below
header <type_traits>, so I wouldn't be proposing them as part of concepts. That said, if you're using concepts, you will only need type traits very rarely. Here's why...
Concepts aren't "is "or "has" checks like type-traits are. is_floating makes sense as a type trait, because you can use it to detect whether a type is a floating-point type, for instance. The equivalent IsFloating concept, which says only whether a type is a floating-point type or not, might be written as:
concept IsFloating<typename T> { }
You could then use IsFloating like a type trait (a yes or no answer), but it wouldn't get you very far. For instance, you can't write any interesting algorithms with it:
template<typename T> requires IsFloating<T> T negate(T x) { return -x; }
The compiler would reject this, because there is no negation operator. Why? Well, we interpret the name IsFloating to mean that the type has certain properties, including a negation operator. Traits work this way, with the implication that the programmer knows what all of the properties are for a given trait. Since templates aren't really type-checked, it works (until it doesn't work; then you get the long error messages).
The compiler can't interpret the name IsFloating, so it looks in the concept bodies to see what properties the type should have. We don't list any properties in the IsFloating concept, so we can do nothing with our template type parameter T.
This is why you don't see "Is" or "Has" in a concept name... concepts specify exactly what properties we expect a type to have. So, we might write a Floating concept like this:
concept Floating<typename T> { T operator-(T); T operator+(T, T); T operator-(T, T); T operator*(T, T); T operator/(T, T); // ... }
Every floating-point type has those properties, so they meet the requirements of the Floating concept, and we can write our negate algorithm:
template<typename T> requires Floating<T> T negate(T x) { return -x; }
The "is" in a concept is implied, really. The requires clause (it was called the "where clause," up until two weeks ago) states what concept requirements the template parameters need to meet. If a type does not meet those requirements, the template can't be used. It's the same kind of decision we make with is_* traits, but the compiler is doing the work, not us.
To try to summarize this: the type trait is_floating says, "Is it a floating point type?" whereas the concept Floating says, "This is what it means to be a floating point type."
Ok, that make sense to me. It's just a slightly different way of looking at the problem, defining the behavior instead of the function. IIUC that's actually like the mind set I use with OOAD, 'how will the system behave'.
Cheers, Doug
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Scanned by McAfee GroupShield {X3BTB534}