FreeAndNil() – Debate de desarrolladores de Delphi

Estás familiarizado con FreeAndNil() , pero ¿lo usas? ¿Con qué frecuencia? ¿Lo estás usando bien? Como con la mayoría de las cosas en el desarrollo de software, es un tema complicado. Entonces, veamos qué tienen que decir los expertos. Vamos a debatir los detalles en una discusión amistosa con algunos de sus MVP favoritos.

• Esta publicación de blog incluirá la repetición, las diapositivas y más después del seminario web.

La encuesta dice…

Cuando se registra para el seminario web , hemos incluido una breve encuesta para ver cuál es su posición sobre el tema. Durante el seminario web, compararemos el consenso general con el de nuestro panel de expertos de MVP.

Incluso más MVP han opinado sobre el tema y tengo algunos adelantos de cómo votaron…

Dejé la leyenda de que los gráficos significan por ahora, debe unirse al seminario web para ver los detalles, pero el uso de FreeAndNil() se divide bastante uniformemente si agrupamos las respuestas en generalidades a favor y en contra.

Si desglosamos las cosas en detalles, aunque es un poco más matizado. De nuevo, sin la leyenda, todavía.

Hacer cheques asignados es similar, pero con diferencias un poco más pronunciadas.

• P: Tengo un lema: si creaste algo, ¡destrúyelo al final de la rutina! ¡Es por eso que uso mucho FreeAndNIl()!
• R: No siempre es posible, pero entiendo su punto.
• P: La creación de instancias a pedido suele ser un patrón sensato, por lo que no tendrá nada para sentarse en su puntero.
• R: buen punto
• P: ¿Este tipo hace alguna programación real?
• R: sí, mucho. Sí, es un codificador extremadamente experimentado y muy respetado. te lo prometo 🙂
• P: Llámame objeto ficticio “Nil” 😛
• R: Buen punto.
• P: Me siento corregido.
• R: jajaja
• P: nil es una excelente manera de confirmar que no hay nada referenciado, y si SIEMPRE es libre con FreeAndNil, entonces su código mantendrá que el puntero será nulo si no es válido, de lo contrario, siempre es un objeto válido.
• R: Sí asigna cero, pero hay momentos en los que no es necesario asignarlo a cero, o cuando puede estar oscureciendo algo más.
• P: ¿Cómo puedes decir “siempre usa interfaces” y luego decir “nunca debes destruir algo que no has creado” – completamente inconsistente!
• R: Dije, “si puede, use interfaces” y el punto sobre la codificación de una interfaz es que el conteo de referencias está diseñado explícitamente para lidiar con esto.
• P: Hay toneladas de casos de uso para Asignado y FreeAndNil. Si no los está utilizando, no está utilizando tales casos de uso o es un mal programador. Decir que no hay razón para usarlos nunca, o que si los estás usando no deberías hacerlo, es completamente erróneo.
• R: Creo que lo que dice Nick es que usar FreeAndNil y los cheques asignados son un olor a código que podría necesitar para tomar un diseño diferente. También que el uso excesivo de FreeAndNil también oscurece las cosas.
• P: Hay muchas circunstancias en las que el código responsable de liberar un objeto no es el mismo código que creó el objeto. El ejemplo más obvio es un modelo de gestión de memoria de recuento de referencias.
• R: seguro
• P: También debería obtener una vista de desarrollo de C++
• R: Sí, algunos de los MVP usan ambos.
• P: F# usa el tipo de opción (tipo de unión con Some y None) para evitar el valor nulo, y creo que esto requiere soporte en el idioma (en el sistema de tipos). ¿Delphi brinda este tipo de soporte?
• R: No que yo sepa…
• P: ¿Por qué alguna vez liberarías un objeto y no establecerías el puntero en cero?
• R: Si la referencia no va a existir porque está fuera de alcance inmediatamente, entonces la asignación no es necesaria.
• P: Lo que Olaf acaba de explicar tiene un nombre: programación de culto de carga
• R: Ese era un concepto en el que estaba pensando antes de este seminario web. Soy un gran creyente en la programación basada en evidencia. ,Tbh, tuve que buscar qué significa “Cargo Cult”. Sí estoy de acuerdo. Pero como dije, si está en su propio camino, o hay conductores seguros, entonces FreeAndNil() ahora es útil. Sin embargo, lo que veo en la naturaleza es muy diferente. Recuerde, con frecuencia trabajo con equipos externos, con conjuntos de habilidades muy diferentes. Muchos de ellos no tienen la etiqueta “Guardar controlador” (todavía)
• P: El artículo de wikipedia incluso tiene esta declaración: “Las comprobaciones obsesivas y redundantes de valores nulos o probar si una colección está vacía antes de iterar sus valores pueden ser un signo de programación de culto de carga”.
• R: jajaja
• P: Usamos métodos de obtención de propiedades que incluyen controles para la asignación de una variable “f” y la construiremos a pedido… a veces la construcción de esa variable “f” tiene ramificaciones (por ejemplo, una solicitud a una base de datos o la construcción de un formulario), por lo que no construya cada variable “f” antes de tiempo. Y freeandnil ayuda a garantizar que las llamadas posteriores a la propiedad se administren e inicialicen de manera adecuada.
• R: seguro
• P: FreeAndNil simula variables locales unique_ptr de C++. Delphi 10.4 finalmente introdujo RAII, por lo que ahora puede haber un elemento unique_ptr más explícito, pero tengo que mantener el código Delphi 7, por lo que sigo usando FreeAndNil como unique_ptr que falta
• R: Siempre es frustrante cuando también tengo que trabajar con código para compiladores antiguos.
• P: “No hay nada de malo en dejar un puntero establecido en un objeto que se ha liberado”, ¿en serio? ¿Alguna vez has tenido que depurar algo?
• R: Correcto, no estoy de acuerdo con el tipo de denigración engañosa de las habilidades de programación, pero veo lo que dices, que es “puede causar problemas con el depurador, por lo que no estás de acuerdo”.
• P: tal vez debería explicar la diferencia exacta entre x.free y FreeAndNil(x) Creo que no todos aquí son conscientes de la diferencia
• R: FreeAndNil(x) free es el objeto, lo mismo que x.free, pero también establece la referencia en nil. Si no establece la referencia en cero, seguirá apuntando al objeto liberado.
• P: Un campo de clase que hace referencia a un objeto debe ser nulo hasta que se cree el objeto, y cuando se libera el objeto, debe ponerse a cero. Esta conversación no tiene sentido para mí.
• P: ¿Ejemplos de código?
• R: Si observa las diapositivas, hay un par de publicaciones de blog que enlazan con el código.
  ¿Necesitamos verificar la referencia del objeto?

 https://developpeur-pascal.fr/faut-il-vraiment-utiliser-freeandnil-dont-nos-programmes-en-pascal.html https://corneliusconcepts.tech/delphi-debates-freeandnil

