This is the mail archive of the cygwin-patches@cygwin.com mailing list for the Cygwin project.


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

Re: [PATCH] Move per_thread::set() def from fork.cc to perthread.h


On Tue, Oct 16, 2001 at 12:43:36PM +1000, Robert Collins wrote:
>----- Original Message -----
>From: "Christopher Faylor" <cgf@redhat.com>
>To: <cygwin-patches@cygwin.com>
>>>>If you mean that you've moved the inline methods into the source file
>>>>then I don't want to do that.
>>>
>>>No, just the virtuals.  Like Robert said, I don't believe they inline.
>>
>>Actually, AFAICT, they do inline.  That's why I changed my mind.
>
>???  How can a virtual function inline.  Virtual functions are found
>through the (Vague memory here ahhh) VMT ?  anyway, to inline them the
>compiler must know in advance the type of the object being operated on,
>and for all foo* types that is *not* known.

If you are referencing a virtual function via a base class pointer,
then, no, they can't be inlined.  There are certainly situations where a
compiler knows enough about the method to inline it, though.  I've traced
through enough fhandler virtual inlined methods to know that the compiler
does the right thing when it can.  I also wrote a simple test case to
convince myself that I wasn't just imagining things.

However, you are 100% right in the specific case that we are discussing.
In the fork() case, the 'set' method couldn't be inlined since it was
referenced via the per_thread base class.

cgf


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