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)
Sintetizando (none / 0) (#32)
por jorginius ("jorginius" en Google Mail) a las Sat Jul 24th, 2004 at 01:06:20 AM CET
(Información Usuario) http://www.rodriguezmoreno.com

* Si tal y como la escribes la implementación de tu tabla hash en Java no cumple los requisitos cambia la implementación. A lo mejor es que no necesitas un objeto cadena sino un array de caracteres que sea mutable o algo así. El algoritmo puede ser bueno pero la realización no. De todas formas no se me ocurre porque tenía que no marchar en el ejemplo que pones. En el caso de que te quedes sin memoria por las cadenas auxiliares que vas creando, el recolector entrará en acción y en paz.

* No pienso en que es mejor para el mal programador, pienso en que el buen programador en ese escenario al final tendría que programar un esquema de asignación de memoria similar al que usa el GC en el lenguaje con recolector. Usar un Allocator adecuado, si usa contendores STL, que anticipe memoria para más objetos de los necesarios inicialmente y sobrecargar new para construir los objetos en esa zona. La GC no es malvada en según que casos.

* Una referencia de Java sólo sustituye parcialmente a un puntero porque no puede contener más que una dirección válida (o que lo haya sido) o nula, no nos deja modificarla aparte de asignarle otra del mismo tipo ni la expone explicitamente.

* Un lenguaje sin punteros pero con instrucciones tipo PEEK y POKE permiten lo mismo que los punteros de C y no son más puñeteras (lo digo por la comparación que me haces con la OO y ensamblador), salvo quizás porque el compilador de C hace magia y arregla la aritmética de punteros acorde con el tamaño de lo que apuntan (magia que da más problemas que otra cosa cuando por ejemplo intentas comunicar dos procesos en máquinas diferentes o portar tu código a otra máquina/compilador, pero esa es otra historia).

* En Java la única posibilidad de que una referencia apunte a un objeto que no es válido pasa porque el objeto haya pasado al limbo del recolector o le hayamos asignado explícitamente valor nulo. Un puntero de C puede apuntar a un objeto válido, a uno inválido o a cualquier sitio en cualquier momento. La mejora es evidente y la probabilidad de meter la pata por despiste en Java es menor.

* Java no tiene destructores así que no es que no sepas cuando se llaman, es que no se llaman nunca. Finalize es otra cosa distinta y si quieres liberar una conexión a una base de datos en un momento determinado, manda un mensaje entonces antes de que el objeto abandone el ámbito y pase a depender del recolector. Finalize no es para hacer esas cosas y nadie dijo que Java fuera como C++.

* Precisamente C++ es uno de los lenguajes más puñeteros de aprender, con más peculiaridades retorcidas, más formas de hacer las cosas y más puñetitas. Mucho más que C y eso ya es decir. Nunca oirás que "ya he aprendido a programar en C++" porque aprender C++ es un proceso que lleva toda una vida X-). Todo el mundo que conozco y que programa en C++ se restringe a un sub-sub-sub conjunto de lo que es el lenguaje, un subconjunto que suele coincidir bastante con Java por otra parte, sobre todo ahora que han incluido plantillas. Aprender Java primero (y orientación a objetos y una forma "sana" de organizar el código también) creo que es una buena idea para abordar C++ después.

* Para no seguir desbarrando: el padre de este hilo decía que los algoritmos sólo se podían implementar en C por los punteros. La respuesta es que que cualquier algoritmo lo puedes codificar en el lenguaje que quieras, con punteros o sin ellos. De forma más sencilla o más complicada pero los mismos algoritmos con el mismo rendimiento. Que luego corran más o menos dependerá de la máquina, del compilador o de lo listos que seamos, pero el algoritmo es el que es y no hay más que rascar.

Precisamente C es bastante malo para expresar según qué algoritmos: normalmente la expresión de un algoritmo en C suele ser bastante más complicada que la misma en otros lenguajes más "pegados" al dominio (por ejemplo comparar un algoritmo sobre un grafo en Lisp con el mismo algoritmo implementado en C).

* Esta conversación se ha ido de madre. Conmigo no cuentes para continuarla.

[ Padre ]


char[] o StringBuffer (none / 0) (#33)
por jorginius ("jorginius" en Google Mail) a las Sat Jul 24th, 2004 at 01:34:14 AM CET
(Información Usuario) http://www.rodriguezmoreno.com

Si tal y como la escribes la implementación de tu tabla hash en Java no cumple los requisitos cambia la implementación. A lo mejor es que no necesitas un objeto cadena sino un array de caracteres que sea mutable o algo así.

El "algo así" podría ser un StringBuffer. Y ya puestos... Me comí un ":-D" al final del mensaje anterior y sin eso parece como si estuviera rebotado. Vamos, que aunque se salga de madre yo seguiré contestando, me temo :-).

[ 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