¿Por qué aprendería C ++ 11, habiendo conocido C y C ++? [cerrado]

Soy programador en C y C ++, aunque no sigo ninguno de los dos idiomas y escribo una mezcla de los dos. A veces, tener código en las clases, posiblemente con sobrecarga del operador o plantillas, y el STL tan genial es obviamente una mejor manera. A veces, el uso de un puntero de función C simple es mucho más legible y claro. Entonces encuentro belleza y practicidad en ambos idiomas. No quiero entrar en la discusión de "Si los mezcla y compila con un compilador de C ++, ya no es una mezcla, es todo C ++" Creo que todos entendemos lo que quiero decir al mezclarlos. Además, no quiero hablar de C vs C ++, esta pregunta se trata de C ++ 11.

C ++ 11 introduce lo que creo que son cambios significativos en el funcionamiento de C ++, pero ha introducido muchos casos especiales, excepciones e irregularidades que cambian el comportamiento de las diferentes características en diferentes circunstancias, imponiendo restricciones a la herencia múltiple, identificadores que actúan como palabras clave, extensiones de literales de cadena, captura de variables de función lambda, etc.

Sé que en algún momento en el futuro, cuando diga C ++, todos asumirían C ++ 11. Al igual que cuando dices C hoy en día, lo más probable es que te refieras a C99. Eso me hace considerar aprender C ++ 11. Después de todo, si deseo continuar escribiendo código en C ++, es posible que en algún momento necesite comenzar a usar esas funciones simplemente porque mis colegas lo han hecho.

Tome C por ejemplo. Después de tantos años, todavía hay muchas personas aprendiendo y escribiendo código en C. ¿Por qué? Porque el lenguaje es bueno. Lo que significa es que sigue muchas de las reglas para crear un buen lenguaje de programación. Entonces, además de ser potente (fácil o difícil, casi todos los lenguajes de programación lo son), C es regular y tiene pocas excepciones, si es que tiene alguna. C ++ 11 sin embargo, no lo creo. No estoy seguro de que los cambios introducidos en C ++ 11 estén mejorando el lenguaje.

Entonces la pregunta es: ¿Por qué aprendería C ++ 11?

Debería aprenderlo si cree que necesitará saberlo en el futuro para conseguir un trabajo. Si está seguro de que seguirá siendo comercializable en la fuerza laboral como C / C ++ [y cualquier otra cosa que pueda saber], entonces no lo aprenda. Si su jefe le dice que use C ++ 11, diga "no, no hago eso". Si te despide, ve a trabajar a otro lado. Aprenda C ++ 11 cuando prevea que pronto no podrá encontrar un empleo satisfactorio con las habilidades que conoce actualmente.

Quería aclarar mi razonamiento: no soy anti-C ++ 11. Solo digo que podría generalizar la pregunta del OP a "¿Por qué debería aprender X?". Nunca aprendí ML, esquema o haskell porque tengo un trabajo con C y C ++. Estoy seguro de que esos idiomas son útiles para alguien, pero no son beneficiosos para mí aprender en este momento. Si alguien me ofreciera un buen dinero para programar en ML, podría intentar aprenderlo.

Es simple. C ++ 11 hace que el código sea mucho más fácil, más limpio de escribir y más rápido.

nullptres una VAST mejora respecto a la anterior 0. Es de tipo seguro y no se convierte cuando no debería, a diferencia 0. Es bueno que nullptrno se convierta en un int. No tiene sentido que eso suceda en absoluto. ¿Sabes qué encontró el Comité C ++ cuando intentaron considerar #define NULL nullptr? Cosas por el estilo char c = NULL;. ¿Qué tan terrible es eso? La única razón por la que hay una excepción aquí es porque boolse considera un tipo integral, lo cual es bastante incorrecto, pero eso estaba allí antes en C ++ y en C. El hecho de que nullptrno se convierta es bueno , es genial y deberías amarlo.

¿O qué tal referencias de valor y plantillas variadas? Código más rápido y genérico. Esa es una victoria total allí mismo.

¿Qué hay de las mejoras de la biblioteca? Cosas como function, unique_ptry shared_ptrson mucho mejores que antes, es imposible argumentar que la forma C ++ 03 fue mejor.

#define adding_func(x, y) ((x)+(y))

Ni siquiera remotamente equivalente. Las macros son malas por seis mil millones de razones. No voy a citarlos todos aquí, pero es bien sabido que las macros deben evitarse para casi todos los propósitos que posiblemente puedan evitarse. ¿Qué vas a hacer cuando sea

#define add_twice(x) (x + x)

Oh, espera, espero que no hayas aumentado o algo así x. Que la versión de la función de plantilla es totalmente inmune a. También espero que no aprecies los espacios de nombres , por ejemplo.

