Verificar existencia de TImage

[[AgustinOrtu]]

Se suele decir que hay dos "escuelas", los que defienden el uso de FreeAndNil y los que no

Es una guerra que no va a tener fin nunca y en parte tenes razon German en que va en gustos

Vos decis que es mas ordenado y claro pero a mi me resulta mas desordenado y mas confuso

Cuando tiramos un query desde tiempo de diseño, no hay que andar haciendo chequeos para preguntar si puedo acceder al objeto o a sus propiedades (dejando de lado aquellas que hay que asignar desde afuera como Connection, etc) simplemente el objeto esta ahi, disponible en todo momento para mi; por algo esta declarado en la parte publica del form, tiene un alcance "global" dentro del form, y no limitado dentro de un metodo. A mi me resultaria muy extraño llegar a pensar que ese puntero pueda tener NIL

A mi no se me ocurre un solo caso en el que el uso de FreeAndNil sea necesario

Nunca ni siquiera me gusto la implementacion del metodo, mas que FreeAndNil deberia ser NilAndFree:

procedure FreeAndNil(var Obj);
var
Temp: TObject;
begin
Temp := TObject(Obj);
Pointer(Obj) := nil;
Temp.Free;
end;

[Casimiro Notevi]

Empezado por AgustinOrtu

procedure FreeAndNil(var Obj);
var
Temp: TObject;
begin
Temp := TObject(Obj);
Pointer(Obj) := nil;
Temp.Free;
end;

Como a todos los novatos, te recuerdo el uso de las etiquetas para el código

[Casimiro Notevi]

Yo suelo usar FreeAndNil donde creo que pueda ser útil.

Un puntero puede ser 'nil' o tener un valor. Pero si al hacer puntero.Free no lo deja a 'nil', entonces tenemos un problema. Imagina un array de punteros con una serie de valores/punteros que vas liberando y tienes que comprobarlo de alguna forma, la única es mirar si está a nulo/nil, pero si hacemos solamente .free estará liberado, pero no nos aseguran que tendrá un "valor nulo",

[roman]

Empezado por Casimiro Notevi

Yo suelo usar FreeAndNil donde creo que pueda ser útil.

Ni más ni menos El problema con visiones como las de Hodges, es que son extremistas. Él piensa que no debe usarse; ok, está en su derecho. Pero el problema es que piensa que quienes lo usan, lo usan para todo y en circunstancias totalmente reprobables donde, como dije, el menor de los problemas es su uso.

LineComment Saludos

[Neftali [Germán.Estévez]]

Empezado por Casimiro Notevi

Como a todos los novatos, te recuerdo el uso de las etiquetas para el código

[[AgustinOrtu]]

Empezado por Casimiro Notevi

Como a todos los novatos, te recuerdo el uso de las etiquetas para el código

Estas cosas nuevas que inventan estos dias

[Tiaguito_Power]

Muchachos, estoy muy agradecido por los aportes, la verdad no se me cruzo por la cabeza asignar Nil luego del Free

Empezado por AgustinOrtu
Por que liberar la memoria de un objeto que vas a volver a usar?

no es que estoy liberando o eliminando un componente que luego voy a volver a usar, el array de Images va de 0 a 250 y en tiempo de ejecución no se crean mas de 6 autitos trafico en simultaneo (del 0 al 5, 1 al 6, 2 al 7, etc), esto está dado por el "alto de la carretera" y una vez que nuestro autito paso y esquivó el trafico este se elimina y solo se tiene en cuenta el indice para que al ejecutar el bucle que desplaza las imagenes trafico omita el eliminado por colisión o sobrepaso.

Empezado por Neftali
¿Qué ventaja puede tener dejar la variable apuntando a "nosesabedonde" en lugar de apuntar a nil?

Si bien no me dedico 100% a programación adhiero a la idea de que una variable apunte a nil, ayuda a mantener orden y control sobre estas.

Desde ya agradezco todos los comentarios, aportes, ideas y debates. Aun no me he sentado a probar todo pero en cuanto lo haga les comento los resultados!

Cordiales saludos!!

[[AgustinOrtu]]

Cada uno programa como quiere

Aunque yo sigo sin entender porque tener 250 TImage cuando usas siempre 6 y no mas

Es como tener todos los forms creados apenas arranca el programa y no irlos creando y liberando a medida que es necesario

[mamcx]

Empezado por Tiaguito_Power

Si bien no me dedico 100% a programación adhiero a la idea de que una variable apunte a nil, ayuda a mantener orden y control sobre estas.

