Local vs Global Static

[Suraj]

I know a local static variable's (declared within a function) scope is
within that function as the name itself would not be available outside
the function.

Also, i know that a static variable declared in global scope is
accessible in all functions.

Are there other differences between these 2? In terms of memory
allocation, performance etc?

static variables are not stored in stack or heap. plus the lifetime is
throughout the life of the program

I hope this isn't too naive to irritate the group

Thanks,
Suraj

 

[Ian Collins]

I know a local static variable's (declared within a function) scope is
within that function as the name itself would not be available outside
the function.

Also, i know that a static variable declared in global scope is
accessible in all functions.

Are there other differences between these 2? In terms of memory
allocation, performance etc?

Memory allocation is almost always an implementation detail you don;t
have to worry about (it is also platform/compiler specific).

One significant difference is when the variable is initialised. A
global is initialised some time before main() is called (again, the
details are left to the implementation) while a function scope static
variable is initialised the first time the function is called.

This distinction can be very significant if you wish to manage the order
of initialisation.

 

[James Kanze]

Ian Collins wrote:

[...]

One significant difference is when the variable is
initialised. A global is initialised some time before
main() is called (again, the details are left to the
implementation) while a function scope static variable is
initialised the first time the function is called.

Actually, a global isn't necessarily initialized before main()
is entered. C++03 standard, section 3.6.2 para 3:

But in practice, the ordering constraints for initialization
after main are impossible to meet, so no one does it.

This is to support dynamic libraries that are loaded after
main begins.

If the link isn't finished before execution, you're not talking
about C++. Formally, using a dynamic library (unless it is
automatically loaded before the first initializer is executed)
is undefined behavior.

In practice, of course, all systems providing support for
dynamic loading define the behavior. In the case of Sun CC
under Solaris, for example, it is defined that the
initialization of static variables will occur between the call
of dlopen and the return---the order of initialization within
the library is NOT defined any more than the order for variables
initialized before main (nor any less, at least in
practice---but there is no guarantee that an object will be
initialized before its first use).

So the real distinction is that a static object inside a
function is not initialized until execution reaches it (not
just the function, but the line that defines the object):

void f( bool b )
{
static Foo foo; // initialized on first f()
if ( b )
static Foo foo2; // initialized on first f( true )
}

With the results that it might never be initialized at all, e.g.
if the function isn't every called (or the block is never
entered).

 

[gw7rib]

I know a local static variable's (declared within a function) scope is
within that function as the name itself would not be available outside
the function.

Also, i know that a static variable declared in global scope is
accessible in all functions.

Are there other differences between these 2? In terms of memory
allocation, performance etc?

static variables are not stored in stack or heap. plus the lifetime is
throughout the life of the program

I hope this isn't too naive to irritate the group

One detail which no-one seems to have pointed out so far is that the
word "static" has a totally different meaning when the variable occurs
outside a function.

*Inside* a function, as you have said, it means that the variable's
lifetime is that of the program (or, at least, it lasts from one call
of the function to the next - other posters have given a bit more
detail).

However, *outside* a function, a variable's lifetime is that of the
program *whether or not* you use the word "static". Using the word
"static" means that the variable cannot be accessed from functions in
other files (or more strictly, translation units). If you don't say
"static" the variable can be accessed from other files, if they say
"extern" which makes them look in all files for the variable.

Hope that helps.
Paul.

 

[Jerry Coffin]

[ ... ]

One detail which no-one seems to have pointed out so far is that the
word "static" has a totally different meaning when the variable occurs
outside a function.

Nobody's mentioned it because it's not really true.

In both cases, static means local visibility and global lifetime. All
that's changed is what would happen by default (i.e., if you didn't
include the "static"). In these two cases, part of what static specifies
happens to coincide with a different part of what would have happened
without it...

 

[James Kanze]

One detail which no-one seems to have pointed out so far is
that the word "static" has a totally different meaning when
the variable occurs outside a function.

The keyword static is seriously overloaded, yes. Used in a
class, it has still a different meaning.

*Inside* a function, as you have said, it means that the
variable's lifetime is that of the program (or, at least, it
lasts from one call of the function to the next - other
posters have given a bit more detail).

In terms of the standard, that the defined symbol has static
lifetime.

However, *outside* a function, a variable's lifetime is that
of the program *whether or not* you use the word "static".
Using the word "static" means that the variable cannot be
accessed from functions in other files (or more strictly,
translation units).

In terms of the standard, that the symbol has internal linkage.

If you don't say "static" the variable can be accessed from
other files, if they say "extern" which makes them look in all
files for the variable.

It's a little more complicated than that, since:

-- Objects declared const also have internal linkage, unless
they are declared extern.

-- Objects declared extern always have external linkage, but a
declaration with storage class extern is only a definition
if it has an initializer.

Now for a real problem: I define a type which has only a default
constructor, and doesn't support copy. How do I declare a const
instance of this type with external linkage? (To date, I've
never actually had this problem. Off hand, I don't think there
is a solution.)

 

[James Kanze]

[ ... ]

One detail which no-one seems to have pointed out so far is
that the word "static" has a totally different meaning when
the variable occurs outside a function.

Nobody's mentioned it because it's not really true.

In both cases, static means local visibility and global
lifetime. All that's changed is what would happen by default
(i.e., if you didn't include the "static"). In these two
cases, part of what static specifies happens to coincide with
a different part of what would have happened without it...

That's a bit disingenuous, and ignores basic language theory (in
which the "meaning" of a word is precisely how it is used, i.e.
what it changes in the meaning of a sentence in which it is
used). Quite clearly: in the case of a local variable, static
changes the lifetime of the object, in the case of a variable or
function at namespace scope, it changes the linkage of the
symbol (and has no effect on the object). And at class scope,
it affects neither linkage nor lifetime (at least in the case of
a function): it has yet a different meaning (which isn't quite
the same when applied to functions and objects, either).

The word itself, using its technical meaning outside of C++,
would only affect lifetime, and it was originally used for local
variables. I'm not sure what logic caused it to be used when
the need for changing linkage at namespace scope became
apparent. The standards committee has deprecated its use for
declaring objects at namespace scope, because it doesn't seem
appropriate (amonst other reasons). It remains necessary when
declaring functions at namespace scope, if the functions are
`extern "C"' (where the unnamed namespace does not guarantee
invisibility in other translation units).

 

[Jerry Coffin]

(e-mail address removed)>, (e-mail address removed)
says...

[ ... ]

That's a bit disingenuous, and ignores basic language theory (in
which the "meaning" of a word is precisely how it is used, i.e.
what it changes in the meaning of a sentence in which it is
used).

I can't say I agree. Consider something like: "what is your name?" In
most casual conversations "Jerry" would be the reasonable answer. On
some sort of government form, I'd more likely give my full name. The
fact that I'd already take the "full" for granted hardly renders it
meaningless nor my interpretation of it disingenuous.