Boost logo

Boost :

From: Matt Doyle (mdoyle_at_[hidden])
Date: 2007-03-12 13:53:26

> [mailto:boost-bounces_at_[hidden]] 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

> Cheers,
> Doug
> _______________________________________________
> Unsubscribe & other changes:

Scanned by McAfee GroupShield {X3BTB534}

Boost list run by bdawes at, gregod at, cpdaniel at, john at