FreeAndNil VS Free

[rgstuamigo]

Empezado por Al González

.. Ignoraba que Delphi "permitiese" referencias de escritura en el parámetro Self (para mí siempre ha sido una referencia de solo lectura), pero no me extraña en absoluto que el compilador la deseche sin generar instrucción máquina alguna para esa sentencia (lo puedes verificar con la ventana CPU).
...

Muy interesante tu interversion amigo Alberto, para serte franco yo tambien ignoraba la cuestion de que el parámetro Self era solo para lectura, pero la cuestion es que Delphi no se queja al momento de hacer:

Código Delphi [-]
Self:=nil;

Si es solo para lectura y ha sido pensado para eso, pues creo que debería mostrar un error¿verdad? o no permitir directamente tal instruccion y es por eso mi confucion.
Como dije claramente en mi anterior post no tengo una solucion para lo que se pretendía hacer, el hecho de que hubiera hecho uso de Self, fué solo un intento y creo que lo explique claramente. Pero me llama la atencion el código que propones en tu clase "TMagiaClientDataSet"

Código Delphi [-]
Constructor TMagiaClientDataSet.Create (AOwner :TComponent);
  Begin
    Inherited Create (AOwner);
    AutoApplyDetails := True;
    AutoCancelDetails := True;
    AutoEdit := True;
    ChangeCheckFieldTypes := [ftString, ftSmallint, ftInteger, ftWord,
      ftBoolean, ftFloat, ftCurrency, ftBCD, ftDate, ftTime, ftDateTime,
      ftAutoInc, ftFixedChar, ftWideString, ftLargeint, ftVariant, ftGuid,
      ftTimeStamp, ftFMTBcd];

    If DataSets = Nil Then
      DataSets := TDataSetList.Create;

    DataSets.Add (Self);//<- muy pero muy interesate 
  End;

La verdad que me has abierto nuevas perpectivas.., aunque no exactamente siguiende ese mismo camino. por ejemplo:

Advertencia:
Lo que voy a exponer a continuacion no significa que pueda llegar a una solucion concreta del tema, sino mas bien hacer conocer una "idea" para quizas poder implementar una solucion desde otro punto de vista.

Todos sabemos que el problema es lo siguiente:
Teniendo creado(instanciado) un formulario de una determinada clase de la siguiente forma:

Código Delphi [-]
if not Assigned(MyForm) then //<- favor poner atencion a ésta linea
   MyForm := TChildForm.Create(Application);//MyForm en una variable privada

MyForm.Show;

y sabiendo que en la clase TChildForm en su evento OnClose tenemos

Código Delphi [-]
procedure TChildForm.FormClose(Sender: TObject; var Action: TCloseAction);
begin
Action:=caFree;//ya sabemos que está linea provocará un liberacion del formulario atraves del método Release.
end;

Ahora el asunto es: ¿cómo lograr saber que el objeto al que hace referencia la variable "MyForm" ha sido liberado?
OJO: todos sabemos que cuando un objeto se libera, pues la referencia que le apuntaba de igual forma sigue referenciando a la misma direccion de memoria donde estaba el objeto.Es decir el espacio de memoria del objeto se libero pero su apuntador(referencia) sigue apuntadolo.
Pues ..en lo anteriores post hemos discutido que la solucion sería poner al apuntador en nulo (nil)despues de la destruccion del objeto y luego para saber si la referencia apunta a un Objeto válido podriamos poner

Código Delphi [-]
if MyForm=nil then
...

o bien usando la funcion Assigned

Código Delphi [-]
if not Assigned(MyForm) then
...

Ahora vá la pregunta ¿Existe alguna forma de determinar que la referencia de un objeto apunta a un objeto no destruido sin estar poniendola a nulo cada vez que se libera el objeto?. Es decir.. yo como programador pienso y digo hipoteticamente:"No quiero que la referencia del objeto se ponga en nulo al momento de destruirse el objeto , más bien quiero que siga apuntado a la misma direccion aunque el objeto ya esté liberado"
Pero si más adelante en mi código quisiera saber si el objeto fue destruido o nó ¿como lo haría? ¿? qué código debiera poner en lugar de

Código Delphi [-]
if MyForm=nil then// éste código ya no serviría ya que MyForm no apunta a nulo pero el objeto ya fué liberado
...

o bien

Código Delphi [-]
if not Assigned(MyForm) then //tampoco sirve
...

¿Cómo lo soluciono?¿Delphi posee algun mecanismo o funcion que me permita solucionarlo?

[[Al González]]

Empezado por rgstuamigo

[...] Si es solo para lectura y ha sido pensado para eso, pues creo que debería mostrar un error¿verdad? o no permitir directamente tal instruccion [...]

Así es, el compilador no debería permitir esa instrucción, no simplemente ignorarla.

Empezado por rgstuamigo

