Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!csd4.csd.uwm.edu!wuarchive!cs.utexas.edu!rutgers!ucsd!ucbvax!hplabs!hp-pcd!hplsla!jima
From: jima@hplsla.HP.COM (Jim Adcock)
Newsgroups: comp.lang.c++
Subject: Re: disappointed with Pohl's C++ book
Message-ID: <6590237@hplsla.HP.COM>
Date: 5 Sep 89 17:11:14 GMT
References: <2293@hub.UUCP>
Organization: HP Lake Stevens, WA
Lines: 55

// >      The real restriction, according to Stroustrup, is that a static 
// >member of a class cannot be of a type which has a constructor.  Static
// >members are also forbidden initializers.  (At first thought this
// >seems strange.  After all, static members are really just global
// >variables to the implementation, and global variables can be of
// >a type with a constructor.  But think about what happens when a
// >class definition is included into several files.  Who does the
// >initialization?)

//--------------------------------------------------------------------

// Consider simulating the effect of static members with init'ers 
// by using references:

#include <stdio.h>

class withIniter
{
  const char* stringp;
public:
  withIniter(const char* p) { stringp = p; }
  void print() { printf("%s\n", stringp); }
};

withIniter withStaticMember__classname("withStaticMember");

class withStaticMember
{
  withIniter& classname;
  int someMembers;
public:
  withStaticMember() : classname(withStaticMember__classname) {}
  void printClassname() { printf("class name is: "); classname.print(); }
};

void main()
{
  withStaticMember someObject;
  someObject.printClassname();
}

// Compiles and executes as expected under 2.0.  Class definitions included in 
// several files is not an issue here [or maybe it is :-] since 
// withStaticMemberClassname must be defined once, in a file of your 
// choosing.  Presumably the "right" place to define withStaticMemberClassname 
// would be in the file defining the member functions of withStaticMember -- 
// IE withStaticMember.c -- assuming one is following the generally sensibly 
// approach of creating a library of seperately compiled classes.
// Still, these problems show that following the .c & .h approach of c
// is really just a hack in order to maintain backwards compatibility with
// archaic compilers and linkers.  Ideally declarations and definitions --
// .h and .c information -- could be contained in one source file, and be 
// compiled into one library file.  Then the inline issues: where an inline
// gets declared, and whether a compiler can successfully inline it or not,
// would also go away.