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

28

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?


fuente
3
Entiendo que no debería haber una queja de C ++ 11 en este foro y estoy totalmente de acuerdo en esto: cada desarrollador tiene el derecho de tener su gusto personal con respecto a los lenguajes y herramientas de programación. Sin embargo, hay un problema mucho más práctico para mí: soy un desarrollador de C ++ y no me gusta C ++ 11, ¿tendré que usar C ++ 11 o estar fuera del mercado / cambiar a otro idioma dentro de ¿unos años?
Giorgio
Bueno, pensé un poco en eso, por supuesto, hay lenguajes más modernos desde cero, como el lenguaje de programación D o Go. Estos podrían ser adecuados para el dominio de su problema, más fáciles, más consistentes, etc. Sin embargo, la cuota de mercado ... ninguno de los jugadores clave en la industria admite D e incluso Go parece ser uno de los "experimentos" de Google. Entonces, la motivación detrás de C + +11 deberían ser las mejoras útiles que le permitan escribir un código mejor legible, más seguro y más rápido, así como el amplio soporte de la industria.
Nils
@ giorgio, durante los últimos dos años, dejé de usar C ++ tanto como lo hice antes (principalmente debido a que me di cuenta de cuán religiosos son los fanáticos de C ++, leyendo las respuestas a esta pregunta), pero aún así también trabajé en una biblioteca de C ++ que voluntariamente C ++ 11 utilizado para. Mi experiencia fue esta: C ++ 11 aborda muchas esquinas de mierda de C ++, y eso es admirable y, de hecho, mejora. La forma en que lo hace tiene sus propias esquinas cutres (ver la publicación original sin editar). Sin embargo, esos rincones de mierda parecen estar fuera del camino si hace las cosas "de la manera normal" (por ejemplo, no almacene una lambda para uso futuro).
@ giorgio, lo que quiero decir es que C ++ 11 puede verse mal al principio, de hecho, C ++ se ve terrible, pero si estás de acuerdo con C ++, probablemente también te gustaría C ++ 11. Simplemente evite tocar sus partes malas y de hecho puede disfrutarlo.
@anon: Una forma de deshacerse de las partes malas de un idioma es cortar con el pasado y comenzar un nuevo idioma, como lo está haciendo Apple con Swift (por nombrar solo uno de los numerosos ejemplos). La interfaz con el código heredado se puede hacer a través de una compilación separada. El problema con C ++ es que se extiende indefinidamente, probablemente porque es respaldado por una comunidad de fanáticos que creen religiosamente que C ++ es el único lenguaje verdadero. En pocas palabras: C ++ 03 me pareció un poco malo, pero hizo el trabajo, especialmente gracias a bibliotecas como Qt y boost. Por otro lado, mantendré mis manos fuera de C ++ 11.
Giorgio

Respuestas:

24

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.

Timmah
fuente
3
Si eres un desarrollador de "C / C ++" y tu jefe te dice que uses C ++ 11, ¿no deberías seguir adelante y agregar eso a tu arsenal? Estoy de acuerdo en que no debes pasar todo tu tiempo aprendiendo idiomas solo por aprenderlos, pero cuando tu jefe te diga "Aprende esto", probablemente sea una buena idea seguir adelante y aprenderlo. También lo hace más comercializable, en lugar de tener que explicar en su próxima solicitud que lo despidieron por insubordinación.
Panzercrisis
Haskell ... Es gracioso, debido a la inclusión lenta de lambdas en C ++. : P
rbaleksandar
85

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.

DeadMG
fuente
77
> El hecho de que nullptr no convierta es bueno, es genial y deberías amarlo. Acepta tu opinión, pero cálmate un poco sobre lo que alguien más debería AMAR, por favor ... ¡El siguiente paso es el talibanismo de abogados de C ++!
Emilio Garavaglia
55
Creo que la parte posterior de su respuesta es más sobre por qué C ++ debería preferirse a C. Eso está fuera de discusión. "Las bibliotecas C no son seguras": ¿cómo responde esto a la pregunta? Quiero decir, por supuesto, uno debe aprender las nuevas características que ofrece C ++ 11, pero C y C ++ NO están destinados a hacer lo mismo. Si C ++ es una perra para implementar a bajo nivel, también lo son C #, Java, Python y otras cosas porque no estaban destinadas a ejecutarse tan bajo. El hecho de que C ++ se compile en código nativo no significa que pueda usar OO y la agitación de la página asociada para obtener un código crítico de nivel de núcleo.
yati sagade
11
@Shahbaz, claramente tienes que aprender un poco más sobre los lenguajes de programación (p. Ej., Sistemas de tipos, alcance léxico, etc.), todos tus comentarios están completamente desincronizados. Comience con este libro: amazon.com/Theories-Programming-Languages-John-Reynolds/dp/…
SK-logic
55
@yati: C ++ tiene el mismo sistema de módulos que C. Las funciones de miembro se implementan como funciones de C antiguas. Las funciones virtuales se implementan igual que las funciones de carga desde un archivo DLL. No hay nada de paliza sobre esos. Y sí, eso definitivamente se aplica. Para empezar, tu creencia de que Unix es el mejor es subjetiva. Su cuota de mercado del 5% sugiere lo contrario. Y en segundo lugar, incluso si adorara Unix sin fin, un ejemplo no establecerá una tendencia. Lo mismo es cierto de los otros ejemplos que cita. Que ejemplos No tienen sentido. C ++ es tan adecuado para los procedimientos como C es.
DeadMG
8
@yatisagade C ++ es un lenguaje de paradigmas múltiples que no impone funciones virtuales para todo, y mis programas en C ++ son similares. Algunas partes usan diseño orientado a objetos, otras son funcionales, etc., dependiendo de lo que resuelva mejor ese subproblema particular. Aprecio C ++ por agregar el estilo orientado a objetos, y aprecio C ++ 11 por expandir enormemente el soporte para la programación funcional.
David Stone
29

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.

