Class from one file not recognized when invoked from another macro file

[wtford]

I’d like to know if the following behavior is expected. I capture from the tutorial a file
macro4.C:

#include <iostream>

class MyClass {

private:
   float   fX;     //x position in centimeters
   float   fY;     //y position in centimeters

public:
   MyClass() { fX = fY = -1; }
   virtual void Print() const;
   void         SetX(float x) { fX = x; }
   void         SetY(float y) { fY = y; }
};

void MyClass::Print() const
{
   cout << "fX = " << fX << ", fY = " << fY << endl;
}

class Child : public MyClass {
public:
   void Print() const;
};

void Child::Print() const
{
   cout << "This is Child::Print()" << endl;
   MyClass::Print();
}

I create the following two additional files:
load_macro4.C:

{
  gROOT->Reset();
  gROOT->ProcessLine(".L macro4.C+");
}

and run_macro4.C:

{
  MyClass* myClass = new MyClass();

  MyClass *a = new Child;
  a->Print();
  a->SetX(10);
  a->SetY(12);
  a->Print();
  gROOT->ProcessLine(".class MyClass");
}

I run these with the following (successful) results:

> root -l -b load_macro4.C run_macro4.C
root [0] 
Processing load_macro4.C...
Info in <TMacOSXSystem::ACLiC>: creating shared library /Users/wtford/cms/src/root/./macro4_C.so
Warning in cling::IncrementalParser::CheckABICompatibility():
  C++ ABI mismatch, compiled with _LIBCPP_VERSION v1101 running with v3700
Processing run_macro4.C...
This is Child::Print()
fX = -1, fY = -1
This is Child::Print()
fX = 10, fY = 12
===========================================================================
class MyClass
SIZE: 16 FILE: macro4.C LINE: 3
List of member variables --------------------------------------------------
macro4.C          6 0x8        private: float fX
macro4.C          7 0xc        private: float fY
List of member functions :---------------------------------------------------
filename     line:size busy function type and name
(compiled)     (NA):(NA) 0 public: MyClass();
(compiled)     (NA):(NA) 0 public: virtual void Print() const;
(compiled)     (NA):(NA) 0 public: void SetX(float x);
(compiled)     (NA):(NA) 0 public: void SetY(float y);
root [2]

However, if I combine the load and run steps as
loadAndRun_macro4.C:

{
  gROOT->Reset();
  gROOT->ProcessLine(".L macro4.C+");

  MyClass* myClass = new MyClass();

  MyClass *a = new Child;
  a->Print();
  a->SetX(10);
  a->SetY(12);
  a->Print();
  gROOT->ProcessLine(".class MyClass");
}

I get an error:

> root -l -b loadAndRun_macro4.C
root [0] 
Processing loadAndRun_macro4.C...
/Users/wtford/cms/src/root/./loadAndRun_macro4.C:6:26: error: unknown type name
      'MyClass'
  MyClass* myClass = new MyClass();
                         ^
/Users/wtford/cms/src/root/./loadAndRun_macro4.C:8:3: error: unknown type name
      'MyClass'
  MyClass *a = new Child;
  ^
/Users/wtford/cms/src/root/./loadAndRun_macro4.C:8:20: error: unknown type name
      'Child'
  MyClass *a = new Child;
                   ^
root [1]

I would have expected the more compact, second method to work; can someone identify the problem? The two-step method is OK, but seems more a work-around than a real solution.
I ran this test on the system described below, but see the same behavior with code of my own run on Scientific Linux 6.

---

ROOT Version 6.04/10:
Mac OS 10.11.6, g++ 4.2.1:

---

Bill

[couet]

It would be good you edit your post and reformat it according to the rules described here: Tips for Efficient and Successful Posting
I will ease the reading of the code part of it.

[wtford]

Hi,

Thanks for the pointer on how to fix that. Much better.

Bill

[eguiraud]

Hi Bill,
if I understand correctly, in the first case the interpreter first compiles MyClass into a library (and loads the library) and then compiles and executes a macro which uses such library. Everything ok.
In the second case the interpreter, tries to compile a macro that uses MyClass, but the class is not known yet (because you haven’t executed the code that compiles it and loads it yet).

I think the confusion arises from the fact that ROOT’s interpreter does not work line-by-line, but function-by-function. But I’m not a cling expert. @pcanal @vvassilev is my interpretation correct? What’s the granularity at which the interpreter compiles-and-runs things?

Cheers,
Enrico

[wtford]

Thanks, Enrico. That explanation is helpful.

Bill