Boost logo

Boost :

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
>> 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?


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


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