sirve - ¿Cuáles serían las limitaciones de C++ comparado con el lenguaje C?

lenguaje c++ ejemplos (30)

Esto es provocado por una respuesta que di a una pregunta actual que pregunta acerca de una biblioteca de genéricos para C: la persona que pregunta específicamente indica 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 C válido:

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

Para hacerlo compilar como C ++ tienes que escribir:

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

que no es válido C más. (Podría usar el molde de estilo C, en cuyo caso se compilaría en C, pero la mayoría de los estándares de codificación de C ++ lo rehuirían).

No son del mismo idioma, y si tiene un proyecto existente en C, no desea volver a escribirlo en un idioma diferente solo para usar una biblioteca. Preferiría usar bibliotecas con las que pueda interactuar en el idioma en el que está trabajando.

Tomando el primer archivo C en un proyecto en el que estoy trabajando, esto es lo que sucede si solo cambias gcc std=c99 para 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 las características que existen en C99 pero no en C ++.

No es como si estuviera usando esas características por gusto. Se necesitaría mucho trabajo para llevarlo a un idioma diferente.

Entonces, es completamente incorrecto sugerir que

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

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

Así que sugerir ''usar la clase C ++ std :: queue'' como respuesta a una pregunta buscando una implementación de biblioteca de una cola en C es posterior a sugerir ''usar el objetivo C'' y ''invocar la clase Java java.util.Queue usando JNI'' o ''llame 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 portar el código no relacionado al lenguaje C ++.

Por supuesto, podría suministrar una fachada C a la biblioteca C ++, pero una vez que lo hace, C ++ no es diferente de Java o Python.

Los siguientes son los beneficios de C ++

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

¿Existen razones concretas y escenarios específicos, donde uno tiene que usar C sobre C ++?

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

No es un duplicado, porque esta pregunta es sobre las limitaciones del lenguaje 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 temas C99 que no había considerado, así que la acepté. Gracias a todos los demás que participaron.

C is a simple language, C++ is not. For many people, C++ is simply too complicated to fully master, see http://en.wikipedia.org/wiki/C%2B%2B#Criticism .
Because of the complexity, different programmers usually only master different subsets of the language. It makes reading other people''s code painful.
The complexity, pitfalls of the language add too much distraction, and sometimes hurt productivity. Instead of focus on the job itself, I often found myself fighting with the language itself. Java/python are more productive alternatives.
Debugging a broken C code is usually much more straightforward than debugging a broken C++ code.
Unlike Java/C#, the C++ standard library achieves little beyond the scope of the C standard library.
Some famous programmers like Linus Torvalds (Linux) and Richard Stallman (Emacs) dislike C++.

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

Ese es el mismo argumento, con falacias obvias. 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 ++ simplemente no es compatible en algunos entornos del mundo real, como los sistemas integrados de bajo nivel. Y hay una buena razón para eso: C es lo suficientemente bueno para tales cosas, entonces, ¿por qué usar algo más grande?

C ++ tiene una curva de aprendizaje mucho más larga. C tiene pocas construcciones que debe tener en cuenta y luego puede comenzar a codificar un software potente. En C ++ necesitas aprender la base C, luego la OO y la programación genérica, excepción, etc. Y después de un tiempo puedes conocer la mayoría de las características y por qué puedes usarlas, pero aún no sabes cómo será el compilador. tradúzcalos, qué gastos generales implícitos tienen o no. Esto lleva mucho tiempo y energía.

Para un proyecto profesional, este argumento puede no contar, porque puede emplear personas que ya conocen muy bien C ++. Pero en proyectos de código abierto, donde aún se usa C, 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.

C tiene la ventaja principal de que puedes ver lo que realmente sucede cuando ves un fragmento de código (sí, preprocesador: compila con -E y luego lo ves). Algo que con demasiada frecuencia no es cierto cuando mira un código C ++. Ahí tienes constructores y destructores a los que se llama implícitamente según el alcance o debido a asignaciones, tienes una sobrecarga del operador 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 este no es un hábito tan malo para un desarrollador de software que quiera escribir software confiable. Solo quiero tener la oportunidad de decir que mi software hace exactamente lo que se supone que debe hacer y no tener una mala sensación en mi estómago al mismo tiempo, porque sé que aún podría haber tantos errores que no lo haría. Ni siquiera noté cuando miré el código que los causa.

