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)
Depende de lo que busques (none / 0) (#19)
por thuban a las Fri Jul 23rd, 2004 at 12:46:19 PM CET
(Información Usuario)

Si no le encuentras sentido a la eficiencia, pues enhorabuena. Vives en un mundo de recursos ilimitados. Pero para los que nos preocupamos por la eficiencia, es absurdo usar un lenguaje en el que no controlas cuando se libera la memoria. ¿Y si el GC tarda en entrar? La memoria se queda ocupada. Simplemente.

¿Seguridad? Pues si, el java es muy seguro porque si no te deja hacer nada donde puedas meter la pata no metes la pata. Por el camino te pierdes el control sobre TU programa. Pero eso si, es seguro. Ahora, ¿no es un poco triste que el diseñador del lenguaje reduzca tus posibilidades para que no puedas meter la pata? ¿No te jode que un tipo desde un despacho decida que eres un torpe? O que decida que si le pasas un entero a una funcion te vas a equivocar si le cambias el valor dentro y no te deje pasarlo por referencia (¿no te joden los p**tos IntHelper cuando programas con Corba?).

Yo prefiero un lenguaje que me deje hacer todo lo que pueda hacer el ordenador y encargarme yo de *programar* las devoluciones de memoria, las comprobaciones... No se trata de volver al ensamblador, pero tampoco de limitarse a lo que un teorico ha decidido que es un "paradigma de programacion".

En Java se pueden hacer muchas cosas y es un lenguaje cojonudo. Pero para aprender a programar algoritmos o para hacer cualquier cosa en la que la eficiencia sea importante, hay mejores opciones.

Y ni siquiera se puede decir que el Java libre de los errores debidos a los punteros salvajes. Si no eres cuidadoso la cagas igual. Como en Java todo es muy facil y no hay punteros, en pocos manuales se distingue entre la referencia y el valor apuntado por la referencia, por ejemplo, en los String. 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.

Como nadie distingue entre puntero y valor, los que no tienen el concepto del puntero no ven problemas en este codigo:
import java.util.*;

class Prueba {
  public String nombre;
  
  Prueba( String nom) {
    nombre = nom;
  }
  
  public static void main( String args[]) {
    Vector vec = new Vector();
    
    Prueba p = new Prueba( "Digo");
    vec.add( p);

    p.nombre = "Diego";
    
    Prueba g = (Prueba)vec.elementAt( 0);
    System.out.println( g.nombre);
  }
}
(Para los que no lo ejecuten, el programa escribe "Diego" aunque muestra el valor recien sacado del vector, que se metio diciendo "Digo". Mucha gente piensa que el valor dentro del Vector esta a salvo de modificaciones y se dan cuenta cuando su vector con 32324 objetos tiene valores incorrectos)

Pero los que saben lo que es un puntero se dan cuenta de que lo correcto es hacer:

p = new Prueba( "Diego"); //p.nombre = "Diego";

Alguien que empieza a programar no necesita lidiar estos problemas sin que nadie le explique porque ocurren, y no te imaginas la cantidad de veces que he tenido que explicar esto a gente que se habia tirado de los pelos delante del monitor sin comprender porque todos los objetos de su vector tenian el mismo valor.

Porque nadie espera que eso pase en Java porque es seguro.

Y la diferencia en la velocidad de comprension entre alguien que habia programado en C o Pascal y sabia lo que es un puntero y entre alguien que habia aprendido a programar en Java sin necesitar punteros se mide en cuartos de hora...

Si los punteros existen y estan ahi agazapados dandote por culo, al menos que te cuenten lo que son. Y si estan ahi, ya seria un gesto que te permitan aprovecharte de ellos si quieres...

Y en cuanto a lo de pasar metodos a las funciones, yo ni entro ni salgo en si tiene sentido pasar funciones como parametros. De hecho, pocas veces he tenido que hacerlo. Yo solo digo que se puede y donde puede leer como se hace. Y es una chapuza porque es lento. Yo hablo de ejecutar un metodo donde sea y tu hablas de pasarle una funcion a un algoritmo generico, que si las clases estan diseñadas como es debido no tiene sentido porque, como bien dices, se pasa dentro del objeto y no es una chapuza porque forma parte de la gracia de la POO. Hablamos de cosas diferentes.

[ Padre ]


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 ]


 
La eficiencia (none / 0) (#22)
por jorginius ("jorginius" en Google Mail) a las Fri Jul 23rd, 2004 at 04:33:14 PM CET
(Información Usuario) http://www.rodriguezmoreno.com

Pero para los que nos preocupamos por la eficiencia, es absurdo usar un lenguaje en el que no controlas cuando se libera la memoria. ¿Y si el GC tarda en entrar? La memoria se queda ocupada. Simplemente.

¿Lo qué?, tu comentario anterior se refería a los algoritmos y la eficiencia de un algoritmo no tiene nada que ver con el recolector o que lo implementes con tal o pascual lenguaje, con o sin recolector... Como si quieres "implementarlo" con un lapiz, papel y un ábaco. La eficiencia es la misma la midas respecto a lo que la midas. ¿De qué estamos hablando?, ¿de algoritmos? ¿de código?, ¿de qué?

De todas formas, por seguir un poco el tema, el recolector tiene sus cosas buenas y sus cosas malas: la parte positiva es, aparte de la comodidad que aporta, que suele ser más eficiente que un mal programador: si éste se dedica a crear unos cuantos miles de objetos pequeños en el heap (como cadenas de caracteres o nodos de un árbol n-binario o AVL, por ejemplo) y reserva memoria por cada uno, el recolector hará un trabajo mucho mejor que él "de serie".

Y buceando un poco en los detalles, es cierto que con GC se reserva más memoria en el heap pero el sistema operativo no asigna realmente todos esos marcos hasta que la aplicación los use, y el GC ya se dará prisa en liberar recursos si escasea la memoria, así que tampoco es tanto el despilfarro.

La parte más negativa es que al no saber cuando entra el recolector, estás pillado si tienes restricciones temporales (que poco o nada tiene que ver con la eficiencia). De todas formas, existen extensiones de Java para tiempo real. Nunca las he usado y no sé como manejan el problema del GC no determinista.

¿Seguridad? Pues si, el java es muy seguro porque si no te deja hacer nada donde puedas meter la pata no metes la pata. Por el camino te pierdes el control sobre TU programa.

Bueno, si quieres meter la pata con Java aún puedes. Java te evita algunos despistes, simplifica algunas cosas que hacen más fácil que varios programadores "se entiendan" (al no haber tantas posibilidades para hacer lo mismo, la codificación de varias personas resulta semejante) y refuerza algunos hábitos buenos de programación.

Además, supongo que desde C no se ve así pero en verdad Java no es demasiado rígido. Desde luego no llega al nivel de "cuadriculación" de otros lenguajes como Ada.

A mí Java me deja frío. En realidad no he programado mucho con él: he hecho mis pinitos con el J2ME, applets y algo de programación de escritorio con gráficos junto con JDBC. Tampoco es el lenguaje que escogería para hacer programación de sistemas ni para expresar mi "vena artística" X-) pero me parece un lenguaje muy válido para "hacer programas" (que no tiene porque ser igual que "programar" :-)) y hay buenas y baratas herramientas por ahí fuera para trabajar con él. Es más adorable que otros que conozco, sin duda.

