From: Doug Gregor (dgregor_at_[hidden])
Date: 2007-03-13 13:12:43
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
>> as documentation. We couldn't verify the complexity (except in very
>> simple cases), and it's unlikely to help in program testing or
> Actually thinking on it some more I think my main worry isn't a
> 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?
> 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
> 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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk