there you have a point. a singleton == a global with lipstick on it.
but besides that, a global is not a solution to a problem either. it can work, and can work long enough. but in this case, there's no need for a global at all. don't you prefer that solution, then?
Ways to avoid the needs and the musts of global variables??
Essentially i prefer the easiest solution. If you're refering to the global function then thats alright yeah. I'd rather have a global than pass something to everything through constructors.
Author
Sorry if I sound n00bish(still learning). Singleton~globals 'wrapped' in the class name. It somehow makes the code 'look' cleaner despite having to type longer words. I'll leave my logger and kernel class as it is for now, and focusing on a more important task. Sorry for all the trouble I caused :p
[Edited by - Bow_vernon on December 30, 2010 1:23:30 PM]
[Edited by - Bow_vernon on December 30, 2010 1:23:30 PM]
Quote:Original post by Dave
Essentially i prefer the easiest solution. If you're refering to the global function then thats alright yeah. I'd rather have a global than pass something to everything through constructors.
sure. Point is, if you want the easy, lazy way, a global is not even needed. And if you want an a bit more complex solution (as said, maybe multiple logging destinations), a global will be in your way.
And to the op, yes, a singleton is a global in a nice sexy oop dress. One that (unlike the global) actually kills class usability (with your global log, you could still create other, local logs as needed. With a singleton, you deny yourself that feature).
Woah a full post written on my winphone7 on the touchscreen. Interesting experience...
Why do you want to remove global variables?
Are the uni professors pushing fixes to non problems again, or has a new book come out by a guy who has time to write a book instead of a program?
I have a good handful of global variables in all my projects and I can't think of any time when this caused a problem. But there were many times, right before they went global, that I was sick of writing accessors and generally dicking about.
I don't even bother with singletons most of the time. If a class only makes sense to exist one time only, just don't create two of them!
Dave+1
There is just something to be said for doing a=b instead of boost::std::munge::haxor::GetObject()->GetAccessor()->GetValue();
Are the uni professors pushing fixes to non problems again, or has a new book come out by a guy who has time to write a book instead of a program?
I have a good handful of global variables in all my projects and I can't think of any time when this caused a problem. But there were many times, right before they went global, that I was sick of writing accessors and generally dicking about.
I don't even bother with singletons most of the time. If a class only makes sense to exist one time only, just don't create two of them!
Dave+1
There is just something to be said for doing a=b instead of boost::std::munge::haxor::GetObject()->GetAccessor()->GetValue();
How is a global in your way?
All my main managers in my project, for example, engine, renderer, ui, physics etc, are all externed global pointers. It's suitably trivial.
Im not saying you in particular dave (or at all), but C++ programmers in general seem to have had some kind of fear put into them with globals and encapsulation etc. There seems to be some kind of fear that if things are not done "perfectly" all hell will break loose! For all i care have some private variables but have public ones too, why not? Don't write empty get/set for them etc.
The less idioms a code base has to work with and therefore remember then the easier it is to get things done.
:)
Pretty much yep!
All my main managers in my project, for example, engine, renderer, ui, physics etc, are all externed global pointers. It's suitably trivial.
Im not saying you in particular dave (or at all), but C++ programmers in general seem to have had some kind of fear put into them with globals and encapsulation etc. There seems to be some kind of fear that if things are not done "perfectly" all hell will break loose! For all i care have some private variables but have public ones too, why not? Don't write empty get/set for them etc.
The less idioms a code base has to work with and therefore remember then the easier it is to get things done.
:)
Quote:There is just something to be said for doing a=b instead of boost::std::munge::haxor::GetObject()->GetAccessor()->GetValue();
Pretty much yep!
i'm coding in c#. c# doesn't have globals. i haven't used globals in years with c++. there's simply no use for them, and no gain by using them. that's what i say, and that's why i suggest anyone to stop using them asap. not using them makes the code much simpler to work with. you know exactly what's there at a given piece of code, and what it depends on.
but i know there are tons who, out of their own ignorance, will never even accept to consider being wrong. they'll continue to splatter globals for nothing. some people just don't want to learn.
oh, and it has nothing to do with something academical. i never was in anything academical computertech related, ever, and the last school is 10 years back. i talk from a practical perspective. the more local a variable is, the more under control you have it.
and my approaches don't have, nor support boost::std::munge::haxor::GetObject()->GetAccessor()->GetValue(); style code, ever. removing a global never creates such code. except when replaced with a singleton, of course. which i have said is not at any point better.
but i know there are tons who, out of their own ignorance, will never even accept to consider being wrong. they'll continue to splatter globals for nothing. some people just don't want to learn.
oh, and it has nothing to do with something academical. i never was in anything academical computertech related, ever, and the last school is 10 years back. i talk from a practical perspective. the more local a variable is, the more under control you have it.
and my approaches don't have, nor support boost::std::munge::haxor::GetObject()->GetAccessor()->GetValue(); style code, ever. removing a global never creates such code. except when replaced with a singleton, of course. which i have said is not at any point better.
Quote:Original post by davepermenIt most certainly has them, they are just called by a different name: static class.
i'm coding in c#. c# doesn't have globals. i haven't used globals in years with c++. there's simply no use for them, and no gain by using them. that's what i say, and that's why i suggest anyone to stop using them asap. not using them makes the code much simpler to work with. you know exactly what's there at a given piece of code, and what it depends on.
Quote:Original post by Bow_vernon
Hmm sounds good. The thing Im making a logger class is only to make it 'elegant'. It creates the log file in constructor and close it in destructor. Okay..I will recode it. Wish it get better. Anyway, if singleton's bad, why it exists?
A signleton is different than a global or static variable.
A signleton class is a definition that says: "there can only be one of these, ever, no matter what." There are not many times when it is necessary, but for those few times it is an important tool.
A static or global instance says "There can be any number of them, but here is one that everybody can know about." Examples are the cin, cout, and cerr character streams in C++. They are globally acccessable streams, but you are free to create any number of other streams.
A frequent compromise between the two that I've seen is that a class will provide a static instance (effectively a global variable version of the class) which anyone can use. It doesn't force the requirements of a singleton since you can still create multiple instances, yet it still provides the concept that there is really just one in the app.
In that compromise you are allowed to have as many instances you want of it so it isn't a singleton, and you also have global access to a default instance. For example, you can write: SomeFactoryClass::Instance().MakeSomething(parameters); You can also write: SomeFactoryClass localInstance;
For all of you advocating globals or singletons, how the hell do you test your code to verify it actually works? How do you write isolated unit tests to check your design makes sense before committing to writing the whole subsystem, and to prevent regressions?
Writing non-shit tests requires being able to check the behaviour of components in specific, isolated contexts, and that requires the ability to mock your collaborators and dependencies; you cannot do that if you are using globals/singletons. You'd have to spin up and configure other full systems, accessed through the global (and roll back this state after every test) - sounds horrid!
It's so much easier just to ask for abstractions for your dependencies. You can create mock implementations in whatever state you want and testing is easy, and you also get a loosely coupled (and generally more cohesive) design.
Writing non-shit tests requires being able to check the behaviour of components in specific, isolated contexts, and that requires the ability to mock your collaborators and dependencies; you cannot do that if you are using globals/singletons. You'd have to spin up and configure other full systems, accessed through the global (and roll back this state after every test) - sounds horrid!
It's so much easier just to ask for abstractions for your dependencies. You can create mock implementations in whatever state you want and testing is easy, and you also get a loosely coupled (and generally more cohesive) design.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
