goofy Domain constructors

[Julian Cummings]

I have finished sweeping through all the Domain classes
and changing enums there to static data members of the
proper type (either bool or int).  Things still do not quite
compile under the HP aCC compiler because of a few
errors that may be compiler bugs of some sort.  I have
reported these to HP for analysis.  Nevertheless, the code
looks a fair bit cleaner as a result.  Also, the HP compiler
pointed out tons of places where we are using members
from a templated base class.  These members are not
visible under the C++ lookup rules, so you have to qualify
these with the "this" pointer (or with the base class name
for static members).  I don't know if gcc warns about this,
but I went ahead and made these changes.  The HP compiler
also caught some typos and bugs in some templated code
in other subdirectories.  I will commit fixes separately.

I ran the code through the gcc compiler on our HP
machine to check that it was happy with my changes,
and it was for the most part.  One thing I noticed under
gcc though is that we still get some of these warnings
about comparing unlike types.  My changes to Domain
eliminated the need for all these static casts of enum
types to ints.  These remaining warnings are coming
from some bizarre constructor definitions for Interval<1>,
Range<1>, etc.

These specializations all have a general templated
constructor that takes a single T argument.  This
argument is assumed to be a Domain of some sort,
and we attempt to construct this Domain object from
that one.  Then the code says we need to specialize
the constructor for all (integral) scalar types.  So we
have constructors from signed and unsigned char,
short, int and long.  In all cases, we set up the Domain
to range from 0 to a-1, where a is the scalar argument.

There are several problems here.  One is that it is
dangerous to subtract 1 from an unsigned value.  We
should probably insert a check if a=0 and do the right
thing.  Also, the unlike type comparisons warnings are
generated because "0" is assumed to be of type int in
all cases.  We could address this by casting the argument
"a" to an int before using it (or in the case where a is a
long, change "0" to "0L").  Finally, I find the constructor
taking a char argument to be rather bizarre.  Is there any
use in allowing that argument type here?

Jeffrey, have you already dealt with the warnings that
arise from these Domain constructors?  If so, how did
you handle it?  I wasn't sure what to do here.

In any event, I am attaching a gzipped tar file of my
modified version of the Domain sources, in case anyone
wants to check them out or test them.  Move the .h and
.cpp files in src/Domain elsewhere, and then expand this
tarfile into that directory.  I don't have cvs diffs because
a) the changes are extensive, and b) I don't have repository
access set up from the machines at Caltech yet.  BTW,
Allan has pointed out that similar changes ought to be
made in the Partition/Layout areas and other places where
clumsy enum usage is rampant.

Regards, Julian C.


--
Dr. Julian C. Cummings                       E-mail: address@hidden
California Institute of Technology           Phone:  626-395-2543
1200 E. California Blvd., Mail Code 158-79   Fax:    626-584-5917
Pasadena, CA 91125

Dom_sources.tar.gz
Description: GNU Zip compressed data