Still on the subject of Singletons (their usage)

Never thought I'd ask this. Since most texts about the singleton pattern focus on its implementation, it hardly occurred to me that I would be facing dilemas concerning their actual usage.

GameMap is a GoF Singleton returning a reference through getInstance(). The problem is that I'm really not sure what to do with its copy constructor and assignment operator.

My first thought was to explicitly declare them in order to make it clear to users of the class they can use them. GameMap implements a vector of hexagons and is meant to be used in various contexts by other objects and routines.

Because of this, I believe it is more practical to write:

GameMap myMap = GameMap::getInstance();

Than it is to make copy-control private and have to write something like the following everytime I need to access the container's contents interface:

GameMap::getInstance().Hexagon(16, 7).hasRoad()

At best I can simplify a bit by renaming getInstance() to Map(), for instance. But still feels awkward to rely on a temporary all the time.

I see too much singleton implementations moving copy-control to the private portion of the class definition. So, i'm a little shaky about not doing it. Should I?

There's no inherent reason you should make a singleton un-copyable. It's just another object, which happens to be global.

That said... why wouldn't you be passing around a GameMap * instead of copying it?

perhaps you could pass around a GameMap& instead. If you want a singleton, then you certainly don't want more than one copy floating around your program. If your program requires more than one copy, then a singleton is a bad choice.

Incidentally, there's no reason why getInstance() has to be a member function. you could just as easily write getInstance as a standalone friend function.

Quote:

---

At best I can simplify a bit by renaming getInstance() to Map(), for instance. But still feels awkward to rely on a temporary all the time.

---

getInstance() doesn't built a temp. It provides a reference to a global object. Once constructed with the first call to instance() that object is always the same over time.

If you want to have a single resource than use singleton and make copy-ctor private.
If you want to have a fixed number > 1 of a type of resources than you could have a look at "multiple"/ "borg" pattern.

Quote:

---

Originally Posted by QuestionC

That said... why wouldn't you be passing around a GameMap * instead of copying it?

---

Just an overlook. getInstance() does return a reference. The text should read instead:

GameMap &myMap = GameMap::getInstance();

Quote:

---

Originally Posted by QuestionC

There's no inherent reason you should make a singleton un-copyable. It's just another object, which happens to be global.

---

Most excellent. Thanks.

Quote:

---

Originally Posted by bench82

Incidentally, there's no reason why getInstance() has to be a member function. you could just as easily write getInstance as a standalone friend function.

---

Hmm... even with it being static?

Quote:

---

Originally Posted by Mario F.

Just an overlook. getInstance() does return a reference. The text should read instead:

GameMap &myMap = GameMap::getInstance();

---

Yea... but you don't need the copy constructor to do that.

Singleton issues aside, would it make sense to make the GameMap copy constructor private anyhow? I am guessing that its a very expensive object to copy.

Quote:

---

Originally Posted by Mario F.

Because of this, I believe it is more practical to write:

GameMap & myMap = GameMap::getInstance();

Than it is to make copy-control private and have to write something like the following everytime I need to access the container's contents interface:

GameMap::getInstance().Hexagon(16, 7).hasRoad()

---

Also... note that there are efficiency reasons for using the former as opposed to the latter. Every call to getInstance() will at least perform an extra comparison, and probably perform a mutex lock as well.

Quote:

---

Originally Posted by Mario F.

Hmm... even with it being static?

---

Friend functions can access any members in the class (Including private constructors...), so, one of (probably several) possible ways to do this is to create the static singleton object inside the friend function.

Code:

---

class MySingleton
{
  MySingleton();
  MySingleton(MySingleton&);
public
  friend MySingleton& getInstance();
};

MySingleton& getInstance()
{
  static MySingleton* the_singleton = new MySingleton;
  return *the_singleton;
}

---

(untested)


The slight disadvantage of this, is that the_singleton's destructor will never be called. But this shouldn't normally be a problem, as long as you don't need any fancy stuff to happen in the destructor.

Quote:

---

Originally Posted by QuestionC

There's no inherent reason you should make a singleton un-copyable. It's just another object, which happens to be global.

---

A singleton is a class of which there can and should only be one instance at any given time. If you're wanting to copy the object, then you shouldn't be using the singleton pattern in the first place.

The right way to do this, if it is truly necessary that there is only one instance of the GameMap object, is to have the getInstance() method return a pointer to the instance and not a reference. Then, you could do this:

Code:

---

GameMap* myMap = GameMap::getInstance()
myMap->whatever();

---

This way, you don't copy the singleton (thus negating the purpose of the singleton pattern in the first place), and you still end up with basically the same syntactic sugar.

>> have the getInstance() method return a pointer to the instance and not a reference.
What's the difference between a pointer and a reference in that situation? Did you mean "return a pointer and not an object"?

returning a pointer does on some monday morning lead some programmer to try to delete the singleton object. returning a reference doesn't lead them into such a temptation.

QuestionC: For what reason do you want to have a copyable singleton? A singleton models single resources, the realtime clock or a database connection for example. while single resources are not copyable, a singleton shouldn't be, too. Have you an example for a design where a copyable singleton is needed?

Quote:

---

Originally Posted by pheres

returning a pointer does on some monday morning lead some programmer to try to delete the singleton object. returning a reference doesn't lead them into such a temptation.

---

Absolutely. There's also the general advise, when given the choice, choose references over pointers; The validity of which I see no reason to question on this case. As Daved pointed out, there's no significant difference. If there's no difference, reference is the way to go.

Quote:

---

Originally Posted by QuestionC

Singleton issues aside, would it make sense to make the GameMap copy constructor private anyhow? I am guessing that its a very expensive object to copy.

---

That is indeed my main dilema. The object is indeed expensive to copy. Not wanting to bore you with the details, just to mention that the GameMap when fully initialized implements a vector of 14060 MapHex objects from a database query.

The problem here is that relying on temporary usage of GameMap is awkward - and does incur in a slightly downgrade in performance from repeated calls to getInstance() as you pointed out. So, making the copy constructor and the assignment operators private forces me into a syntax that is both awkward and slower (although, I must say, performance issues are not a concern and should never be).

On the other hand, I find that making the copy constructor private and keeping with the compiler generated assignment operator is... ugly. I either need both or none. At least users of the class expect that. From my understanding the copy constructor and assignment constructor incur in the same overhead. If the user creates a reference to the singleton (as opposed to a non reference object) with either one of them, the overhead is... what?... zero?

It was because I was seeing so many singleton examples making copy-control private that I started to have doubts about having my own public. I could eventually follow Bench82 advise and make getInstance() an helper function thus, simplifying the syntax for a private copy-control implementation... however, it would complicate the logic and code readability, I reckon.

What does copying have to do with references? Since you're using references, copying should never occur. The right thing to do is to make the copy constructor and assignment operator private, then fix all compiler errors that occur because somewhere some piece of code tries to copy the object returned by getInstance().

It's called "single"ton for a reason.

I know. I apologize. Been wasting you folks time. Last night it just popped on my mind that if I'm creating a reference, of course I wouldn't be using the copy constructor. Silly me.

QuestionC mentioned it on a previous post and I didn't do the math. My bad.

Private they are now and everything is ok. Thanks everyone.