¿Cuáles serían las limitaciones de C ++ en comparación con el lenguaje C? [cerrado]

Los siguientes son los beneficios de C ++

• C ++ proporciona las características específicas sobre las que preguntan
• Es casi seguro que su compilador de C es realmente un compilador de C ++, por lo que no hay implicaciones de costos de software
• C ++ es tan portátil como C
• El código C ++ puede ser tan eficiente como C (o más o menos)

¿Hay razones concretas y escenarios específicos en los que uno tiene que usar C sobre C ++?

Referencia a esta pregunta: Biblioteca para genéricos en C

No es un duplicado, porque esta pregunta se refiere a las limitaciones del idioma y no sobre si debería / no debería aprender un idioma sobre otro.

La publicación de Peter Kirkham fue para mí la más informativa, particularmente con respecto a los problemas de C99 que no había considerado, así que la acepté. Gracias a todos los que participaron.

Esto se debe a una respuesta que di a una pregunta actual que indaga sobre una biblioteca genérica para C; el interrogador afirma específicamente que no quiere usar C ++.

C es un lenguaje de programación completo. C no es un subconjunto arbitrario de C ++. C no es un subconjunto de C ++ en absoluto.

Esto es válido C:

foo_t* foo = malloc ( sizeof(foo_t) );

Para que se compile como C ++ tienes que escribir:

foo_t* foo = static_cast<foo_t*>( malloc ( sizeof(foo_t) ) );

que ya no es válida C. (podría usar la conversión de estilo C, en cuyo caso se compilaría en C, pero sería rechazado por la mayoría de los estándares de codificación de C ++, y también por muchos programadores de C; observe los comentarios de "no lanzar malloc" en todo Stack Overflow) .

No son el mismo idioma, y ​​si tiene un proyecto existente en C, no desea reescribirlo en un idioma diferente solo para usar una biblioteca. Preferiría utilizar bibliotecas con las que pueda interactuar en el idioma en el que está trabajando. (En algunos casos, esto es posible con unos pocosextern "C" funciones contenedoras, dependiendo de la plantilla / en línea de una biblioteca C ++).

Tomando el primer archivo C en un proyecto en el que estoy trabajando, esto es lo que sucede si simplemente cambia gcc std=c99por g++:

sandiego:$ g++ -g  -O1 -pedantic -mfpmath=sse -DUSE_SSE2 -DUSE_XMM3  -I src/core -L /usr/lib -DARCH=elf64 -D_BSD_SOURCE -DPOSIX -D_ISOC99_SOURCE -D_POSIX_C_SOURCE=200112L -Wall -Wextra -Wwrite-strings -Wredundant-decls -Werror -Isrc  src/core/kin_object.c -c -o obj/kin_object.o | wc -l
In file included from src/core/kin_object.c:22:
src/core/kin_object.h:791:28: error: anonymous variadic macros were introduced in C99
In file included from src/core/kin_object.c:26:
src/core/kin_log.h:42:42: error: anonymous variadic macros were introduced in C99
src/core/kin_log.h:94:29: error: anonymous variadic macros were introduced in C99
...
cc1plus: warnings being treated as errors
src/core/kin_object.c:101: error: ISO C++ does not support the ‘z’ printf length modifier
..
src/core/kin_object.c:160: error: invalid conversion from ‘void*’ to ‘kin_object_t*’
..
src/core/kin_object.c:227: error: unused parameter ‘restrict’
..
src/core/kin_object.c:271: error: ISO C++ does not support the ‘z’ printf length modifier
src/core/kin_object.c:271: error: ISO C++ does not support the ‘z’ printf length modifier

En total 69 líneas de errores, cuatro de las cuales son conversiones no válidas, pero principalmente para características que existen en C99 pero no en C ++.

No es como si estuviera usando esas funciones por el gusto de hacerlo. Se necesitaría un trabajo significativo para portarlo a un idioma diferente.

Por tanto, es un error sugerir que

[a] El compilador de C es casi seguro que en realidad es un compilador de C ++, por lo que no hay implicaciones de costos de software

A menudo, hay implicaciones de costos significativas al migrar el código C existente al subconjunto de procedimientos de C ++.