DXM
fuente
77
@Shahbaz: creo que todavía te falta la intención de por qué se agregaron funciones sin nombre. Y "usar variables sin tomarlas como entrada" se llama cierre y está disponible en muchos otros lenguajes de alto nivel. Si escribiera una gran cantidad de código de plantilla con objetos functor, con C ++ 11 estaría dando la bienvenida a las funciones lambda con los brazos abiertos. Piénselo de esta manera ... cuando el compilador genera código de máquina, no existe una función de plantilla o clase. Todos están "instanciados" para crear clases / funciones concretas antes de ese punto. Las lambdas son lo mismo cuando se trata de tener estado ...
DXM
55
... functors. En lugar de hacer que la gente escriba una tonelada de código, uno para cada tipo de functor y cada elemento de cierre que desea pasar, C ++ 11 le permite especificar una sintaxis de acceso directo y creará una instancia automática de toda una clase de functor interno como crea instancias de plantillas. Nuevamente, tenga en cuenta que la mayoría de estas características no se usarán en el 98% del código de nivel de aplicación, pero se agregaron para hacer que las bibliotecas como STL / Boost sean mucho más potentes y fáciles de implementar / mantener / depurar
DXM
10
@Shahbaz: De acuerdo, no entiendes las funciones lambda o los cierres. Es razonable. El hecho de que se usen en muchos idiomas diferentes debería sugerir que son útiles, ya sea que los entiendas o no, y que debes entenderlos antes de criticarlos demasiado.
David Thornley, el
8
@Shahbaz: Si crees que los cierres son similares a las variables globales, no entiendes los cierres. (Sugerencia: las variables globales causan problemas porque cualquier función puede modificarlas). Si entendiera el concepto de lambdas, no la implementación, no lo atribuiría a la confusión de clases versus código. Todo en el Estándar C ++ está ahí por razones que fueron convincentes para una gran cantidad de personas inteligentes. No tiene que estar de acuerdo con los motivos, pero sin conocerlos está criticando por ignorancia.
David Thornley
66
@Shahbaz, no hay absolutamente ninguna similitud entre los cierres y los globales, te estás perdiendo el punto por completo. Lea esto: en.wikipedia.org/wiki/Lambda_calculus y explote su cerebro: en.wikipedia.org/wiki/Combinatory_logic
SK-logic
18

¿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.

alto y claro
fuente
Los argumentos sobre autodocumentación y menos desplazamiento, etc., estoy bastante seguro de que argumentos opuestos como "código de desorden", "restricción de acceso", etc., alguna vez se usaron para argumentar por qué las funciones fuera de clase deben prohibirse. Creo que las personas necesitan tener más experiencia para decidir cuál es mejor. Me parece que este es un experimento fallido o un mal diseño. Estoy más convencido de no ser la rata de laboratorio en este experimento.
Shahbaz
Sobre la sintaxis que parece fea, tome estos dos por ejemplo: bool is_alive;y bool thisSpecialObjectOfMineIsAlive;. Ambos hacen lo mismo, pero el segundo se ve realmente feo. ¿Por qué? Porque erróneamente pensé que poner más información lo hace más claro, pero ha hecho lo contrario. Es el mismo trato aquí, Stroustrup quiso decir bien al darnos características, pero simplemente no lo hizo atractivo. Para mí esto muestra un mal diseño.
Shahbaz
3
apuesto! = bueno y malo! = malo.
DeadMG
@Shahbaz: Creo que las lambdas son un gran concepto (y han existido durante muchos años en idiomas como Lisp). Los uso mucho en Haskell. Estoy menos seguro de que encajen en lenguajes como C ++, Java, etc. Se sienten un poco como una ocurrencia tardía para mí: algo que se agregó más tarde porque las lambdas se han vuelto populares. ¿Por qué no se introdujeron en estos idiomas desde el principio? ¿Stroustrup y Goslin nunca habían oído hablar de Lisp?
Giorgio
8

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.