Pero los que saben lo que es un puntero se dan cuenta de que lo correcto es...

... Primero saber que quieren hacer, segundo tener claros los conceptos de qué es una referencia y que es un objeto segundo y tercero leerse la documentación del contenedor. Eso sería lo correcto, supongo :-).

Si los punteros existen y estan ahi agazapados dandote por culo, al menos que te cuenten lo que son. Y si estan ahi, ya seria un gesto que te permitan aprovecharte de ellos si quieres...

Tanto como que existen... Un puntero de C o Pascal no es más que un entero con un montón de azucar sintáctico por encima. Donde realmente hay algo que entender no es ahí, sino en el código ensamblador que genera el compilador y en cómo funciona la máquina que hay por debajo (sea real o virtual). En cualquier lenguaje que tenga instrucciones para leer/escribir en direcciones (aunque éstas se llaman PEEK y POKE X-) puedes hacer lo mismo, aunque no haya nada explicitamente llamado puntero.

Y en cuanto a lo de pasar metodos a las funciones, yo ni entro ni salgo en si tiene sentido pasar funciones como parametros.

Funciones como parámetros sí, tiene mucho sentido y es de lo más habitual. En la biblioteca estandar de C tienes ejemplos y la parte de algoritmos de la biblioteca estandar de C++ le saca mucho partido. El tema está en que los métodos pertenecen a un objeto y en teoría no tiene sentido hablar de pasar un método solo sin pasar el objeto al que pertenece. Una clase functor es lo más apropiado en un lenguaje OO.

