como verificar objetos null en c++

[Yotes]

pero aqui estamos llamando al contructor??

Código (cpp) [Seleccionar] Expand

AUX_RGBImageRec textureImage;

no se lo llama recien con el new?? ups.. tendre que releer esa parte.. :S

[davur]

Sí, se llama al constructor por defecto implícitamente (y si este no existiera, el compilador emitiría un error), precisamente porque el objeto reside en el stack. Otro ejemplo en el que esto se ve más claramente consiste en utilizar un constructor con argumentos:

Código [Seleccionar] Expand


AUX_RGBImageRec textureImage("image.tex");


[Ruben]

Hi,

Si estás utilizando punteros llanos en gran parte de tu código, posiblemente estás haciendo las cosas mal.

Aunque se va un poco del tema del post, molaria saber el por qué de esa afirmacion. :) Gracias.

Un saludo,
Ruben

[Pogacha]

if(p) *p = 10;

Eso parece un poco arriesgado, no? >:D


Magistral, davur, grax

por?

[Yotes]

no importa que se desvie el tema todo ayuda :D

[davur]

Si estás utilizando punteros llanos en gran parte de tu código, posiblemente estás haciendo las cosas mal.

Aunque se va un poco del tema del post, molaria saber el por qué de esa afirmacion. :) Gracias.

Principalmente, por dos motivos:

- RAII, exception-safety, seguridad, claridad y mantenibilidad. Si comparamos este fragmento de código:

Código [Seleccionar] Expand


Foo* p = new Foo;

try
{
    p->do_something();
}
catch (...)
{
    delete p;
    throw;
}

delete p;


con este otro:

Código [Seleccionar] Expand


boost::scoped_ptr<Foo> p(new Foo);
p->do_something();


, vemos que en el segundo obtenemos automáticamente dos cosas: el código es más claro y más seguro ante la presencia de excepciones (no dejamos en manos del programador la responsabilidad de liberar la memoria en ningún caso, ni el normal ni el excepcional). De nuevo, estoy suponiendo un uso moderno del lenguaje al dar por sentada la posible aparición de excepciones en la ejecución del programa.

- Semántica de propiedad de los recursos (memoria u otros) más clara. Consideremos:

Código [Seleccionar] Expand


Foo* create_a_foo();


y:

Código [Seleccionar] Expand


boost::shared_ptr<Foo> create_a_foo();


En el primer código, es posible cometer varios errores:

- Olvidarse de hacer el delete o delete[] del puntero recibido => memory leak.
- Confundir delete con delete[].
- Hacer un doble delete del puntero recibido.

Sí, son fallos humanos que no deberían ocurrir. Pero ocurren. Y el segundo código los imposibilita todos automáticamente.

Y además, marca de manera explícita en el código quién es/son el/los propietario/s de la memoria u otros recursos (esto es especialmente útil para reforzar los contratos de las interficies que creamos o utilizamos, especialmente en lo referente a parámetros y valores de retorno de funciones).

Y de ahí mi afirmación anterior. Pero nótese que me he cuidado muy mucho de no adoptar una postura "todo o nada": definitivamente, en ocasiones es necesario utilizar punteros llanos (por ejemplo, por motivos de eficiencia por frame, es habitual que la implementación de un sistema de partículas o de una malla de geometría utilice punteros llanos). Pero para gestionar la lógica general de una aplicación, ese famoso 80% en el que no es ventajoso optimizar más allá de cierto umbral, es idiomático (es decir, buen estilo) y prácticamente obligado el uso de herramientas de más alto nivel, por todos los motivos anteriores.

[Ruben]

Hi,
la primera razon totalmente de acuerdo, de manual :)

La segunda, creo que no nos saca de pobres. Vamos, que nadie le impide al tio que este usando la interfaz coger el puntero a pelo del smart pointer y hacer un delete, delete[] o format c:... :P . Si la quiere liar, lo va hacer igual uses smart pointers o documentandolo.

Además, creo que para completar tu explicacion, estaria bien decir que es una forma para compartir objetos que te ayuda a gestionar la vida de estos de una manera sencilla. Por ejemplo, a la hora de compartir mallas, materiales, etc...

Un saludo,
Ruben

[HarvesterOfAcorns]

if(p) *p = 10;

Eso parece un poco arriesgado, no? >:D


Magistral, davur, grax

por?

Si mal no lo entiendo los punteros son variables que contienen la dirección de memoria de otras variables o funciones luego lo correcto sería:

int *p;
int n;

n = 10;
p = &n;//el operador & devuleve la dirección de memoria de n

pero si haces

*p = 10;

estás intentando cambiar el valor del entero, al que apunta p, directamente a través del puntero y eso es peligroso, de hecho a mi me provoca un fallo del sistema, mucho más si lo haces sin declarar n

......

int *p;
*p = 10;

donde se guarda ese 10? que dirección de memoria tiene?

???

[davur]

La segunda, creo que no nos saca de pobres. Vamos, que nadie le impide al tio que este usando la interfaz coger el puntero a pelo del smart pointer y hacer un delete, delete[] o format c:... :P . Si la quiere liar, lo va hacer igual uses smart pointers o documentandolo.

Bueno, no me refería a protegerse de Maquiavelo, sino a protegerse de errores no intencionados (que son los que interesa evitar). Para hacer lo que comentas con un puntero inteligente es necesaria una subversión explícita de su forma de uso.

[davur]

HarvesterOfAcorns, ten en cuenta que Pogacha está comprobando que p no es nulo (es decir, que apunta a un objeto de tipo int) antes de dereferenciarlo, precisamente para evitar el comportamiento indefinido que comentábamos antes.

[HarvesterOfAcorns]

Bueno, igual me precipité y Pogacha sólo mostraba algunos ejemplos de lo que se puede hacer con punteros, sin pretender mostrar una secuencia completa de código, :-[ el caso es que me chirrió ver esa asignación directa de un entero a la desreferencia de un puntero sin tan siquiera haber reservado, declarado, previamente memoria para el entero... joe que tortilla cacofónica.