Emilio Garavaglia
fuente
Yo tambien estoy de acuerdo. Y como desarrollador, me resulta muy perturbador tener un lenguaje que cambia constantemente (que tengo que aprender una y otra vez). Si desarrolla un nuevo lenguaje, debe comenzar de nuevo y usar un nombre diferente. Si desea que coopere con el código heredado, hay una compilación separada para eso. Así que realmente no entiendo la política de cambiar un idioma existente al incorporar las últimas funciones que se han puesto de moda. Como alguien dijo: un mayor desarrollo no implica automáticamente progreso.
Giorgio
"C ++ simplemente no se puede simplificar en ese sentido. No a esta edad": ¿Por qué otros lenguajes de programación (por ejemplo, C, Ada, ...) no siguen el mismo camino? Tal vez porque tienen su propio nicho de aplicaciones y no se espera que sean la herramienta para todas las áreas de aplicación posibles.
Giorgio
@ giorgio: sí ... probablemente tengas razón en el sentido "pragmático". Pero en teoría ... Recuerdo algunos buenos días donde pascal era el "lenguaje de referencia de enseñanza" y ada era el "aspirante a todo lenguaje de programación".
Emilio Garavaglia
También aprendí programación en Pascal. Hasta donde yo sé, Ada pasó por varias revisiones, pero el diseño básico del lenguaje no fue subvertido. Lo mismo con C y Pascal. Si uno quiere desarrollar un lenguaje realmente nuevo, debe ser lo suficientemente valiente como para hacer un corte claro y comenzar algo nuevo, como D, Java, C #. Mi problema con la ruta actual que está tomando C ++ es que (innecesariamente) se está volviendo demasiado complejo. Si los principios de KISS y YAGNI se aplican al diseño de software, ¿por qué no deberían aplicarse también al diseño de lenguaje de programación?
Giorgio
@Giorgio: oh ... se aplican ... exactamente como dijiste. Si cree que C # o D hicieron una mejor elección que un C ++ "hervido" (mi interpretación de su sentimiento), simplemente utilícelos en lugar de C ++. Un paso del tiempo en C ++ morirá lentamente. En este momento, veo que C ++ 11 le da una nueva oportunidad al C ++ 03 "hervido", y D con algo que falta para romper la barrera inicial. Los intereses económicos y corporativos también juegan un papel en cómo se financia y alienta el desarrollo. Tienes razón en teoría, pero el mundo real es más complejo.
Emilio Garavaglia
7

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.

Nemanja Trifunovic
fuente
6

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.

Dima
fuente
Citaste mi frase de forma incompleta. Como dije en la oración siguiente, goodsignifica que sigue las reglas de un buen diseño de lenguaje de programación. No sé dónde estudias, pero sé de 4 o 5 países y todos comienzan a aprender a programar con C. Como dije, con C, casi no hay excepciones (algo que es opuesto en Java, apenas se podría encuentre una construcción que no tenga una excepción).
Shahbaz el
1
@Shahbaz: Cité oraciones completas. Hiciste una conexión causal y dije que, en el mejor de los casos, está incompleta. Afortunadamente, no estudio más. :) Ya he hecho bastante de eso. Vivo en los Estados Unidos, y cuando fui a la universidad (hace más de 15 años) C era el idioma introductorio. Sin embargo, hoy en día la mayoría de las escuelas de EE. UU. Comienzan con Java, y no hay tantos programadores jóvenes que conozcan C.
Dima
55
@Shahbaz: Realmente no veo el problema con las reglas del idioma que tienen excepciones. Sí, C es un lenguaje mucho más simple que C ++. Por otro lado, C ++ hace que sea más fácil escribir código más simple. Para escribir código más simple, necesita más funciones de idioma. Eso hace que el lenguaje sea más complejo. Por mi parte, me gustan cosas como clases, referencias, RAII, plantillas, constructores, destructores, excepciones y espacios de nombres. Pero dijiste que tu pregunta no era sobre C vs C ++, así que no escribí sobre eso en la respuesta.
Dima
5
  • 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.

Pubby
fuente
Todos los idiomas fueron creados porque a alguien no le gustaban los existentes. Eso no los hace buenos.
Shahbaz el
No digo que NULLdeba ser un int. No debería Lo que no me parece apropiado es introducir una construcción en el lenguaje que resuelva esto, pero introduce excepciones. Deberían haber podido hacer lo mismo de una mejor manera.
Shahbaz el
2
"C ++ 11 se creó porque a las personas no les gustaba escribir C ++": si no les gustaba escribir C ++, ¿por qué C ++ es un subconjunto de C ++ 11?
Giorgio
1
Debería ser: C # y Java fue creado porque a la gente no le gustaba escribir C ++.
Calmarius
4

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.

littleadv
fuente
4

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.

Nir Friedman
fuente
Y también, por cierto, eficiente.
Nir Friedman