C ++ también tiene plantillas. Los odio y los amo, pero si alguien dice que los entiende completamente, ¡lo llamo mentiroso! Eso incluye tanto a los escritores del compilador como a las personas involucradas en la definición del estándar (lo que se vuelve obvio cuando intentas leerlo). Hay tantos casos de esquina absurdamente engañosos involucrados que simplemente no es posible considerarlos todos mientras se escribe el código real. Me encantan las plantillas C ++ por su gran poder. Es realmente increíble lo que puedes hacer con ellos, pero también pueden llevar a los errores más extraños y difíciles de encontrar que puedas (no) imaginar. Y estos errores realmente ocurren y ni siquiera raramente. Leer acerca de las reglas involucradas para resolver plantillas en el C ++ ARM casi me hace explotar. Y me da la mala sensación de perder el tiempo al leer los mensajes de error del compilador que tienen varios miles de caracteres y que necesito 10 minutos o más para comprender lo que el compilador realmente quiere de mí. En el código típico de C ++ (biblioteca) también suele encontrar gran cantidad de 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 demasiado 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 const para todos los casos de uso menos triviales o tarde o temprano tendrá que descartarlo o refactorizar grandes partes de la base de código cuando evoluciona, especialmente cuando está a punto de desarrollar un diseño de OO agradable y flexible.

C ++ tiene un tipado más fuerte que C, lo cual es genial, pero a veces siento que estoy alimentando un Tamagotchi cuando intento compilar el código C ++. Una gran parte de las advertencias y los errores que normalmente obtengo de él no son realmente algo que no funcionaría, sino simplemente cosas que el compilador no quiere que haga de esta manera o no sin incluir o poner aquí algunas palabras clave adicionales. 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 equipos con otras personas. Casi no importa si son hackers C ++ muy ingeniosos o principiantes ingenuos. Todo el mundo comete errores, pero C ++ hace que sea deliberadamente difícil encontrarlos y aún más difícil de detectar antes de que sucedan.

Con C ++ simplemente se pierde 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 y tratar de tomar todas las ramas que tiene, incluso en subrutinas, etc. y utilizar un depurador solo de vez en cuando solo para ver qué bien funciona en todos los lugares acogedores que preparé para él. Escribir y ejecutar tantos casos de prueba que todas las rutas de código se han usado 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 grande sea un proyecto de C ++, más bajo será mi confianza de que no tendrá muchos errores no detectados, incluso si funciona perfectamente con todos los datos de prueba que tenemos a mano. Eventualmente lo arruino y comienzo de nuevo con algún otro lenguaje o combinación de otros idiomas.

Podría seguir, pero supongo que ya expliqué mi punto. Todo esto me ha hecho sentir improductivo cuando programo en C ++ y me hizo perder la confianza en la corrección de mi propio código, lo que significa que ya no lo usaré, mientras uso 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 en otros idiomas, me permite reconocer lo poco que realmente soy cuando se trata de C ++, y que nunca seré capaz de comprenderlo por completo. .

La vida es corta...

El desarrollo del kernel de Windows no admite c ++ (tristemente).

En un entorno incrustado de bajo nivel, algunos de los "ingenieros de software" tendrán un fondo EE y apenas han dominado C. C ++ es más complejo y algunos de ellos simplemente temen aprender un nuevo idioma. Por lo tanto, C se usa como el mínimo común denominador. (Antes de sugerir deshacerse de estos tipos, son al menos tan importantes como los mayores de CS que no entienden las cosas analógicas hardcore).

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 capas aleatorias de abstracción envían a tu cerebro a dar vueltas por la base del código tratando de descubrir qué código se va a ejecutar en qué circunstancias.

Si tengo que trabajar con ingenieros que sé que no producirán diseños excelentes, preferiría tener los primeros que los segundos.

Hay un montón de argumentos sobre la programación integrada, el rendimiento y otras 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 C. Debo decir que si bien hay buenas características en C ++ que hacen la vida más fácil, también hay una gran cantidad de trampas y una especie de "siempre hay una mejor manera" de hacer las cosas. En realidad nunca te alegras mucho con la solución que hiciste. (No me malinterpreten, esto podría ser algo bueno, pero sobre todo no).

C ++ te da disparos infinitos. Lo cual podría decirse que es bueno, pero de alguna manera siempre terminas usando demasiado. Esto significa que estás ocultando tus soluciones con capas "agradables" y "bonitas" de abstracciones, generalidades, etc.

Lo que descubrí volviendo a C fue que en realidad fue una programación divertida otra vez. Después de haber dedicado tanto tiempo a modelar y pensar cómo usar mejor la herencia, descubrí que la programación en C realmente hace que mi código fuente sea más pequeño y más legible. Esto, por supuesto, depende de tu nivel de autodisciplina. Pero es muy fácil poner demasiadas abstracciones en el código directo, que en realidad nunca se necesita.

