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.
because it was in the coding guidelines some years ago. The rule was removed
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).