Re: extern const variable in case label
On Oct 3, 1:33 pm, "Christian Meier" <chris@no_spam.com> wrote:
Interesting. I would have thought 0 occurances (or at most,
only for those where the address was being taken).
I don't know in which cases the address is needed. I suppose
there are many other situations than "&iValue". What about
passing it to a function which takes a "const int&" as
parameter? If references are implemented as pointers than the
address is needed for this. Using this variable in such a way
is not unusual in our project. Could this be the reason for
all (or at least almost) the symbols in my executable?
Technically, the rule is that an instance of the variable is
needed if the variable is used in any context where there is not
an immediate lvalue to rvalue conversion. Practically, in the
case of const values, that means taking its address or using it
to initialize a reference. (I can't think of any other cases
which would be legal with a const variable, but I could have
forgotten some.)
A second rule sometimes comes into play: the "as if" rule.
Basically, given a legal program, the compiler can do anything
it wants, as long as the observable behavior of the program is
"as if" it followed the abstract semantics. Thus, if you pass
the value by reference to an inline function, the compiler is
likely able to optimize away the use of the reference, and not
generate the instance. The observable behavior of your code
would not change. I expect that most compilers do this as well,
if they actually inline the function.
And just curious, but why are you passing int's by const
references?
It's possible that in debug mode, g++ would generate them, since you
could presumable modify the value with a debugger, but a quick
check with a single module on my system (g++ 4.1.0 under Solaris
and Linux) didn't reveal them. Even in debug mode: "nm a.out |
grep staticConst" (where the actual variable was named
staticConst) didn't have any output. Sun CC did generate the
object in debug mode (as a global, no less, but with a funny
prefix added to the name, presumably to make it distinct), but
not when optimizing was turned on.
I'm curious. If you compile the following program:
static int const staticConst = 42 ;
int
main()
{
return staticConst ;
}
then do "nm a.out | grep staticConst", what do you get (with and
without optimizing)?
I don't get any output for this.
But for an extended version of your code, I got an indication:
$ cat main.cpp
#include <iostream>
static int const staticConst = 42;
void func(const int& ri)
{
std::cout << ri << '\n';
}
int main()
{
func(staticConst);
return staticConst ;
}
$ g++ -o main main.cpp
$ nm main | grep staticConst
0000000000400938 r staticConst
$ g++ -O3 -o main main.cpp
$ nm main | grep staticConst
$
Compiling this code without an explicit optimization level
results in having 1 symbol staticConst. However, we are
compiling everything with -O3.
That's what I explained above. When optimization is turned on,
g++ will inline simple functions anytime it sees the definition.
Even if the function is not declared inline. With the result
that it doesn't ever actually need the instance, and won't
generate it.
In most cases, about the only time you'll have references to a
const int is as a result of template instantiation (and even
then, one could argue that having things like
std::vector<>::push_back take a T const&, rather than simply a
T, is poor design). Because g++ doesn't implement export, that
means that the implementation of the function will be visible.
And because the function has to be in a header file, it should
be small enough that g++ can inline it with -O3.
That's for the theory. In practice, implementations of things
like std::vector<>::push_back often involve enough levels of
indirection that it's quite possible that g++ doesn't manage to
inline them completely, which could result in what you are
seeing. (The obvious answer then is to get a better compiler
and a better implementation of the library. Easier said than
done---all of the other implementations I know have the same
problems:-).)
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34