Expedientes X En Modo Release

[CoLSoN2]

 A parte de:
- Contención (o no) de información simbólica
- Optimizar el output (o no)
- Inicialización de variables a 0 (o no)
¿En qué se diferencian el modo Debug del modo Release?

Tengo una aplicación que funciona `perfectamente´ en modo Debug (uso MSVC6 + SP6). La cosa es que si compilo y ejecuto en modo Release hace cosas rarísimas, pongo un ejemplo:

Tengo un template Singleton:

Código [Seleccionar] Expand


template <typename T>
class Singleton {
public:
 static inline T* get() {
  static T instance;
  return &instance;
 }
};

del que derivan varias clases, como GuiManager.
Luego tengo:

Código [Seleccionar] Expand


GuiManager::GuiManager() {
Log("gui manager created");
}


Después de ejecutar la aplicación y del crash que se produce (debido a este mal funcionamiento general que comento), en el fichero log pueden verse varios "gui manager created" en distintos puntos del fichero, cuando SIEMPRE llamo al manager utilizando GuiManager::get()->.. lo que me lleva a pensar que el constructor se llama varias veces, cuando la variable es static. La pregunta, obviamente, es ¿PORQUE?

Si soluciono esto podria ver si otros expedientes x que se producen son realmente causa de este o no (podría bien ser, debido a cómo está montado todo)..

un saludo

[Zaelsius]

 Buscando en google "vc6 inline singleton bug" he encontrado cosas como esta:

http://www.flipcode.com/cgi-bin/msg.cgi?sh...m=general&id=-1

....

This works fine in debug mode, but in release mode, some singletons are instantiated twice, and I get lots of null pointer errors.

...

Colson parece que no estás solo XD. Podrias probar a que alguien te lo compilase en VC7. Por lo visto(yo pasé del 5 al 7) el VC6 tenia algun que otro bug feo... mira la primera entrada de Google porque tambien comentan algo de eso(aunque no lo he leido entero).

Al final la solución es pasar de singletons :(  o irte a otro lenguaje si no quieres POO tocapelotas jajaaj.

[CoLSoN2]

 pse. y qué pretendes que use? variables globales???!! NO! xD
A ver si consigo de una vez el vc7, porque el 6 sí que me tiene un poco mosca ya..  

[ethernet]

 Variables globales rocks, singletones sucks

[seryu]

 por curiosidad, porque siempre que sale la palabra singleton la rechazas con un simple sucks, me gustaria saber tu opinion al respecto de porque no deberian utilizarse.

Vamos, una respuesta mas elaborada que el simple apestan en su formato anglicista.

[ethernet]

 Por el simple hecho de que si metes un singleton en un dll, por ejemplo vas a empezar a tener miles de problemas (de linker, de heap...).hasta hace nada yo era defensor de los singletones hasta que programando un manager me di cuenta de que dan mas problemas que ventajas. Ademas, tener una variable global de una clase sinceramente no es tan cutre y al final lo que importa es que funcione :). Que mas te da tener algo asi:

Código [Seleccionar] Expand


class MyMesh
{
     void Load(params...)
     {
             .....
              TextureManager::load(tex);
      }
}


que

Código [Seleccionar] Expand


class MyMesh
{
     void Load(params,..., TextureManager* mngr = GTextureManager)
     {
             .....
              mngr->load(tex);
      }
}


Apruebo el uso del singleton siempre que estos tengan un allocator como dios manda, es la unica forma de q tiren bien

[fiero]

 Internamente, una vez compilado el código, una variable global se comporta igual que una static dentro de una clase. Así que igual dá.
Yo hay muchas cosas de POO que desconozco, pero la verdad es que todavia no he tenido la necesidad de aprender esas cosas tan "raras".

Como dice ethernet, lo que importa es que funcione. Pocas cosas hay tan claras y simples como una variable global.

Joder, no logro acordarme del último error que tuve debug-release, esto me pasa por no apuntar las cosas... si lo recuerdo igual te ayuda

un saludo

[CoLSoN2]

 pues ya está solucionado. Cambié el template para que usara una variable miembro static alojada dinámicamente, y luego cada clase que deriva de Singleton tiene un método release() cuya última línea es 'delete this', y ya no hay petes ni leaks. Pero me parece una guarrada xDDD con lo bien que quedaba lo otro..

[Helius]

 Por si te sirve de algo te muestro mi clase singleton:

Código [Seleccionar] Expand


template<typename T>
class CSingleton
{
private:
 
 static T* ms_singleton;

 
public:

 ~CSingleton()
 {
  ms_singleton=NULL;
 }
 
 static inline T& GetSingleton()
 {
  Assert(ms_singleton,"No existe singleton al intentar instanciarlo");
  return *ms_singleton;
 }

 static inline T* GetSingletonPtr()
 {
  return ms_singleton;
 }

 static inline void NewSingleton()
 {
  if (ms_singleton == NULL)
   ms_singleton = new T;

  Assert(ms_singleton,"No existe singleton al intentar instanciarlo");
 }
};

template <typename T> T* CSingleton <T>::ms_singleton = NULL;

A mi me va perfectamente y si lo prefieres puedes unir la función "NewSingleton()" y GetSingleton()" en una sóla.

Para acabar con el singleton sólo hay que hacer:

Código [Seleccionar] Expand

delete CManager::GetSingletonPtr();