Luego, se abre a un mundo de comportamiento indefinido para usar variables externas cuyos ámbitos ya están terminados.

En una API funcional, por ejemplo, algoritmos STL, entonces la referencia está bien. Si se trata de una devolución de llamada almacenada, debe capturar por valor. Cualquier documentación que tenga sobre la función debe indicar claramente cuál es necesaria. El hecho de que el código esté escrito en una lambda es irrelevante para el problema de referirse a las variables locales: si pasa un objeto de función regular, tendrá exactamente el mismo problema. Y no es un problema. En absoluto. Porque es inherentemente obvio cuando puedes y no puedes referirte a variables locales.

Tome C por ejemplo. Después de tantos años, todavía hay muchas personas aprendiendo y escribiendo código en C. ¿Por qué?

Hay muchas personas que no se lavan los dientes por la mañana. Hay muchos asesinos, violadores y prostitutas. Y políticos. Las personas que se suicidan. ¿Diría que eso hace que estas actividades sean buenas o útiles? Por supuesto no. Es una falacia lógica que solo porque alguien lo hizo, por lo tanto, debe ser bueno o útil.

C todavía se está escribiendo por tres razones: porque C ++ es una perra para implementar, por ejemplo, en modo incrustado o kernel; porque las bases de código heredadas están escritas en C y costaría demasiado actualizarlas, aunque incluso eso es cuestionable dada la excelente interoperabilidad de C ++ de C ++; y porque la gente que lo escribe no sabe programar. Eso es. No hay otra razón para escribir C.

Si toma C o el viejo estilo C ++, no encontrará muchas excepciones.

¿Qué tal las patéticas matrices de estilo C, por un simple ejemplo? El número de personas que no pueden obtener conjuntos y punteros directamente en su cabeza es obsceno. Sin mencionar el hecho de que la biblioteca C Standard es increíblemente insegura.

Sus argumentos centrales están llenos de falacias lógicas y malentendidos.

C ++ 11 no es un lenguaje nuevo; es solo una extensión / modificación de C ++ que ya conoces. C ++ 11 al igual que cualquier otro lenguaje de programación consta de características. Muchos de ellos estuvieron allí antes, algunos de ellos son nuevos. Pero su pregunta realmente es, ¿debería aprender todas las características del lenguaje (en este caso C ++ 11), o solo familiarizarme con el 90%?

OMI, incluso si no está utilizando todo el lenguaje, al menos debería leer sobre lo que las nuevas funciones hacen por usted. Muchos de ellos se introdujeron para hacer que el código de la biblioteca / marco (especialmente las plantillas) sea más fácil de escribir (por ejemplo, antes de que C ++ 11 el reenvío perfecto fuera imposible), pero si nunca antes tuvo la necesidad de esa función, es probable que haya ganado No observe que estas características se agregaron en C ++ 11.

Por otro lado, si anteriormente incursionó en la escritura de código de biblioteca / núcleo que imita algunas de las funciones de STL / Boost y se vio limitado por el idioma porque ha llegado al 95% a tener una solución genial y elegante, pero luego te detuvieron porque descubriste que el lenguaje simplemente no es compatible con lo que quieres, te darás cuenta del verdadero poder de C ++ 11. Desde que nuestro equipo actualizó a VS2010 (y descubrimos Boost en el proceso), he podido producir un código increíblemente increíble, eso sería simplemente imposible antes de cosas como referencias de valor r y reenvío de parámetros de plantilla.

También cosas como lambda pueden parecer extrañas, pero no introducen una nueva construcción. En cambio, hacen que lo que solíamos tener antes fuera mucho más fácil de escribir. Anteriormente, cada función lambda tendría que ser una clase separada. Ahora es solo {... código ...}. Quiéralo.

La clave es no mirar estas características y pensar en lo desalentadora que es la lista. En cambio, use C ++ como lo hace normalmente y cuando encuentre algún escenario en el que estas nuevas características de C ++ 11 sean útiles (más del 90% de las personas nunca llegarán a ese punto), estará muy contento de que la extensión al idioma estaba hecho. Por ahora, le sugiero que aprenda lo suficiente sobre el idioma para saber qué hay allí, no necesariamente cómo usarlo todo.

¿Es tan difícil escribir una función que tiene que escribir el contenido de la función en línea con el código, además de no darle nombre?

Cuando lo hace, se desplaza hacia arriba o abre un nuevo archivo fuente y agrega la definición de la función allí. Luego tienes que regresar y continuar con lo que estabas trabajando, lo que te distrae hasta cierto punto.

Aparte de eso, cuando otras personas leen tu código, una lambda puede ser más auto-documentada en algunos casos, en lugar de decir "Oh, ¿qué hace esta función? y saltando a su declaración puedes echar un vistazo a lo que está haciendo en su propio lugar.

