Topic: derived classes of buil-in types
Author: karplus@cse.ucsc.edu (Kevin Karplus)
Date: 16 Oct 91 04:09:55 GMT Raw View
My research group has been learning c++ the hard way (writing a 30,000-line
program in it) and have come across several things that we had
difficulty in doing that the various manuals were not much help with.
In some cases, the problem went away as our skill in C++ improved, in
others we are still looking for clean ways to do things.
Here are a couple of problems that haven't gone away for us.
1) Using built-in types as base for derived classes.
We wanted to have a derived class of a built-in type. In particular,
we wanted to derive objects from gnu's Pix type (which is
typedef'ed to void*). We have had to do a somewhat klugier derivation
that made the Pix be the sole member of a class. Luckily, Pix has
very few operations, so we did not have to define all the
operations over. But what if I wanted to derive something from
a float or an int, keeping all the normal operations but adding one
or two that were unique to the new type?
Why can't classes be derived from the built-in types?
Is this just an oversight in the design of the language, or is there
some philosophical or practical difficulty with allowing it?
2) order of initialization in different files
We managed to get initialization order to be correct for most
of our static objects by adding tests to all constructors that had
dependencies. This did require changing some objects to pointers
to objects, so that we could allocate them with new. We still had
problems in that we couldn't guarantee that our Output class used for
error messages was initialized before constructors that could produce
error messages. We haven't found a work-around for that yet, because
we haven't found a way to force the allocation of the ostream to
occur before our constructors are called.
The kluges in the books for forcing particular initialization orders
are extremely ugly, and don't work with classes from libraries,
unless the library happens to be set up with the particular kluge you
plan to use.
I'd like to see the C++ language have a construct that gives an
an initialization order. For example, I could see something like
#initialize "foo.o"
or
#initialize "item.a"
being used in a file to indicate that all initializations in file
foo.o or in files from library item.a should preceed any contructor
initializations from this file.
Perhaps there already is such a construct and I just haven't read the
right manual? (I'm using g++, because I want source-level debugging,
and want to be able to distribute my source code to other people, and
have them run it without paying enormous liicense fees.)
Kevin Karplus