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