Alternative to global variables in c++: Newbie

[weird0]

Is there any alternative way to work in c# as if i want some variable
or object to be globally
available in c# just like i can do it in c++ b defining on top of
main().

 

[Guest]

No.
The closest you can come is to use a static class variable.
--
David Anton
www.tangiblesoftwaresolutions.com
Instant C#: VB to C# converter
Instant VB: C# to VB converter
Instant C++: C#/VB to C++ converter
Instant Python: C#/VB to Python converter

 

[pvdg42]

Is there any alternative way to work in c# as if i want some variable
or object to be globally
available in c# just like i can do it in c++ b defining on top of
main().

I'll start by telling you what you don't want to hear:
Global variables are the antithesis of everything a good object oriented
design tries to achieve. Principles like encapsulation and information
hiding are violated when all code has unrestricted access to data. You
should consider looking into private fields defined in your classes, with
public properties defined to give outside code controlled access to the
data.

There is no truly global variable available in C# as there is in C/C++.
In my limited experience, the closest you'll come is to declare public
static fields in a class, and make that class available in your project
namespace, and that's generally not a good idea, IMHO.

 

[> Adrian]

Can someone give me one good reason why statics are so terrible?
Ok others can drill into the application and muck about with it, so what?
(I am not talking about situations that need special security protection.)

Adrian.

 

[Jon Skeet [C# MVP]]

Can someone give me one good reason why statics are so terrible?
Ok others can drill into the application and muck about with it, so what?
(I am not talking about situations that need special security protection.)

For one thing, the more static state there is, the harder things are to
think about *and test* in isolation.

Some things naturally lend themselves to statics (and/or singletons)
but they should generally be few and far between.

 

[rayreeves]

Global data was a natural, efficient and invaluable way to share data but
open to abuse. The public static method of C# seems like an effective
substitute. I have asked before in this group what would be the recommended
way to share data collected by a dialog box. The only suggestion was to
instantiate the classes that need to know and pass the data into the
constructors. Although sound, this suggestion has several disadvantages: the
dialog box programmer is credited with information she doesn't need to know
about the whole project, and it leads to duplications of the data. It's not
the same as sharing. The suggestion of private data with "controlled access"
is very isolationist; it raises the question of why it was private in the
first place, and leads to code proliferation in various ways. C# is not
conspicuous for it's efficiency although, arguably, that is not a serious
failing in this day and age.

Ray Reeves

 

[Peter Duniho]

Global data was a natural, efficient and invaluable way to share data but
open to abuse. The public static method of C# seems like an effective
substitute. I have asked before in this group what would be the
recommended
way to share data collected by a dialog box. The only suggestion was to
instantiate the classes that need to know and pass the data into the
constructors.

There is so much traffic on this newsgroup, topics drift so frequently,
and subjects so often don't reflect what's actually in the thread (or even
the first post in a thread) that not every question is seen by every
person reading the newsgroup.

Personally, I would never recommend that if a dialog box gathers
information to be shared by multiple classes, that the correct solution is
to have the dialog box instantiate all of those classes and initialize
them with the data from the dialog box. I'm surprised you even used the
word "sound" to describe the idea. It has all of the disadvantages you
describe, and is every bit as problematic as you think it is.

But that doesn't mean you need global variables. Data should be stored in
an object that matches the visibility and lifetime of that data. In the
case of a dialog box, some component of the code created and displayed
that dialog box, and generally that component is a likely candidate for
storage of the data obtained by the dialog box.

How it does that depends on the rest of the way that data is used. If the
data is needed only temporarily to instantiate other objects, then the
code calling the dialog box is probably also the code instantiating the
other objects. So it should store the data from the dialog box long
enough to do that.

Another scenario is that the dialog box allows the user to initialize some
default settings that persist through the lifetime of the application. In
that case, the data might be more appropriately stored in the main
Application class, or in the Properties.Settings.Default class (if they
are to be persistent from one execution session to another, for example).

There are no hard and fast rules...it just depends on what you intend to
do with the data. But even at the simplest level, the Application object
makes a perfectly fine repository for things that would have been global
variables in a non-OOP environment. (And of course it goes without saying
that the *only* data that should be stored in the Application object are
data that truly do need to persist for the entire lifetime of the
application).

Pete

 

[Bruce Wood]

Well, Jon Skeet came up with an interesting reason as to why _statics_
are not a good idea, but I think that public fields (aka "global
variables") are frowned upon far more than statics.

To me, the problem isn't static-ness: it's direct, global
accessibility to data. Make that static field private and wrap that
puppy in a property and I'm happier about the whole thing: at least
then you can make some guarantees about what it can be set to and
when. Otherwise you can make no guarantees about its value (state).
Public static fields are even more disastrous in a multi-threading
world, in which you can make no guarantees about the field's value,
and no guarantee that it will remain stable from one line of code to
the next.

The same problems occur on a smaller scale for public instance fields,
which is why I say that the static-ness isn't the principal problem.

 

[KWienhold]

Its not really about what others could do, its about what you have to
keep in mind while programming.
In a well structured project, encapsulation will ensure that you can
think about your objects in an abstract way, without having to
remember their actual implementation.
When you introduce global data, you need to think about every piece of
code that alters this data whenever you access it from somewhere else,
always making sure that no sequence of events will leave the data in a
corrupt (or inappropriate) state.
This only gets worse when you are working with multiple threads.
In general, when you find yourself in a situation that would require
global data, you may want to think about alternative approaches (even
if that means changing your architecture).
In the very few cases where global data is necessary, make sure to
document your decision to use it thoroughly and use some kind of
naming convention that clearly indicates when you are working with
global fields.

Sincerely,
Kevin Wienhold