Me doy cuenta de que no es ni una respuesta profesional ni una buena en particular, pero para mí es simplemente porque me gusta C. C es pequeña y simple y puedo adaptar todo el lenguaje en mi cerebro, C ++ siempre me ha parecido un gran desastre con todo tipo de capas tengo dificultades para asimilar. Debido a esto, encuentro que cada vez que escribo C ++ termino gastando mucho más tiempo depurando y golpeando mi cabeza contra superficies duras que cuando codigo C. Nuevamente me doy cuenta de que gran parte de esto es en gran parte el resultado de mi propia "ignorancia".

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

Editar: Me gustaría agregar que creo que C con algunas características C ++ es en gran medida una mala idea si va a haber varias personas trabajando en un proyecto o si el mantenimiento es una prioridad. Habrá desacuerdo en cuanto a qué constituye un ''unos pocos'' y qué bits se deben hacer en C y qué bits en C ++ conducen finalmente a una base de código muy esquizofrénica.

Me gustaría seguir la respuesta de Dan Olson. Creo que las personas temen 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:

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

Creo que la segunda razón aquí es mucho más importante que la primera, porque la decisión 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:

Puede usar contenedores stl, pero no para usar plantillas en su propio código.
La gente comienza a quejarse de que serían más productivos si solo se les permitiera codificar esta o esa clase de plantilla.
El estándar de codificación se revisa para permitir eso.
Deslice una pendiente hacia un estándar de codificación demasiado complicado que nadie sigue y utilice exactamente el tipo de código peligroso que se suponía que debía evitar el estándar, 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 como para considerarla y de todos modos no sería mucho mejor).

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

No veo ninguna razón más que disgusto personal, incluso para la programación de sistemas integrados y cosas similares. En C ++ pagas solo por las características que utilizas. Puede usar 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 algunos constructos de C ++. Déjame enumerar algunos ejemplos:

Las clases y las funciones miembro tienen una sobrecarga cero en comparación con las funciones normales (a menos que use funciones virtuales, en cuyo caso no hay gastos generales en comparación con el uso de indicadores de funciones)
Las plantillas tienen muy poca sobrecarga (la mayoría de las veces no tienen gastos generales)

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

Nunca he visto argumentos para utilizar C sobre C ++ que consideraría convincentes. Creo que la mayoría de la gente le teme a ciertas características que ofrece C ++, a menudo justificadamente. Sin embargo, esto no me convence porque uno puede exigir el uso o no de ciertas características a través de estándares de codificación. Incluso en C, hay mucho que te gustaría evitar. Descartar C ++ en su totalidad es esencialmente decir que no ofrece beneficios tangibles sobre C que ayudaría a uno a escribir un código mejor, que es una vista que considero bastante ignorante.

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

Odio la programación 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 que son compatibles con C ++. Y algunos compiladores de C ++ generan un código ineficaz e inflado. 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. Todavía puede escribir código C ++ si se atiene al núcleo del idioma, pero luego puede ser más simple cambiar a C.
Familiaridad. C ++ es un lenguaje complejo. Es más fácil enseñarle a alguien C que a C ++, y es más fácil encontrar un buen programador en C que un buen programador en C ++. (la palabra clave aquí es "buena". Hay muchos programadores de C ++, pero la mayoría no aprendió el idioma correctamente)
Curva de aprendizaje: como se indicó anteriormente, enseñar a alguien en C ++ es una tarea enorme. Si está escribiendo una aplicación que otros deben mantener en el futuro, y estos otros pueden no ser programadores de C ++, escribirla en C lo hace mucho más fácil de entender.

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

Un punto que no he visto planteado aún, 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 ajustar las bibliotecas C con 19 enlaces de idiomas diferentes de lo que es. envolver las bibliotecas de C ++.

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

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

C ++ es probablemente un mejor lenguaje si está escribiendo una función para usar 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 idioma desde el principio.

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

No quiero molestias ABI mal definidas.

I can follow many suggestions here in both directions. But in the end it comes down to a) comparable simple b) comparable complex.

I don''t have an idea if someone has "invented" a sort of language complexity measurement.

On a scale from 0 - 10 I probably would rate C at 2 or 3 whereas C++ would be between 8-10. I''d argue C++ is one of the most complex languages but I do not know eg Ada, PL1 or the like, so maybe it''s not that complex in comparison to some other language.

C++ inherits all complexity of C so it can not be below the complexity level of C.