Ahora vá la pregunta ¿Existe alguna forma de determinar que la referencia de un objeto apunta a un objeto no destruido sin estar poniendola a nulo cada vez que se libera el objeto?. Es decir.. yo como programador pienso y digo hipoteticamente:"No quiero que la referencia del objeto se ponga en nulo al momento de destruirse el objeto , más bien quiero que siga apuntado a la misma direccion aunque el objeto ya esté liberado"
Pero si más adelante en mi código quisiera saber si el objeto fue destruido o nó ¿como lo haría? ¿? qué código debiera poner en lugar de

Código Delphi [-]
if MyForm=nil then// éste código ya no serviría ya que MyForm no apunta a nulo pero el objeto ya fué liberado
...

o bien

Código Delphi [-]
if not Assigned(MyForm) then //tampoco sirve
...

¿Cómo lo soluciono?¿Delphi posee algun mecanismo o funcion que me permita solucionarlo?

Es interesante lo que planteas y en más de una ocasión me he preguntado cómo resolverlo, ya que Delphi no tiene un mecanismo directo para evaluar si una referencia de objeto es aún válida o un simple puntero hacia donde estuvo una instancia que ya fue destruida.

Pero ahora que vuelvo a leer el planteamiento de parte tuya, recordando que GetMem y FreeMem son las funciones que utiliza nativamente una clase para reservar y liberar el bloque de memoria de la instancia, y que tales funciones son reemplazables , se antoja posible implementar una especie de lista de punteros liberados, para buscar en esa lista la dirección contenida en una variable objeto no Nil, y con ello determinar si se trata de un objeto que ya fue destruido o no.

El inconveniente a resolver sería el de las coincidencias de bloques, es decir, aquellos casos donde una nueva instancia de objeto venga a ocupar la parte inicial (o el bloque de memoria completo) que ocupaba previamente otro objeto ya destruido. Quizá una solución a esto sería hacer que GetMem desplace el bloque que devuelve para que no haya coincidencias o algún control similar, pero eso haría crecer constantemente la memoria usada por la aplicación, por lo que se necesitaría de cierta ayuda de parte del programador, como para decir "estas variables ya no me interesa evaluar", lo cual nos remite, una vez más, a la recomendación de que cada programador se haga responsable de la vida de sus variables objetos.

No obstante el antojo de darle algunas vueltas más la tuerca persiste, e intentar lo que comento de GetMem y FreeMem puede ser cuando menos un ejercicio interesante (sin olvidar que esas funciones no sólo se utilizan para instancias de objetos).

Saludos.

Al González.

[rgstuamigo]

Empezado por Al González

Es interesante lo que planteas y en más de una ocasión me he preguntado cómo resolverlo, ya que Delphi no tiene un mecanismo directo para evaluar si una referencia de objeto es aún válida o un simple puntero hacia donde estuvo una instancia que ya fue destruida.
...

Veo que me has entendido perfectamente....

Empezado por Al González

Pero ahora que vuelvo a leer el planteamiento de parte tuya, recordando que GetMem y FreeMem son las funciones que utiliza nativamente una clase para reservar y liberar el bloque de memoria de la instancia, y que tales funciones son reemplazables , se antoja posible implementar una especie de lista de punteros liberados, para buscar en esa lista la dirección contenida en una variable objeto no Nil, y con ello determinar si se trata de un objeto que ya fue destruido o no.
...

Pues creo que estamos muy cerca de dar con una solucion, aunque pienso que ésto ya debió pensarse cuando Delphi se estaba construyendo y que los creadores de Delphi ya debieron darle una solucion, o por lo menos tener alguna rutuna que la lo haga, pero que sea el programador quien decida si la usa o no.., en fin....si GetMem y FreeMem son reemplazable pues creo y viendo la situacion tenemos dos caminos posibles para una solucion(segun yo)

1. Tener alguna rutina que cuando se libera un determinado Objeto con FreeMen, su referencia apunte a null;está solucion sería la primera que se estaba discutiendo y sería tener una rutina muy similar al FreeMem, es más podriamos escribir nuestra propia version de FreeMen, mas o menos de la siguiente Forma:
   

   Código Delphi [-]
   procedure MyFreeMem(var P: Pointer[; Size: Integer]);
   begin
      FreeMem(P);//aqui llamamos a nuestra la funcion normal
      P:=nil;//hacermos que P sea Nulo  ésta linea podría ser nuestra solucion
   end;

   Lógicamente tendriamos que hacer que se ejecute nuestra "nueva" version de FreeMem en código fuente de Delphi.
2. Implementar algun mecanismo(rutina) que permita saber si una referencia apunta a un objeto destruido o no; lo cual viendolo más a fondo me parece que sería más engorroso, pero no imposible dado tu ejemplo que propones en el anterior post.

La cuestion es que de una u otra forma se solucione...
Como podrás ver, si se puede lograr la primera opcion creo que ya la cosa se soluciona...ALELUYA.. ¿verdad? o como lo vés tú amigo Alberto, ya que tú tienes mas experiencia que yo, pues eres un tremendo bibliotecarioy yo solo soy un simple aprendís
Saludos...