help-gplusplus
[Top][All Lists]
Advanced

[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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]