Estoy desarrollando una aplicación para Embedded Linux (ARM). Se ejecutará 500 veces por segundo, por lo que la velocidad es importante. Preferiría usar C++, pero me temo que será más lento que C, incluso si evito funciones sofisticadas como funciones virtuales. ¿Hay alguna razón para usar C o es igual de bueno escribir en C++?
Martín Beckett
C++ en general no sufre ninguna penalización de tiempo de ejecución sobre C – (excepto por algunas cosas como RTTI).
Excepto en algunas circunstancias extrañas, el compilador debería poder determinar qué función virtual llamar en el momento de la compilación y, por lo tanto, no agregar gastos generales.
Editar: Ok, con tal variedad de compiladores, CPU, bibliotecas de tiempo de ejecución, sistemas operativos, hay algunas características de C ++ que pueden crear un código más lento, hay algunas características que pueden crear un código más rápido.
Pero, ¿podemos estar todos de acuerdo en que C++ no se excluye automáticamente de incorporado usar más?
-
Si usa C ++ como “C feo” (cambios adicionales por todas partes), entonces lo que ha dicho es cierto. Pero tan pronto como comience a usar cualquier cosa que haga que C++ sea “cómodo”, habrá muchos más gastos generales que no se pueden optimizar.
– R.. GitHub DEJA DE AYUDAR A ICE
28 de febrero de 2011 a las 21:34
-
Las funciones y plantillas virtuales deben tener un costo cero. La excepción es el costo cero si no se llama a ningún compilador decente. Dynamic_cast normalmente funcionará sin RTTI, con algunas advertencias. El tamaño del código puede ser un problema, pero depende de lo que entiendas por incrustado, por supuesto.
– Martín Beckett
28 de febrero de 2011 a las 22:00
-
Las excepciones tienen un costo negativo cuando puede eliminar el manejo de errores C del flujo de código normal. Los optimizadores pueden optimizar fácilmente para el caso de no excepción, pero no saben si una función C devuelve 0,1 o -1 en caso de error.
– MSalters
1 de marzo de 2011 a las 8:43
-
¡Utilizo C++ 11 y metaprogramación en un ARM integrado con 32K de flash! Descubrí que si usa un compilador moderno (yo uso GCC 4.6) puede transferir el código C a C ++ y, a veces, ver que el tamaño disminuye. constexpr es una herramienta importante.
– odinthenerd
28 de junio de 2013 a las 18:18
-
Los contenedores STL (implementados con plantillas) son, de hecho, una gran ventaja si tiene estructuras de datos significativas en su código. Las implementaciones son tan buenas como es posible obtener, y probablemente mejores que las que escribiría usted mismo. También puede asignar asignaciones en grupo si es necesario.
– marko
28 de junio de 2013 a las 18:18
j4x
En C++, tiene cosas como la metaprogramación de plantillas que resuelven en tiempo de compilación varias situaciones en las que C o cualquier otro lenguaje de programación de procedimientos tendría que funcionar en tiempo de ejecución.
Debería decir más. La metaprogramación de plantillas y algunos trucos de herencia de clases son realmente sorprendentes. Puede ahorrarle una gran cantidad de tiempo de procesamiento que, de lo contrario, gastaría “ifing” y “switching”.
Esto significa que C++ puede ser más rápido que C si se lleva a cabo correctamente.
Obviamente, puedes programar “en C” usando C++ y no tendrías ninguna penalización. Si no eres muy aficionado a C++, te aconsejo que hagas un “C en C++” o “C con extensiones de C++” solo para aprovechar las mejoras de C++, pero la verdadera ventaja que tendrás es programando el C++ forma. Ahí verás que C++ esbuena parte de los tiempos, o más rápido o más limpio que C o, al menos tan rápido como.
No tener miedo. Cara C++. Después de stdc++ (contra libc) casi no habrá sobrecarga en el tamaño del código. Si su aplicación es de tamaño mediano a alto, se diluirá.
Uso C++ desde el simple ATmega de 8 bits hasta el ARM9 de Marvell, pasando por AVR32 UC3 y Cortex-M3 y siempre lo encuentro rentable.
Si necesita asesoramiento específico en una situación determinada, no dude en preguntar.
-
Esa es la respuesta que esperaba. C ++ es mucho más divertido de escribir, incluso para cosas simples como poder declarar una var cuando la necesita (a diferencia del comienzo del bloque en C). Y por eso prefiero la encapsulación de clases frente a las funciones globales de C. Espero evitar la asignación de memoria dinámica o cualquier cosa exótica.
– Gregory Khrapunovich
3 de marzo de 2011 a las 22:28
-
las ventajas de C++ en el mundo integrado son de gran alcance. Descubrí que __attribute((always_inline)) es una bendición al hacer que las interfaces abstractas se compilen en la nada y solo dejen una verificación estática más fuerte de las cosas importantes.
– odinthenerd
28 de junio de 2013 a las 18:12
La razón principal para elegir C sobre C++ es el tamaño del binario compilado, que puede ser una restricción real para los sistemas integrados.
En el rendimiento, no hay una diferencia medible, si usa el idioma correctamente. Puede escribir código C lento con la misma facilidad que C ++ lento, siempre que esté al tanto de los mecanismos ocultos de lo que está escribiendo, debería estar bien con cualquiera de los dos.
-
La diferencia de tamaño es insignificante, siempre que la versión C sea funcionalmente equivalente a la versión C++. Por ejemplo, si la versión C++ usa herencia, la versión C también debe codificar el equivalente, sin atajos. En mi experiencia, el tamaño no es un problema.
– Thomas Matthews
28 de febrero de 2011 a las 20:02
-
@Thomas: esto simplemente no es cierto, porque gran parte del código de la biblioteca que se obtiene tendrá un gran superconjunto de la funcionalidad requerida, y el enlazador no tiene forma de determinar qué partes se pueden omitir. Enlace estático un programa C hello world con cualquier biblioteca C sana (cualquiera de los BSD, uClibc, Bionic, etc., pero no glibc cuyo stdio está esencialmente escrito en C++) y compare un programa C++ enlazado estático equivalente usando iostream.
– R.. GitHub DEJA DE AYUDAR A ICE
28 de febrero de 2011 a las 21:37
-
@R..: si selecciona una implementación apropiada de libc, debe ser justo y seleccionar un iostream igualmente apropiado. Dietmar Kuehl demostró (hace unos 10 años) que Hello, World puede ser más pequeño en C++. Razón simple: el enlazador poder eliminar
operator<<ostream&, float)pero nocase 'f':desde elprintf()implementación.– MSalters
1 de marzo de 2011 a las 8:46
-
el tamaño de la biblioteca (teóricamente hablando) puede ser un problema en algunos entornos, pero la pregunta original menciona Linux incorporado, por lo que es un sistema de al menos 32 bits y el sistema operativo en sí es lo suficientemente grande. Así que dudo que el tamaño importe en este caso 🙂
– usuario396672
1 de marzo de 2011 a las 9:48
-
Actualmente estoy construyendo un sistema integrado basado en Linux donde elegí agregar más flash al dispositivo para poder incluir las bibliotecas dinámicas de c ++. Entonces, al menos para mí, el tamaño fue un factor real.
– Erik
1 de marzo de 2011 a las 9:51
Siempre que limite las funciones que usa, no tendrá mucho impacto en el rendimiento, si es que lo tiene, en C++ sobre C. Las funciones que querrá evitar incluyen: excepciones, RTTI y mantenga su jerarquía de clases lo más plana posible. (y use funciones virtuales con moderación).
C ++ está bien siempre que tenga suficiente RAM y flash en su sistema integrado. La biblioteca de tiempo de ejecución de C++ (libstdc++) es grande y se suma a la biblioteca estándar de C (libc), incluso si solo usa C++.
-
En un sistema integrado, solo se incluyen las bibliotecas que se necesitan. Las bibliotecas utilizadas para una versión de escritorio suelen ser mucho más grandes y no tienen correlación de tamaño. Falso sobre cuestiones de tamaño. Ver mi otra publicación en SO.
– Thomas Matthews
28 de febrero de 2011 a las 20:03
-
Es un movimiento audaz argumentar en contra del hecho de que libstdc++ requiere ram y flash…
– GT.
28 de febrero de 2011 a las 20:43
-
@Thomas: Me gustaría verte encontrar una manera de hacer
libstdc++pequeño.uClibc++existe por una razón; por desgracia es bastante incompleto.– R.. GitHub DEJA DE AYUDAR A ICE
28 de febrero de 2011 a las 21:38
Comunidad
Puedes usar C++ pero ten mucho cuidado.
Para el tamaño, vigile de cerca su archivo de mapa del enlazador. Puede encontrarlo incluyendo toneladas de cosas que no necesita, solo a partir de una declaración de aspecto inocente.
Para velocidad, perfil o pausa aleatoria a menudo. Es muy fácil hacer más newarena deletes de lo que realmente necesita, especialmente con las clases contenedoras, y tenga mucho cuidado con cosas como los iteradores. A menudo te están haciendo favores que no has pedido.
Puede recorrer el código en el nivel del lenguaje ensamblador para asegurarse de que solo está haciendo lo que realmente necesita, que debería ser casi igual que el código C.
-
En un sistema integrado, solo se incluyen las bibliotecas que se necesitan. Las bibliotecas utilizadas para una versión de escritorio suelen ser mucho más grandes y no tienen correlación de tamaño. Falso sobre cuestiones de tamaño. Ver mi otra publicación en SO.
– Thomas Matthews
28 de febrero de 2011 a las 20:03
-
Es un movimiento audaz argumentar en contra del hecho de que libstdc++ requiere ram y flash…
– GT.
28 de febrero de 2011 a las 20:43
-
@Thomas: Me gustaría verte encontrar una manera de hacer
libstdc++pequeño.uClibc++existe por una razón; por desgracia es bastante incompleto.– R.. GitHub DEJA DE AYUDAR A ICE
28 de febrero de 2011 a las 21:38
chris stratton
La clave real para el código eficiente en tamaño y velocidad, incrustado o no, es que el programador comprenda completamente las implicaciones de sus decisiones.
Hasta cierto punto, C++ brinda más oportunidades donde algo costoso puede parecer engañosamente inocente. La funcionalidad equivalente a las características de C++ a menudo requiere más tinta en la página, lo que puede conducir a una mayor contemplación de su gasto potencial. Pero de ninguna manera es un absoluto: C (y sus bibliotecas) también tiene el riesgo de un gasto engañosamente inocente.
En última instancia, no hay sustituto para comprender lo que ha pedido en cada línea de código.
La función virtual no es una de las cosas que debe evitar. Implementar la misma funcionalidad en C manualmente no será más rápido que la versión generada por el compilador, y el compilador de C++ es bueno para optimizarla cuando no se necesita.
– Martín York
28/02/2011 a las 20:00
@Martin tiene razón. Las funciones virtuales solo cuestan una o dos instrucciones para llamar, y si eso es realmente lo que necesita, tendría que hacerlo de todos modos en C.
–Mike Dunlavey
28 de febrero de 2011 a las 20:44
Algunas lecturas relacionadas interesantes aquí: stackoverflow.com/questions/2039444/…
– Émile Cormier
28 de febrero de 2011 a las 20:54
Pruebe tanto C como C++, luego mida los archivos binarios resultantes en el dispositivo integrado. Si no desea escribir 2 versiones de la aplicación, simplemente use el lenguaje con el que se sienta más cómodo (C++).
– pmg
28 de febrero de 2011 a las 21:19