RE: [ROOT] More about 'TObject overlapping'

From: Philippe Canal (pcanal@fnal.gov)
Date: Thu Apr 04 2002 - 01:04:16 MEST 

Hi Simon,

Looking at your code (see other mail) you have:

SDAQ::SDAQ() { ... }

SDAQ::SDAQ(Int_t run, TCanvas *canvas = 0, Cratemap *cratemap = 0)
{
  ...
  SDAQ(); // <--------Default constructor
  ...
}

Your call to the Default Constructor does not do what you have expected
The behavior seen in totalview is the correct one.

The meaning of your line is NOT to call the default contructor method
on the currently constructed object BUT to actually create a temporary
variable of the same type.  The code above is functionaly equivalent to:

SDAQ::SDAQ(Int_t run, TCanvas *canvas = 0, Cratemap *cratemap = 0)
{
  ...
  SDAQ someother_variable; // <--------Default constructor
  ...
}

Thus in your case the variable numHDI of the object constructed with the
constructor that takes arguments are NEVER reset to zero.

To achive what you were trying to do (factoring the default initialization)
you would need something like:

SDAQ::Init() {
  numHDI              = 0;
}

SDAQ::SDAQ()
{ 
  Init();
}

SDAQ::SDAQ(Int_t run, TCanvas *canvas = 0, Cratemap *cratemap = 0)
{ 
  Init(); // <----- Zero out all variables ....
  fCanvas = canvas;
  fCrateMap = cratemap;
  fillRuns(run);
}

Also note that a constructor can NOT call (properly) a virtual function and so 
the SDAQ::Init has to be non-virtual.

Cheers,
Philippe.

-----Original Message-----
From: owner-roottalk@pcroot.cern.ch
[mailto:owner-roottalk@pcroot.cern.ch]On Behalf Of Simon Dean
Sent: Wednesday, April 03, 2002 4:31 PM
To: roottalk@pcroot.cern.ch
Subject: [ROOT] More about 'TObject overlapping'


Hi,

Further to my previous e-mail, I've been using totalview to look into this
problem. My class, SDAQ, has a default constructor that sets some
member variable values to zero, and a constructor which takes
arguments. This last constructor also invokes the default constructor.

Now, totalview is showing me that when the default constructor is invoked 
from within the other constructor, it sets the values of ANOTHER
(local?) SDAQ to zero and so the changes do not affect the current
SDAQ. Even more bizarrely, the current SDAQ seems to have been created
with the same member variable values as a previously-deleted SDAQ.

Anyone know what's going on?

cheers,

Simon

This archive was generated by hypermail 2b29 : Sat Jan 04 2003 - 23:50:48 MET