I for my part would be much more comfortable using some scripting language and C. So in the end one has to answer the following question. "Is more always better?"

I can think of several reasons.

There may not be a satisfactory C++ compiler. C++ is a much bigger language, and I''ve run C compilers on systems that would not be able to handle modern C++.

The questioner, or people he or she works with, may be familiar with C but not C++.

The project may be in C. While it''s possible to add some C++ features to C, that can easily lead to an unmaintainable mess. I''d suggest picking one language or the other (usually C++, when practical).

The questioner may have an obsolete view of C++''s learning curve. (When approached correctly, it''s easier than C''s. Most introductory books I''ve seen don''t approach it correctly.)

Remember that C and C++ are two different languages, and are getting more different over time. Coding in both at once is a bad idea, and using a C-like subset of C++ misses most of the advantages of C++.

I think C is more portable. I did some work about 5 years ago porting code to many flavours of unix (AIX,Irix,HPUX,Linux). The C code was easy to port but we had various problems porting some of the C++ code across. Maybe it was just immature development environments but i would much rather use C over C++ for this reason...

I use C++ with C programming for two reasons:

vector and string to get the array memory management away from me
strict type checking and casts to warn and/or catch allthe nuisances I would miss otherwise.

So it is C really borrowing a few c++ but using the c++ compiler as much as I can. As someone else says in the answers, I find now I am actually picking up more C++ this way and where C would be too involving, I use C++. Monitor/Lock using RAII is one of these I''ve used recently when dealing with multi-threaded programs and another similar construct to open/close files.

If you work in an environment with two languages, you might use C for some performance critical low-level functions and a more functional/high level language like C#/Java for the business logic. If C++ code is usedfor these functions ,C-Wrappers are required for JNI/unmanaged code around and this makes things more complex than solely using C.

Most people seem to think that C and C++ are somehow related, but they are sadly mistaken. C++ is a completely different language than C.

In C++, you think in terms of objects and how they are related to each other. In C, you think in terms of APIs. It''s like the difference between day and 17.

A poor analogy: if someone adds Chinese to English and calls it English++, you probably wouldn''t feel comfortable to add a Chinese line to your latest love letter, because it''s so much easier to express love in this part of English++.

Most programmers take it for granted that everyone considers quality a high priority. That''s not always the case. If you''re use to C, C++ might seem like it''s doing too much for you behind the scenes. The strictness of type checking in C++ might also seem confining. Many people are willing to risk introducing the kinds of bugs that C++ can help prevent to avoid these "nuisances."

Native code on a mac is objective-c. Native code on a PC is c (window.h) or c++ (mfc). Both of these environments will let you use c with little or no changes. When I want a library of code to be cross platform ansi c seems like a good choice.

Portability may be an issue. Different to Gordon Carpenter-Thomp''s answer, I would suggest that it''s rather the runtime support of different versions of libstdc++ on different linux/unix versions. See this link for a good discussion about this. A little excerpt:

The runtime support code used by different parts of a C++ application needs to be compatible. If one part of the program needs to dynamic_cast or catch objects provided by another, both parts must agree on certain implementation details: how to find vtables, how to unwind the stack, and so on.
For C++ and a few other GCC-supported languages with similar features, such details are specified by a C++ ABI. Whenever the ABI used by GCC changes you''ll end up with incompatible libraries produced by the different GCC versions. The same is true for plain C, but the C ABI is much simpler and has been around a lot longer so it''s fairly stable.

The following are all reasons why it may be beneficial to limit a project to C:

faster compilation because the language is much simpler
requires less runtime support, making it more suitable low-level environments
much easier to interface with other languages
supports variable sized arrays on the stack
easier to read assembly code because there is no name mangling
allows code produced by different compilers to be easily combined since it is the de facto standard application binary interface

The most useful thing I found in C is the lack of namespaces and overloads: function and symbol names are unique identifiers. To find the places where these symbols are used you can just grep through the source code files and search results will shows the locations.

It''s essential when wiring in a new feature or component to an old and tangled system.

You cannot do this easily in C++, without a sophisticated call graph building tool.

There are three reasons I can think of. One is that C is more suited for embedded systems, due to the small size of its binaries and the wider availability of C compilers on any system. The second is portability: C is a smaller language, and and ANSI C code will compile anywhere. It''s easier to break portability in C++. The last one is the language itself. C++ is harder, and is most definitely a very poorly designed language. Torvalds gripes are reported above. You may also want to look at the C++ Frequently Questioned Answers ( http://yosefk.com/c++fqa/ ).

You can read an entertaining rant about why Linus Torvalds favours C here