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