4

I'm new and a little ignorant in C++ and I encounter a C++ code that used a singleton pattern,

class CFoo
{
 public:
   static CFoo& getInstance()
   {
     static CFoo self;
     return self;
   }

 private:
   CFoo(){}
   ~CFoo(){}
};

I am just confused why return a static reference? Is this a valid code? Why the programmer didn't use a pointer?

Bill the Lizard
  • 398,270
  • 210
  • 566
  • 880
domlao
  • 15,663
  • 34
  • 95
  • 134

3 Answers3

7

Why use a pointer? A reference is simple and matches what I want to do: alias an object, not point to it. The static doesn't apply to the reference, it applies to the function, making it callable without an instance.

(Even better, why use a singleton?)

GManNickG
  • 494,350
  • 52
  • 494
  • 543
  • OK. Singleton is over used and rarely used correctly. But that does not stop it from being useful. The problem is the way we teach people to use it. The simplest way to demonstrate what a singleton is (as above) just shows the singleton but not how to use it correctly. The problem with singleton(s) is not the singleton pattern but its use in providing `globally accessible mutable state`. A good talk about the subject is: http://www.youtube.com/watch?v=-FRm3VPhseI – Martin York Nov 03 '10 at 05:40
  • 1
    @GMan: No. It depends on situation. But it is one of those patterns that can not be used in isolation. You need a way to decide what to create like a potentially a factory that may return the singelton or may some other object (like a test object). – Martin York Nov 03 '10 at 16:08
  • @Martin: no, the global mutable state is *half* of the problem with a singleton. And I agree with you, if that was the only issue, then singletons would have their uses (occasionally). The problem is that they *also* give you a completely absurd compile-time guarantee whose only effect is to make it harder for you to adapt your code to changing requirements. I've never seen a case where *both* the properties of a singleton were desirable. (Global mutable state is occasionally ok. Single-instance restriction is generally not necessary. And I can't imagine a case where you'd want *both*.) – jalf Nov 08 '10 at 02:33
  • There are other patterns that give us global mutable state with less implementation complexity and less potential for subtle bugs (synchronization, for example, or dependencies between singletons which can get wonderfully hairy at startup or shutdown). If that's what we're after, there's still no point in using a singleton instead of, say, the monostate pattern – jalf Nov 08 '10 at 02:35
2

A static local variable e.g. self once initialized (one first pass through the function getInstance) remains for the entire duration of the program unless explicitly deleted. Therefore it is perfectly safe to return the reference to self.

Note that it is getInstance which is static in the function declaration. Storage class specifiers are not allowed on return types of a function.

I would suggest you to use the Monostate design pattern unless of course the need for Singleton is strongly suggested

Community
  • 1
  • 1
Chubsdad
  • 24,777
  • 4
  • 73
  • 129
1

If you use a pointer, you have to de-reference the pointer in order to use any overloaded operators implemented by CFoo. If it returned a pointer, the code might look like:

(*(CFoo::getInstance ())) == "comparison overloaded op"

vs.

CFoo::getInstance () == "comparison overloaded op"
  • 1
    While true, does it really make sense to compare equality on a singleton object? – Billy ONeal Nov 03 '10 at 04:14
  • It would be if equality is an overloaded operator. Maybe you're managing some state globally in a singleton and you want to query to see if the program is in a given state? There may be many reasons to check equality of the singleton with *something*. It could just as easily be an overloaded unary operator "CFoo::getInstance()++". The string was just an example to show it was invoking an overloaded operator. –  Nov 03 '10 at 04:19