Stratos: Punto de Encuentro de Desarrolladores

¡Bienvenido a Stratos!

Acceder

Foros





como verificar objetos null en c++

Iniciado por Yotes, 05 de Junio de 2009, 09:57:32 PM

« anterior - próximo »

Yotes

pero aqui estamos llamando al contructor??

Código (cpp) [Seleccionar]
AUX_RGBImageRec textureImage;

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

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:


AUX_RGBImageRec textureImage("image.tex");

Ruben

Hi,
CitarSi 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


Yotes

no importa que se desvie el tema todo ayuda :D
Yotes!

davur

Cita de: Ruben en 07 de Junio de 2009, 08:15:43 PM
CitarSi 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:


Foo* p = new Foo;

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

delete p;


con este otro:


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:


Foo* create_a_foo();


y:


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

Cita de: Pogacha en 07 de Junio de 2009, 08:16:42 PM
Cita de: HarvesterOfAcorns en 07 de Junio de 2009, 10:34:06 AM
Cita de: Pogacha en 06 de Junio de 2009, 09:54:17 PM
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

Cita de: Ruben en 07 de Junio de 2009, 10:05:47 PM
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.






Stratos es un servicio gratuito, cuyos costes se cubren en parte con la publicidad.
Por favor, desactiva el bloqueador de anuncios en esta web para ayudar a que siga adelante.
Muchísimas gracias.