globals from lib accessed by other libs

[Christopher]

Is this a bad idea? I think it is. However, I am having a bit of trouble explaining why.

I generally frown on globals in the first place, but this seems even worse. Sharing a global from one library with other libraries?

Every 3rd Party lib I've used doesn't do this.

-----
In Lib 1, In A.H:

class A
{
// Various methods and data
};

extern A * pA;

-----
In Lib 1, In A.cpp:
A * pA = NULL;

-----

In Lib 2, in something.cpp:
#include "A.h"

A a;

void SomeMethod()
{
pA = &a;
}

-----
In Lib 3, in someother.cpp

void SomeOtherMethod()
{
pA->DoStuff();
}

 

[Victor Bazarov]

Is this a bad idea? I think it is. However, I am having a bit of trouble explaining why.
[..]

Simple: dependencies between parts of the system must always lead from
upper levels into lower levels, never up and never horizontally. This
is not a C++ language issue, however, and is better discussed in
comp.software-eng (or what's the name of that NG?)

V

 

[Mike McCarty]

Is this a bad idea? I think it is. However, I am having a bit of trouble explaining why.

I generally frown on globals in the first place, but this seems even worse. Sharing a global from one library with other libraries?

Beyond the usual caveats concerning global variables, an additional problemhere is that Lib2 will probably be unloaded before Lib1 at app shutdown. This leaves pA pointing at a destroyed object (since the instance was allocated statically) for some indeterminate span of time. All someone has to do is call SomeOtherMethod() at the wrong time and *kaboom*.

 

[BGB]

Is this a bad idea? I think it is. However, I am having a bit of trouble explaining why.

I generally frown on globals in the first place, but this seems even worse. Sharing a global from one library with other libraries?

Every 3rd Party lib I've used doesn't do this.

agreed, directly sharing globals is a bad idea.

even if globals are used internally (where, IMO, typically they
shouldn't be used, except in certain edge cases), better is to access
them via functions (or methods), which secondarily gives more freedom to
make design changes later on, such as moving the variable into a struct
or class, or even making the value be computed at runtime or depend on
some other context.

directly sharing globals, and even directly sharing struct and class
fields, is often a bad idea.


side note: it is for the above scenario that certain languages have
added things like properties and similar.

secondary side note: in some cases, shared globals may also run afoul of
things like DLL imports/exports, ... (one needs a special "__declspec"
so that the compiler knows to access the variable indirectly, otherwise
it wont link correctly).

or such...

 

[Jorgen Grahn]

Beyond the usual caveats concerning global variables, an addition...

Please don't post overlong lines! Here you even merged
the quoted lines.

Note that the original poster didn't define the term "library". There
is no unloading of ordinary libraries. Shared libraries work
differently in different OSes; he didn't state which one he was using,
either.

/Jorgen

 

[BGB]

Please don't post overlong lines! Here you even merged
the quoted lines.

Note that the original poster didn't define the term "library". There
is no unloading of ordinary libraries. Shared libraries work
differently in different OSes; he didn't state which one he was using,
either.

I at first thought that was what was being said, and considered saying
that "no, libraries don't generally get unloaded until the app actually
terminates".

then I looked more, and noted that it seemed like he was more talking
about global variables and dangling pointers or similar.

like, teardown process in a library frees the allocated object;
some other code tries to call a method for said just-freed object;
stuff blows up.

but, this isn't so much an issue with globals I think, but with general
programming practice (things like setting freed object-pointers to NULL,
and checking that pointers aren't NULL before trying to use them, ...).