This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: Inlining problem


> Date: Thu, 04 Jan 2001 20:33:12 +1300
> From: Bryce McKinlay <bryce@albatross.co.nz>
> To: rjschwei@mindspring.com
> CC: gcc@gcc.gnu.org

> > The method "DeclareMatVar(MatPointVarID const &, MatPointVarID const &)"
> > is declared as inline, and thus no symbol should be created when the
> > method is being called. This of course leads to link errors.
> >

> "inline" is just a _hint_ to the compiler. It does not guarantee that
> an outlined implementation will not be emitted somewhere, so if you
> include a header file containg inline declarations the linker will get
> confused.

I don't know what your trying to say it but it sounds completely
wrong.  The linker doesn't get confused.

> You can use "#pragma interface"/"#pragma implementation" to ensure
> that the compiler only attempts to emit an outlined implementation of
> your method in one object file.

We don't recommend these in this situation.

> I would also suggest not pre-declaring inline functions if you want to
> be sure they are inlined wherever possible. This is probibly why you
> are seeing this problem.

No, I suspect this has nothing to do with the problem.

The problem he is seeing is that he appears to have failed to meet the
mandated requirement of the C++ language standard.  My guess is that
he either failed to define MatPointLayout::~MatPointLayout ()
somewhere, or he failed to define all inlines in all translation
units, in particular the one that defines the above virtual.  Since he
stripped the # lines from the file, I can't tell is the inline
definitions are in fact in the same file that has the class
declaration.  Since he didn't show the .ii file from the file that
defines the virtual dtor, I can't verify that that file has the
definitions of the inlines in it.

In addition, the testcase provided fails _because_ he stripped some of
the # lines.  The # lines have heavy semantic content in C++ and
cannot be stripped.

If I negate the effects of stripping the # lines, and add:

MatPointLayout::~MatPointLayout () { }

to the translation unit (this is a virtual function that is mandated
to be defined by the user, somewhere), we can notice that the inlines
he wants `mysteriously' appear.

And last this is a FAQ.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]