cultura y tecnología
112 meneos
1500 clics
C++ para el Siglo XXI [EN]

C++ para el Siglo XXI [EN]

Han pasado más de 45 años desde que se concibió por primera vez C++. Como estaba previsto, evolucionó para afrontar los desafíos, pero muchos desarrolladores utilizan C++ como si todavía estuviéramos en el milenio anterior. Esto no es óptimo desde la perspectiva de la facilidad para expresar ideas, el rendimiento, la fiabilidad y la capacidad de mantenimiento. Aquí presento los conceptos clave sobre los que se puede construir un software C++ de alto rendimiento, de tipado seguro y flexible: gestión de recursos, del ciclo de vida, errores...

| etiquetas: bjarne stroustrup , c++ , programación
C++ para el Siglo XXI -> Rust
#6 Un lenguaje con recolector de basura dudo mucho que pueda tildarse como el C++ de Siglo XXI.
#10 BoehmGC funciona. Y el siglo XXI tiene una E/S muy superior y esta hecha para el multiproceso, el IOMMU permite virguerias.
En un single core lo entenderia. Hoy cualquier SO decente deberia poder obligar a ejecutar procesos o hilos por nucleo de forma exclusiva.
Los de plan9/9ftont estan haciendo locuras con el kernel nix. CSP? No he mirado, pero es una bestia ejecutando concurrentemente.
Las mainframes admitian reemplazar modulos en caliente. Pues hoy usar una GC no deberia ser ni problema. Si a los de C# les va...
No podemos pensar en los SO de hoy como si fueran monotarea. Eso esta muerto.
#26 Si, mucho de aquí y de allá. Ponte como quieras, los cores, los hilos y toda la cancamusa que tengas que si tienes GC siempre habrá un momento en el que entrará en funcionamiento y habrá un bajón de rendimiento. Podrá ser pequeño, o no, pero es algo que un lenguaje sin GC nunca va a tener.
#27 cancamusa, no. Hecha un ojo a Nix.
Como concepto light, taskset, pero lo de dedicar un core en exclusiva no lo tiene GNU por hoy.
#6 JS !!! :shit:

Ya cierro al salir :troll:
#1 Rust no tiene orientación a objetos. La comparación sería con C, no con C++
#11 Pero tiene interfaces.
#19 Ya, y qué ?

Sigue sin ser lo más apropiado para implementar un modelo diseñado mediante orientación a objetos. C++ es mucho mejor para eso.

Rust puede sustituir a C, no a C++
#21 Rust difícilmente puede sustituir a C cuando:
- No es tan portable como C.
- Sus abstracciones que hacen que sea "memory-safe" tienen coste computacional.

Dicho esto, me encanta Rust para el backend y es lo que usamos en el día a día. Pero para cosas como un sistema operativo, un videojuego, máquinas virtuales etc, no creo que lo vaya a sustituir o que sea lo más indicado.
#34 ¿Por qué dices que no es tan portable como C?

En el kernel de Linux ya hay código Rust.
#34 Las abstracciones de Rust para que sea memory-safe, hasta donde yo se, se resuelven en tiempo de compilación y no deberían afectar al rendimiento.
#34 Las «abstracciones que hacen que sea "memory-safe"» no tienen coste computacional.
#11 Revisa structs, impl y traits, y/o el Patrón de Objeto Revelador
#11 los acabará teniendo implementados malamente como otras castañas d lenguajes milagrosos tipo JavaScript o Python.
#41 Python no es ninguna castaña y tiene una buena orientación a objetos. Cada cosa para lo suyo.

Me llama la atención la de Python haters que hay, cuando es de lejos el lenguaje que más ha democratizado la programación entre la gente que no tiene un título de informática, de Telecos o de Físicas bajo el brazo. Y oye, si quieres rendimiento extremo, pues programas un módulo en C/C++ o Rust y luego Python es tu interfaz "fácil" para llamar a eso.
#76 te doy la razón que me he pasado ocho pueblos al meter a Python en la misma cesta que JavaScript.

