Singleton as a "one and only one" instance enforcement

This is better handled with standard object construction / destruction; if there should only be one instance of an object in your program, instantiate only one.

If your code would break because more than one object has been instantiated that is a big problem that should be solved.

I mostly agree with what you've said, but in this case I'd point out that the only time I use a singleton is when I inherit this kind of problem from an external library. I actually had that problem crop up in class last semester, where a library we were using abstracted all resources and forced us to refer to everything by assigning it an integer handle. I created a singleton to function as a kind of handle distributor. It contained an internal int that started at 1 (the lowest allowed value for the int handles) and it had a method that would return that and increment it. If there were ever two instances of this class then all of my resources would potentially be invalidated because their handles could suddenly be used to load a new resource. My whole motivation in creating the singleton was to enforce one-and-only-one instance.

That is a poorly designed library, or your understanding of the API might be incomplete.

*snip*

It's a poorly designed library, and I bitched at the professor. He said he's been bitching at the dept and they're removing the library from the coursework within the next few sessions. Randomization would be counter productive (and pointless?) in this case. The handles need to be unique, positive, non-zero integers. To load a resource you do something like loadResourceType(filename, handleToUse). After that you use functions like doSomethingWithResource(1, arg, arg). If you load a different resource with the same handle, chaos ensues.

If there were ever two instances of this class then all of my resources would potentially be invalidated because their handles could suddenly be used to load a new resource. My whole motivation in creating the singleton was to enforce one-and-only-one instance.

As pointed out earlier in this thread (and easy enough to forget that I've done so in the past), it's not a singleton unless it provides global access.

If you're forced to use a bit of static data to enforce the "singularity" of an object, that's unfortunate, and may require you to address initialization order and threading issues. However, that doesn't require you to also make that object globally accessible. You can still create and use it as a normal object.

Globalization wasn't much of an issue in this case, since the problem library is all global anyway. I suppose I could have done something like:

int getNextHandle() {
  static int nextHandle = 1;
  return nextHandle++;
}