Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c++ > #14757 > unrolled thread

globals from lib accessed by other libs

Back to article view | Back to comp.lang.c++

Contents

  globals from lib accessed by other libs Christopher <cpisz@austin.rr.com> - 2012-03-05 08:24 -0800
    Re: globals from lib accessed by other libs Victor Bazarov <v.bazarov@comcast.invalid> - 2012-03-05 12:03 -0500
    Re: globals from lib accessed by other libs Mike McCarty <mcmccarty@gmail.com> - 2012-03-05 09:56 -0800
      Re: globals from lib accessed by other libs Jorgen Grahn <grahn+nntp@snipabacken.se> - 2012-03-07 13:16 +0000
        Re: globals from lib accessed by other libs BGB <cr88192@hotmail.com> - 2012-03-08 09:39 -0700
    Re: globals from lib accessed by other libs BGB <cr88192@hotmail.com> - 2012-03-05 11:16 -0700

#14757 — globals from lib accessed by other libs

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();
}

[toc] | [next] | [standalone]

#14758

On 3/5/2012 11:24 AM, Christopher wrote:
> 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
-- 
I do not respond to top-posted replies, please don't ask

[toc] | [prev] | [next] | [standalone]

#14759

On Monday, March 5, 2012 10:24:56 AM UTC-6, Christopher wrote:
> 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 problem here 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*.  

[toc] | [prev] | [next] | [standalone]

#14801

On Mon, 2012-03-05, Mike McCarty wrote:
> On Monday, March 5, 2012 10:24:56 AM UTC-6, Christopher wrote:
>> Is this a bad idea? I think it is. However, I am having a bit of...
>> 
>> I generally frown on globals in the first place, but this seems ...
>
> 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

-- 
  // Jorgen Grahn <grahn@  Oo  o.   .     .
\X/     snipabacken.se>   O  o   .

[toc] | [prev] | [next] | [standalone]

#14831

On 3/7/2012 6:16 AM, Jorgen Grahn wrote:
> On Mon, 2012-03-05, Mike McCarty wrote:
>> On Monday, March 5, 2012 10:24:56 AM UTC-6, Christopher wrote:
>>> Is this a bad idea? I think it is. However, I am having a bit of...
>>>
>>> I generally frown on globals in the first place, but this seems ...
>>
>> 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.
>

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, ...).


> /Jorgen
>

[toc] | [prev] | [next] | [standalone]

#14760

On 3/5/2012 9:24 AM, Christopher wrote:
> 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...

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.c++

csiph-web