Libertonia
Portada · Todo · Software Libre · Desarrolladores · Comunidad · Internet · Tecnología · Meta · Diarios
Ver: Modo: Orden:
Aprendiendo a programar | 37 comentarios (37 temáticos, editoriales, 0 ocultos)
Nunca sé qué poner aquí (none / 0) (#21)
por Draco a las Fri Jul 23rd, 2004 at 02:04:30 PM CET
(Información Usuario)

¿Y si el GC tarda en entrar? La memoria se queda ocupada. Simplemente.

Si el GC tarda en entrar, es probablemente porque no hay suficientes objetos para recolectar y memoria más que suficiente, por lo que estamos haciendo un mejor aprovechamiento de la CPU gracias a un buen uso de la memoria. Probablemente también, cuando se dé dicha recolección, se liberarán zonas contiguas del heap, reduciendo la fragmentación... hay muchos factores y es difícil determinar cuando es mejor recolección automática o manual.

Es facil encontrase con codigo por ahi donde de pronto donde dijo "Digo" dice "Diego" porque desde dos sitios diferentes se tiene la misma referencia del mismo String (los dos punteros apuntan al mismo valor) y al cambiar los datos en uno se cambia en los dos.

Pués precisamente las Strings en Java son inmutables por lo que justo ése caso no va a pasar nunca.

Respecto al ejemplo, no sé qué querías demostrar ¿que la referencias Java son parecidas a los punteros? ¿quién lo ha negado? Más bien hemos sostenido lo contrario...
There are two major products to come out of Berkeley: LSD & BSD Unix. I don't believe this to be a coincidence.
[ Padre ]


Yo tampoco (none / 0) (#27)
por thuban a las Fri Jul 23rd, 2004 at 08:02:15 PM CET
(Información Usuario)

El mejor momento para liberar la memoria ocupada por algo que no se va usar mas es... el momento en el que se sabe que no se va a usar mas. Cuanto antes mejor.

Y si quieres esperar, si eres tu el que libera, puedes retrasar ese momento. Porque quieres y porque tienes esa opcion. Si no tienes la opcion, te aguantas con lo que te dan.

En el ejemplo lo que queria demostrar es que Java no es tan seguro como se dice por ahi (decir "seguro" cuando se habla de lenguajes es decir "tipado". Por eso Ada es "muy seguro") y que la misma problematica de los punteros salvajes que tienes en C, que lo hacen inseguro e inadecuado para aprender, la tienes en Java, pero sin que nadie te avise... Y ademas no te puedes beneficiar de lo que te dan los punteros.

En el ejemplo, pasa. No se si me he expresado bien, pero en el ejemplo, pasa.

De hecho, la parte de las referencias Java no las tiene bien resueltas. Si pasas un int a una funcion y cambias el valor dentro, al salir vuelves a tener el valor original porque se pasa por valor. Si ese entero esta dentro de otro objeto, el valor ha cambiado porque se ha pasado por valor la referencia del objeto, no el objeto en si. Si piensas en terminos de punteros es perfectamente logico, pero como en Java no hay punteros, alguien que aprenda con Java no puede pensar en terminos de punteros y se lia con ello.

[ Padre ]


Yo me lo invento: punteros trampa (none / 0) (#28)
por man ls a las Fri Jul 23rd, 2004 at 08:45:56 PM CET
(Información Usuario)

la misma problematica de los punteros salvajes que tienes en C, que lo hacen inseguro e inadecuado para aprender, la tienes en Java, pero sin que nadie te avise...
Pero, pero eso es hacer trampa. El pobre GonzoTBA, si no sabe programar, pensará: "oh, entonces es mejor usar punteros". ¡Ni de coña! Lo mismo que tú explicas con punteros, se puede explicar con objetos:
En el ejemplo, pasa. No se si me he expresado bien, pero en el ejemplo, pasa.
Sí, claro que pasa: que estás reusando un objeto donde no debes. Y para muestra un botón:

  // creo un botón de Swing
  JButton boton = new JButton("perico");
  // lo meto en un vector o conjunto de objetos
  Vector vector = new Vector();
  vector.add(boton);
  // ahora cambio el texto del botón
  boton.setText("juanico");
  // adivina el texto del botón en el vector?
  JButton enVector = (JButton)vector.get(0);
  System.out.println(enVector.getText());
> "juanico"
  // pues claro! porque es el mismo botón  
El objeto de dentro del vector lo sigues usando fuera; si lo modificas, en el vector seguirás teniendo el objeto pero modificado. No dudo que mucha gente no lo comprenda: es que la programación orientada a objetos cuesta un poco pillarla.

Y más:
Si pasas un int a una funcion y cambias el valor dentro, al salir vuelves a tener el valor original porque se pasa por valor. Si ese entero esta dentro de otro objeto, el valor ha cambiado porque se ha pasado por valor la referencia del objeto, no el objeto en si.
De nuevo, no hace falta saber ni lo que es pasar por valor, ni por referencia ni nada. Sólo tienes que saber que: los objetos se tratan como objetos, y los tipos primitivos (int, long y tal) no son objetos. Así que no se modifican.

No sé, a mí me parece perfectamente lógico. Hay gente que aboga por eliminar los tipos primitivos y tratar a todos los objetos por igual, y creo que es buena idea (aunque al principio se pierda rendimiento; ya se optimizará). Mientras tanto, se tratan de distinta manera.

Mira que Java tiene sus cosas, y me he hinchado a criticarlas un poco más arriba; pero a mí esta discusión me parece un poco bizantina.

[ Padre ]


Pero si estamos casi online... (none / 0) (#31)
por thuban a las Fri Jul 23rd, 2004 at 09:27:48 PM CET
(Información Usuario)

Pues si es una discusion bizantina, si...

Para mi tambien tienen logica esos errores, pero he mirado libros de Java y en niguno (o casi ninguno, que siempre hay un contra-ejemplo) me han prevenido contra esos errores. En todos me han contado que Java es muy listo y se encarga el de las referencia, de la asignacion de memoria, que ya nos olvidamos de problemas con los punteros salvajes que tiene el C++... Cuando no es verdad. Y lo peor es que ni siquiera se ponian a explicar ese caso de error, igual que no explican lo de los parametros por valor y porque unas veces las cosas cambian y otras no cuando se pasan a una funcion. Con prueba y error se deduce que cuando lo que cambias esta dentro de un objeto se cambia y cuando va por su cuenta y riesgo no. Pero hay que probar, y darse cuenta, porque no se explica para no entrar en contar lo que es un puntero. Y cuando lo entiendes, se explica "como lo de dentro si y lo de fuera no" porque como no sabes lo que es un puntero no lo sabes explicar mejor.

Y tambien pasa con objetos porque en realidad en Java TODOS los objetos son punteros a objetos. No hay objetos estaticos como puedes declarar en C++ o en Pascal ¿con objetos?. Tooooodos se crean con new y se pueden desasignar igualandolos a null. Talmente como si fueran punteros a objeto.


Gonzotba. No estas obligado a usar punteros. De hecho, los punteros dan dolores de cabeza. Pero estan ahi de una forma u otra aunque te los intenten esconder, asi que cuanto mejor comprendas como funcionan, mejor te ira.

[ Padre ]


Me despisté unas horillas (none / 0) (#34)
por man ls a las Sat Jul 24th, 2004 at 02:35:39 AM CET
(Información Usuario)

Pues aclarado. Que conste que yo veo más interesante aprender cómo hacer las cosas con objetos que cómo funcionan los punteros, pero son dos puntos de vista complementarios.

[ Padre ]


 
más sobre basura (none / 0) (#37)
por Draco a las Sun Jul 25th, 2004 at 09:01:09 PM CET
(Información Usuario)

Y si quieres esperar, si eres tu el que libera, puedes retrasar ese momento. Porque quieres y porque tienes esa opcion. Si no tienes la opcion, te aguantas con lo que te dan.

Es muy normal que la decisión de liberar y cuándo sea mejor tomarla en ejecución, y éso pasa por recolectores de basura o "memory pools" lo que implica "desperdiciar memoria" en forma de pedir más de la que necesitas o retrasar su liberación. Si en Java, Lisp o Python tienes un recolector(o varios) de basura, bienvenido sea.

los punteros salvajes que tienes en C, que lo hacen inseguro e inadecuado para aprender, la tienes en Java, pero sin que nadie te avise... Y ademas no te puedes beneficiar de lo que te dan los punteros.

Yo diría que es al revés. Casi todo lo bueno de los punteros y muchos menos riesgos. De todas formas, hay que saber cómo funcionan las referencias, está claro
There are two major products to come out of Berkeley: LSD & BSD Unix. I don't believe this to be a coincidence.
[ Padre ]


 

Aprendiendo a programar | 37 comentarios (37 temáticos, editoriales, 0 ocultos)
Ver: Modo: Orden:
Menu
· crear cuenta
· FAQ
· búsqueda
· Fuentes de Noticias

Login
Nueva cuenta
Usuario:
Contraseña:

ecol Logo Powered by Scoop
Todas las Marcas Registradas y copyrights de esta página son propiedad de sus respectivos dueños.
Los comentarios son propiedad del que los escribe.
Los iconos de las noticias y el logotipo son propiedad de Javier Malonda.
El Resto © 2002 Escomposlinux.org y aledaños.

Puedes sindicar los contenidos de libertonia en formato RSS 1.0 y RDF 0.9. También se puede sindicar la cola de envíos pendientes de moderación.

El proyecto escomposlinux.org está dedicado a la memoria de tas

crear cuenta | faq | búsqueda