|
|
|
Secciones
Este hilo ha sido archivado.
No pueden publicarse nuevos comentarios.
Resumen de la charla sobre Mono ofrecida por Icaza
|
Log in/Crear cuenta
| Top
| 82 comentarios
| Buscar hilo
Y recuerda: Los comentarios que siguen pertenecen a las personas que los han enviado. No somos responsables de los mismos.
Obrar mucho, y hablar poco; que lo demás es de loco.
Barrapunto © 1999-2007. Contenido disponible bajo licencia Creative Commons Reconocimiento 2.5
Aviso legal
Barrapunto © 1999-2007. Contenido disponible bajo licencia Creative Commons Reconocimiento 2.5
Aviso legal
Re:¿Y qué dice del C++? +1 Inspirado
(Puntos:1)( http://julipedia.blogspot.com/ )
The Julipedia [blogspot.com]
Re:¿Y qué dice del C++?
(Puntos:1, Inspirado)Re:¿Y qué dice del C++?
(Puntos:0)esto se merece un +1 por gracioso.
Re:¿Y qué dice del C++?
(Puntos:2)( http://www.flawedcode.org/ )
No.
Esas operaciones no son tarea del SO ni de la MMU. Si lo fueran, difícilmente íbamos a ver cosas como buffer overflows y similares.
Lo que sí es su tarea es gestionar los recursos de hardware, y actuar cuando un proceso intente acceder donde no debe.
Tanto la comprobación de punteros nulos como la de límites de arrays son medidas que tomaron los diseñadores del lenguaje para ayudar a los desarrolladores a capturar errores, y es algo que solamente se hace una vez, nada de esfuerzos duplicados.
En particular, ayudan mucho a rebajar los casos de programas que pueden funcionar bien un día, incluso el 99% de las veces, pero que están mal hechos y en cualquier momento fatídico podrían cascar. Y en especial aumentan la seguridad por defecto de un programa, lo cual no quiere decir que sea completamente seguro, y a un buen programador que además tuviese en cuenta la seguridad esos chequeos no le serian necesarios en alguna ocasiones.
Pero todos sabemos que los buenos programadores no nacen hechos.
Unix have fun [barrapunto.com]
Re:¿Y qué dice del C++?
(Puntos:0)A ti te puede dar igual que un programa salga(o no) tras una excepción tipo IndexOutOfBoundException o NullPointerException en el contexto de la máquina virtual, que por una violación de segmento, pese a las implicaciones se seguridad que conlleva, y las facilidades que ofrece una plataforma para los chequeos y control en tiempo de ejecución respecto a lo anterior. Pero muchos programadores C/C++ han tenido con frecuencia dificultades para aprovechar las más que suficientes comprobaciones que efectúa el sistema operativo, porque las vulnerabilidades por buffer overflows y similares son bastante más frecuentes en lenguajes "no redundantes".
Las estadísticas de sourceforge, donde por cierto el número de proyectos en java es cuantitativamente similar a los "aplastantes" de C o C++, es representativa en su contexto. En el de la realidad empresarial de productos a medida y plazos de entrega se usan lenguajes más productivos si no hay una razón evidente para no hacerlo, y desde luego una mínima mejora en la carga o el tiempo de respuesta de una aplicación de escritorio no suele serlo.
Todos los lenguajes estáticamente compilados, a nativo, supongo que querrás decir, ya han hecho todas sus optimizaciones en ese momento, haciendo suposiciones para optimizar el código si la mejor opción depende en tiempo de ejecución de la entrada. Para determinadas aplicaciones la capacidad de una plataforma con un profiler y un compilador adaptativo que ajuste los cuellos de botella de su código en función de la cadencia de peticiones a un servicio puede ser más perceptible que la sobrecarga que origina, pero supongo que no todos lo han visto.
Las máquinas virtuales más conocidas están escritas en C++, no en C. Por cierto, el bootsec del kernel de linux está escrito en ensamblador, por algo será... (pista: no es porque para todas las aplicaciones sea lo mejor).
Re:¿Y qué dice del C++?
(Puntos:2)( http://barrapunto.com/ )
Lo que tiene uno que escuchar. ¿Porque esta cada vez mas de moda usar recolectores de basura? Una de las principales fuentes de bugs (por no decir la principal) es la gestion de memoria que usa C/C++ (uno se lo gisa uno se lo come) y cualquier programador serio te dira que es imposible librar un programa en C del 100% de los memory leaks (fugas de memoria). Un gestor de memoria como http://www.hpl.hp.com/personal/Hans_Boehm/gc/ promete por lo general la misma velocidad que usar unas funiones malloc/new e incluso si tu programa recolecta mucha memoria para objetos pequeños notaras una mejora de velocidad de ejecucion ya que el recolector no estara como loco cogiendo y liberando objetos (el C esta obligado a hacerlo inmediatamente despues de llamar al malloc/free en lugar).
¿Código seguro que no da cores ni fallos de segmentación?
Me estas comparando una excepcion del Java con un fallo de segmentacion? Te dire la diferencia:
try {
a[12345] = 0;
} catch(Exception e) {
printf("Aqui no ha pasado nada\n");
}
a[0] = 0;
Un fallo de segmentacion te lo comes con patatas.
¿Velocidad?.
En eso estoy de acuerdo contigo, la unica diferencia al final es que unos compiladores optimizan mas el codigo que otros, es decir, la limitacion no es del lenguaje si no de la calidad de compilador (normalmente contra mas tiempo en el mercado mas calidad tiene aunque no necesariamente). Lo que quiere decir que es cuestion de tiempo.
No digo que el C sea una caca de la vaca si no que hay que saber que escoger para segun que tipo de programas. Para que vas a hacer un programa de gestion para una empresa en C? Eso es una locura! Hazlo en Java, C# o incluso en python.
Todos los lenguajes tienen una fecha de caducidad y el C no se libra tampoco. Cada vez van apareciendo mas alternativas, supongo que eso quiere decir algo.
Pa que? Pa cagala?
Re:¿Y qué dice del C++?
(Puntos:1)( http://blog.irreality.eu/ )
Todo esto hace que en la actualidad no tenga mucho sentido gestionar la memoria "a mano" salvo en aplicaciones de tiempo real, e incluso hay trabajos que pretenden acabar con este último feudo de los mallocs/frees.
En resumen, ahora mismo no hay muchos motivos para elegir un lenguaje tipo C/C++ sobre uno tipo Java, salvo si (1) estamos haciendo el kernel de un sistema operativo, (2) trabajamos contra código legacy, (3) queremos presentar un ejecutable pequeñito y nos fastidia tener que distribuir u obligar a bajar la JVM, o (4) simplemente nos gusta más/tenemos más experiencia en ese lenguaje.
La velocidad, desde luego, ha dejado de ser un motivo. Vivan las VM's.
Mi bitácora: Reductio ad Absurdum 2.1 [irreality.eu]
Re:¿Y qué dice del C++?
(Puntos:1)( Última bitácora: Martes, 18 Mayo de 2004, 09:30h )
Hombre, para empezar me gustaria destacar que Icaza no defendió en ningún momento C# ni ningún otro lenguaje, precisamente Mono (bueno, y .NET) se hizo con el objetivo de poder desarrollar APIs en cualquier lenguaje y utilizarlas desde cualquier otro lenguaje, con lo cual permite usar el más apropiado para cada tipo de problema(o el que mejor se te dé).
Respondiendo más directamente a tus puntos, creo que:
Por otro lado, no se porque dices que C# solo funciona a medias en Linux. El compilador de C# de mono funciona para Linux, Mac y incluso Solaris, y que yo sepa en todos ellos igual de bien.
Para acabar solo comentar que a mi tambien me gusta C++ y no tengo ningun inconveniente en que se convierta en lenguaje standard de facto, pero tiene un problema que C# y Java solucionan magistralmente: los strings!! los de la STL son una porqueria, y lo demuestra el hecho de que cada proyecto que conozco se implementa un tipo propio para ellos!!
[OT]: Buffer overflow
(Puntos:1)( http://barrapunto.com/ )
Ahi se te ha ido la olla tio. Si eso fuera cierto no habría ningún fallo de seguridad por desbordamiento de buffer ;).
Si te sales del límite de un array en C o C++ puede que ni siquiera te enteres. No hay excepción por violación de segmento porque sigue accediendo a memoria del proceso.
Lo que ocurre es que las direcciones de retorno de las funciones se encuentran en el mismo segmento de memoria que los buffers (la pila). Si te sales de los límites del buffer puedes sobreescribir esa direccion de retorno y la ejecución del programa se desviará a otro lugar, generalmente la zona del buffer donde está el 'código malicioso'. Si el usuario que ejecuta el proceso tiene privilegios suficientes (root@localhost) puedes conseguir el control total de la máquina remotamente.
Si ese buffer es por ejemplo una imagen de una página web, podría sustituir la verdadera imagen por instrucciones máquina, desviar la ejecución a esa zona y ya lo tienes: ejecución remota de código :) Hace poco corrigieron un fallo de este tipo en la librería png (libpng).
Todo esto en Java y .NET no puede ocurrir porque siempre se chequean los índices porque los buffers están otra zona memoria (el heap). En C++ es fácil de evitar siguiendo unas buenas costumbres de programación. En C es bastante más difícil porque suele ser más incómodo de comprobar y por la mala (e inútil) costumbre de querer optimizarlo todo.
Re:¿Y qué dice del C++?
(Puntos:0)