• P: Realmente no entiendo el motivo de este debate. Pensé que iba a ser una explicación de por qué se debería usar FreeAndNil en lugar de usar .Free y luego := nil. Aquí parece que estamos discutiendo el uso de FreeAndNil en objetos que nunca creé. Creo que he perdido la trama!
• R: La discusión son los pros y los contras de usar FreeAndNil y tener referencias sin asignar.
• P: Desarrollé SafeMM3 y encontré un error en FireMonkey. Destructor usó “Free” para una referencia que se suponía que había desaparecido ya que después de todo es destructor, pero luego alguna operación de SetFocus estaba caminando con punteros colgantes. Rara vez puede estar seguro de que la última operación en la referencia sea realmente la última.
• R: buen punto.
• P:El punto es que NIL es un verdadero valor real en el código, y por esa razón uno verificará esas situaciones (como rechazar un NIL como dice Nick), y como tal NIL no desaparece, por lo que tiene sentido NIL algo para asegúrese de que la memoria sea NIL y no un valor antiguo aleatorio de los viejos tiempos. Esto es especialmente importante cuando se escribe código de alto rendimiento de bajo nivel, pero obviamente es mucho menos importante cuando se está escribiendo principalmente código de alto nivel, esencialmente creando scripts de módulos existentes juntos. Las interfaces tienen absolutamente muchos usos excelentes, pero a veces necesitamos simplemente punteros a registros o clases, y hacer un seguimiento de NIL o no NIL es bastante crítico. Por lo tanto, FreeAndNil tiene sus usos, pero también x.Free; yx:=nil; Si el último falla, entonces FreeAndNil puede fallar y estamos hablando de un escenario de subprocesos múltiples,
• R: Buen punto Kim.
• P: Incorrecto. No siempre debe crear clases en su constructor. Si es común crear el objeto en su primer uso y luego dejarlo creado para su reutilización.
• R: Veo que hay bastantes personas que adoptan ambos lados de este punto de vista.
• P: El patrón de objeto nulo (así es como Nick llamó objeto ficticio) está bien para los inyectables, pero no para muchos creables.
• P: Recientemente tuve un bloqueo grave debido al acceso a un objeto liberado que no era nulo. Esto es realmente difícil de detectar. Si la variable queda fuera del alcance, nil no es realmente necesario, pero debe verificar el código con mucho cuidado para evitar usarlo después.
• R: En mi opinión, si existe la posibilidad de que su referencia aún se use más adelante, entonces debería asignarla a cero con FreeAndNil.
• P: Acción := caFree Cuando hago esto, ¿tengo que poner un puntero nulo? MiClase := TMiClase.Crear; MyClass := nil cuando uso Action := caFree
• P: La pregunta clave probablemente debería ser… ¿existe un verdadero DESVENTAJA en el uso de freeandnil?
• R: Oscurece las cosas y puede introducir errores con la inicialización diferida.
• P: Normalmente, el uso de interfaces no tiene que ver con la administración de la memoria, mezclar los dos (con la falta de documentación explícita) es toda una serie de desastres esperando a suceder. He visto muchos códigos que contienen referencias de interfaz a objetos que se liberaron cuando el recuento de referencias llegó a cero. Una disciplina de administración de memoria de liberación siempre explícita con FreeAndNil parece que debe ser inherentemente más segura.
• R: tal vez
• P: Creo que en una aplicación de subprocesos múltiples tiene sentido usar Assigned() y FreeAndNil(), cuando las instancias se pueden usar temporalmente o las interacciones con servicios/servidores remotos se pueden interrumpir y necesitan reconexiones con estas instancias temporales.
• R: Sí, creo que varios de los MVP están de acuerdo contigo.
• P: Ada.Unchecked_Deallocation funciona como FreeAndNil desde el primer momento. Lo mismo ocurre con el procedimiento Eliminar, destruye el cursor pasado. Lástima que los desarrolladores de Delphi rara vez busquen inspiración en otros descendientes de Pascal
• R: Creo que hay muchas más investigaciones sobre las técnicas e innovaciones de todos los idiomas, no solo los descendientes de Pascal, de las que podrías darte cuenta. Por ejemplo, las declaraciones de variables en línea (que personalmente odié cuando salieron) están inspiradas en otros lenguajes que hicieron esto. Son muy “anti-Pascal”, pero resultaron tener algunas ventajas muy distintas que eran demasiado convincentes para ignorarlas.
• P: No siempre debe crear todos los objetos de una clase en su constructor. Es común, al menos para nosotros, crear el(los) objeto(s) solo si se necesitan y cuando se necesitan, y luego dejarlos creados para su reutilización. Luego, cuando se destruye la clase, debería destruir las instancias creadas. Asignado y FreeAndNill son vitales para esto.
• A: inicialización diferida, sí
• P: Tengo que dejarlo, ¡pero gran discusión!
• R: Gracias, Gary.
• P: Para las computadoras de hoy, los ciclos de CPU para FreeAndNil son insignificantes, incluso para motores 3D o lo que sea. ¡Esto no es 1980!
• R: como señalaron Nick y Thomas, requiere que el desarrollador considere por qué FreeAndNil, por lo que requiere más ciclos de desarrollo.
• P:Estoy aprendiendo a desarrollar una aplicación móvil usando Delphi 10.4 CE FMX, y tengo muchas dudas y no las encuentro en ningún lado, excepto en grupos de telegram o videos de 99coders – que tiene una didáctica fantástica, además de Márcio, Gledson Prego , Anderson Fiori y MobiusOne, que nos ha ayudado mucho. Pero eso no es suficiente para una aplicación tan antigua como Delphi. Mis dudas son: 1) ¿Cuál es el método correcto y dónde destruyo los objetos(*) que se instancian en una función/procedimiento en la sección VAR? (*) jsonarray, jsonobject, frame, etc… >> 1a) ¿Estos objetos los destruyen con FreeAndNil, disposeOf, .free, =nil? >> 1b) ¿Cuál es el mejor y más efectivo método para destruir estos objetos? >> 1c) ¿dónde está el lugar correcto (evento) para destruirlos? al cerrar, en Destruir? 2) ¿Por qué Delphi causa tantas fugas de memoria de objetos que estamos seguros de que están siendo destruidos?
• P: Esta es una gran sesión (Marco)
• R: Sí, parece popular.
• P: ¿Podría explicar por qué FreeAndNil() no es seguro para subprocesos?
• R: No es atómico. Debe bloquear la referencia antes de la llamada a FreeAndNil.
• P: “Puntero colgante”: un modelo de gestión de memoria cooperativo debe garantizar que los consumidores de objetos reciban una notificación cuando se libere un objeto.
• P: FreeAndNil se establece en nil antes de que se libere, por lo que, si bien puede tener un cambio de contexto antes de liberar el objeto, ya habrá establecido el puntero en nil…
• P: Si liberar es la última acción, entonces Free(). Si una variable se usa varias veces, entonces FreeAndNill()?
• R: si va a reutilizar la referencia, FreeAndNil
• P: ¿Qué hace realmente FreeAndNil? ¿Por qué .Free no establece la referencia en cero?
• R: Free verifica la referencia para ver si está asignada y, si lo está, destruye el objeto, pero aún hace referencia al objeto destruido. FreeAndNil además le asigna la referencia a nil.
• P: Lamentablemente, las variables en línea aún no funcionan. si usa la búsqueda de referencia o las herramientas de refactorización “después” de una variable en línea en una unidad, rompe estas herramientas 🙁
• R: Hay más trabajo y RSP en relación con la refactorización y las variables en línea. La refactorización (y cosas como el reformateo automático) puede ser un problema para las construcciones de lenguaje más nuevas.
• P: La única ventaja específica que Pascal tenía sobre los lenguajes basados ​​en C… el requisito de declarar la sección de interfaz Y las variables antes de su uso. La forma en que es posible obtener una visión general del código con solo echarle un vistazo.
• R: si
• P: Encuentre mi proyecto SafeMM3 en OSDN. A diferencia de SafeMM y SafeMM2, es compatible con Delphi reciente, probado en Delphi 10.2. He encontrado punteros colgantes en FireMonkey, producido por desnudo Free
• R: cuidado con los punteros colgantes.
• P: Y luego esa ventaja se vio “comprometida” por la declaración de variables en línea e incluso la deducción del tipo de datos… Brzzzzz….
• R: Me encantan las variables en línea.
• P: ¿Dónde están los ejemplos?
• R: He publicado algunos enlaces arriba.
• P: recordando, vengo del clipper/puerto donde comencé a los 14 años y me quedé allí hasta 2021, cuando me di por vencido y vi un video de 99coders que hablaba sobre Delphi donde el título era algo así: “delphi es ¿muerto? y demostró que puedes hacer mucho a través de delphi, especialmente para dispositivos móviles (android/ios) jajaja
• P: ¿Cómo le va cuando usa archivos DLL y pasa objetos como parámetro? ¿Haces una copia del objeto y la devuelves como objeto de resultado?
• R: Depende, supongo.
• P: una pregunta más de alguien de Brasil: 3) ¿por qué intentaste usar .DisposeOf si tenías que volver a FreeAndNil()?
• P: C++: tengo experiencia en C++, por lo que me parece tan exasperante la falta de documentación explícita sobre las interfaces de Delphi.
• R: ah, si
• P: 4) por favor dé un buen ejemplo del uso de freeAndNill() de manera efectiva sin fugas de memoria…
• P: Estos puntos traen a colación las ideas de propiedad/préstamo en Rust
• R: Sí, Rust se inspiró mucho en Delphi.
• P: No tengo una pregunta, pero quiero agradecerles por el desarrollo de Delphi. Gracias)
• R: ¡Gracias! ¡Me alegro de que Delphi también esté aquí!
• P: ¿Cuál es una buena fuente para comprender la estructura del diseño de la interfaz ?
• R: Creo que los libros de Nick Hodges lo discuten.
• P: Las interfaces no son seguras para subprocesos. Solo lo es el contador de referencia dentro de TInterfacedObject. Pero la asignación de interfaz es una operación no atómica y debería estar bajo bloqueo.
• R: Sí, el libro de Dalija analiza esto en detalle.
• P: Hubo un comentario sobre “desperdiciar ciclos de CPU”… ¿Cuántas instrucciones de ensamblador se requieren para “x = cero”? Si esto se hace en varios objetos en algún tipo de ciclo/bucle, la asignación de NIL puede afectar el rendimiento si ya no se hace referencia a las variables después de liberarlas, pero si las variables se pueden hacer referencia fuera del ciclo más adelante, es mejor saber si lo están. realmente haciendo referencia a un objeto existente.
• R: Verifique la vista de la CPU y vea.
• P: MISRA C tiene que ver con la programación de culto de carga. C permite declaraciones de una sola línea, pero MISRA C las prohíbe. Así que es una práctica bastante industrial. Nada de que avergonzarse
• R: ah
• P: ¡Buen debate!
• R: ¡Ha resultado ser mucho más popular, y divisivo, de lo que pensábamos que sería!
• P: @Nick, si considera no usar nunca FreeAndNil(), entonces en aplicaciones basadas en eventos (no tan raras), ¿cómo puede evitar crear objetos en momentos desconocidos y evitar crearlos dos veces o más? El caso típico es cuando el usuario hace clic en un botón y ejecuta algún descendiente de TThread. ¿Qué pasa si el usuario hace clic dos veces en el mismo botón, la segunda vez cuando el primer TThread lanzado por el primer clic no ha terminado?
• R: ¿Quizás evitar que se haga clic dos veces en el botón? Eso parece una preocupación válida.
• P: Logré crear una instancia de un objeto usando “asignado”. Solo liberé el objeto de la memoria con “acción: caFree”, pero no señalé “nil”. ¿Cómo es esto posible?
• R: A menos que llame a FreeAndNil, o lo asigne explícitamente a Nil, free no anula la referencia.
• P: ejemplo, donde FreeAndNil mostrará errores en el código: Con object.Free no obtendrá una excepción si accidentalmente usa el objeto. con FreeAndNil(objeto) obtendrá la excepción inmediatamente. Ejemplo: procedimiento TForm1.BT_Click(Sender: TObject); var sl: TStringList; comenzar sl:=TStringList.Crear; intente finalmente sl.Free; //LibreYNil(sl); final; // — // otras cosas // — if (sl.Text = ”) then sl.Text:= ‘¡Hola mundo!’; final;
• R: gracias
• P: ¿Hay alguna situación en la que necesite usar un objeto liberado? (más a menudo necesito “Nil” una var sin liberar el objeto). O, tal vez, FreeAndNil existe solo para completar porque x.free no pudo “Nil” la var. Gracias
• R: En mi opinión, uso FreeAndNil cuando hay otras referencias que podrían hacer referencia a él después de que es nulo.
• P: Ningún código está libre de errores. Desea que los errores fallen pronto y con fuerza. FreeAndNil ayuda a detectar errores de “uso después de gratis”.
• R: cierto
• P: Nunca llamo al destructor directamente, ese es el trabajo de Free, ¿no?
• R: si
• P: Casi siempre uso freeandnil en componentes de terceros, nunca confío en el código de otras personas 😛
• P: No estoy seguro de si llamar directamente a Destroy es realmente más rápido que usar Free. Simplemente porque Destroy es una llamada de método virtual. Alguien tiene que proporcionar algún punto de referencia para probar ese punto
• R: cierto
• P: La creación de objetos en su primer uso puede crear muchos problemas al intentar hacer algo con ese objeto. Experimenté esto al agregar alguna funcionalidad al InplaceEditor de un TCustomGrid.
• P: Lo ideal sería programar de modo que el compilador ayude a detectar problemas… Mucha discusión aquí es sobre la habilidad del programador.
• P: Referencias de formularios globales: el IDE creará automáticamente un puntero global a los formularios…
• P: Entonces, ¿estás llamando loco al IDE? ¿De Jim? ¡Eso es grosero!
• R: 🙂
• P: Hablando de variables en línea “no-Pascal”, Ada desde el inicio tiene un bloque de declaración-comienzo-fin. Entonces no es “no-Pascal”, es solo que aún no estás familiarizado con Ada. Pero Ada no termina en esto. Delphi recientemente obtuvo “vars en línea”, mientras que en Ada, el desarrollador disfruta más a menudo de “constantes en línea”. De hecho, si algo se inicializa al comienzo de un bloque, es probable que nunca cambie hasta el final del alcance. Marcar cosas “constantes” ayuda a la legibilidad y al razonamiento
• R: ¡Sí! = Pascal. ️
• P: Si usa constantemente FreeAndNIL, entonces no hay un ciclo de desarrollador adicional cuando se usa. Es solo cuando no eres consistente en tu uso…
• R: Supongo que es un punto válido.
• P: ¿Puedo decir cuánto he disfrutado de esta discusión que invita a la reflexión? ¡Gracias!
• R: me alegra escucharlo.
• P: ¿Qué libros de Dalija Prasnikar recomendaría con respecto al tema de hoy?
• R: https://dalija.prasnikar.info/delphimm/index.html
• P: Lanzaré mis dos centavos al ring… con declaración… trate de no usarlos y ciertamente no los use para más de una cosa… solo MHO
• R: Sí, esta es mi opinión también, pero aparentemente no todos están de acuerdo, de ahí el debate.
• P: ¿Cuál usar para destruir: .free disposeOf =nil freeAndNil() ??? ¿Cuál realmente libera memoria y nos deshacemos de la basura de “Memory Leak”? obs.: delphi 10.4 CE / FMX / Móvil
• P: ¿Cómo se llama el libro de Dalija?
• R: https://dalija.prasnikar.info/delphitspatt/
• P: Este seminario web ha sido excelente. Seré honesto, no esperaba mucho, pero francamente, este ha sido uno de los mejores seminarios web de los últimos tiempos… Más de lo mismo por favor !!
• R: Anotado. Me alegra que lo hayas disfrutado.
• P: Nunca usé FreeAndNil. Nunca lo haré, a menos que Nick comience a usarlo 😀
• R: ah
• P: Una discusión muy interesante sobre el manejo de variables de punteros… Normalmente desecho o devuelvo los punteros a la memoria después de usarlos
• R: Sí. Eso es un patrón.
• P: Totalmente de acuerdo con la sugerencia de Holger: ¿puede Delphi dejar de crear una nueva aplicación con un formulario basado en globales? Sin duda vale la pena un debate.
• R: He pensado en esto también.
• P: el enlace proporcionado por usted no funciona: https://developpeur-pascal.fr/faut-il-vraiment-utiliser-freeandnil-don’t-nos-programmes-en-pascal.html – este enlace no funciona ( error 404)
• P: ¡Gracias, disfruté la sesión!
• P: Sugerir mantener y publicar el chat también
• P: Tengo que correr. ¡¡¡Gracias un montón!!! Gran trabajo.
• P: Destruir solo es más rápido que Gratis. La implementación de Gratis es “SI Asignado (Auto) ENTONCES Destruir”; así que al llamar a Destroy directamente, está omitiendo una LLAMADA y una verificación de “Si está asignado”: todavía está llamando a Destroy virtual …
• P: Si desea verificar la seguridad de subprocesos de las cosas de la interfaz, escriba el descendiente de TInterfacedObject que está invocando Sleep(10) en AddRef y Release. He escrito referencias sin bloqueo con la primitiva Compare-And-Exchange que está pasando esta prueba. Probablemente también pueda hacer una referencia débil segura para subprocesos
• P: Honestamente, los nobles “gurús” no respondieron ninguna de mis preguntas. Son 11 hombres y mujeres que son las calaveras de Pascal/Delphi y estoy partiendo y viniendo del clíper/puerto, quisiera su atención, hasta para sentirme como en casa!
• P: Siempre intento, en la medida de lo posible, crear el objeto y liberar el mismo objeto dentro de la misma rutina, de esa manera tengo mucho más control y muchas menos posibilidades de problemas de memoria y referencia y r
• P: Hablamos mucho a lo largo de los años sobre el uso de interfaces para la gestión automática de la memoria… ¿qué pasa ahora con los registros gestionados? ¿Podemos hacer RAII en Delphi… hay otro camino?
• R: sí, RAII introduce eso.
• P: Si tuviera que compilar las preguntas y respuestas que se están haciendo y publicarlas, sería excelente.
• R: Veré sobre hacer eso.
• P: Me uní un poco tarde, disculpe si eso se discutió antes; si obtiene el objeto secundario como en (ParentObject.childObject) liberado de todos modos, y luego freeAndNil parentObject… ¿puede esto no ser seguro debido a que el tiempo necesario para liberar cada objeto puede cruzarse y ser secuencial?
• R: Buena pregunta. Incluso si elimina la referencia, el objeto seguirá siendo responsable de liberar a sus hijos, mientras que los hijos usan un patrón de notificación para notificar al padre cuando se liberan.
• P: Si inicia un hilo al hacer clic en un botón, parece obvio que debe estar preparado para ejecutar múltiples hilos :-), no liberará objetos compartidos en dicho hilo. O… deshabilitas el botón.
• R: si
• P: ¿Cuánto más caro es FreeAndNil que FreeAndNil manual seguido de asignación gratuita manual?
• R: En cuanto a la CPU, no requiere mucho, pero ¿qué está comunicando?
• P: Disfruté esa vívida discusión de verdaderos expertos en programación.
• P: Delphi RTL usa GOTO 🙂
• R: si
• P: Gracias, más sobre esto por favor. +1
• R: seguro
• P: Si destruye un TJSONObject, ¿también destruye todos los objetos “GetValue as TJSONString”?
• P: Sugerencia… no podemos simplemente tener “no usar con”… veamos lo que intentó hacer… lo que tienen otros lenguajes… y lo que podríamos empezar a hacer en su lugar con Delphi moderno en esa dirección
• P: ¿Los eventos en los que se hace clic en un botón no se entregan como resultado de GetMessage’d desde la cola de subprocesos de la interfaz de usuario? El segundo evento de clic no se entregará hasta que se haya procesado el primero, a menos que se produzca mediante programación, lo que sería un problema de reingreso. ¿Que me estoy perdiendo aqui?
• P: Más goto en RTL desde que comencé a optimizar algunas funciones del sistema sin hacer asm 😉
• P: No es tan simple simplemente deshabilitar el botón, porque las cosas son más complicadas. Uso algo como “demanda” de la programación funcional. Entonces, cuando se hace clic por primera vez en el botón, se crea la demanda contada por referencia, dedicada al “primer clic”. Luego, el subproceso puede hacer algunas cosas y sondear su propia “demanda” para verificar si todavía se demanda. Y habiendo ingresado a Sincronizar, verifique también si esta “demanda” específica todavía está vigente. Cuando se hace clic por segunda vez en el botón, la demanda anterior se marca como obsoleta y se implementa la nueva demanda. De esta manera, el primer hilo recibe el mensaje: vete, ya no te necesitamos.
• P: Deseo: Variables locales, estáticas, que sobreviven a través de las llamadas (actualmente se usan CONST locales asignables)
• P: gracias