Path: utzoo!attcan!uunet!mcvax!ukc!dcl-cs!aber-cs!pcg
From: pcg@aber-cs.UUCP (Piercarlo Grandi)
Newsgroups: comp.lang.c++
Subject: Re: static members
Summary: If we had import/export! class attributes!
Message-ID: <507@aber-cs.UUCP>
Date: 8 Jan 89 15:06:58 GMT
Reply-To: pcg@cs.aber.ac.uk (Piercarlo Grandi)
Distribution: eunet,world
Organization: Dept of CS, UCW Aberystwyth
	(Disclaimer: my statements are purely personal)
Lines: 111

[this is a repost of an article that did not get out a week ago because of
net problems -- I think it is still useful]

In article <8695@alice.UUCP> ark@alice.UUCP (Andrew Koenig) writes:

    In article <701@cadillac.CAD.MCC.COM>, rpj@redcloud.cad.mcc.com (Rich
    Johns) writes:

	[ ... several sensible questions about static class members ... ]

    [ ... equally sensible replies to such questions, with an interesting
    comment on static function members ... ]

Frankly I find this whole business of static members difficulties a bit
disappointing. I think that initialized static members, initialized static
const members and such are useuful concepts and ought to be allowed.

I know that initializing static members, as it has been correctly observed,
runs the risk, in a straightforward implementation, to have multiple
initializations, because the class definition is included potentially several
times in several source files.

I can think of three solutions to this (some other proposal was voiced in
some C++ conference but I don't yet have the proceedings to look it up):

    [1] consider static members as de facto global variables (e.g.  regard
    "C::m" as a kind of "C_m") and allow initialization of the member outside
    the class, away from the definition:

	class C { ... static int m; ... }; int C::m = 1;

    which resembles the current allowed syntax for defining member functions
    away from their declaration, outside the class definition. Note that the
    rationale for doing this in the case of procedure members is exactly
    equivalent to the rationale for allowing this for data members (avoiding
    replication).

    [2] sidestep the problem entirely, by using an import or export syntax
    and mechanism . This has several other advantages, some people (including
    myself) reckon.

    [3] add yet another kludgey wart to "bunch", or "collect", or whatever
    tools is used to reconcile the ideal of C++ global objects with the
    reality of existing linkers.

In my reckoning, solution [1] does not address very well the case of static
members of a type with constructors, solution [3] is inelegant, as all
compromises are, and solution [2] works well, and only impacts C++ compilers,
not linkers.

There has been a discussion in this newsgroup in the past on the relative
merits of an import/export mechanism to replace the current reliance on
#include, and it was not very conclusive. Can I now add that the static
members problem is one fair example where the wholesale replication of text
implied by #include causes problems?


As to the static procedure idea, this adds a new dimension to the discussion.
C++ does not have metaclasses. It also does not have a proper way of defining
class attributes, as opposed to instance attributes. The static function idea
to me shows that a good way to add them to the language would be to say "static
members of a class definition are members of the class object, not of any
instance object of that class". A possible consequence could be to define
"C::m" to be the syntax used to access members of the class object, and "C.m"
to access members of an instance object.

Consider the example by Andrew Koenig:

	class Widget {
		static int n;
	public:
		Widget() { n++; /* other stuff */ }
		~Widget() { n--; /* other stuff */ }
		static int count() { return n; }
		/* other stuff */
	};

	[ ... ]

    Of course if there aren't any Widgets at all I can't use this notation to
    count them, but I should be able to call Widget::count.

It seems to me fairly clear that "count" is a class/factory method, in
Smalltalk/Objective C terminology.  Now class methods ARE useful in
Smalltalk, as factory methods are useful in Objective C.

Under this interpretation, the problems with static data members acquire a
new dimension: they really are members of the class object, and the
difficulties with them are merely a reflection of the fact that in C++ there
is no explicit or clear notion and support (yet) of a class object or
metaclasses.

This said I would not however explicitly introduce the notion of metaclass
in C++, because it seems to me that it does not belong to a language where
the environment is not expected to contain much (what I mean is that
certainly a C++ compiler will implement metaclasses -- the symbol table entry
for a class -- but then probably this compile time structure should not
become in toto a runtime entity as well).

It seems that extending Andrew Koenig's idea to say that C++ acquire a
mechanism like static to achive something similar to the distinction between
+/- members in Objective C is not, at first sight, a terribly bad
suggestion, and would be sufficient.
-- 
Piercarlo "Peter" Grandi	   | ARPA: pcg%cs.aber.ac.uk@nss.cs.ucl.ac.uk
Dept of CS, UCW Aberystwyth	   | UUCP: ...!mcvax!ukc!aber-cs!pcg
Penglais, Aberystwyth SY23 3BZ, UK | INET: pcg@cs.aber.ac.uk
-- 
Piercarlo "Peter" Grandi	   | ARPA: pcg%cs.aber.ac.uk@nss.cs.ucl.ac.uk
Dept of CS, UCW Aberystwyth	   | UUCP: ...!mcvax!ukc!aber-cs!pcg
Penglais, Aberystwyth SY23 3BZ, UK | INET: pcg@cs.aber.ac.uk