Re: [boost] Concepts talk on Google Video

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
behave'.

> 
> 	Cheers,
> 	Doug
> 
> _______________________________________________
> Unsubscribe & other changes: 
> http://lists.boost.org/mailman/listinfo.cgi/boost
> 

Scanned by McAfee GroupShield {X3BTB534}