Herb Sutter habla bien de las lambdas, quizás él pueda convencerte mejor:

http://channel9.msdn.com/events/PDC/PDC10/FT13

Bueno, ¿por qué no escribes el código allí en lugar de convertirlo en una función lambda?

Porque no puede hacerlo cuando está usando algoritmos STL, o cualquier función que esté usando que requiera que pase una función.

#definir agregar_func (x, y) ((x) + (y))

No hay forma de justificar este uso en lugar de lambdas, no puede llenar su código con macros en todas partes. Las macros y las funciones tienen diferentes propósitos, y una, en general, no reemplaza a la otra.

template<class Lhs, class Rhs>
auto adding_func(const Lhs &lhs, const Rhs &rhs)
                -> decltype(lhs+rhs) {return lhs + rhs;}

Estoy de acuerdo, esto es feo. Sin embargo, me recuerdo a mí mismo diciendo "¿por qué demonios debería calcular el tipo de esta expresión a pesar de que el compilador puede inferir esto?" en muchos casos Esto podría ayudar mucho en esos momentos.

Para resumir:

Aunque las nuevas características de C ++ 11 parecen feas en su sintaxis, creo que uno puede acostumbrarse a ellas en poco tiempo. Cada nueva construcción del lenguaje es difícil de aprender al principio; imagine la primera vez que aprendió a escribir una clase completa: poner la declaración en el archivo de encabezado, sin olvidar el punto y coma adicional al final, poner las definiciones en el archivo de origen, incluido el archivo de encabezado, al tiempo que se asegura de que tiene una protección para evitar inclusiones múltiples, sin olvidar el operador de resolución de alcance en las declaraciones de funciones miembro, etc.

Pero estoy bastante seguro de que después de escribir algunas clases te acostumbras y no piensas en la complejidad de este proceso: porque sabes que una clase hace que tu trabajo como programador sea mucho más fácil y la utilidad que Los beneficios de esta nueva construcción son mucho mayores que la pérdida de utilidad durante el tiempo que intentaba aprender el idioma . Creo que esta puede ser la razón por la que uno debería tratar de aprender o usar C ++ 11 de manera similar.

En realidad, el OP tiene algunos puntos, como la mayoría de las respuestas. Pero son "distantes" en visión. C ++ (incluido el subconjunto C) tiene una larga historia en la que se han agregado varias características a lo largo del tiempo, algunas de ellas se usaron con mayor o menor frecuencia y, a través de su uso y errores, se perfeccionaron en otras y otras.

A veces sucede que, después de introducir una nueva característica, ya se necesita una antigua, o se siente en contradicción con ella. Un lenguaje "limpio" debería ser coherente tal como es, y ya no deberían eliminarse las características necesarias.

Pero agregar no destruye nada. Al eliminar (o cambiar) se rompe el código existente que todavía está en producción, por lo que sea cual sea la característica que agregue, debe tener cuidado de no romper el código existente (en particular, no lo rompa en silencio , haciendo que haga cosas diferentes según lo previsto )

¿Tienes que aprender todo eso? Sí, porque todas las funciones se utilizan, ya sea en buenas o malas, tarde o temprano. Si esto es algo bueno para la "calidad" del lenguaje (admitiendo que hay una medida objetiva para ello) es otra historia: ¿cuánto tiempo debe conservarse la compatibilidad con versiones anteriores? Es difícil encontrar una respuesta, cuando alguien dice 3 años y otro dice 50.

La alternativa para mantener C ++ más "regular" es ... romperlo más a menudo, con un reinicio desde cero. Pero ya no será C ++.

También hay intentos de hacerlo (piense en D, por ejemplo: mucho más ortogonal como C ++ (incluso 11) en realidad lo es), pero ¿qué tan populares son? Una de las razones de su dificultad para tener impulso es la incompatibilidad con muchos códigos existentes que aún deben ejecutarse.

C ++ 11, para mí, es claramente un compromiso entre las nuevas necesidades y la compatibilidad con versiones anteriores. Eso resultó en un cierto "desorden" de sus especificaciones e implementación. Hasta que el costo de ese "desorden" sea menor que el costo de la incompatibilidad ... tienes que irte con ese compromiso.

Si ya no puede tolerarlo, ... mejor considerar otro idioma más joven. C ++ simplemente no se puede simplificar en ese sentido. No a esta edad.

Incluso si decide ignorar las nuevas características de C ++ 11, aún se beneficiará de ellas porque la Biblioteca estándar de C ++ las usará. Por ejemplo, en C ++ 98 tener una variable de tipo vector<string>era potencialmente un desastre de rendimiento debido a la cantidad de copias que se necesitaban hacer cuando el vector crece. Con C ++ 11 move constructor, no es un problema. De hecho, desearía que C ++ 11 nos trajera más funciones nuevas, no menos, especialmente en la Biblioteca estándar.

