Re: ACLIC and privacy of classes

Hi Thiemo,

It is a side effect of the fact that the script is being compiled by ACLiC as part of the CINT dictionary for the script.

It is *not* intended as a feature to rely on. In particular we are planning to change this behavior when migrating to the Cling.

Cheers,
Philippe.

On 2/9/12 9:53 AM, Thiemo Nagel wrote:
> Dear ROOTers,
>
> today I've come across an interesting feature of ACLIC (or ROOT?): It seems to break the privacy of classes (and I remember very
> faintly that I've read about this somewhere). Take the following code, where a sub-class (wrongly) tries to access the parent
> class' private member:
>
> #include <iostream>
>
> class A {
> private:
> int fa;
> };
>
> class B : public A {
> public:
> B() { fa=1; std::cout << fa << std::endl; }
> };
>
> As expected, this will cause a compilation error, when compiled directly with g++:
>
> [0] mnemosyne:~/analysis/selector> g++ test2.cc
> test2.cc: In constructor ‘B::B()’:
> test2.cc:5: error: ‘int A::fa’ is private
> test2.cc:10: error: within this context
> test2.cc:5: error: ‘int A::fa’ is private
> test2.cc:10: error: within this context
>
> But with v5.30.03 ROOT/ACLIC the broken code "just works":
>
> [0] mnemosyne:~/analysis/selector> root
> root [0] .L test2.cc+
> Info in <TUnixSystem::ACLiC>: creating shared library /nfs/hicran/project/compass/analysis/tnagel/analysis/selector/./test2_cc.so
> root [1] B b;
> 1
> root [2]
>
> To my mind, this behaviour raises two questions: Is it a bug or a feature? Can it be fixed or disabled?
>
> Thank you and kind regards,
> Thiemo
>
Received on Thu Feb 09 2012 - 16:58:50 CET