Re: ACLIC and privacy of classes

Hi Thiemo,

Using this requires both the definition of R__ACCESS_IN_SYMBOL and a modification of the behavior of rootcint. It used on Windows (because the C++ mangled symbol contains the privacy level) but leads to a (small) restriction in features supported by the dictionary.

I do not recommend using it as a general case as the downside (allowing illegal C++ to compile is somewhat better than the alternative (preventing legal C++ from being properly handled). (And remember that this behavior will disappear in future releases).

Cheers,
Philippe.

On 2/9/12 10:26 AM, Thiemo Nagel wrote:
> Dear Philippe,
>
> thank you very much for the quick reply! Now that you're saying it's related to the dictionary, I've found the piece of
> (generated) code that seems to be the culprit:
>
> #define R__DICTIONARY_FILENAME UCint
> #include "RConfig.h" //rootcint 4834
> #if !defined(R__ACCESS_IN_SYMBOL)
> //Break the privacy of classes -- Disabled for the moment
> #define private public
> #define protected public
> #endif
>
> The code seems to suggest that there is a possibility to disable the "feature" by defining R__ACCESS_IN_SYMBOL. Is that a viable
> option, or will it break something?
>
> Thank you and kind regards,
> Thiemo
>
>
> On 02/09/2012 04:58 PM, Philippe Canal wrote:
>> 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 - 17:34:04 CET