A question regarding singleton

[LarryChen]

Here is a simple implementation of singleton,

class A
{
private:
	A(int x) : _x(x)
	{
	}
    int _x;

	friend A& createA(int x)
	{
		static A a(x);
		return a;
	}
};

int main()
{
	A a1 = createA(1);
	A a2 = createA(2);

	return 0;
}

By debugging, I found that a1._x = 1 and a2._x = 1. It looks like only one object is created. But I wonder why returning static object a can guarantee only one object is created.

[Eri523]

Aside from the fact that your creator function needs to be static instead of friend...

By debugging, I found that a1._x = 1 and a2._x = 1. It looks like only one object is created.

Creating only one object is the intention behind a singleton. Your creator function instantiates the static variable only once when it is first called, and subsequentially just returns a reference to that very instance.

But I wonder why returning static object a can guarantee only one object is created.

Just returning a reference to a static doesn't do that. Your objects a1 and a2 are actually copies (created by the compiler-generated default copy constructor) of the "singleton" object, thus breaking the singleton concept. You can simply check that by assigning something to the _x member of one of the objects in main() (after making that member public).

You need not only to return a reference, you also need to initialize references from it instead of making copies. To enforce that you need to declare a private copy constructor and assignment operator which disables copying and assignment.

BTW, an alternative to returning a reference in the singleton pattern is to return a pointer to the single reference. But that doesn't change anything about the principle.

[Speedo]

But I wonder why returning static object a can guarantee only one object is created.

What you have there isn't really a singleton... it's something more like a factory. Only one A exists within the createA() function (thanks to it being static), but you have more than one A in your program (three of them, in fact). You're just forced to create them by calling createA().

[LarryChen]

[QUOTE=Eri523;2011149]Aside from the fact that your creator function needs to be static instead of friend...
Why does the creator function need to be static? Take a look at the following implementation,

class A
{
private:
	A(int x) : _x(x)
	{
	}

	A(const A&){}

	operator=(const A&){}

    int _x;

    friend A& createA(int x)
	{
		static A a(x);
		return a;
	}
};

Is there anything wrong? Thanks.

[laserlight]

Why does the creator function need to be static?

It doesn't need to be a static member function, but with such factory functions it is more conventional to write:

A a1 = A.create(1);

rather than

A a1 = createA(1);

unless createA can be a non-member non-friend.

[Eri523]

Take a look at the following implementation,

[...]

Is there anything wrong? Thanks.

Did you actually try to compile that?

Aside from that, I see absolutely no point in making a member function a friend of its own class.

[laserlight]

I see absolutely no point in making a member function a friend of its own class.

I do not think it is possible to make a member function a friend of its own class.

[Eri523]

It doesn't need to be a static member function [...]

To my understanding a singleton instance accessor that is a non-static member of the singleton is completely paradox. Ths instance accessor can be a non-static class member, but then of another class, at least as I understand the description at http://en.wikipedia.org/wiki/Singlet...method_pattern.

I think it's also possible to make the instance accessor a free friend function of the singleton, but then it would still implicitly be static.

I do not think it is possible to make a member function a friend of its own class.

To my surprise, the following actually does compile under VC++ 2010:

#include <iostream>

using namespace std;

class B
{
public:
  B() : m_x(23)
  {}

private:
  friend int getx(const B &b_)
  {
    return b_.m_x;
  }

  int m_x;
};

int main()
{
  B b;
  cout << getx(b) << endl;
  return 0;
}

But note that in this scenario getx() actually is a disguised free function.

[S_M_A]

Is it that disguised? After all we all expect a friend function to be a free function so isn't this more about where it's implemented?
I think laserligths statement still is true since it should be impossible to implement it as B::getx

[Eri523]

I think laserligths statement still is true since it should be impossible to implement it as B::getx

I agree. That code is just my attempt to find out the OP's (potential) intention behind the (non-compiling) code from post #1 and how it might be turned into something that actually does compile, mostly regardless of what would then be the result of that compilation, or better, trying to find out what that result then would be.

[S_M_A]

And that's absolutely nothing to be embarressed for and that wasn't my intention either. I was just happy that I had knowledge enough to be part of the thread.

[Eri523]

Update: The Comeau compiler accepted the code from post #8 without any complaints as well.

[laserlight]

To my understanding a singleton instance accessor that is a non-static member of the singleton is completely paradox.

A non-member function is also not a static member function

In fact, that is how I understood the point that LarryChen was making. It seemed to me that LarryChen correctly identified the friend function createA as a non-member function, despite it being defined within the definition of a class.

I think it's also possible to make the instance accessor a free friend function of the singleton, but then it would still implicitly be static.

No, it wouldn't implicitly be static, because the static specifier as applied to free functions has a different, though related, meaning.

[Eri523]

Ah, I'm gradually getting it... I obviously misinterpreted your sentence:

It doesn't need to be a static member function [...].

You actually meant it doesn't need to be a member at all (which of course is absolutely right) and I interpreted that as "it needs to be a member, just not static". This misunderstanding probably got some extra promotion from the fact that I myself actually prefer static member instance accessors because I find they make it more obvious what they're intended for.

A non-member function is also not a static member function

[...]

No, it wouldn't implicitly be static, because the static specifier as applied to free functions has a different, though related, meaning.

Looks like another communication problem, this time of type "terminology clash"... And it's clearly my own fault. With respect to the topic of this thread, I more or less intentionally misused the word static. I used it with the meaning "not object-bound" but of course it has another meaning for free functions. When I wrote it I was assuming it was perfectly clear and understandable what I meant, but obviously I was sooo wrong...

[TheGreatCthulhu]

It seemed to me that LarryChen correctly identified the friend function createA as a non-member function, despite it being defined within the definition of a class.

I'm not saying you're wrong, and my intention is entirely to learn something, but, from an OO design point of view: how can a function the enclosing context of which is a class not be a member function of that class?
Is this something C++ specific? (My weapon of choice is C#, so - maybe I'm missing something...) Or maybe the words "member function" have a slightly different meaning for us?