we agree completely. Most of the automatically generated code
of CINT contains already a lot of G__ and other symbols to make
it less readable -:). These two slipped through. Masaharu Goto, the
author of CINT (who is also on the list) will surely fix this as soon
as possible and the next release of ROOT should at least not have
this problem anymore. Thanks for reporting this problem.
Not to start a debate on coding conventions (10 programmers 10
preferred styles) we still would like to ask people to have look
at the page: http://root.cern.ch/root/Conventions.html
Adhering to a few very simple rules will make the reading of code
of fellow ROOT users and developers much easier.
Cheers, Fons Rademakers.
dave morrison wrote:
>
> Hi all,
>
> In experimenting with adding classes to ROOT, I think I stumbled on an
> inconvenience in the way rootcint works. I wanted to see how ROOT
> would work with user-defined abstract base classes, so I put together
> a seemingly trivial example using two classes, `base' and `derived'.
> The native SGI CC found errors in the dictionary file for these
> classes created by running `rootcint'. When I looked at the source, I
> found the following:
>
> /* Setting up class inheritance */
> static long G__2vbo_derived_base_0(long pobject) {
> derived *derived=(derived*)pobject;
> base *base=derived;
> return((long)base-(long)derived);
> }
>
> Here's a dissection of that first variable declaration:
>
> derived *derived=(derived*)pobject;
> ^ ^
> | |
> | name of local variable automatically generated by rootcint
> |
> name taken from the name of my class, `derived'
>
> The fact that the local variable (coincidentally) has the same name as
> my class, causes errors in compilation. If I change the name of my
> class to `derived1', the same lines in the output of `rootcint' look
> like:
>
> /* Setting up class inheritance */
> static long G__2vbo_derived1_base1_0(long pobject) {
> derived1 *derived=(derived1*)pobject;
> base1 *base=derived;
> return((long)base-(long)derived);
> }
>
> And everything works just fine. We can certainly debate whether user
> classes named `derived' and `base' are a good idea or not, but since
> these functions above are automatically generated by `rootcint', and
> are not generally intended for human consumption, I'd suggest it pick
> names less likely to collide with user code - lots of underscores and
> the like. Just my 2 [cents,francs,yen].
>
> Cheers,
> Dave
>
> --
> David P. Morrison, Postdoctoral Research Associate
> University of Tennessee, 401 Nielsen Hall, Knoxville, TN 37996-1200
> Oak Ridge National Laboratory, MS 6374, Oak Ridge, TN 37831-6374
> Phone: (423) 576-8765, Fax: (423) 576-5780, Finger for public key
-- Org: CERN, European Laboratory for Particle Physics. Mail: 1211 Geneve 23, Switzerland Phone: +41 22 7679248 E-Mail: Fons.Rademakers@cern.ch Fax: +41 22 7822601