Después de tantos años, todavía hay muchas personas aprendiendo y escribiendo código en C. ¿Por qué? Porque el lenguaje es bueno.

Primero, la mayoría de los estudiantes en estos días están aprendiendo Java o .NET, no C. En segundo lugar, las personas todavía usan C no solo por sus ventajas como lenguaje, sino principalmente porque hay una gran cantidad de software existente escrito en C que necesita mantenerse y ampliarse, y porque en muchos casos (por ejemplo, plataformas integradas) un compilador de C es todo lo que hay. Por cierto, estas son algunas de las razones por las cuales la gente todavía escribe COBOL.

Es muy raro que un programador en la industria comience a trabajar en un nuevo proyecto que no esté vinculado a una base de código existente y continúe trabajando solo. Entonces, la razón para aprender C ++ 11 es que es probable que tengas que lidiar con el código escrito por otras personas, que usa las nuevas características. Además, las características que se agregaron se agregaron por una razón. Una vez que los aprenda y los use, podría llegar a apreciarlos.

• El ensamblaje se creó porque a la gente no le gustaba escribir código de máquina
• C fue creado porque a la gente no le gustaba escribir ensamblaje
• C ++ fue creado porque a la gente no le gustaba escribir C
• C ++ 11 se creó porque a la gente no le gustaba escribir C ++

Llegará a un punto en su carrera en C ++ en el que se dirá a sí mismo: "Seguro que desearía que los functors fueran más simples" o "¿Por qué NULL es una int?" y entonces entenderás C ++ 11.

El aprendizaje siempre es beneficioso. El conocimiento es poder.

Esa es la respuesta, básicamente. Todo lo demás son solo detalles sobre cómo exactamente puede beneficiarse de él y qué poderes tiene al conocerlo, y son tantos que cualquier enumeración sería incompleta.

Un ejemplo es tu propia pregunta. Ni siquiera podrías preguntarlo sin aprender al menos un poco.

Y como comenté, la verdadera preocupación no es por qué aprender, sino por qué usar . Y esa es una pregunta completamente diferente.

Debería aprender C ++ 11 porque las características agregadas le permiten escribir un mejor código. Algunas personas han mencionado el tipo de seguridad de punteros NULL y lambdas, que son muy agradables. Pero quiero llamar la atención sobre lo que creo que es el cambio más dramático en C ++ 11, especialmente en un entorno de producción grande: mover la semántica.

C ++ 11 admite nociones separadas de 'mover' y 'copiar'. En C ++ normal, solo tenemos el operador = que básicamente hace ambas cosas. Pero realmente, estamos expresando dos ideas separadas con un operador, lo cual es peligroso.

El ejemplo más obvio de dónde esto es útil es el nuevo unique_ptr. Tiene todas las mejores características de los viejos auto_ptr y scoped_ptr. Supongamos que queremos tener un puntero que sea el único puntero que apunta a un objeto. ¿Cómo lidiamos con a = b? Bueno, antes de que estuviéramos atascados, podría rechazarlo por completo (como scoped_ptr), o podríamos hacer lo que auto_ptr hace donde a = b le roba la propiedad a b. Este comportamiento de auto_ptr es muy confuso porque a = b en realidad cambia b. unique_ptr maneja esto: a = b no está permitido, pero tiene a = std :: move (b) para robar la propiedad. ¿Cómo es esto útil? Donde, hay una versión separada (sobrecargada) de intercambio que usa semántica de movimiento en lugar de semántica de copia. Esto significa que unique_ptr se puede intercambiar, no hay problema. Esto significa que unique_ptr, a diferencia de auto_ptr, es seguro de usar en un contenedor y luego decir ordenar. unique_ptr es básicamente la función de administración de memoria segura cuando no necesita múltiples punteros en el mismo objeto.

Otro gran ejemplo: suponga que tiene un objeto que no se puede copiar. Esto es útil en varias situaciones. Nunca puede devolver este objeto desde una función, porque cuando la función termina, copia lo que está devolviendo. Lo irónico es que generalmente el compilador realmente optimiza esto (es decir, nada se copia al final, el valor de retorno se crea en la dirección de la asignación final). Pero esto no tiene nada que ver con por qué lo hicimos incobrable; regresar de una función es realmente solo mover el objeto desde el alcance interno de la función hacia afuera. Ahora puede escribir objetos que no se pueden copiar pero SON móviles, y estos objetos se pueden devolver de las funciones.

La semántica de movimiento hace que sea mucho más fácil escribir código que no tenga fugas y que sea seguro para subprocesos.