[boost] [optional] Suggestion for adding an optional_number class

[Viktor Sehr via Boost]

I'd like to make a suggestion for adding an optional class for number
types, called optional_number, where the max value of the number type is
utilized as the uninitalized value.

Differences compared to std::optional<int, float, enum etc>:
*- No size overhead from the wrapped type*
- Theoretically faster (althrough in practice probably negilble)
- Can be assigned to any value except the max value
- Operator-> is removed as it does not make sense for an integer


Notes:
- Throws if assigned the numeric_limits<T>::max
- Also works with enums, using the underlying_type
- The operator bool conversion is missing in the prototype implementation

Attaching a prototype implementation (currently for C++14).


/Viktor

[degski via Boost]

Post by Viktor Sehr via Boost
I'd like to make a suggestion for adding an optional class for number
types, called optional_number, where the max value of the number type is
utilized as the uninitalized value.

What problem are you trying to solve?

Post by Viktor Sehr via Boost
- Can be assigned to any value except the max value

<snip>

- Throws if assigned the numeric_limits<T>::max
Seems to me the poison is worse than the disease.

degski

[Viktor Sehr via Boost]

Post by degski via Boost

Post by Viktor Sehr via Boost
I'd like to make a suggestion for adding an optional class for number
types, called optional_number, where the max value of the number type is
utilized as the uninitalized value.

What problem are you trying to solve?

The same problem as boost::optional solves for integers\enums\floats, but
without the additional space for a boolean.
In the case of numbers programmers often tend to use magic numbers
(std::string::npos, -1, less than 0, enum::None) etc to indicate
nonexistante index\invalid value etc.
Boost::optional solves this but adds a little overhead in space, using an
optional_number does not.

Post by degski via Boost
- Throws if assigned the numeric_limits<T>::max
Seems to me the poison is worse than the disease.

I expressed myself badly perhaps, what I mean is that users cannot utilize
the max value in any way. It's hidden inside the optional,
meaning that any handling of the max value is undefined or throws. Perhaps
even a static max member function returning (numeric_limits::max<T>() -1)
should be added.
/Viktor

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Gavin Lambert via Boost]

Post by Viktor Sehr via Boost
I expressed myself badly perhaps, what I mean is that users cannot utilize
the max value in any way. It's hidden inside the optional,
meaning that any handling of the max value is undefined or throws. Perhaps
even a static max member function returning (numeric_limits::max<T>() -1)
should be added.

Memory is cheap; the extra tests required to throw on:

optional_number<unsigned> x = 0;
--x;

(Or the developer headaches that would ensue if made UB and arithmetic
operations occasionally make the value pop in and out of existence or do
other weird things.)

Are less cheap.

If you're worried about wasting memory in large arrays of numbers,
consider a hybrid approach where you have an array of regular integers
and a bitset that separately indicates validity. This might use an
extra cache line but still should perform reasonably well.


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost