It have to do with either bad design or non-OO design. C# is exclusivly for OOP (other paradigms can be used, but not easily). In OOP there is no such thing as a global variable everything is an object, and every object is a member of a function or another object. What kind of stuff do you consider for globals?

Well you could use static classes.

public sealed class Globals{     public static int SomeStupidInteger = 0;}

There now every class can access Globals.SomeStupidInteger.

However I'm pretty sure this is frowned upon in C#. If you want something that other classes can access, I believe creating a singleton is considered the "better" method.

Classes really should strive to be as re-entrant as reasonable.

For the (extremely rare) case where a global variable is the best option, and you have compelling reasons that static classes with static methods are worse options, you can create objects in the global namespace by emiting MSIL code, linking with something containing it, and other methods. But I wouldn't do it. I have seen it exactly once in the years I have been programming with C#, and that was because of difficult circumstances while also working with badly written managed C++.

Global variables have a whole lot of badness. Sure they made sense in C and languages developed without the concept of encapsulation, but there is no reason to use them in day-to-day code any more. yay!

Does C# [or, I suppose, .Net in general] suffer from the pitfalls that make singletons in C++ neccessary to begin with? I've never really looked into it, but it seems like the details of static objects would have been fleshed out better in the specifications.

CM

Personally I find it very rare you need a global static, and if you do, make it a global property with only a getter.
Ie, don't let some random code set it to null. This could play havok with the rest of your program.

constants are good too.

public const int SomeStupidInteger = 0;

Generally, I do not use publically visible static objects in my current project.
That said, I do have 'singletons', which are tied to the current instance of the application (using thread statics to reference the application instance) but this sort of thing is quite tricky and you can get memory leaks if you are not careful.

At work is a tad different. We are using axiom, and that thing is filled to the brim with statics. Honestly it's actually been damned annoying. First thing it means is we can't have two copies of the engine running independantly, and there isn't any explicit 'shutdown' which kills all the statics.. Required quite a bit of hack and slash to get it running twice in a row without leaking buckets of memory.


As for the original example, connection sockets. I see no reason why you want to limit yourself to one connection. You never know what may be required in the future. The moment you need 2 connections, you are screwed.

Quote:Original post by Afr0m@n
Should one ideally even have to pass "global" variables through class constructors from one class to another, which I seem to be doing alot, in C#?

Ideally, yes. They shouldn't be global, they should just be passed to the classes that need them.