#18 España en sí vota a corruptos
Cuanto amor...
#52 Esto no es cierto, C++ tiene ámbitos en los que el compilador tiene más información sobre qué hace el código, por lo que puede generar un código máquina más adecuado.
Por favor, si hay que desprestigiar algo, proporciona datos por lo menos.
#77: Esa es otra, que si quieres usar Krita, te tienes que instalar medio KDE. Es decir, si eres KDEro típico, Krita puede ser de gran interés, sino... pues a lo mejor no te interesa.
#78: Normalmente C es más rápido que C++, por eso se usa en programación de aplicaciones que hacen un uso intensivo del procesador, como vídeo, sistemas operativos...
De todas formas, a veces se hace programación mixta, y unos módulos van en C++ y otros en C.
#45
krita es una parte de un todo mucho mayor que es koffice (bueno, ya no, ahora se llama calligra y es una suite offimatica completa) Krita ha elegido otro camino que es la integración con kde y todo lo que ello conlleva de beneficios... para lo interoperabilidad ya esta openraster. Y gimp se esta quedando muy atras en muchas cosas... mas que nada porque usa gtk que como libreria es una puta mierda... pero de las grandes.
#79 Simplemente eso que dices no es cierto... pero alla tu. Krita no te obliga a instalar más de qt/kde que gimp de gtk/gnome. Yo tengo los dos instalados en mi ordenador y no "sufro" por ello. Si algo usa gtk no me muero, tengo gimp y algún programa mas basado en gtk... aunque la mayoría de mi software es qt (kate, amarok, kmymoney, kspread, krita, calibre, kstars, okular... no me importa tener algún programita por ahi gtk (o con dependencias de este) como luakit o gimp.
#82: Aquí tienes la lista de correo:
http://lists.xcf.berkeley.edu/lists/gimp-developer/
Mira a ver cuántas personas solo han colaborado para enviar solo algunos parches.
Y por cierto, yo he hecho algún scritpt fffuuu de esos y lo he publicado.
#83: El trabajo de los desarrolladores de GIMP actualmente se está centrando en GEGL, por eso parece que el programa no avanza, pero en el fondo, si que avanza, pero por debajo.
#55, las mejoras de C++ son meramente sintácticas. La orientación a objetos puede implementarse en C perfectamente.
#59, los objetos SON redundantes. Modelar una aplicación en forma de objetos no requiere un lenguaje orientado a objetos. Y si me hablas de que bajo el mismo programador poco hábil, un lenguaje produce un código más óptimo que otro lenguaje, eso realmente no es un argumento.
#68, a ver, es obvio que si utilizo el gcc y el g++ para compilar el mismo archivo las diferencias van a ser miserables (quizá g++ incluya algún extraño thunk con impacto nulo en un código bastante trabajoso). Y sobre lo que dices, a ver, está claro que depende del programador. Pero también está claro que cada lenguaje tiene sus tendencias y sus formas. Si usas C++ es porque vas a usar objetos. Y es aquí donde se debe establecer la comparativa con C.
#69, no son el mismo proyecto. C tiene un estándar, C++ tiene otro y objective-C tiene otro distinto. Y a ver, también he de dejar claro por qué defiendo C a ultranza. C++ es un lenguaje con el que no me meto si lo más duro que vas a hacer va a ser la mítica aplicación gráfica de usuario que manipula representaciones de elementos del mundo real. Te rompes menos la cabeza. Sin embargo, yo he tenido que programar mis rollos desde el más puro bajo nivel hasta la más abstracta interfaz gráfica (no es que haya programado tampoco demasiado, pero sí en muy diversos ámbitos). He usado GTK (aún cuando Qt seguramente tenga bindings para C) el cual, pese a ser tradicionalmente en C incorpora una orientación a objetos. Y el hecho de que C pueda usarlo a tantos niveles con la misma facilidad me parece realmente atractivo.
#78, explícame eso de los ámbitos. Yo he tenido que desensamblar binarios en C y C++, y estos últimos incorporan una cantidad ingente de basura que lo último en lo que te hacen pensar es en un compilador con mucha información.
Veréis, y así quizá os responda a todos, mi problema con C++ es doble. El primero es que la abstracción a objetos no requiere una nueva sintaxis en C. De hecho, quizá algo que me parece bastante desagradable de muchos de los proyectos en C++ que he visto por ahí es la sobreabstracción de algunos elementos sacrificando una eficiencia que puede llegar a ser importante. El segundo es todo el código de apoyo que tiene que generar para mantener todas esas abstracciones, que lo aleja más de su estructura una vez compilado. Quizá lo que más miedo me da es el operador "new". ¿Cómo funciona? ¿Necesita paginación para funcionar? ¿Dónde reserva? ¿Puedo tocar sus estructuras internas? ¿Y qué pasa con malloc? Tengo un operador que hace cosas muy complicadas con la memoria, cuando eso es algo que normalmente se deja a la merced una función. Los operadores deberían hacer operaciones atómicas, o casi atómicas. Si esto fuese como Java quizá no me escandalizaría tanto, pues la memoria es una caja negra que la VM sabe cómo manejar.
Quizá sea un anticuado y tenga la cabeza cuadriculada, pero a mí tantas abstracciones a tan diversos niveles en el mismo lenguaje me asustan.
#86 el presidente del club de adoradores de std::vector te saluda
#c-87" class="content-link" style="color: rgb(227, 86, 20)" data-toggle="popover" data-popover-type="comment" data-popover-url="/tooltip/comment/1348650/order/87">#87
#define DECLARE_VECTOR_TYPE(type, name) \
typedef struct \
\
name ## _vector;
Y así con las funciones que manejan cada tipo de vector.
¿Decías?
#95 pues a eso iba, con lo bonito que es mi querido vector para que voy a andar haciendo yo el trabajo sucio. Por cierto que no es la api de c++, es que yo puedo declarar vectores de cualquier clase propia.
#86 las mejoras de C++ son meramente sintácticas. La orientación a objetos puede implementarse en C perfectamente.
Yo he vivido eso, un proyecto modelado con POO e implementado en C, y te aseguro que no es lo mismo, es un jodido dolor de cabeza, asi que por favor, sobre el papel esta todo muy bonito pero en la practica existe C++ y es por una razón.
#91 Pues has dicho C siempre, que no es lo mismo que un framework hecho con C para un fin muy concreto, ya que no es igual desarrollar una aplicacion que una herramienta.
#94, lo que hace GTK es poco importante. GTK dispone de herencia, relaciones, sobrecarga de métodos (aunque admito que esto ya es un poco trampa) y bueno, casi todo lo que la POO define.
#96, coño, y yo con mi implementación puedo hacer vectores con los tipos que quiera. Desde enteros, floats y chars hasta structs y enums (incluyendo los correspondientes punteros)... estamos en lo mismo, una plantilla que puede funcionar con cualquier tipo.
Por cierto, antes de seguir, estoy empezando a sentirme realmente mal. Después de "envía un comentario" me pone "porque alguien en Internet está equivocado". ¿Esto es un rollo automático o siempre aparece? 
#86 Entiendo perfectamente tus reservas. Yo he sido durante muchos años programador de ASM y al pasar a C tuve resistencias similares, las tuve también de C a C++, de hecho, las mismas o muy parecidas a las tuyas.
Mira, tienes razón en que todo lo que hace C++ se puede implementar en C (de hecho, en ASM también), pero cuando ves la gran diferencia es cuando trabajas en un proyecto con muchos programadores (sin llegar a cientos, que también).
A uno, programando solo, le puede parecer irrelevante declarar los miembros de una clase como public, private o protected, por poner un ejemplo sencillo, y eso solo se puede hacer en C++. Ciertamente el código generado no varía, pero cuando meten mano a un repositorio muchos programadores, un proyecto C es muy dificil de mantener (uno en ASM, aún peor). Sin embargo, esos detalles aparentemente irrelevantes como declarar correctamente los private de una clase ayudan a mantener un cierto orden dentro del caos que a la larga, ahorra muchísimos bugs. La abstracción (muchas veces con tendencia a la sobre-abstracción, como bien dices), también simplifican mucho la programación entre muchas personas, al hacer clases que son autonómas por si mismas y mucho más fáciles de mantener.
En mi experiencia, cuanta más gente mete mano en el código, más se aprecian las virtudes del C++, que no son efectivamente en pro de una mayor velocidad de ejecución si no de una mayor robusted y/o modularidad. Más sencilllo de mantener, en definitiva.
Las herencias son una herramienta muy potente de C++ que si bien pueden implementarse en C, son un poco follón de hacer. Abusando o mal implementando pueden ser horribles, pero bien usadas ahorran una barbaridad de trabajo y el código no tiene por qué perder eficicencia. Creo que la mayoría de los programadores de C abrazan definitivamente el C++ cuando aprenden a usar bien las herencias y descubren la potencia de utilizar las clases de una forma abstracta. Pensar "en C++" no es lo mismo que pensar "en C". Cuando un programador ASM empieza a programar en C, se nota, hace C al estilo ASM. Lo mismo cuando un programador de C pasa a C++, tarda un tiempo en apreciarlo y sacarle jugo (más si va con prejucios).
En cuanto a las redefiniciones caóticas de operadores como new, u otros operadores, el abuso es un vicio en C++ que debe evitarse o manejarse con precaución. En principio, el operador new estándar no tiene mucho misterio, es un malloc o bien un alojamiento en el stack de los datos de una clase y posterior llamada al constructor. Puedes ver el código en el runtime estándar o puedes desensamblarlo.
Yo que no tengo ningún prejucio a priori con ningún lenguaje (en el mismo proyecto puedo usar ASM, C, C++, PHP y Bash Script, por decirte algo), te animaría a que te acercases al C++ con la mente abierta, y descubras las grandes ventajas que tiene. Hay por ahí un libro, "Think in C++", que te recomiendo encarecidamente. Un saludo.
#86 menuda sarta de disparates estas diciendo.
Para empezar, C++ tiene genéricos, que no es lo mismo que un puntero void. Ya que los genéricos, el compilador se encarga de detectar posibles errores en tiempo de compilación. Y posiblemente este es uno de los puntos mas fuertes de C++ enfocada a la meta programación. http://codeando.blogspot.com/2006/11/metaprogramacin-por-medio-de-templates.html
Luego tenemos, las múltiples cosas que nos ofrece el paradigma orientado a objetos. Como la herencia, la ligadura dinámica, clases abstractas, etc... mírate la teoría de la orientación a objetos. Que es muchísimo mas que simples clases y objetos.
Pero vamos, por ti seguiríamos programando en ensamblador de 8086.
Por cierto, vete mirando una cosa llamada Scala. Buen lenguaje.
#110, pero es que yo puedo hacer una plantilla con macros. De hecho, muchos de mis programas utilizan plantillas basadas en macros.
De ser por mí, utilizaría un lenguaje cuya sintaxis se pudiese definir dentro del propio lenguaje (sin necesidad de una máquina virtual o algo así). Y C no hace eso, pero tiene sus trucos. No sé, hasta el momento C++ no me ha enseñado nada que no pueda hacer con C con mayor control.
He mirado Scala y tiene buena pinta (lo de mezclar programación funcional con objetos es muy atractivo), lo que es una lástima es que corra bajo una máquina virtual de Java. Quizá chapucee un poco con él un día de estos.
#117, esto es absurdo. Hay bibliotecas que implementan una orientación a objetos en C y se usan con bastante éxito. Hay bibliotecas para el manejo de cadenas, vectores, listas y cualquier estructura que te venga a la cabeza en C que ríete tú de lo que proporciona C++. No es que yo quiera implementarlas desde cero, es que ya están implementadas aunque no como la biblioteca estándar de C. C++ puede tener una biblioteca estándar amplísima, pero eso no es más que utilería escrita para el lenguaje.
Y bueno, lo de aplicaciones medianamente grandes es un ejemplo nefasto. Gimp está en C. Linux está en C (cuando podría estar en objective-C como NeXT o C++ como el kernel de Liedtke). Gnome está mayoritariamente en C (cuando existen bindings a muchísimos lenguajes orientados a objetos). Aplicaciones de Windows en C ya se me escapan un poco porque no suelo usarlo, pero seguro que hay algunas cuantas.
Todo es cuestión de la calidad de las abstracciones que uses.
#114, me prometí aprender LISP este verano, pero al final entre pitos y flautas no hice nada. Llevo con la promesa de LISP varios años ya, pff.
#118 Si tienes que recurrir en librerías externas para hacer lo mismo que C++ ¿eso no es redundante?
Linux está C porque cuando se empezó a programar, se hizo en C (observese que Linux viene de Minix). Gnome está en C porque cuando se empezó a desarrollar C++ no estaba suficiente establecido aún...
Si, la mayor parte de proyectos grandes que me puedas mencionar están hechos en C, pero no precisamente porque C sea más rápido, si no porque (al menos entonces) la base de programadores de C es más grande que la de C++. También influye el que inicia el proyecto qué lenguaje domina (pregúntales a los que mantienen el aMSN si dejarían de usar tcl/tk a pesar de que hay lenguajes que le ganan por goleada en más de un sentido).
Además, la discusión es un poco absurda. En el peor de los casos con C++ puedo hacer exactamente lo mismo que con C. Con C también puedo llegar a hacer lo mismo que C++... pero tengo que programarlo. Y hacer una librería para que C tenga de manera "artificial" lo que me proporciona C++ y que además lo supere en rendimiento... no es moco de pavo.
Insisto en lo mismo, que un código en C++ que haga lo mismo que otro en C obtenga un rendimiento inferior, habla más de la capacidad del programador que del lenguaje. Porque insisto en lo mismo, el mismo código en C (con ligerísimas modificaciones) me compila en C++. Así que utilizando las ventajas que cada lenguaje me proporciona, y configurando el compilador de forma adecuada, difícilmente notaré diferencias de rendimiento entre un lenguaje y otro. A no ser, claro está, que se abuse de la abstracción, como también han comentado anteriormente.
#119, es todo lo contrario a redundante. Redundante es cuando hago parte del lenguaje algo que ya puedo hacer con bibliotecas externas.
Linux está en C porque se decidió hacer en C. Linux no está basado en Minix. Está inspirado en Minix, pero está muy lejos de estar basado en él. No comparten código.
Gnome se empezó a desarrollar a finales de los noventa. Y en cualquier caso, esto no es lo importante del debate.
A ver, la comparativa no tiene sentido en lo que ambos lenguajes comparten porque en ambos es lo mismo. La comparativa debe hacerse con lo que un lenguaje proporciona y el otro no. Por eso mencioné el operador new (lo que yo dije, ejemplo de redundancia), los vectores o las cadenas. ¿Puede hacerse una biblioteca de tratamiento de cadenas en C más o menos eficiente que la de C++? ¿"Crear instancia" necesita un operador propio? Etc, etc.
Por cierto, este flame está siendo un canteo ya. ¿No podemos seguir por el IRC o algo así?
#120 new no es en absoluto redundante: new llama al constructor en su caso, malloc no. También podríamos entrar al debate de si los constructores de C++ son prescindibles o no. Pero tanto en C++ como C tendrás una porción de código (función o método), que establezca el código a un estado inicial.
De todas formas, no voy a seguir más con el debate, porque está claro que hablaríamos mil años sobre el mismo tema y no llegaríamos a un acuerdo y tengo el arroz en el fuego...
#113 Sin ánimo de ofender... Dudo mucho de tu profesionalidad cuando presupones que con macros obtienes lo mismo que con templates de C++.
Si bien es cierto que la implementación de templates de C++ no es una solución muy limpia por el diseño del lenguaje (medio nivel, fuertemente tipado, no basado en objetos, etc, etc..), las posibilidades y la calidad del resultado dista mucho de lo que puedas hacer con macros.
Es bastante habitual que uno se crea que está escribiendo código más rápido simplemente por usar un lenguaje de más bajo nivel, pero en la realidad casi siempre es lo contrario. Por ejemplo, la mayoría de la gente se preocupa por estupideces como el coste de la llamada a una función (que en C++ requiere niveles de indirección adicionales frente a C) y deja de lado aspectos realmente importantes como el coste de la creación, destrucción y acceso a memoria.
Con estas premisas viene uno de estos, lo programa en C, se crea sus propias estructuras de datos y obtiene una implementación más lenta que otro con un nivel de conocimiento similar que lo hizo en C++ con STL directamente. Además, (el primero) con mayor probabilidad de contener bugs, leaks y que el código sea complicado o directamente imposible de mantener.
Ahora viene un tercero, lo implementa en Java en la menos de la mitad de tiempo y se ríe de los otros dos porque la diferencia de rendimiento resulta inapreciable.
#86 Decir que la orientación a objetos es "redundante" es gritar al cielo que no has programado nada de más de 1000 lineas e C.
Como han dicho ya en un comentario anterior, a día de hoy C es un subconjunto de C++. Es decir, ciertamente puedes hacer igual los programas que haces con C++ con lo que hay en C, pero renuncias a las facilidades que te da C++.
Es como si me dices que al pueblo de al lado puedo ir en bicicleta o en coche. La diferencia de tiempo es despreciable y en cambio me ahorro el combustible, el seguro, el mantenimiento abusivamente más caro del coche... y te daría la razón. El problema vendría cuando en lugar de ir al pueblo de al lado, quiera hacer un trayecto Madrid-Barcelona. Y el problema es cuando has visto el pueblo de al lado, luego quieres ver otros pueblos. Cuanto más viajas, más te interesa el coche.
Cierto es que se pueden implementar las características de C++ con C (los primeros compiladores de C++ se escribían en C). Pero es como si me dijeses que si a tu bicicleta le pusieses 2 ruedas más, un motor, frenos de disco, un volante con dirección asistida... haría lo mismo que el coche. Aunque claro, entonces la pregunta que te haría yo ¿vas a hacer el coche desde 0 solo pq no te interesa que el coche lleve elevalunas eléctrico?
En fín, por no alargar más esta explicación, pregúntale a alguien que tenga que hacer un programa medianamente grande (y GIMP por ejemplo lo sería), si lo haría con C o C++. Solo por la gestión de las cadenas en C++, ya vale la pena...
#78 en video el rey sin discusión es Nuke (C++) y en renderizado (uso hiperintensivo) lo son MentalRay en produciones serias (C++) y Vray en temas más pequeños (C++)
Eso os pasa por confiar en software privativo.
Es lo que tiene, es la solución fácil usarlo, pero te tienen agarrado por los huevos, sobretodo en el caso que es gratis y tal.
Eso de decir 1000 milisievert es porque 1 sievert parece poco?
#2 no, es porque hasta ahora todas las medidas se han dado en milisieverts y me parecia mas facil de comparar. Ademas ese es el titulo original de la noticia en ingles.
Para entenderla mejor: http://dilbert.com/strips/comic/2011-02-23/
El público aclama: "Matrix es una y no 51!!"
http://digitizor.com/2010/04/06/spokify-a-kde-client-for-spotify-is-finally-coming-video/
ya teníamos de esto. El problema sigue siendo que hay que ser premium para usar clientes en linux
#9 esta notación sigue funcionando. Simplemente no se ha decidido crear una rama de desarrollo llamada 2.7 porque se está dejando madurar el kernel en 2.6
#4 #17 La regla no escrita de versiones pares = estables, impares = desarrollo, ya no se sigue.
El kernel no se está "madurando", se están incorporando todas las novedades en la rama 2.6. En lugar de hacer largos ciclos de desarrollo de años, ahora Linus abre ventanas de incorporación de código nuevo (1-2 semanas) para que en ese tiempo se añadan las novedades, y en los siguientes 3 meses se van puliendo las regresiones. Ya no hay concepto de "versión inestable".
Por cierto, los editores deben ser preclaros, porque ni Linus ha mencionado que vaya a haber una 2.8
Está mal traducido. DiBona dice que "no cree que sea más fork que el de RedHat", no que "no es un fork como RedHat"
¿Estados Unidos premia?
el título está mal
#49 Recuerde: Una mujer da a luz en 9 meses pero 9 mujeres no dan a luz en 1 mes
De media si
#51 Nombre del proyecto: Niño
tiempo de ejecución: 1 mes
Recursos: 9 mujeres fértiles
multa por mes de retraso XXXXXXXXXXXXXXXXXXXX mil
fíate tu de las medias
mujer 1 - 9 meses
mujer 2 - 9 meses
mujer 3 - 8 meses
mujer N - 9 meses
media = 9 meses
La tasa de mortalidad no es 100%?
debe ser la única forma de que no nos carguemos el planeta, que se lo cargue otro.
¿Es este el mismo que bendecía los bombarderos que mandaban a barcelona?
#13 ¿Mejor invertir en la antigua, que seguro que no lo será?