The problem you reported is not a bug in gcc. By default, gcc
*without* optimization turned on will *not* inline function calls, even
if the functions are specified as "inline" in the class definition.
Recall that the "inline" keyword does not guarantee that a function
will be emitted "inline" at its call site. The "inline" keyword is only
a hint to the compiler that it may want to consider emitting the
function "inline" if it chooses too.
In the "GNU CC manual" for gcc/g++, there is a very informative
section on inline functions. There you will find descriptions of the
numerous options to gcc/g++ controlling how, if and when functions may
be emitted inline at their call site. In fact, gcc/g++ with
optimization turned on will usually emit "simple" functions "inline" at
their call site even if you don't specify the "inline" keyword (provided
they are defined in the class definition, i.e. in the header file).
If your performance measurements indicate that you need to have your
functions "inlined" as much as possible, then the easiest solution is to
simply turn on optimization (i.e. with the gcc/g++ flags -O, -O2, etc.).
-- Matt Langston SLD, Stanford Linear Accelerator Center langston@SLAC.Stanford.EDU (415) 926-3279Pasha Murat wrote: > > Those of us who use GCC-compiled ROOT shold be aware of a weird > compiler bug present in version 2.7.2.x: > > declaration of virtual function in the class header makes compiler > (sometimes?) to forget about the definitions of inline methods of this > class: > ---------------------------------------------------------- test.cc > class A { > int a; > public: > A(); > ~A(); > inline int aa() { return 1; } > virtual int qqqq(); > }; > > main() { > A q; > int b = q.aa(); > } > -------------------------------------------------- > /data35/upgrade/murat/run1>gcc -c test.cc ; nm test.o | grep aa > U aa__1A > -------------------------------------------------------------------------------- > You see that *inline* method A::aa() body of which should normally be inserted > into the source code has been considered to be an *external* function by GCC. > > As ClassDef(..) macro contains declarations of virtual functions this may cause > problems for people using GCC-compiled ROOT. > > This "feature" is reproducible on IRIX 6.2 and on AIX 4.2. > For some reasons switching ON optimization on AIX resolves the problem, on > IRIX however it doesn't help. I didn't try versions of GCC other than > 2.7.2.1(IRIX) and 2.7.2.2(AIX Power PC). > > The only other C++ compiler I tried on UNIX - KAI C++ (on IRIX 6.2) doesn't > have this bug. > Regards, Pasha.