Entonces, sugerir 'usar la clase C ++ std :: queue' como respuesta a la pregunta de buscar una implementación de biblioteca de una cola en C es más posterior que sugerir 'usar el objetivo C' y 'llamar a la clase Java java.util.Queue usando JNI' o 'llamar a la biblioteca CPython' : Objective C en realidad es un superconjunto adecuado de C (incluido C99), y las bibliotecas Java y CPython se pueden llamar directamente desde C sin tener que transferir código no relacionado al lenguaje C ++.

Por supuesto, podría proporcionar una fachada C a la biblioteca C ++, pero una vez que lo esté haciendo, C ++ no es diferente a Java o Python.

Me doy cuenta de que no es una respuesta profesional ni buena en particular, pero para mí es simplemente porque realmente me gusta C. C es pequeño y simple y puedo encajar todo el lenguaje en mi cerebro, C ++ para mí siempre me ha parecido un enorme desastre. con todo tipo de capas me cuesta asimilar. Debido a esto, encuentro que cada vez que escribo C ++ termino pasando mucho más tiempo depurando y golpeándome la cabeza contra superficies duras que cuando codifico C. Nuevamente me doy cuenta de que mucho de esto es en gran parte el resultado de mi propia 'ignorancia'.

Si puedo elegir, escribiré todas las cosas de alto nivel como la interfaz y la interacción de la base de datos en Python (o posiblemente C #) y todas las cosas que tienen que ser rápidas en C. Para mí, eso me da lo mejor de todos los mundos. Escribir todo en C ++ se siente como obtener el peor de todos los mundos.

Editar: Me gustaría agregar que creo que C con algunas características de C ++ es en gran medida una mala idea si va a haber varias personas trabajando en un proyecto o si la capacidad de mantenimiento es la prioridad. Habrá desacuerdo en cuanto a lo que constituye "unos pocos" y qué bits deben hacerse en C y qué bits en C ++, lo que eventualmente conducirá a una base de código muy esquizofrénica.

C ++ simplemente no es compatible con algunos entornos del mundo real, como los sistemas integrados de bajo nivel. Y hay una buena razón para eso: C fácilmente lo suficientemente bueno para tales cosas, entonces, ¿por qué usar algo más grande?

Odio programar en C ++.

Un par de razones pueden ser:

• Falta de soporte: no todos los compiladores de C son también compiladores de C ++. No todos los compiladores son particularmente compatibles con el estándar, incluso si afirman ser compatibles con C ++. Y algunos compiladores de C ++ generan código ineficaz e ineficaz. Algunos compiladores tienen implementaciones terribles de la biblioteca estándar. El desarrollo en modo kernel generalmente hace imposible el uso de la biblioteca estándar de C ++, así como algunas características del lenguaje. Aún puede escribir código C ++ si se apega al núcleo del lenguaje, pero entonces puede ser más simple cambiar a C.
• Familiaridad. C ++ es un lenguaje complejo. Es más fácil enseñar C a alguien que C ++, y es más fácil encontrar un buen programador en C que un buen programador en C ++. (la palabra clave aquí es "bueno". Hay muchos programadores de C ++, pero la mayoría de ellos no ha aprendido el lenguaje correctamente)
• Curva de aprendizaje: como se indicó anteriormente, enseñarle a alguien C ++ es una tarea enorme. Si está escribiendo una aplicación que debe ser mantenida por otros en el futuro, y estos otros pueden no ser programadores de C ++, escribirla en C hace que sea mucho más fácil de manejar.

Todavía prefiero escribir en C ++ cuando puedo salirme con la mía y, en general, creo que los beneficios superan a las desventajas. Pero también puedo ver el argumento para usar C en algunos casos.

Hay muchos argumentos sobre la programación integrada, el rendimiento y esas cosas, no los compro. C ++ se compara fácilmente con C en esas áreas. Sin embargo:

Recientemente, después de haber programado en C ++ durante más de 15 años, he estado redescubriendo mis raíces en C. Debo decir que si bien hay buenas características en C ++ que facilitan la vida, también hay un montón de trampas y una especie de "siempre hay una mejor manera" de hacer las cosas. En realidad, nunca te sientes muy feliz con la solución que obtuviste. (No me malinterpretes, esto podría ser algo bueno, pero en general no).

C ++ te ofrece disparos infinitos. Lo que podría ser bueno, pero de alguna manera siempre terminas usando demasiado. Esto significa que está disfrazando sus soluciones con capas "bonitas" y "bonitas" de abstracciones, generalidad, etc.

Lo que descubrí volviendo a C fue que en realidad era divertido programar de nuevo. Habiendo pasado tanto tiempo modelando y pensando en cómo usar mejor la herencia, encuentro que programar en C en realidad hace que mi código fuente sea más pequeño y más legible. Por supuesto, esto depende de su nivel de autodisciplina. Pero es muy fácil poner demasiadas abstracciones en código sencillo, que en realidad nunca es necesario.

C tiene la principal ventaja de que puedes ver lo que realmente está sucediendo cuando miras un fragmento de código (sí, preprocesador: compila con -E y luego lo ves). Algo que con demasiada frecuencia no es cierto cuando miras algún código C ++. Allí tiene constructores y destructores que se llaman implícitamente en función del alcance o debido a asignaciones, tiene una sobrecarga de operadores que puede tener un comportamiento sorprendente incluso cuando no se usa mal. Admito que soy un fanático del control, pero he llegado a la conclusión de que esto no es un mal hábito para un desarrollador de software que quiere escribir software confiable. Solo quiero tener una oportunidad justa de decir que mi software hace exactamente lo que se supone que debe hacer y no tener un mal presentimiento en mi estómago al mismo tiempo porque sé que todavía podría haber tantos errores en él que no lo haría '

C ++ también tiene plantillas. Los odio y los amo, pero si alguien dice que los entiende completamente, ¡lo llamo mentiroso! Eso incluye a los redactores del compilador, así como a las personas involucradas en la definición del estándar (que se vuelve obvio cuando intenta leerlo). Hay tantos casos de esquina absurdamente engañosos involucrados que simplemente no es posible considerarlos todos mientras escribe el código real. Me encantan las plantillas de C ++ por su gran poder. Es realmente sorprendente lo que puede hacer con ellos, pero también pueden conducir a los errores más extraños y difíciles de encontrar que uno pueda (no) imaginar. Y estos errores ocurren realmente y ni siquiera raramente. Leer sobre las reglas involucradas para resolver plantillas en C ++ ARM casi me hace estallar la cabeza. Y me da la mala sensación de perder el tiempo al tener que leer mensajes de error del compilador que tienen varios 1000 caracteres para los cuales ya necesito 10 minutos o más para entender lo que el compilador realmente quiere de mí. En el código típico de C ++ (biblioteca), a menudo también se encuentra mucho código en los archivos de encabezado para hacer posibles ciertas plantillas, lo que a su vez hace que los ciclos de compilación / ejecución sean dolorosamente lentos incluso en máquinas rápidas y requiere la recompilación de grandes partes del código cuando cambia algo ahí.

C ++ también tiene la trampa const. O evita la const para todos los casos de uso menos los más triviales o tarde o temprano tendrá que desecharlo o refactorizar gran parte del código base cuando evolucione, especialmente cuando está a punto de desarrollar un diseño OO agradable y flexible.

C ++ tiene una escritura más fuerte que C, lo cual es genial, pero a veces siento que estoy alimentando un Tamagotchi cuando trato de compilar código C ++. Una gran parte de las advertencias y errores que generalmente recibo no son realmente que yo esté haciendo algo que no funcionaría, sino solo cosas que al compilador no le gusta que haga de esta manera o no sin enviar o poner algunas palabras clave adicionales aquí y ahí.

Estas son solo algunas de las razones por las que no me gusta C ++ para el software que escribo solo usando algunas bibliotecas externas supuestamente robustas. El verdadero horror comienza cuando escribes código en equipo con otras personas. Casi no importa si son hackers de C ++ muy inteligentes o principiantes ingenuos. Todo el mundo comete errores, pero C ++ hace que sea deliberadamente difícil encontrarlos y aún más difícil detectarlos antes de que sucedan.

Con C ++ simplemente estás perdido sin usar un depurador todo el tiempo, pero me gusta poder verificar la exactitud de mi código en mi cabeza y no tener que depender de un depurador para encontrar mi código ejecutándose en rutas que nunca hubiera anticipado. De hecho, trato de ejecutar todo mi código en mi cabeza e intento tomar todas las ramas que tiene, incluso en subrutinas, etc. y usar un depurador solo ocasionalmente para ver qué tan bien se ejecuta en todos los lugares acogedores que preparé para ello. Escribir y ejecutar tantos casos de prueba que todas las rutas de código se hayan utilizado en todas las combinaciones con todo tipo de datos de entrada extraños es simplemente imposible. Por lo tanto, es posible que no conozca los errores en los programas C ++, pero eso no significa que no estén allí. Cuanto más grandes sean los proyectos de C ++, menor será mi confianza en que no tendrá muchos errores no detectados, incluso si funciona perfectamente con todos los datos de prueba que tenemos a mano. Eventualmente lo tiro a la basura y empiezo de nuevo con algún otro idioma o combinación de otros idiomas.

Podría continuar, pero supongo que ya dejé mi punto claro. Todo esto me ha hecho sentir improductivo cuando programo en C ++ y me hizo perder la confianza en la exactitud de mi propio código, lo que significa que no lo usaré más, mientras sigo usando y confío en el código C que escribí más de 20 hace años que. Tal vez sea simplemente porque no soy un buen programador de C ++, o tal vez ser bastante bueno en C y otros lenguajes me permite reconocer lo un poco lamer que soy en realidad cuando se trata de C ++, y que nunca podré comprenderlo por completo. .

La vida es corta...

En un entorno embebido de bajo nivel, algunos de los "ingenieros de software" tendrán experiencia en EE y apenas dominarán C. C ++ es más complejo y algunos de estos tipos simplemente tienen miedo de aprender un nuevo idioma. Por tanto, C se utiliza como mínimo común denominador. (Antes de sugerir deshacerse de estos tipos, son al menos tan importantes como las especialidades de informática que no entienden las cosas analógicas incondicionales).

Hablando de la experiencia de haber heredado y mantenido ambos: un diseño horrible en C es difícil de entender, desenrollar y refactorizar en algo utilizable.

Un diseño horrible en C ++ es infinitamente peor, ya que las capas aleatorias de abstracción envían a tu cerebro a dar vueltas por el código base tratando de averiguar qué código se ejecutará en qué circunstancia.

Si tengo que trabajar con ingenieros que sé que no producirán grandes diseños, preferiría el primero que el segundo.

No veo ninguna otra razón que no sea la aversión personal, incluso para programar sistemas embebidos y cosas similares. En C ++, solo paga gastos generales por las funciones que utiliza. Puede utilizar el subconjunto C de C ++ en algunas situaciones específicas donde la sobrecarga de C ++ es demasiado alta para usted. Dicho esto, creo que algunos programadores de C sobreestiman la sobrecarga de algunas construcciones de C ++. Permítanme enumerar algunos ejemplos:

• Las clases y las funciones miembro tienen cero sobrecarga en comparación con las funciones normales (a menos que use funciones virtuales, en cuyo caso no hay sobrecarga en comparación con el uso de punteros de funciones)
• Las plantillas tienen muy poca sobrecarga (por lo general, ninguna sobrecarga)

Una razón válida sería cuando está programando para una plataforma que no tiene un compilador de C ++ decente (no hay compilador de C ++ en absoluto, o existe un compilador, pero está mal implementado e impone una sobrecarga innecesaria para algunas características de C ++).

¿Por qué limitar el habla en inglés? Quizás sería un autor más creativo en serbio.

Ese es el mismo argumento, con obvias falacias. Si tiene una tarea y sus cómodas herramientas resuelven la tarea de manera eficiente, es probable que utilice sus cómodas herramientas por una buena razón.

C ++ tiene una curva de aprendizaje mucho más larga. C tiene solo unas pocas construcciones que debe conocer y luego puede comenzar a codificar un software poderoso. En C ++ es necesario aprender la base de C, luego la programación orientada a objetos y la programación genérica, excepción, etc. traducirlos, qué gastos generales implícitos tienen o no. Esto requiere mucho tiempo y energía.

Para un proyecto profesional, este argumento puede no contar, porque puede emplear a personas que ya conocen muy bien C ++. Pero en los proyectos de código abierto, donde C todavía se usa ampliamente, las personas eligen el idioma que les gusta y pueden usar. Tenga en cuenta que no todos los programadores de sistemas operativos son programadores profesionales.

Me gustaría continuar con la respuesta de Dan Olson. Creo que la gente teme las características potencialmente peligrosas y contraproducentes de C ++, y con razón. Pero a diferencia de lo que dice Dan, no creo que simplemente decidir sobre un estándar de codificación sea efectivo, por dos razones:

1. Los estándares de codificación pueden ser difíciles de hacer cumplir estrictamente
2. Puede ser muy difícil encontrar uno bueno.

Creo que la segunda razón aquí es mucho más importante que la primera, porque decidir sobre un estándar de codificación puede convertirse fácilmente en un asunto político y estar sujeto a revisión más adelante. Considere el siguiente caso simplificado:

1. Puede usar contenedores stl, pero no usar plantillas en ninguno de sus propios códigos.
2. La gente comienza a quejarse de que serían más productivos si solo se les permitiera codificar esta o aquella clase de plantilla.
3. El estándar de codificación se revisa para permitir eso.
4. Deslice una pendiente hacia un estándar de codificación demasiado complicado que nadie sigue y use exactamente el tipo de código peligroso que se suponía que el estándar debía prevenir, combinado con un exceso de burocracia en torno al estándar.

(La alternativa de que el estándar no se revise en el paso 3 es empíricamente demasiado improbable de considerar y no sería mucho mejor de todos modos).

Aunque solía usar C ++ para casi todo hace unos años, estoy empezando a sentir que C es preferible en tareas de bajo nivel que deben ser manejadas por C o C ++ y todo lo demás debe hacerse en algún otro idioma por completo. (Las únicas excepciones posibles son algunos dominios de problemas específicos de alto rendimiento, wrt. Blitz ++ )

Utilizo C, o al menos exporto una interfaz C cuando escribo código de biblioteca.

No quiero problemas de ABI mal definidos.

Nunca he visto ningún argumento para usar C sobre C ++ que considere convincente. Creo que la mayoría de la gente tiene miedo de ciertas características que ofrece C ++, a menudo con razón. Sin embargo, esto no me convence porque uno puede exigir si se usan o no ciertas funciones a través de estándares de codificación. Incluso en C, hay muchas cosas que querrías evitar. Descartar C ++ por completo es esencialmente decir que no ofrece beneficios tangibles sobre C que ayudarían a escribir un mejor código, que es una visión que considero bastante ignorante.

Además, la gente siempre parece plantear la situación de las plataformas donde no existe un compilador de C ++. Ciertamente, C sería apropiado aquí, pero creo que sería difícil encontrar una plataforma como esa en estos días.

Un punto que no he visto planteado todavía, que creo que es el más importante:

La mayoría de las bibliotecas que utilizo a diario son bibliotecas C con enlaces para Python, Ruby, Perl, Java, etc. Por lo que he visto, es mucho más fácil envolver bibliotecas C con 19 enlaces de lenguaje diferentes que envolver bibliotecas de C ++.

Por ejemplo, aprendí El Cairo una vez y desde entonces lo he usado en 3 o 4 idiomas diferentes. ¡Gran victoria! Prefiero escribir un programa que se pueda usar de nuevo en el futuro, y escribir uno que se pueda adoptar fácilmente a otros lenguajes de programación es un caso extremo de esto.

Sé que es posible vincular bibliotecas C ++, pero AFAICT no es lo mismo. He usado Qt (v3 y v4) en otros lenguajes y no es tan agradable de usar: tienen ganas de escribir C ++ en algún otro idioma, no como bibliotecas nativas. (¡Tienes que pasar los sigs del método C ++ como cadenas!)

C ++ es probablemente un lenguaje mejor si está escribiendo una función para usarla una vez, o si cree que todo el mundo es C ++. C parece un lenguaje más fácil si está diseñando para la portabilidad del lenguaje desde el principio.

El desarrollo del kernel de Windows no es compatible con c ++ (lamentablemente).

Puedes leer una perorata entretenida sobre por qué Linus Torvalds favorece a C aquí.

El código nativo en una mac es objetivo-c. El código nativo en una PC es c (window.h) o c ++ (mfc). Ambos entornos te permitirán usar c con pocos cambios o sin cambios. Cuando quiero que una biblioteca de código sea multiplataforma, ansi c parece una buena opción.

Puedo pensar en varias razones.

Puede que no haya un compilador de C ++ satisfactorio. C ++ es un lenguaje mucho más grande y he ejecutado compiladores de C en sistemas que no serían capaces de manejar C ++ moderno.

El interrogador, o las personas con las que trabaja, pueden estar familiarizados con C pero no con C ++.

El proyecto puede estar en C. Si bien es posible agregar algunas características de C ++ a C, eso puede conducir fácilmente a un desastre que no se puede mantener. Sugeriría elegir un idioma u otro (generalmente C ++, cuando sea práctico).

El interrogador puede tener una visión obsoleta de la curva de aprendizaje de C ++. (Cuando se aborda correctamente, es más fácil que el de C. La mayoría de los libros introductorios que he visto no lo abordan correctamente).

Recuerde que C y C ++ son dos lenguajes diferentes y se están volviendo más diferentes con el tiempo. Codificar en ambos a la vez es una mala idea, y usar un subconjunto similar a C de C ++ pierde la mayoría de las ventajas de C ++.

Si trabaja en un entorno con dos lenguajes, puede utilizar C para algunas funciones de bajo nivel críticas para el rendimiento y un lenguaje más funcional / de alto nivel como C # / Java para la lógica empresarial. Si se usa código C ++ para estas funciones, se requieren C-Wrappers para el código JNI / no administrado y esto hace que las cosas sean más complejas que usar únicamente C.

Utilizo C ++ con programación en C por dos razones:

• vector y string quitarme la gestión de la memoria de la matriz
• control de tipo estricto y conversiones para advertir y / o detectar todas las molestias que me perdería de otra manera.

Entonces, es C realmente tomando prestado algunos C ++ pero usando el compilador de C ++ tanto como puedo. Como alguien más dice en las respuestas, me doy cuenta de que ahora estoy aprendiendo más C ++ de esta manera y donde C sería demasiado complicado, uso C ++. Monitor / Lock usando RAII es uno de estos que he usado recientemente cuando trato con programas multiproceso y otra construcción similar para abrir / cerrar archivos.

Creo que C es más portátil. Hice un trabajo hace unos 5 años portando código a muchas versiones de Unix (AIX, Irix, HPUX, Linux). El código C fue fácil de migrar, pero tuvimos varios problemas para migrar parte del código C ++. Tal vez fue solo entornos de desarrollo inmaduros, pero preferiría usar C sobre C ++ por esta razón ...

1. C es un lenguaje simple, C ++ no lo es. Para muchas personas, C ++ es simplemente demasiado complicado para dominarlo por completo, consulte http://en.wikipedia.org/wiki/C%2B%2B#Criticism .

2. Debido a la complejidad, diferentes programadores generalmente solo dominan diferentes subconjuntos del lenguaje. Hace que leer el código de otras personas sea doloroso.

3. La complejidad y las trampas del idioma añaden demasiada distracción y, a veces, perjudican la productividad. En lugar de concentrarme en el trabajo en sí, a menudo me encontraba luchando con el idioma en sí. Java / python son alternativas más productivas.

4. Depurar un código C roto suele ser mucho más sencillo que depurar un código C ++ roto.

5. A diferencia de Java / C #, la biblioteca estándar de C ++ logra poco más allá del alcance de la biblioteca estándar de C.

6. Algunos programadores famosos como Linus Torvalds (Linux) y Richard Stallman (Emacs) no les gusta C ++.

La mayoría de los programadores dan por sentado que todos consideran la calidad una alta prioridad. No siempre es así. Si está acostumbrado a C, puede parecer que C ++ está haciendo demasiado por usted detrás de escena. El rigor de la verificación de tipos en C ++ también puede parecer limitado. Mucha gente está dispuesta a arriesgarse a introducir los tipos de errores que C ++ puede ayudar a prevenir para evitar estas "molestias".

Hay tres razones en las que puedo pensar. Una es que C es más adecuado para sistemas embebidos, debido al pequeño tamaño de sus binarios y la mayor disponibilidad de compiladores de C en cualquier sistema. El segundo es la portabilidad: C es un lenguaje más pequeño y el código ANSI C se compilará en cualquier lugar. Es más fácil romper la portabilidad en C ++. El último es el propio idioma. C ++ es más difícil y definitivamente es un lenguaje muy mal diseñado. Las quejas de Torvalds se describen arriba. También puede consultar las respuestas a preguntas frecuentes de C ++ ( http://yosefk.com/c++fqa/ ).

La portabilidad puede ser un problema. A diferencia de la respuesta de Gordon Carpenter-Thomp, sugeriría que es más bien el soporte en tiempo de ejecución de diferentes versiones de libstdc ++ en diferentes versiones de linux / unix. Vea este enlace para una buena discusión sobre esto. Un pequeño extracto:

El código de soporte de tiempo de ejecución utilizado por diferentes partes de una aplicación C ++ debe ser compatible. Si una parte del programa necesita dynamic_cast o capturar objetos proporcionados por otra, ambas partes deben acordar ciertos detalles de implementación: cómo encontrar vtables, cómo desenrollar la pila, etc.

Para C ++ y algunos otros lenguajes compatibles con GCC con características similares, dichos detalles se especifican mediante una ABI de C ++. Siempre que cambie la ABI utilizada por GCC, terminará con bibliotecas incompatibles producidas por las diferentes versiones de GCC. Lo mismo es cierto para C simple, pero el C ABI es mucho más simple y ha existido por mucho más tiempo, por lo que es bastante estable.

Puedo seguir muchas sugerencias aquí en ambas direcciones. Pero al final se reduce a a) simple comparable b) complejo comparable.

