FTP | CCD | Buscar | Trucos | Trabajo | Foros |
|
Registrarse | FAQ | Miembros | Calendario | Guía de estilo | Temas de Hoy |
|
Herramientas | Buscar en Tema | Desplegado |
|
#1
|
||||
|
||||
Cita:
Justo por eso (y sólo por eso) es que siempre se recomienda usar Free en lugar de Destroy. // Saludos |
#2
|
||||
|
||||
Cita:
Código Delphi [-]procedure TObject.Free; begin if Self <> nil then Destroy; end; Justo por eso (y sólo por eso) es que siempre se recomienda usar Free en lugar de Destroy. // Saludos[/quote] Y te parece segura una llamada como Nil.free ???? Este tema incluso esta referenciado en el blog de Allen Bauer, no todos estan convencidos de una u otra manera. Para mi entre código raro y código seguro : siempre seguro. Eso me permite que un servidor corra 24 horas sin un solo problema. Saludos. |
#3
|
||||
|
||||
En Delphi es de lo más seguro, Donald.
Cuando el objeto es Nil y el método Free hace esta validación: , está preguntando si Nil es diferente de Nil, en cuyo caso llama a Destroy. De lo contrario no hace absolutamente nada. Si Free fuese un método virtual o hiciera alguna otra cosa con la "improbable" instancia, entonces sí sería inadecuado usarlo en esos casos. Self es un parámetro implícito que llevan todos los métodos y equivale al puntero en sí de la instancia en cuestión. Nil, cuando el puntero está en blanco. No hay absolutamente ningún problema. ¿Ya convencido? |
#4
|
||||
|
||||
Tal como dice Al. Es completamente seguro usar Free en nil. Ese es el objetivo de Free, que sea seguro usarlo. Y lo es porque nunca hay una llamada a nil.Destroy.
// Saludos |
#5
|
||||
|
||||
A ver, borrón y cuenta nueva.
Creo que ya veo por donde va la preocupación de Donald. A él no le inquieta la llamada a Destroy, sino la misma llamada a nil.Free. Pero creo que hay que recordar que un objeto no es un record. ¿Qué pasa cuando se llama nil.Free? El compilador genera esta llamada: Código:
mov eax, [eax + ...] call TObject.Free // Saludos |
#6
|
||||
|
||||
Cita:
Cita:
Para agregar a la charla y enriquecerla , un post sobre los efectos colaterales de la forma en que esta implementado, sobre todo cuando usas tareas: link Saludos. |
#7
|
||||
|
||||
Hola ???
Retomando la pregunta inicial.
Por que no haces esto:
Al salir de la función GetStrings, la variable se libera sola. Un saludo |
#8
|
||||
|
||||
¿quien te ha dicho eso? ¿eh? que yo me entere
__________________
Si usted entendió mi comentario, contácteme y gustosamente, se lo volveré a explicar hasta que no lo entienda, Gracias. |
#9
|
||||
|
||||
Cita:
Estas explicándome que hace el código y que es self . Lo que quiero saber es porque razón un puntero a la nada (nil) es seguro. Saludos. |
#10
|
||||
|
||||
De hecho (aunque no lo voy a jurar ) esto es seguro:
// Saludos |
#11
|
||||
|
||||
Cita:
FPC se queja con ese código, por lo tanto prefiero escribir código seguro que experimenta con lo que se banca la VCL. Saludos |
#12
|
||||
|
||||
Cita:
En el ejemplo anterior, la llamada Persona.Saluda realmente genera este código: Código:
call TPersona.Saluda Si tuviéramos
entonces sí que habría problemas, porque no ha sido asignada memoria a ningún objeto y por tanto el campo Persona.Saludo no existe aún. // Saludos |
#13
|
||||
|
||||
Cita:
Tratándose de objetos, debes recordar que el código compilado de las rutinas (métodos) se guarda en ubicaciones de memoria distintas a donde se alojan los campos de datos de una instancia. De hecho, por dentro, el bloque de memoria que ocupa una instancia de objeto es meramente una "estructura" del estilo Record, teniendo un primer "campo" invisible que guarda un apuntador a donde se encuentra definida la clase a la que pertenece, su herencia, métodos y otros elementos de RTTI. El código compilado está disponible para el programa desde que arranca la aplicación, así que los métodos que el compilador incluyó en el programa ejecutable pueden (mas no necesariamente "deben") ser llamados sin necesidad de usar una instancia real de por medio, como bien lo ejemplificó Román más arriba. Lo inseguro es hacer esto con un método que emplee uno de los campos de la instancia o algún otro dato de memoria cuya disponibilidad (existencia) dependa de que el objeto sea "real", como ya también lo ejemplificó Román. El método Free no "toca" nada de la memoria de datos. Se limita a preguntar si Self es otra cosa distinta de Nil, para luego llamar al destructor con seguridad. Por ello es que no preocupa su uso con un objeto Nil. Fue concebido tal como es para que el programador no tuviese que preguntar si una variable objeto es Nil antes de intentar liberar dicho objeto. Cita:
Cita:
Espero haber ayudado a esclarecer un poco el asunto. Saludos a todos y no se estresen porque me estreso. Al. P.D. Cabe mencionar que la llamada a métodos virtuales con un objeto Nil sí es totalmente inviable y en todos los casos elevará una excepción. Porque, para hacer el late binding, se necesita conocer cuál es la clase real de la instancia, es decir, leer ese primer campo invisible que está alojado en los primeros cuatro bytes de la memoria del objeto. Siendo el objeto Nil (dirección de memoria 0), no hay tal dato. En todo caso el programa intentará leer los primeros cuatro bytes de la RAM, posición de memoria no accesible. Free NO es virtual, carecería de sentido si lo fuera. Última edición por Al González fecha: 12-11-2008 a las 22:00:57. |
#14
|
||||
|
||||
Cita:
Cita:
Saludos |
#15
|
||||
|
||||
¿ que es nil ?
jojojojo
__________________
|
#16
|
||||
|
||||
Porque el punto de la discusión donde hiciste esa referencia («un post sobre los efectos colaterales de la forma en que esta implementado, sobre todo cuando usas tareas») era que no entendías o no dabas por válido el uso del método Free con un objeto Nil. Como si ese artículo de Miller pudiera llevarnos a concluir que la práctica del "ObjetoNil.Free" fuese algo desaconsejable.
Quizá pregunte una estupidez, pero ¿qué es FPC? Google me llevó a la página del Fútbol Profesional Colombiano. Mi pregunta se refería a eso de «prefiero escribir código seguro que experimenta con lo que se banca la VCL». En espera de tus apreciaciones. Saludos. Al González. |
#17
|
||||
|
||||
Cita:
del libro Delphi in a Nutshell de Ray Lischner Cita:
Cita:
// Saludos |
#18
|
||||
|
||||
Cita:
Además, leer tanto texto sin Internet y un diccionario en la mano me ayudó a conseguir mis primeras nociones reales del idioma inglés. Un abrazo esquemático y textual. Al González. |
|
|
Temas Similares | ||||
Tema | Autor | Foro | Respuestas | Último mensaje |
Buenas prácticas de programación | elcigarra | OOP | 18 | 07-11-2008 17:05:27 |
Siete prácticas para un óptimo y rápido desarrollo de software | poliburro | Noticias | 5 | 30-07-2008 16:48:55 |
buenas maneras... | BlueSteel | Humor | 23 | 13-06-2008 08:11:21 |
Buenas Noticias | faustoffp | Noticias | 0 | 04-09-2006 06:33:06 |
Ayuda Practicas En Delphi | MARIAM23 | Varios | 1 | 22-07-2006 01:19:34 |
|