Path: utzoo!utgpu!attcan!uunet!lll-winken!ames!mailrus!tut.cis.ohio-state.edu!rutgers!bellcore!faline!thumper!ulysses!andante!alice!bs
From: bs@alice.UUCP (Bjarne Stroustrup)
Newsgroups: comp.lang.c++
Subject: Re: static members
Summary: static member initialization is comming static member functions are comming
Message-ID: <8770@alice.UUCP>
Date: 16 Jan 89 00:37:28 GMT
References: <507@aber-cs.UUCP>
Distribution: eunet,world
Organization: AT&T Bell Laboratories, Murray Hill NJ
Lines: 71



I'm sorry I haven't commented on the discussion on static members
before. I have been busy. Release 2.0 will provide two new features
related to static members:
	(1) static member functions, and
	(2) initialization of static members
both have been mentioned in comp.lang.c++ before. I believe that
the idea of static member functions originate with Jonathan Shopiro.
Unfortunately, I don't know who first proposed the way of for initializing
static members we adopted; Andrew Koenig brought it to my attention, but
he couldn't remember who gave it to him. Both ideas were presented and
discussed at the implementors workshop at the Denver C++ conference.

1: static member functions

	The reason for static members is to reduce the number of global names,
	to make it obvious which class objects belong, and to be able to apply
	the access control rules to names of objects and values that are not
	replicated one per object. This is a boon for library providers in that
	it avoids polluting the global name space and thereby allow easier
	writing of library code and safer use of multiple libraries.

	It was observed that these reasons applied for functions as well as
	for objects and the absence of static functions has been commented
	on repeatedly over the years. It was observed that MOST of the names
	a library provider wants local are in fact function names. it was
	observed that nonportable code, such as
		((X*)0)->f();
	was used to simulate static member functions (this ``trick'' is a
	time bomb because it will fail under some implementations of dynamic
	linking).

	We now have a facility that is logically equivalent to Modula2's
	qualified export and marginally more efficient than usual member
	function calls:

		class X {
			// ...
			static f();
		};

		f();	// error (unless there really is a global function f())
		X::f();	// fine

2: initialization of static data members

	In earlier cfronts it was possible to have static data members, but not
	possible to explicitly initialize such static members. The original
	reference manual clearly states this limitation. This limitation means
	that it is impossible to have static members of classes and types that
	require initialization. This have been reported as a serious problem
	many times (about twice a month) and often as a bug by both novice and
	experienced users.

	The solution is simply to remove the restriction and allow initialization
	exactly as is done for member functions. For example:

		struct s {
			static const a;
			static X b;
			// ...
			int f();
		}

		const s::a = 7;
		X s::b(1,2);
		int s::f() { return a; }

About the time of the release of 2.0, I'll post a summary of new features
and short descriptions of each.