Douglas Gregor wrote:

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; }

I'm still trying to get the video to load...damn google videos can never seem to complete... so if this is answered in the video forgive me for asking again. Will this allow me to instantiate based on what concept is followed? For instance, with traits I might do something like the following: template <typename T> struct is_floating { static bool const value = true; }; template <typename T> typename enable_if<is_floating<T>, bool>::type f(T value) {...} template <typename T> typename enable_if<is_somethingelse<T>, bool>::type f(T value) {...} I rather started to disregard boost::concepts because I couldn't find a way to do this with them and type traits could be equally expressive so that they completely describe the concepts you are trying to get.

[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}

Douglas Gregor wrote: < glossing over the fact complexity is untestable... >

Even if we did, it's unclear how useful it would be except as documentation. We couldn't verify the complexity (except in very simple cases), and it's unlikely to help in program testing or optimization.

It might be useful where there were known ways of combining big-O functions for generic code to flag up "Whoa! don't go there, we exceeded some sanity limit!" For instance, O(n) implementation calls another O(n) function, we 'know' we are dealing with an O(n^2) function. I don't imagine any work on this kind of semantic outside accedemia, but could see some application in a decade or so once someone figures out how to do this simply and reliably, and for once Concepts is probably not that answer ;?) -- AlisdairM

On Mar 13, 2007, at 12:46 PM, Michael Marcin wrote:

Douglas Gregor wrote:

...

No, there isn't. We haven't really seen a good way to describe complexity. Even if we did, it's unclear how useful it would be except as documentation. We couldn't verify the complexity (except in very simple cases), and it's unlikely to help in program testing or optimization.

Actually thinking on it some more I think my main worry isn't a problem. Lets say I have an iterator class that has an operator + convenience function that just internally does a slow O(n) loop of operator ++'s. Now IIUC having operator + alone isn't enough to make it choose a RandomAccessIterator overload over an InputIterator overload because I didn't specialize the concept map for this type, right?

Right.

Another note, I'm probably in the minority but many of the platforms I work on don't have FPU's and thus we use fixed point math. In the current STL and many libraries we have to specialize methods that claim to require floating point types. It feels to me like we are lying by specifying floating point traits for fixed point types. Perhaps the concept you referred to a in an early post of Floating could be a refinement of a concept for types with sub integral precision so that fixed point types can meet the requirements of most things floating point types can without lying.

I'm hoping that, as part of upgrading numeric_limits to use Concepts, we end up with a solid way to categorize the various number types in the world, including fixed-point types. Cheers, Doug

Jeff Garland wrote:

Doug Gregor wrote:

...

On Mar 13, 2007, at 12:46 PM, Michael Marcin wrote:

...

I'm hoping that, as part of upgrading numeric_limits to use Concepts, we end up with a solid way to categorize the various number types in the world, including fixed-point types.

Since there's a proposal to add fixed-point decimal types I would hope that some of that work already been done. I believe this is the latest draft:

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n1965.html

In any case, it would be good to review these and see if from your experience you feel they are up to the task.

I was referring to binary fixed point types. http://en.wikipedia.org/wiki/Fixed-point_arithmetic Although I imagine most Concepts should hold for both. - Michael Marcin