Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!elroy.jpl.nasa.gov!sdd.hp.com!wuarchive!zazen!uwvax!heurikon!ex.heurikon.com!daves
From: daves@ex.heurikon.com (Dave Scidmore)
Newsgroups: comp.lang.c++
Subject: Re: C++ Static Members and Inheritance
Message-ID: <520@heurikon.heurikon.com>
Date: 8 May 91 04:11:30 GMT
References: <5069@servax0.essex.ac.uk> <7510@harrier.ukc.ac.uk> <1991May5.224348.12578@neon.Stanford.EDU>
Sender: news@heurikon.heurikon.com
Reply-To: daves@ex.heurikon.com (Dave Scidmore)
Organization: Heurikon Corporation, Madison, WI
Lines: 46


whisd@essex.ac.uk (Whiteside S D B) writes:
>I had a base class in which I declared a static data member.
>I then derived TWO separate classes which both inherited from the base class.
>Then these classes were instanstiated as objects I found that for BOTH the
>static data member (a pointer) had the SAME value.

philip@pescadero.stanford.edu (Philip Machanick) writes:
>Make the statics private (rather than protected). Then you are forced to
>redeclare them for derived classes. This still doesn't help you if you call a
>function higher up the hierarchy - the only solution I can propose here is that
>you pass the statics as parameters at all times. This, combined with the use of
>private, ensures you get the right one.

Perhaps I am dense, but I would assume that if a static member variable
was declared in a base class it is because you want only one instance of
that variable to exist for that class and all those derived from it. I
am having trouble envisioning a situation where you would want multiple
static member variable (a contradiction in terms IMHO). It seems to me
that if you want separate static member variables in derived classes you
would declare them there. This problem seems somewhat analogous to the
case where you want all objects of a class to be "attached" to some
set of possible static variables though not all to the same variable.

For example I have created an error handler classes to deal with all the
different types of errors one particular program can have. In the case of
internal errors the program may exit immediately. So do file I/O
errors, but they always print a file I/O location. Up to 'n' compilation
errors can occur before exiting, and some error messages are just warnings
and do not exit at all. The solution was to create groups or classes of
error handlers and attach each error handler to the appropriate class of
error handler. This is done by requiring a pointer to the error handler
class class when constructing an error handler.

Would it be practical in your situation to force construction of each
base class to include a pointer to a static member variable which it
uses in place of a permanent static member variable. Classes derived from
the base class can then provide their own static member variable and
construct the base class using that variable. Just a thought.

If having the base class store a pointer to a "static" variable represents
too much overhead then perhaps requiring base class method invoctions to
provide a pointer to the derived class static member variable would work.
--
Dave Scidmore, Heurikon Corp.
dave.scidmore@heurikon.com