Re: ACLIC and privacy of classes

From: Thiemo Nagel <thiemo.nagel_at_tum.de>
Date: Thu, 9 Feb 2012 17:26:09 +0100

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
>>

-- 
+-----------------------------------+--------------------------+
| Dipl.-Phys. Thiemo Nagel          |                          |
| Technische Universitaet Muenchen  | Room    PH1 3276         |
| Physik-Department E18             |                          |
| James-Franck-Strasse              | Phone  +49 89 289-12379  |
| D-85747 Garching                  | Fax    +49 89 289-12570  |
+-----------------------------------+--------------------------+

Received on Thu Feb 09 2012 - 17:26:40 CET