Solo era por lanzar el flame.
#1 No es igual, en Rust toda abstracción tiene que mantener el tipado fuerte. En C++ la máxima es "no cost abstractions".
#20 Es "zero cost abstractions", y es una máxima tanto de C++ como de Rust.
#7 X11 sigue vigente.

Y funciona muy bien.
#12 De hecho, todo lo que ha mencionado. Ni a propósito.
#22 C++ es una programación cercana al hardware....... o no.

Si quieres lo es. Si no quieres, no lo es.
#23 es lo que he dicho
#23 Al menos es binario.
#57 Muy discutible "buena práctica".
Es muy habitual tener bucles infinitos (como podría ser el bucle principal de una aplicación, juego o simulación. Y dentro de ese bucle se procesan multiples mensajes que son costosos de evaluar, y por ello se evalúan de menos costoso a más costoso y diferentes casos consecutivos dentro del bucle.
Para esos caso, quieres que tan pronto un mensaje indique la inmediata interrupción del bucle, el bucle se interrumpa inmediatamente.
Semánticamente, eso…   » ver todo el comentario
C++XXI = CXXII
#2 121 en mi pueblo
#5 Perdon por el negativo.
#5 eres romano? xD
Pues para tener 45 años, aguanta muy bien el tipo. Parece increíble que todavía se siga usando y Pascal, por ejemplo, que pretendía resolver todos los problemas del C++, haya desaparecido.
#4 Ser longevo no lo hace mejor. Mira basic, x11, ncurses, terminales y baudios en el siglo XXI...
#4 Difícilmente Pascal pretendería resolver todos los problemas de C++ cuando es unos cuantos años más viejo
#4 que tiene buenos "tipos"? De qué conio.h me estás hablando? :-D

p.d.: a mi siempre me dio pena que no triunfara más Pascal-Delphi: me parecía mucho más claro y sencillo como lenguaje...
#4 El que pretendía resolver los problemas de C++ era Java.
#4 Pascal (Delphi) y Free Pascal (Lazarus) siguen vivitos y coleando.
Odio cuando ponen FOR o IF y "como solo es una línea" no ponen las llaves. >:-(

Eso confunde mucho, sobre todo a los principiantes, jamás lo hagáis.
#33 yo lo hago. Porque el hecho de que más líneas de código entren en pantalla facilita la lectura.
#35 #39 Es fuente de bugs porque luego llega otro y añade otra línea debajo del if y manda la segunda línea fuera del condicional. Anda que no lo he visto yo veces...
#50 Eso ya depende de la gente con la que te mezcles, obviamente. Yo no lo he visto jamás en mi equipo, pero quien sabe. Nosotros lo usamos y ningun problema.
#33 a mi me fastidian más la falta de llaves en los switch. Que como sea muy grande no encuentro el siguiente case. Encima si pones llaves el IntelliJ te protesta en plan, para que pones esto? Estás bien? Jajaja
#37 Pues las llaves en cada case de los switch debería ser una práctica recomendable.
Inicias un ámbito nuevo exclusivo a ese case, de modo que puedes declarar variables locales a ese ámbito que no son visibles desde los otros cases. El comportamiento por defecto es que las variables definidas en un case son visibles desde los otros cases, con lo que puede llevar a errores.
No sé cómo se les ocurrió diseñar el lenguaje así. Va en contra de la programación estructurada.
En general, la sentencia…   » ver todo el comentario
#51 Curioso, en lenguajes como PHP eso se soluciona con un "break(2)" para salir dos veces. En C parece que requiere cosas menos directas como la combinación de "continue".
#55 En C, en programas profesionales comerciales con millones de unidades vendidas, que he visto yo con mis ojos, he llegado a ver gotos y etiquetas para salir de switches dentro de bucles dentro de bucles.
#33 Más que no poner las llaves, puede ser recomendable para hacer más legible el código, lo que son un peligro son las instrucciones vacías. Por ejemplo, el típico programa de mostrar los números del 1 al 10 que NO funciona:
int i = 1;
for(;i<11;i++) ; {
printf("%dn", i);
}

Lenguajes como Rust prohíben esta construcción.
#22 C++ tiene programacion cercana al hardware y de alto nivel como cualquier lenguaje moderno con el C++ moderno (C++11, C++14, C++17, C++20, etc)

Por favor, actualizaros un poco y dejar de repetir los mantras del C++98 que no salis de ellos...
#30 meneame sigue siendo lo que era :-D
¿Algún curso gratuito o barato que conozcáis para empezar con C++?
#15 Consejo. A menos que tengas a vista algún trabajo muy especializado para usar C++, evitalo. C++ es uno de esos lenguajes que son para aprender en exclusiva. Si quieres ser bueno, bueno y no aprender solo las cosas basicas que son parecidas en todos los lenguajes te llevara mucho tiempo y sufrimiento.
#16 Que cosa tan "especial" tiene C++ que provoca tanto "sufrimiento"?

Que debes ser cuidadoso?
#18 No tanto el lenguaje en sí, sino lo que se programa en C/C++/Rust. Es una programación cercana al hardware.

Edit: Ah. No eres quien hizo la pregunta.
#18 Bien preguntado es: ¿Con qué debes de ser cuidadoso?. Y si no sabes la respuesta a eso, es que no has programado en C++ profesionalmente. "Googlea" y respuestas tendrás.
#28 C++ hoy en dia no tiene nada por lo que ser cuidadoso... actualizaros un poco y dejar de repetir mantras del C++98...

Hoy en dia no tienes que hacer new/delete... tienes smart pointers (std::unique_ptr y std::shared_ptr) para evitar memory leaks... tienes STD para multitud de funcionalidades seguras: threads, functions, variables auto, loop foreach, funciones lambda, etc etc etc...
#31 salvo que hayan roto la compatibilidad con el pasado por supuesto que tienes que ser cuidadoso.

¿Ya no puedes tener punteros a objetos liberados, o hacer aritmética de punteros errónea, o tener referencias al mismo objeto en dos hilos, etc etc?
#36 Creo que se refiere a que, si quieres basta con ser cuidadoso en no utilizar funcionalidad del pasado.
#56 si todo el código con el que interactuas es nuevo sí, pero lo dudo mucho.
#48
#36 Si, pero nadie te obliga a usarla hoy en dia, tienes alternativas dentro del mismo lenguaje...
#18 Un estándar que hace 7 años ya iba por las 1700 páginas, frente a las 700 de C.

Una lista enorme de cosas que provocan "Undefined Behavior", y que los creadores de compiladores se han tomado como licencia para compilar incorrectamente.
#16: Pues yo creo que como primera toma de contacto es mejor un lenguaje genérico como C o C++, sin profundizar mucho en ellos para no complicarse, lo justo para las variables, IF, ELSE, FOR, WHILE, vectores... Nada de aprender directamente con JS, Python o otros lenguajes de uso específico. Una vez se tiene una base con C o C++ ya saltas al lenguaje que necesites. Python tiene fallos gordos para ser un lenguaje de entrada, te añade saltos de línea en la pantalla sin pedirlos, o te obliga a indentar en lugar de plantearlo como algo conveniente.
#32 Yo aconsejaria Pascal o ADA para aprender. Son lenguajes muy estructurados que te obligan a seguir unas serie de patrones. Los lenguajes de la familia del C te permiten poner las cosas al tun tun.
#80: El problema es que si es muy engorroso puede distraer del objetivo inicial: aprender algoritmos. En mi opinión C aporta un equilibrio entre muchas cosas. Por ejemplo, puedes empezar con C y luego saltar a C++ para vectores y funciones, y luego ya saltas a lo demás.
#16 todo lo contrario, el que aprende C++ no solo lo tiene facil para aprender cualquier otro lenguaje (porque no te enseña malos habitos) sino que ademas entiende mucho mejor como funciona un ordenador, y en especial la memoria de este.

En la uni donde yo impartia clases trataron reemplazarlo por Python en los primeros años de carrera y fue un desastre, para lo que luego tuvieron que volver a enseñar C++.
#43 Yo aprendi con Pascal y depues ADA en la universidad y para nada usaria C++ como lenguaje para enseñar a programar. Lenguajes como Pascal por ejemplo son excelentes porque te obligan a seguir una seria de patrones muy bien definidos. Por no hablar de la legibilidad. Puede leer y releer Pascal y entender lo que pone después de pasado mucho tiempo. C++ es una monstruosidad, pero oye, buena suerte con C++.
#81 yo me refiero al C++ de hace 20 años (que era calcado a Pascal). Obviamente enseñar C++ moderno es una burrada.
#85
Si no quieres instalarte un C++ de primeras para hacer pruebas, puedes usar este compilador online:
www.onlinegdb.com/online_c++_compiler
#86 Le acabo de echar un vistazo a ese compilador desde la Surface y me ha encantado, (estoy de viaje). No sabía que había compiladores C en línea.
Lamentablemente ahora mismo estoy un poco agobiado de tiempo y trabajo, pero te garantizo que en cuanto esté de vuelta instalaré el C++ de Visual, (soy esclavo de Microsoft por imperativo legal).
Y te diré que admiro sin condiciones a la gente que comparte el conocimiento como lo haces tú, de lo otro ya estoy agotado.
Muchas gracias por tu aportación.

Salud !!!!
#0 Te falta la etiqueta SFW (para nerds).
A mi lo que me mata del C++ y del java es la sintaxis. Debo estar ya mayor pero la sintaxis de ciertas funcionalidad "avanzadas", por ejemplo el uso de lambdas o métodos anónimos. No voy a entrar en los aspectos técnicos de un lenguaje, pero para mi, repito, para mi, la sintaxis de un lenguaje de alto nivel, hecho para personas, tiene que ser autoexplicativo y mnemotécnico, es decir tiene que ser una sintaxis clara y lo mas cercana al lenguaje natural. Odio esas sintaxis en la que si…   » ver todo el comentario
#65 Pues te digo que el C++ moderno (C++11, C++14, C++17, C++20 y C++24) ha metido infinidad de cosas nuevas (muchas provenientes de las librerias boost incorporadas a las librerias estandar STD) que nada tiene que envidiar a JAVA y C#...

En C++ moderno ya no tienes que usar (de hecho lo mejor es que ni lo uses) new/delete: usa smart pointers:
- std::unique_ptr o std::shared_ptr
std::unique_ptr<Obj1> pObj1= std::make_unique<Obj1>();

ya tienes un puntero a un Objeto…   » ver todo el comentario
#65 Añado a #71 tambien el uso de threads, que ya estan incluidos en la STD desde C++11 y es super sencillo crear threads en C++:

#include <thread>
#include <string>
#include <vector>
#include <iostream>

void task1(int a) {
// do stuff
}

void task2(const std::string str) {
// do stuff
}

void task3() {
// do stuff
}

int main (int argc, char ** argv) {
double mult = 0.0;
std::vector<double> mult_vec = {0.0, 0.0};
auto lambda =…   » ver todo el comentario
#74 xD xD xD
Acabarás por convencerme.
En cuanto me alivie un poco el trabajo instalaré un C++ y le echaré un vistazo

Salud y gracias !!!!
¡Ojo! Que el artículo lo firma el propio Bjarne Stroustrup. Hace tiempo que no tiro de C++, pero me ha dado curiosidad por ver su evolución. Me lo guardo para leerlo con calma.
nim es poco conocido fuera del ámbito de las criptos, está inspirado en lo mejor de varios lenguajes como C, C++, pascal y Python,,

resuelve muchas de las pegas de c++ sobre todo en lo referente a gestión de memoria, código mucho más legible y compacto al eliminar las famosas llaves {},

he hecho varios port de código c++ y el resultado mejoraba mucho, el rendimiento es prácticamente el de C, ya que el compilador de nim compila a C o C++ por lo que usar C/C++ desde nim es inmediato.
#47 No entiendo el problema con lasllaves {}.... son muchisimo mas aclaratorias de donde empieza un scope y donde acaba...
if(...) {
....
}
#47 Las llaves no son ninguna pega, sino todo lo contrario. Y la gestión de la memoria es un problema que ya lleva años resuelto. Suena a la típica solución que nadie ha pedido para un problema inexistente.
Qué recuerdos!
Hace años que no utilizo c++ y las pesadillas con sus punteros, exactamente los mismos en que utilizo c#.
Puede que a alguno le suene a herejía pero para el tipo de proyectos en los que estoy metido fue mano de santo.
No vuelvo ni de coña.

Salud !!!!
#38 Hoy en dia la pesadilla de los punteros se soluciona con smart pointers: std::unique_ptr y std::shared_ptr... con ellos no tienes que hacer ni new ni delete y asi no tienes que preocuparte de memory leaks...

aparte de toda la funcionalidad añadida desde C++11, como variables auto, loops foreach, funciones lambda, functions, threads, etc etc etc
#59 Gracias por tu comentario. Llevo muchos años desconectado de C++ y lo último que recuerdo eran esos horrosos bugs de memoria.
Estoy seguro que habrá proyectos en los que el actual C++ será más eficiente, no lo sé, pero es que una vez habituado a C#, al IDE de Visual Studio y a su IntelliSense es muy difícil volver. Al menos tal y como yo lo recuerdo.
De hecho .NET tiene un C++ que ya nunca instalo en equipos nuevos, aunque tu comentario me está haciendo dudar.
C# es el C++ para programadores vagos, como es el caso. xD xD xD


Salud !!!!
#_33 si es solo una línea, no confunde para nada.

Además eso suena a queja de muy muy junior. A poco que te dediques a esto meter una línea debajo de un IF o FOREACH sin llaves no te afecta en absolutamente nada en la comprensión.
#39 Confunde. Y es más sencillo que, durante el mantenimiento, cause problemas.
"Queja" de alguien más cercano a los 20 años de experiencia que a los 10.
#42 Pues no sé, nunca he escuchado una sola queja de nadie en mi empresa, y lo usamos de manera sistemática.
#45 Yo tampoco me he quejado, por eso lo entrecomillé. Simplemente, cuando veo algo así, lo cambio porque sé que es un potencial punto de error.
He hecho alguna cosa con C++ y hace un par de años que me he puesto con Rust. Después de ese par de años en uso me quedo con Rust por la seguridad que proporciona y sabes lo que estás haciendo. Si tienes claro el algoritmo que quieres programar, en cuanto compila, sabes que lo tienes.
Puedes elegir el tipo de gestión de memoria ya sea puntero único (por defecto en Rust) o conteo de referencias. Además de tipos específicos para gestión de memoria cuando se usan hilos. Por ejemplo,…   » ver todo el comentario
#52 Me autocorrijo Arc<RwLock> en lugar de Rc<RwLock>
#52
let mut i : u64 = 1; // Es un int
i += 2;
let i = 2.3;//¡Se redefine a double!

Esto es un puto caos... imagina un codigo complejo donde tienes mas variables y cada una se redefine a distintos tipos distintas veces.... es un puto caos saber si esa variable deberia de tener un 2, un 3, un 2.3, un 3.2, etc etc...
#61 Por este tipo de cosas es por lo que odio JS y en general los lenguajes no tipados o con tipado dinámico. Cuando defines un campo en un objeto y que equivocas te crea un nuevo y a correr...Ole!
#61 #69 Para redefinir hay que usar "let". El típico caso de uso de una redefinición es de inmutable a mutable, y no es algo que se haga tan a menudo.

menéame