Hep

[Manmeet]

Hi,

Problem is regarding the global variables.
I am running an win32 EXE created using VS2005 which in turn use many
DLL's which inturn are using static library (abc.LIB).
Now when I create a global variable in LIB project, it values is
changed( to null )after some point of time.
Does the scope of LIB or DLL has to do with that?
I mean loading and unloading of DLL.
Can anyone guide me on this issue.

Thanks in advance.

 

[Fernando Gómez]

* Manmeet:


It's simple: avoid global variables.

Use a Singleton instead?

 

[Christopher]

Hi,

Problem is regarding the global variables.
I am running an win32 EXE created using VS2005 which in turn use many
DLL's which inturn are using static library (abc.LIB).
Now when I create a global variable in LIB project, it values is
changed( to null )after some point of time.
Does the scope of LIB or DLL has to do with that?
I mean loading and unloading of DLL.
Can anyone guide me on this issue.

Globals and Statics have scope of the module they are defined in. i.e.
The .dll or library that defines them. They can also be exported to be
visible outside the module (keyword export).

Your problem is most likely that in C++ the order of initialization
and destruction for globals and statics is undefined. You are probably
trying to use the variable before the value has been set by the
initialization process. This is a common bug, especially where
singletons are relied on, and can be avoided by following Alf's
advice. Sometimes it is not possible. In those cases you must make
certain that no global or static is used during the construction of
any other global or static object. Also, that during the
deconstruction of any global or static object, that no other global or
static object is used.

Or you can try your hand at more complicated solutions like lifetime
managers.

If this occurs in a third party lib, You have to prove to them that
they have a problem. I suggest submittal of a minimum test case and
call stack to the author of the lib.

 

[James Kanze]

* Fernando Gómez:

Well, that would be good idea, even if many good people
caution against it.

Any that have any real experience with large applications?

With regards to global variables (including singletons), for the
most part, you do want to avoid mutable ones (althouth there are
also a few exceptions there---keeping track of the worst error
seen, in order to determine the return code, for example), but I
know of a couple of idioms which count on the execution of
static initializers to work.

 

[James Kanze]

Globals and Statics have scope of the module they are defined
in. i.e. The .dll or library that defines them.

Nonsense.

First, don't confuse scope with lifetime or linkage. A
declaration has scope, not a variable. And whether declarations
of the same name in different places refers to the same object
or not depends on linkage.

And finally, whether the object file is part of a library or not
is totally irrelevant to the question.

They can also be exported to be visible outside the module
(keyword export).

The keyword export only applies to templates, and isn't
implemented by a lot of compilers.

Your problem is most likely that in C++ the order of
initialization and destruction for globals and statics is
undefined.

Possibly. Alternatively, it's possible that he's built or is
loading the dynamic libraries in a way that causes the variable
to be defined more than once; he might start by outputting its
address. (This is, of course, very much outside the scope of
C++, which doesn't say much of anything about how dynamic
linking works. Unix has a number of options so that its
behavior can be controlled by the programmer; I believe Windows
does as well, with the difference that under Windows, the
options are link-time, where as under Unix, they are at least
partially runtime. At any rate, it's a very platform dependent
issue.)

 

[Stefan Ram]

First, don't confuse scope with lifetime or linkage. A
declaration has scope, not a variable. [..] [...]

A declaration is an _action_ that defines the scope [of the
name], [because it] happens in a scope, but doesn't *have* it.

¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯
The wording »scope of a declaration« is used in
ISO/IEC 14882:2003(E). For example:

»To determine the scope of a declaration, it is sometimes
convenient to refer to the potential scope of a
declaration. The scope of a declaration is the same as its
potential scope unless the potential scope contains
another declaration of the same name. In that case, the
potential scope of the declaration in the inner
(contained) declarative region is excluded from the scope
of the declaration in the outer (containing) declarative
region.« - ISO/IEC 14882:2003(E), 3.3p1.

one can extend the statement that a name has
scope to mean that _a variable has scope_.

This is a restriction (not an extension), because there are other
names that do not name an object, but a non-object entity or label.

</nitpick>

To »nitpick« means »to correct minutiae or find fault«
according to »http://en.wiktionary.org/wiki/nitpick«. So by
using »<nitpick>« one emphasizes that one will write someting
(more) correct. This usually is implied even without
»<nitpick>«, but someone who adds »<nitpick>« must be very
sure that he indeed /is/ (more) correct with regard to details.

 

[James Kanze]

[..]
First, don't confuse scope with lifetime or linkage. A
declaration has scope, not a variable. [..]

<nitpick>

A *name* has scope. A declaration is an _action_ that defines
the scope [of the name], [because it] happens in a scope, but
doesn't *have* it.

How right you are. In the end, a declaration is just a
directive to the compiler, telling it to do something. (There
are even some declarations which put the name in another scope;
the definition of a static class member, for example.)

A variable is an entity, a way to designate an object by means
of a name. Since a name and a variable are inseparable (a
variable cannot exist without a name), one can extend the
statement that a name has scope to mean that _a variable has
scope_. An *object* OTOH does not have a scope.

In other words, there are two categories of "objects", those
with names, and those without. Called, respectively, variables
and temporaries. But I don't think it's quite that simple in
C++, since scope is always limited to a single translation unit.
For various historical reasons, C++ distinguishes between scope
and linkage. Practically, it probably is acceptable to consider
external linkage as a "scope" which transcends translation unit
boundaries, provided we stick to the simple cases: the
declaration introduces the name into a more or less limited
scope in a single translation unit, even if the name is
"visible" in other translation units (external linkage). Thus,
for example, in:

void
f()
{
extern int i ;
}

The scope of `i' is limited to the function f, even though it
has external linkage, and an "extern int i ;" declaration in
another translation unit will associate the name i to the same
object.

The way I think of it, informally, is that scope defines the
visibility of a name, whereas linkage is concerned with the
binding of the name to the object (or function or reference).

Arguable, scope, linkage and lifetime are, or should be, more or
less orthogonal. But of course, they way they are specified is
very much linked in C++: scope affects the default lifetime,
even the type (as well as the scope) affects the default
linkage, and the same keyword will sometimes affect one,
sometimes another. If you tried to design something
intentionally to confuse beginners, you could hardly do a better
job of it.

I believe that's what you intended to express.

But didn't, at least not correctly.

 

[James Kanze]

James Kanze wrote: [...]
</nitpick>

To »nitpick« means »to correct minutiae or find fault«
according to »http://en.wiktionary.org/wiki/nitpick«. So by
using »<nitpick>« one emphasizes that one will write someting
(more) correct. This usually is implied even without
»<nitpick>«, but someone who adds »<nitpick>« must be very
sure that he indeed /is/ (more) correct with regard to details.

In everyday use, especially when one uses it referring to one's
own statements, the term is generally understood to mean that
the point being made isn't in anyway essential, and that the
statement being commented was really pretty close to correct to
begin with. In a posting like Victor's, I think it mainly
expresses an intent that the comments shouldn't be taken as a
serious criticism, and that it doesn't raise a fundamental issue
with the original text.

I think Victor actually raised a good point. In C++, at least,
the issues are complex (and in practice, I think this is true of
any language which supports separate compilation), and one
cannot be too precise with regards to the wording used.