Cita:
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.
Cita:
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
o bien
Código Delphi [-]if not Assigned(MyForm) then ...
¿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.