Re: failure to construct global object

[Gisli Ottarsson <gisli at adams dot com>]

>>>>> On Mon, 6 Mar 2000 09:39:52 +0100, Martin v. Loewis said:
 
  >> The problem seems to be that the constructor for this object is never
  >> called.  

  MvL> Thanks for your bug report. Without seeing any details, I'd
  MvL> claim that the compiler is working properly, and that you made
  MvL> some mistake. 

Fair enough.  Let me try to change your mind.

  MvL> Again, it is then hard to guess what the mistake could have
  MvL> been, but here are some options:

  MvL> a) the object file containing the global object is not linked into the
  MvL>    executable. That could happen if it is in a library, and none of the
  MvL>    symbols in that object file are referenced.

I have moved the global object into the object file which contains
the main().  The program still runs without visiting the constructor
for the class in question.  I create another object of the same class,
this time inside to scope of main().  Now the constructor is hit once.

  MvL> b) The object will be created, but not at the time you are expecting
  MvL>    it to be created. In C++, order of creation of global objects is
  MvL>    unspecified - except that they must be initialized some time before
  MvL>    they are first referenced from inside main (or functions called by
  MvL>    main). In g++, construction order depends on the order in which
  MvL>    object files are provided to the linker.

I have been trying to see whether I am making some stupid assumption
about the order of creation but I am drawing a blank.  Please keep in
mind that the software behaves as expected on IRIX, (MIPSpro 7.2.1,
o32 and n32), HP-UX (HP ANSI C++ B3910B A.01.18), SunOS (WorkShop 4.2)
and MS Visual C++ (whatever the current version is).  The program also
runs off-and-on with IBM's compilers.

Please look at these two pieces of pseudocode that correspond to
an experiment I just performed.

Case A:

  MyClass Obj;

  main()
  {
     Obj.do_something();
  }

Case B:

  MyClass *pObj;

  main()
  {
     pObj = new MyClass;
     pObj->do_something();
  }

In Case B the code passes through the MyClass constructor (it contains
cout << " Constructor" << endl;) and the do_something() is executed.
In Case A the MyClass constructor is never hit and the program crashes
while trying to access an uninitialized data member in do_something().
In case it matters, it crashes while trying to get the size of an STL
list.

  >> 1) How do I gather useful information about this problem so that
  >> I may write a proper bug report.

  MvL> The object should be constructed in the object file containing
  MvL> its definition. So please send preprocessor output and
  MvL> assembler code for that file; you'll probably need to bzip2
  MvL> them because of the mailing list limit.

I am going to try to recreate the problem on a smaller scale.  I
will try to post this tomorrow.

  >> 2) Are there any ways to coerce the construction.

  MvL> As I said: If you have a well-formed C++ program, the compiler
  MvL> *will* make sure that the object is constructed, so there is no
  MvL> mechanism to coerce construction beyond that guarantee.

True, but in the past I have been thrown all manner of curves by less
than perfect C++ compilers.  For instance SGI's o32 compiler has a
dendency to fail to construct static members, requiring beauties like
this:

void Partial::force_static_member_initialization()
{
  // MIPSpro o32 fails fails to call constructor for Partial::Empty
  // we need to initalize the rep pointer in Partial::Empty as the
  // constuctor should have.

   Partial::AtomRep **a;
   a = const_cast<Partial::AtomRep**>(&Partial::Empty.rep);	
  *a = new Partial::AtomRep();
}

I was wondering if there was something similar I could do to my global
object to allow my Linux build to limp along until a proper fix is
found.

Thanks for your time.

  Gisli