[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Forcing instantiation of static class functions
From: |
Paul Pluzhnikov |
Subject: |
Re: Forcing instantiation of static class functions |
Date: |
Sat, 05 May 2007 21:43:10 -0700 |
User-agent: |
Gnus/5.1006 (Gnus v5.10.6) XEmacs/21.4 (Jumbo Shrimp, linux) |
Mike Harrold <mike@nospam.com> writes:
>>What is "this unit" ?
> A file contain a class.
A file can not "contain a class".
You are not explaining yourself very well; you probably mean the
file that contains implementations of non-inlined X::* functions.
> I should have added that everything is compiled with the
> -fno-default-inline switch to prevent functions being
> inlined.
Yes, you should have. However, even if that flag is used, my copy
of gcc-4.1.1 emits code for X::foo() into the *using* module,
provided X::foo()'s body is present (as it should be).
Therefore, you likely are *still* not telling the whole story.
> I want a switch that forces the emission of code for all static
> functions in a class. (I've subsequently found that this isn't limited
> to static functions.
There *is* a switch that forces emission of code for all inline
functions, and you already know about it.
> The compiler isn't emitting member functions either.)
That's right: there is no point in emitting code for unused inline
(static or member) functions -- that code could and will be emitted
when the function is used (in the other unit).
Both gcc-3.3 and 4.1.1 exhibit the same behavior here, so I suspect
you are just barking up the wrong tree.
> What I really want is to know what changed with regard to
> code emission. I have looked through the docs, and can't find anything.
Something definitely changed, but not this (AFAICT).
>>Finally, when I compile your test on Linux with gcc-3.3.3,
>>I do not get a definition of X::foo(), and I bet your gcc-3.4
>>doesn't emit it either (for that test case). IOW, you are not telling
>>the whole story, and omitting some very relevant parts.
>
> Not at all
You already admitted earlier that you didn't tell the whole story.
> my program compiles _and links_ fine on gcc-3.2 and
> gcc-3.4. It will not link with gcc-4.1 with several thousand
> "undefined reference" errors...
Oh, I believe that.
But the test case you provided compiles the same with gcc-3.3
and 4.1.1 (at least for me); and therefore does *not* demonstrate
the problem you are having.
Now the interesting question is: what happens with that case for
your versions. If it compiles differently, then it is likely that
*exact* versions of gcc matter. More likely, the test case compiles
the same for you as well; in which case the test case is just not
relevant -- something *else* (that you didn't tell us about) matters.
Cheers,
--
In order to understand recursion you must first understand recursion.
Remove /-nsp/ for email.