About dlw_oprs.zip, version 19

From: Daryle Walker (darylew_at_[hidden])
Date: 2001-02-23 15:09:11

I put up version 19 of the "dlw_oprs.zip" file in the Boost vault.  The
files in it were what would have been affected by the queries I made in the
list about changing the random-number class and finding the bases of the
"char" and "wchar_t" types.  Unfortunately, I ran into compiler problems, so
the version you see doesn't take any of those suggestions into account.

After doing the CRC stuff, I decided to review some of the other Boost stuff
I had on queue.  I went back to the "operator.hpp" changes (incorporated in
"dlw_oprs.zip").  I checked that it worked with the latest version of Boost.
I decided to add something I was originally planning to hold off until after
the other changes were officially incorporated: arithmetic conversion
operators.

Some classes may want to define conversion operators to all the built-in
arithmetic types.  Instead of doing each type separately (see "bitint.zip"
for an example), we could just explicitly define conversion operators for
the biggest built-in types, and use operator templates for the rest.  I
think the non-biggest built-in types have to be subsets, or identical to,
the biggest built-in types.  These biggest types are:

+ "unsigned long long," or "unsigned long" if the former doesn't exist
+ "long long," or "long" if the former doesn't exist
+ "long double"

I use "boost::uintmax_t" and "boost::intmax_t" to avoid having to determine
if the extra-long integral types exist for the most part.  I did need the
determination to check for the "[unsigned] long" conversions.

There is not a single operator template.  I decided to separate the
conversion operators based on what biggest built-in types should be used.
The problem is with the standard character types; the template(s) that
"char" and "wchar_t" would have gone to are implementation-defined.  For
now, I put them in a separate operator template, and you are expected to
have the conversion to the appropriate base type already set, probably by
using one of the other operator templates.  I'll come up with a better
solution.

Note that there is one built-in arithmetic type not covered as being
supplied by an operator template or being needed by an operator template:
"bool."  Besides being an integral type of indeterminate signed-ness, an
user would most likely have a custom, optimized conversion operator for
"bool" already.  (If you don't, I'm forcing the issue.)

Thought experiment: if an user defines a public "bool" conversion operator,
but privately inherits these conversion operator templates, would that block
(most) accidental integral conversions that something that is
"bool"-convertible can get in?  This problem is why the I/O stream classes
define their Boolean converter as "operator void *()".

BTW, I made all of these operator templates because I want to use them in
new numeric classes.  (Well, the new input and output iterator group
operator templates are an exception; I did those for completeness.)

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