No tengo ni idea de si alguien ha "inventado" una especie de medición de la complejidad del lenguaje.

En una escala de 0 a 10, probablemente calificaría C en 2 o 3, mientras que C ++ estaría entre 8-10. Yo diría que C ++ es uno de los lenguajes más complejos, pero no lo sé, por ejemplo, Ada, PL1 o similares, así que tal vez no sea tan complejo en comparación con otros lenguajes.

C ++ hereda toda la complejidad de C, por lo que no puede estar por debajo del nivel de complejidad de C.

Yo, por mi parte, me sentiría mucho más cómodo usando algún lenguaje de programación y C. Entonces, al final, uno tiene que responder la siguiente pregunta. "¿Más siempre es mejor?"

Lo más útil que encontré en C es la falta de espacios de nombres y sobrecargas: los nombres de funciones y símbolos son identificadores únicos. Para encontrar los lugares donde se utilizan estos símbolos, puede simplemente a greptravés de los archivos de código fuente y los resultados de la búsqueda mostrarán las ubicaciones.

Es esencial cuando se conecta una nueva característica o componente a un sistema viejo y enredado.

No puede hacer esto fácilmente en C ++, sin una herramienta sofisticada de creación de gráficos de llamadas.

La mayoría de la gente parece pensar que C y C ++ están relacionados de alguna manera, pero lamentablemente están equivocados. C ++ es un lenguaje completamente diferente a C.

En C ++, piensas en términos de objetos y cómo se relacionan entre sí. En C, piensas en términos de API. Es como la diferencia entre el día y el 17.

Una mala analogía: si alguien agrega chino al inglés y lo llama inglés ++, probablemente no se sienta cómodo al agregar una línea en chino a su última carta de amor, porque es mucho más fácil expresar amor en esta parte de inglés ++.

Las siguientes son todas las razones por las que puede ser beneficioso limitar un proyecto a C:

• compilación más rápida porque el lenguaje es mucho más simple
• Requiere menos soporte de tiempo de ejecución, lo que lo hace más adecuado para entornos de bajo nivel.
• mucho más fácil de interactuar con otros idiomas
• admite matrices de tamaño variable en la pila
• más fácil de leer el código ensamblador porque no hay alteración de nombres
• permite que el código producido por diferentes compiladores se combine fácilmente ya que es la interfaz binaria de aplicación estándar de facto