FTP | CCD | Buscar | Trucos | Trabajo | Foros |
|
Registrarse | FAQ | Miembros | Calendario | Guía de estilo | Temas de Hoy |
|
Herramientas | Buscar en Tema | Desplegado |
|
#1
|
|||
|
|||
más buenas prácticas de programación
Una consulta relacionada a otro hilo que comencé con este nombre, y referente a la liberación de la memoria. Alguien me puede explicar por qué no se puede hacer lo siguiente:
Y sabiendo que no puede hacerse esto, como entonces puedo liberar la memoria de la variable miLista creada en esa función. |
#2
|
||||
|
||||
Cita:
Opciones hay muchas,y no entiendo bien que queres hacer, pero como sea que lo hagas deberías destruir el objeto solo después de usarlo, es decir en el código que lo recibe. Ejemplo tosco:
Saludos |
#3
|
||||
|
||||
Cita:
También podrías no crearte el TStrings y mandarle directo a tu función Memo.Lines que ya es un TStrings. Tu codigo quedaría así:
Saluditos
__________________
Disfruten cada minuto de su vida a lado de sus seres queridos como si fuese el ultimo, uno nunca sabe lo que puede pasar. |
#4
|
||||
|
||||
También te queda otra opción, como es el devolver los datos directamente como tipos de datos simples, puros y duros:
Un saludo Última edición por roman fecha: 12-11-2008 a las 18:28:29. Razón: Corregir formato de código |
#5
|
||||
|
||||
ARGH... Pero... ¿Que le pasa a mi editor?
Mil perdones |
#6
|
||||
|
||||
TStringList es una clase TObject, la variable no contiene la clase en sí, sino su referencia. Esto quiere decir que es un puntero a la dirección de memoria en la que se contiene ese objeto.
En esa función lo que haces es devolver el puntero a una dirección de memoria que contiene el objeto que tu has destruido en la misma función, por ello te salta el error. En todo caso, si deseas seguir con esa sintaxis debería ser así el código:
__________________
"La recompensa de una buena acción está en haberla hecho" |
#7
|
||||
|
||||
El problema de esto es que no tiene sentido crear un objeto en una función y liberarlo en otra. Por que? Porque en este caso una función es totalmente dependiente de la otra. Entonces para que separarlas?
Saludos. |
#8
|
||||
|
||||
Desde mi punto de vista, no es buena idea que una rutina interna cree un objeto y que después sea el usuario del módulo el que deba destruirlo. Si ha de hacerse así, hay que documentarlo muy bien.
Lo que yo haría:
Hay que guardar la semántica en delphi, dicho de otra forma, si veo este código dentro de 1 año: Lo primero que digo es: " MiLista no ha sido creado", ahora tengo que buscar la implementación de GetStrings y ver si dentro se llama a Milista.Create. Lo correcto según mi opinión es: dentro de esa rutina queda claro que has creado un TStringList y lo estás liberando, no hay dudas. Ten en cuenta que TStrings es una clase con descendientes, por tanto milista puede ser un TstringList, TMemoStrings, TComboboxStrings, etc., todos ellos son compatibles porque heredan de TStrings, pero no son iguales. En ese código, dejas claro que se trata de un TStringList. Por cierto, el nombre de la rutina, "GetStrings", me parece ambiguo, (ya sé que es sólo un ejemplo, pero en fin, a ver si me explico...) si dentro de GetStrings estoy añadiendo elementos a la variable "MiLista" yo le cambiaría el nombre, por algo así como "AddItemsTo(Milista)". Saludos
__________________
Si usted entendió mi comentario, contácteme y gustosamente, se lo volveré a explicar hasta que no lo entienda, Gracias. |
#9
|
||||
|
||||
¿por qué no seguir el ejemplo que viene en la ayuda de delphi?
Es decir, en el ejemplo de la ayuda de delphi, la última línea dice: MyList.Free no utilizan FreeAndNil.... Así que esto no debería darte problemas:
Aunque me gusta más lo que propone Caro, digo, si ya tienes un stringlist, ¿para qué crear otro?
__________________
|
#10
|
||||
|
||||
Cita:
Es decir valida que solo libera cuando esta creado. Es codigo seguro. Lo que tu colocas da problemas porque sigues liberando un objeto que pretendes devolver. Saludos. |
#11
|
||||
|
||||
¡Hola!
Cita:
Como ya se dijo, es normal utilizar FreeAndNil con variables globales, y aunque también puede ser aplicado a variables locales, por lo general sólo utilizamos Free con éstas. En otras palabras, el uso de FreeAndNil se justifica cuando existe la posibilidad de que alguna parte del código intente hacer algo con la instancia de objeto apuntada por la variable después de haberse destruido dicha instancia. Por otro lado, la solución propuesta por Linett al principio me parece la más adecuada. Cuando mucho haría falta una llamada al método Clear antes del primer Add. Un abrazo sin destruir. Al González. Última edición por Al González fecha: 12-11-2008 a las 17:51:17. |
#12
|
||||
|
||||
Cita:
Esto segun Allen Bauer es un vicio horrendo de programación . Ahora si mirás el código delhi de FreeAndNil:
Si obj = nil estas llamando a nil.free!!!! No jodamos, es inaceptable o muy arriesgado para mis pareceres. Aunque se enoje Allen Bauer , escucho argumentos en contra que me quiten el vicio. Saludos |
#13
|
||||
|
||||
Cita:
Justo por eso (y sólo por eso) es que siempre se recomienda usar Free en lugar de Destroy. // Saludos |
#14
|
||||
|
||||
Cita:
Una disculpa a elcigarra por las derivaciones que tuvo el hilo (al menos por lo que a mí me toca). Saludos. Al González. |
#15
|
||||
|
||||
Cita:
Por lo menos yo cuando libero un TStringList lo hago con FreeAndNil, porque, digamos que tengo un tStringList como variable global en mi Unit. Cuando libero con Free y en otro lugar hago esto:
Al no haberlo hecho con FreeAndNil habiendolo liberado antes me sale un accessViolation, por eso lo libero con FreeAndNil. Saluditos
__________________
Disfruten cada minuto de su vida a lado de sus seres queridos como si fuese el ultimo, uno nunca sabe lo que puede pasar. |
#16
|
||||
|
||||
ya, me guíe por el ejemplo de Delphi, no me había fijado que era una función que tendría que regresar ese valor.
__________________
|
#17
|
||||
|
||||
Resumiendo:
Si vas a reutilizar una variable varias veces (crearla en memoria y liberarla) es mejor usar FreeAndNil. Si sólo vas a crear y destruir la variable una vez, puedes usar variable.Free; Saludos
__________________
Si usted entendió mi comentario, contácteme y gustosamente, se lo volveré a explicar hasta que no lo entienda, Gracias. |
|
|
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 |
|