Should we "pervert" next() and prior() for numeric types?

From: Daryle Walker (darylew_at_[hidden])
Date: 2001-01-15 23:43:53

The "next" and "prior" function templates in "utility.hpp" return the
successor or predecessor values of their iterator argument.  I wonder if we
could make versions of these functions for numeric types that we define.
The inspiration was from a gap in the ++ and -- operations.

-   For pointers and iterators, the ++ and -- operations go to the next or
previous item in the sequence.
-   For numeric types, the ++ and -- operations add or subtract one from the
current value.
-   For the built-in integral types, the above two points are equivalent.
-   The hole is: the built-in floating types can _only_ shift values by "1,"
there is _no_ provision to going to the immediately next or previous
floating point value!  This means that the ++ and -- will skip over a lot of
values for a (absolutely) small base value, and become useless no-ops for
(absolutely) large base values[1].

Some might find it useful to go to the next (or previous) representable
value of a numeric object, even if the difference is not one.  (Some numeric
types could have even spacing, like fixed-points, and others could have
varying spacing, like floating-points or rationals.)

We could do this for "next" and "prior" handling:

-   A class could have non-constant methods called "next" and "prior" that
take no arguments and don't return anything.  Calling one of these methods
turns the object's value to the successor or predecessor value.  (If the
values are always spaced by one, then operator++ and operator-- could be
inline-d defined in terms of these!)
-   The "next" and "prior" free-form functions return a copy of their
argument, after applying the appropriate method to it.

This is similar to the standard "swap" policy for the standard containers.

Optionally, we could be kind to the standard library and provide versions of
"next" and "prior" for the built-in floating-point types, so the hole I
described can be filled.  I don't know how feasible this is, since it
requires intimate knowledge of the representation, so the implementation
would have to be in a *.cpp file with #guards for each platform.

[1] Since the spacing between large consecutive values is greater than one,
a shift by one will be lost as noise.

-- 
Daryle Walker
Mac, Internet, and Video Game Junkie
darylew AT mac DOT com