NIL/NULLs son valores ultraproblematicos, y se deberian evitar al maximo:

https://dzone.com/articles/the-worst...uter-science-1

Ademas, NIL no es muy diferente de apuntar a "donde sea". NIL no es un valor fijo, no significa nada concreto (que uno le suponga un significado es otra cosa). NIL no es vacio, ni *nada*, ni *algo*. NIL es "indefinido". NIL no es igual a NIL ni es diferente de NIL (Delphi dice que NIL=NIL, pero eso es un error!).

En fin...

-----

Entre los programadores de juegos, hay un esquema que es muy popular, porque es mas eficiente y ademas mas claro a la hora del codigo:

http://gamedevelopment.tutsplus.com/...ign--cms-21052

----

Sin embargo por la simplicidad de tu problema, hago eco de lo que te han dicho. Si ya tienes fijo el tamaño de tu problema, es mas simple que pre-cargues al arranque todo y simplemente reemplaces (en vez de crear/eliminar cada vez). Eso es truco de programacion pa' videojuegos #1 (y que es parte de lo que el link arriba te enseña).

[[AgustinOrtu]]

+1 Mario

Basicamente si uno programa como si nil nunca existiera, no deberia haber problemas; al menos no en la base de codigo escrita por el/los programadores del equipo

Código Delphi [-]
procedure FindFiles(StartDir, FileMask: string; recursively: boolean; FilesList:TStringList=nil);

Leyendo el comentario, "devuelve una lista de"... no seria mejor una function para el caso?

Y en el caso de, darle la lista al metodo para que ahi meta lo que va encontrado, es responsabilidad del usuario del metodo suministrar un StringList; basicamente, si no me lo dan, ocurrira la excepcion que tiene que ocurrir, y eso es solo culpa de quien invoca el metodo y no de quien lo programo

Pero como ya dijimos mas arriba, para gustos, colores

[roman]

Empezado por mamcx

NIL/NULLs son valores ultraproblematicos, y se deberian evitar al maximo:

Esto puede ser verdad, o, por lo menos, debatible. Pero lo que aquí hablamos es del uso de FreeAndNil, no de la existencia y uso de nil.

LineComment Saludos

[Casimiro Notevi]

Empezado por mamcx

(Delphi dice que NIL=NIL, pero eso es un error!).

Pues yo le creo, a Delphi
Y FreeAndNil es muy útil en diversas ocasiones.

[[AgustinOrtu]]

En realidad la duda del compañero es justamente eso

Para echar culpas diganle a ese Casimiro que arrojó la primera piedra

[Neftali [Germán.Estévez]]

Empezado por AgustinOrtu

Cuando tiramos un query desde tiempo de diseño, no hay que andar haciendo chequeos para preguntar si puedo acceder al objeto o a sus propiedades (dejando de lado aquellas que hay que asignar desde afuera como Connection, etc) simplemente el objeto esta ahi, disponible en todo momento para mi; por algo esta declarado en la parte publica del form, tiene un alcance "global" dentro del form, y no limitado dentro de un metodo. A mi me resultaria muy extraño llegar a pensar que ese puntero pueda tener NIL

Está claro que en ese punto no tiene sentido utilizar FreeAndNil, es más, es que en ese caso ni siquiera tendrás que usar un Free, pues no viene al caso.
Pero hay muchos otros objetos que se generan durante una ejecución y que se deben liberar.

Se me ocurre un ejemplo sencillo. ¿Has pasado alguna vez un objeto como parámetero en un procedimiento?
Mira este método, que viene del clubdelphi y que ahora mismo tengo en pantalla.

Código Delphi [-]
{: Devuelve una lista de nombres de fichero encontrados a partir de la
     carpeta inicial StartDir, que cumplen el patrón especificado por
     FileMask.Mediante recursively se indica si se desea hacer la busqueda
     en los subdirectorios.}
procedure FindFiles(StartDir, FileMask: string; recursively: boolean; var FilesList: TStringList);

Imagina que el último parámetro es opcional.
Se convertiría en:

Código Delphi [-]
{: Devuelve una lista de nombres de fichero encontrados a partir de la
     carpeta inicial StartDir, que cumplen el patrón especificado por
     FileMask.Mediante recursively se indica si se desea hacer la busqueda
     en los subdirectorios.}
procedure FindFiles(StartDir, FileMask: string; recursively: boolean; FilesList:TStringList=nil);

¿Has usado algo así alguna vez?
En este caso y según lo que hagas antes deberás asignar nil de forma obligatoria.