Y éstos son los datos del pasado año (en USA, claro está):

Gonzo no tiene ni puta de ligar con tias :lol:

Si solo fuera Gonzo...

¿A ti también te van las maduritas?  :P

A cada uno le mataba la curiosidad por saber qué sabía el otro.

Muahahahaha... no voy a decir nada sobre las curiosidades por mujeres que superan los 60. (Es broma, eh, lo digo porque si tocas a según quién, algunos saltan y se emocionan, llegando a extremos cercanos al fanatismo).

Extraña "entrevista", enormente aburrida conversación.

Si es que estás desaprovechado, vaca. Tú deberías ser asesor de Bill Gates, qué digo asesor, deberías ser su sucesor. Anda, que te pires, fantasmón...  :lol:

¿Esto no era una comunidad de desarrolladores?

Yo, personalmente, creo que es muy bonito reunirse y filosofar acerca de lo genial o lo terrible que está la cosa, mirarse el ombligo y elaborar teorías sociológicas al respecto; pero de nada sirve en comparación al trabajo (aunque sea "en la sombra"). Creo que muchos de los que no se lamentan tanto son los que realmente están haciendo cosas o intentándolo.

[coña]
Flint yo si te hubiera hechado de menos :wink:
[/coña]

Eyyy que tan malo no soy. En serio, la mejor de las suertes.

Yo no te voy a echar de menos.  :roll:

Arggghh, esos dibujos de fondo deberían estar prohibidos.

No son thread-safe. Por ejemplo, en la que ha puesto Lex, puede suceder:

- Un thread evalúa la expresión if (_instance == 0) y encuentra que es verdadera.
- Ahora viene otro thread, entra el if porque la expresión es verdadera y construye la instancia.
- Regresa el thread anterior al punto en el que quedó, y éste también construye una instancia.

Con lo que tenemos dos instancias y ¡pam!, nos hemos cargado el invento.

Es interesante, lo unico que no me queda claro es cuando usar la clase Singleton.
Una utilidad que se me acaba de ocurrir es cuando solo quieres tener una instancia de tu programa sin que puedan ejecutarlo dos veces.
Podeis poner los principales motivos de usar singleton o cuando lo usais vosotros?

Siguiendo estrictamente la definición, cuando quieras asegurar que una instancia de una determinada clase sea la única existente en el programa, quieras tener acceso global a ella, y tener una única variable corriente no te resulte suficiente o apropiado; desde luego es algo dependiente de la aplicación. Una clase que típicamente se implementa como singleton es la de logging. Otros usos habituales son los diferentes managers de un programa (render, audio, etc...), aunque la utilidad y corrección real en esos casos es más discutible porque el código de render, audio, etc. no suele necesitar un acceso global, sino que se utiliza en una parte del código pequeña y específica. Si la visibilidad del objeto en cuestión no debe ser global, entonces olvídate de singletons, y céntrate en asegurar que sólo pueda crearse una instancia del mismo (lanzando una excepción, por ejemplo, en el caso de que esto no se cumpla).

Se suele considerar el singleton como un anti-patrón de diseño porque evita tener que pensar en la visibilidad de un objeto y realmente no es sino una manera más fina de tener globales en tu programa, con todo lo que ello conlleva.

BTW, ninguna de esas implementaciones de singleton son thread-safe.

Efectivamente. Una solución sencilla sería sincronizar el método Instance().

Un singleton se declara así:

Código [Seleccionar] Expand

class Singleton {
  public:
     static Singleton* Instance();
  protected:
     Singleton();
  private:
     static Singleton* _instance;
};

Singleton* Singleton::_instance = 0;

Singleton* Singleton::Instance () {
  if (_instance == 0) {
     _instance = new Singleton;
  }
  return _instance;
}

Para poder usarlo solo tienes que llamar a la función que de devuelve la instancia creada del objeto.

Te falto el delete ... no?

Creo que ésa es precisamente la implementación del Singleton de Gamma. ¿Hay un memory leak? Pues depende de cómo lo mires: un memory leak suele ser definido como una acumulación de datos sobre los que se pierde la referencia durante la ejecución del programa, lo que imposibilita su liberación. En este caso, _instance vive en la memoria hasta que la aplicación termina, por lo que no tiene que considerarse un memory leak. De todos modos, no todos los sistemas operativos liberan la memoria que cuelga de un proceso terminado, por lo que, en esos sistemas, si el singleton hubiera accedido a recursos del sistema, se podría producir un resource leak una vez hubiera finalizado el problema. ¿Solución? Recordarse de hacer un delete sobre el singleton manualmente o cambiar de implementación.

Asi se podria hacer aquello de crearlo en el orden que se quiera, pero repito que aun no he comprobado si va bien que sea estatico dentro de una funcion, por aquello de aquel otro hilo, me imagino que puede fallar si el compilador hace que la funcion sea inline por ejemplo, aunque aun no estoy seguro.

Si te refieres a mantener la instancia estática dentro de una función (en este caso el constructor), como también he puesto en mi post anterior, no hay ningún problema. De hecho, es la solución conocida como el Singleton de Meyers; la construcción parte del hecho de que los objetos estáticos dentro de una función sólo son inicializados la primera vez que se llama dicha función.

Me da cosa ponerlo porque ya sabemos donde acaban los debates semánticos, pero...

Técnicamente hablando, considero que ser accesible globalmente, por más que sea el uso que en la práctica le damos, sea requerimiento para ser singleton.

Single = único :p

Pero vamos, que si, que nos entendemos, que como todo hijo de vecino, cuando pensamos en un singleton es para aplicarlo en objetos globales. Viene bien decirlo.

Personalmente, yo recurro a la definición del Design Patterns (Gamma et al 1995, p. 127): The Singleton pattern "ensures a class only has one instance, and provides a global point of access to it."

Pero evidentemente, luego cada cual es libre de hacer lo que quiera.