Quote:Original post by s.kweeNo, it isn't. First of all, there's no such thing as a "pure virtual class". You're thinking of an abstract class, which contains pure virtual functions. A class being abstract is a side effect of its having pure virtual functions. And remembering to implement all pure virtual functions in some descendant class of the abstract base class is a lot trickier than remembering to not accidentally create an object.
Ok I got the main idea.
But anyway I can tell you "Why to do class pure virtual? Just don't create object from this class and there is no need to do it pure virtual." Its the same.
Singleton Pattern, C++
Author
Quote:Original post by SneftelQuote:Original post by s.kweeNo, it isn't. First of all, there's no such thing as a "pure virtual class". You're thinking of an abstract class, which contains pure virtual functions. A class being abstract is a side effect of its having pure virtual functions. And remembering to implement all pure virtual functions in some descendant class of the abstract base class is a lot trickier than remembering to not accidentally create an object.
Ok I got the main idea.
But anyway I can tell you "Why to do class pure virtual? Just don't create object from this class and there is no need to do it pure virtual." Its the same.
My fault, I meant abstract class.
The point in my words is that thing weren't developed by formula "and let the singleton to be for fun", if you can force user who use your program to follow this "don't create more that one instance" so there is no need for singleton to be, singleton (not only singleton many things, I use him for example) created to prevent creating more that one object. The same with abstract class for example, that was created in order to prevent creating object of this class.
Any way I don't want to turn this topic into spam or argument topic. I think I got the answer I looked for.
Thanks for everyone who answered :)
Author
Quote:Original post by Driv3MeFar
Recommended readings on the Singleton pattern, assembled by Promit.
Thanks.
After reading some of the articles mentioned in this link I finally understood that singleton is a bad style of programming and I need to avoid using them.
Thanks.
Quote:Original post by Sneftel
The singleton should only be used where it would literally be logically impossible to create more than one.
I've seen this line of argumentation mentioned before, but I regard it as entirely arbitrary.
Singletons are appropriate for both "shouldn't" and "can't" cases concerning multiple instances. Restricting it to only the "can't" case is fairly popular it seems, especially on this board, but I've never seen a good reason to exclude the "shouldn't" case put forth.
Quote:Original post by exwonderQuote:Original post by Sneftel
The singleton should only be used where it would literally be logically impossible to create more than one.
I've seen this line of argumentation mentioned before, but I regard it as entirely arbitrary.
Singletons are appropriate for both "shouldn't" and "can't" cases concerning multiple instances. Restricting it to only the "can't" case is fairly popular it seems, especially on this board, but I've never seen a good reason to exclude the "shouldn't" case put forth.
Because the "shouldn't" of today can easily become the "should" of tomorrow without "can't", which can be extremely problematic to deal with in large codebases especially. While you might argue it's okay when you're "certain" it will always be "shouldn't", IMO good coding practices acknowledge that the programmer is fallible -- and thus incapable of making such an assertion accurately.
It's also my opinion that the cost of dealing with those mistakes very very quickly outweighs any benefits of using singletons, resulting in a loss on average. (Aside from this, more of my general rationale against singletons can be found in one of the 4 previous singleton threads made this month alone).
2¢
Quote:Original post by exwonderQuote:Original post by Sneftel
The singleton should only be used where it would literally be logically impossible to create more than one.
I've seen this line of argumentation mentioned before, but I regard it as entirely arbitrary.
Singletons are appropriate for both "shouldn't" and "can't" cases concerning multiple instances. Restricting it to only the "can't" case is fairly popular it seems, especially on this board, but I've never seen a good reason to exclude the "shouldn't" case put forth.
Yeah, I kind of agree. There are many REALLY good reasons not to use singletons, but "if you don't want multiple, then don't create multiple" is open to interpretation, IMO. If, for instance, creating more than one would yield undefined behaviour or whatever, and if you happen to be working on a platform/library that other developers you aren't directly talking to will be writing code with, you can't just rely on your documentation to inform them that they shouldn't create more than one of something. Then again, most libraries offer ample opportunities to shoot one's self in the foot...
Quote:Original post by Replicon
Yeah, I kind of agree. There are many REALLY good reasons not to use singletons, but "if you don't want multiple, then don't create multiple" is open to interpretation, IMO. If, for instance, creating more than one would yield undefined behaviour or whatever, and if you happen to be working on a platform/library that other developers you aren't directly talking to will be writing code with, you can't just rely on your documentation to inform them that they shouldn't create more than one of something. Then again, most libraries offer ample opportunities to shoot one's self in the foot...
Here's my usual pattern for dealing with that in C++:
//---- HEADER ----class foo {public: foo( ... ); ~foo();};//---- SOURCE FILE ----namespace { foo* instance = 0; }foo::foo( ... ) { assert(!instance); instance = this; }foo::~foo() { assert(instance==this); instance = 0; }For code to be used out-of-house, simply upgrade the first assert to a more robust error reporting mechanism. By doing this, I won't have to break any existing code (as I would with the singleton) if I added support for multiple instances at a later date.
Note that I avoid depending on "instance" for anything but this error checking within foo, and never expose it to anything outside of foo's implementation details.
Do people actually read GoF and latch onto singleton, and nothing else, as some kind of feel-good global or is there some tutorial out there suggesting people should be using it? I don't get where relatively new users of C++ are finding this thing.
To be constructive: Singletons. All the threads end up saying roughly the same things.
To be constructive: Singletons. All the threads end up saying roughly the same things.
Quote:Original post by MaulingMonkey
IMO good coding practices acknowledge that the programmer is fallible
At the risk of taking your quote out of context... this is the exact reason I'd want to regulate the "only create one instance" rule in code that's only intended to be instantiated once. I see you've posted alternate code for this, which is interesting and I'll have to look at it more carefully later.
There's always the possibility that you'll need a singleton to become a non-singleton, but if you restrict singleton usage to "managers", this usually doesn't come up. We use singletons heavily at work, for good or evil, and I don't recall ever having to change one because everyone "gets" them and makes reasonably good decisions about when there's only going to be one thing.
Now, aside from the "maybe you'll need more than one" argument, which is a very valid consideration (although argued poorly in most cases I've seen), most of the people on this board that I've read so far are arguing against globality in general, rather than singletons... which makes me look at this board a little strangely when half the people in a thread are saying you should use a global instead. It all seems like a religious argument, similar to "don't use goto zomg it's so bad." Like people are opposed to using singletons just because someone told them it would make them a better programmer.
Globality and single-instantiation are both interesting topics of debate and good discussions to have when talking about clean/cleaner/cleanest code. I don't get the feeling that any of the threads I've read on singletons from this board so far (admittedly, not all of them) take either of these issues seriously and are just "don't use singletons"... accompanied by a couple paper-thin explanations of why not to use singletons, sometimes hinting at valid issues, sometimes not.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