[ Padre ]


El GC y el tiempo real (y 2. El bueno) (none / 0) (#24)
por ridiculum a las Fri Jul 23rd, 2004 at 06:16:13 PM CET
(Información Usuario)

El otro comentario no tiene un forma decente, este se lee mejor.

Se supone que los sistemas de tiempo real esta terminantemente prohibido el empleo de recolectores de basura por el indeterminismo que introducen, asi que la solucion que ofrence la RTSJ (Real Time Specification for Java) es algo similar al mlock que hay en POSIX.
Haciendo un cut && paste:

The main issue with Java derives from its foundation in object-oriented programming. The problem isn't so much with efficiency--the overhead of dynamic binding needn't be more than an extra level of indirection on the method call--but rather with the apparent unpredictability or latency incurred by garbage collection. The approach taken in the RTSJ is to allow the program to define memory areas that aren't subject to garbage collection and to define certain kinds of threads that aren't allowed to access the garbage-collected heap; such threads may preempt the garbage collector

Respecto a Ada, mejor no comentar nada, que me saldrian demasiados exabruptos :P

[ Padre ]


 
Re: La eficiencia (none / 0) (#30)
por thuban a las Fri Jul 23rd, 2004 at 09:09:26 PM CET
(Información Usuario)

Pues si tiene relacion. Es absurdo enredarse con los algoritmos si toda la memoria que puedas ahorrar machacandote para reducir las colisiones de una funcion hash y asi poder tener una zona de colisiones mas pequeña en el array, se van a perder porque por otro lado te dejas sin liberar la memoria de un auxString que creas en el interior del bucle que rellena la tabla. No merece la pena el esfuerzo. (Y si quieres una Hashtable con tratamiento decente de colisiones te la tienes que hacer tu)

Y el problema es que estas pensando en un mal programador. Como el programador es malo hacemos el trabajo por el. No le dejamos liberar memoria, ni le damos punteros... ¿No seria mejor convertir al mal programador en buen programador? Hacerle responsable de su codigo y explicarle que tiene que soltar lo que coje. Especialmente cuando aprende, como quiere hacer Gonzotba.

Y en cuanto a la seguridad del Java... Pues si, es seguro porque se supone que un lenguaje tipado y sin punteros reduce errores de programadores poco cuidadosos (otra vez) y por tanto es seguro. Pero mal codigo es mal codigo. Y despistes se pueden tener igual como en el ejemplo que he puesto (visto en el mundo real, con mas lineas por medio). Si java no me proteje de los dolores de cabeza que dan los punteros salvajes ¿que gano con no tener punteros? Peos aun. Si tengo el problema de los punteros, ¿por que nadie me cuenta que tengo el problema de los punteros?

Yo programo con java desde la version 1.0 del lenguaje, y aunque me gusta, y mucho, no me parece que sea un lenguaje para aprender a programar ni para meterse a hacer con el ciertas cosas (como arbolesB). Para eso esta el C++ o un Modula2, un lenguaje que tenga de todo y que no aisle al que aprende de la problematica de la programacion. Si no se aprende al principio, ¿cuando?

Los punteros existen aunque en Java se llaman referencias. Y eso de que cualquier lenguaje con PEEK y POKE los tiene... Pues si. Supongo que tambien se puede hacer programacion orientada a objetos en ensamblador, pero que se busquen a otro que yo me tengo que lavar el pelo...

El java no es adecuado para aprender porque pierdes todo lo que puedas aprender de punteros, la sobrecarga de operadores, la utilidad de los destructores... Menos los operadores, lo demas se puede poner en java, de acuerdo, pero ¿sirve para algo el metodo finalize? ¿Es util un destructor que no sabes cuando se lanza? ¿Puedes confiar en el para liberar una conexion a una base de datos? Con o sin pool, el problema es el mismo.

Es mas facil aprender en C++ y olvidar cosas segun el lenguaje en el que aterrices que aprender en Java y tener que aprender sobre la marcha y con prisas lo que no sabias porque java no daba.


[ Padre ]


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