TRint app using custom namespace

[nadrino]

@Axel

We only parse headers of dictionaries once we “need” them, and we remember only classes vs header, not function vs header. That’s why your object declaration makes the functions available.

Isn’t a way we could explicitly ask for parsing the header functions?

@Axel

You can add #pragma link C++ class GenericToolbox - does that help?

Unfortunately it doesn’t, and GenericToolbox is just a namespace so I don’t know what is it doing.

One side effect of this I think, is that ROOT_GENERATE_DICTIONARY is only performing a shallow scan of the passed header. This means for example that static members of function can’t be linked as they are supposed to be defined out-of-line. In C++17 it is fine since inline prefix is available for static members, and the dict generator can look at the definition if it’s defined later in the file.

Typically for C++14 builds of ROOT, the non out of line declarations is not seen. Even though it compiles fine, we get an error from IncrementalExecutor::executeFunction in the interpreter complaining about:

IncrementalExecutor::executeFunction: symbol '[...]' unresolved while linking [cling interface function]!
You are probably missing the definition of [...]
Maybe you need to load the corresponding shared library?

And I didn’t found any workaround for that yet. Here is a mock up example:

namespace{
  class Logger{
  public:
    Logger() = default;
    static void triggerNewLine(){ _isNewLine_ = true; }
  private:
    static bool _isNewLine_;
  };

  bool Logger::_isNewLine_{false};
}

The ROOT_GENERATE_DICTIONARY with a linkdef file will not see bool Logger::_isNewLine_{false}; and the following error will happen:

gundamRoot [0] Logger::triggerNewLine()
IncrementalExecutor::executeFunction: symbol '_ZN12_GLOBAL__N_16Logger11_isNewLine_E' unresolved while linking [cling interface function]!
You are probably missing the definition of (anonymous namespace)::Logger::_isNewLine_
Maybe you need to load the corresponding shared library?

Do you have a solution for this?

[jalopezg]

Hi @nadrino,

@nadrino

I don’t know have Rint does while parsing this instruction, but it takes few extra seconds while running gundamRoot

I was just wondering if building a C++ module (or PCH) would be an option for you; if the header -after all #includes- is large, this should be much faster than parsing the header every time.

@nadrino

Alright so after a few tries, it seems to be loading the header library on runtime without having to explicitly call #include. However the function are only available once I defined a dummy class.

In this case, as @axel mentioned, parsing of dictionary payload only happens when it is needed, e.g. the definition of TablePrinter is needed to instantiate it.

@nadrino

Isn’t a way we could explicitly ask for parsing the header functions?

Not sure of this one, maybe @pcanal can suggest something here.

@nadrino

The ROOT_GENERATE_DICTIONARY with a linkdef file will not see bool Logger::_isNewLine_{false}; and the following error will happen:

gundamRoot [0] Logger::triggerNewLine()
IncrementalExecutor::executeFunction: symbol '_ZN12_GLOBAL__N_16Logger11_isNewLine_E' unresolved while linking [cling interface function]!
You are probably missing the definition of (anonymous namespace)::Logger::_isNewLine_
Maybe you need to load the corresponding shared library?

Are you getting the same result with a named namespace? Unnamed namespaces guarantee that the compiler will generate a unique mangled name, which might cause problems during linking.

Cheers,
J.

[nadrino]

@jalopezg

I was just wondering if building a C++ module (or PCH) would be an option for you; if the header -after all #includes- is large, this should be much faster than parsing the header every time.

Interesting, do you know how to do that?

@jalopezg

Are you getting the same result with a named namespace? Unnamed namespaces guarantee that the compiler will generate a unique mangled name, which might cause problems during linking.

Yes indeed, I tried with a dummy variable like so:

namespace GenericToolbox{
  static double test;
}

And the result is the same:

gundamRoot [0] GenericToolbox::test
IncrementalExecutor::executeFunction: symbol '_ZN14GenericToolboxL4testE' unresolved while linking [cling interface function]!
You are probably missing the definition of GenericToolbox::test
Maybe you need to load the corresponding shared library?

In addition here, even by putting an inline prefix I get the error

[jalopezg]

Hi @nadrino,

I wanted to resurrect this topic (no I did not forget about it!); do you want to provide any updates? Should I dedicate some time this week to try to debug the issue?

Cheers,
J.