Cosas sobre C ++ que ponen nerviosos a los programadores de C
Hay mucha magia sucediendo debajo del capó; constructores, destructores, métodos virtuales, plantillas, etc., pueden hacer que el código C ++ sea mucho más fácil y rápido de escribir que el código C equivalente, pero más difícil de entender y razonar (dependiendo de qué tan bien conozca C ++ y sus convenciones asociadas). Algo tan simple como Foo newFoo;invocar una gran cantidad de código, dependiendo de cómo Foose haya definido el constructor de la clase (y cualquier clase de la que dependa). Esta es también la razón por la cual la convención es escribir en ++itlugar de it++iterar a través de un contenedor, ya que el postfix a ++menudo implica una operación de copia costosa.
Dependiendo de lo que esté haciendo, puede haber una sobrecarga no trivial, especialmente para tareas simples. Tome los siguientes dos programas, el primero en C, el segundo en C ++:
/* C version */
#include <stdio.h>
int main(void)
{
char greeting[] = "Hello, world";
printf("%s\n", greeting);
return 0;
}
/* end C version */
/* C++ version */
#include <iostream>
#include <string>
int main(void)
{
std::string greeting("Hello, world");
std::cout << greeting << std::endl;
return 0;
}
/* end C++ version */
Comportamiento idéntico, no hay mucha diferencia en términos de fuente, pero en el cuadro SLES 10 en el que trabajo con gcc 4.1.2, el primero genera un ejecutable de ~ 9 kb de tamaño, mientras que el segundo ocupa más de 12.5 kb (sin optimización ), casi un 28% más grande. El stringtipo C ++ es mucho más fácil de trabajar con IMO que la biblioteca de cadenas C, y las secuencias C ++ son mucho más flexibles y personalizables que las secuencias C, pero para un código realmente cerebral como este, puede que no valga la pena la sobrecarga.
C ++ es un lenguaje enorme en comparación con C, con algunas semánticas extremadamente complejas. Se necesita mucho más tiempo para dominar C ++ que C ++, lo que significa que muchas personas que afirman conocer C ++ no lo saben tan bien como creen.
Cosas sobre C que ponen nerviosos a los programadores de C ++
C no es un lenguaje de programación seguro por ningún tramo de la imaginación; no hay comprobación de límites en matrices conduce a un montón de comportamiento explotable (ya sea a través del ahora muerto getsfunción, o mediante scanfel %se %[indicadores de conversión). C ++ al menos le ofrece contenedores que arrojan excepciones si intenta acceder fuera de su rango definido actualmente; todo lo que C te da es (si tienes suerte) una violación de segmentación.
La administración de memoria en C es muy laboriosa y propensa a errores, en comparación con las herramientas que le proporciona C ++. Si está creando su propio contenedor, es responsable de hacer coincidir todas las llamadas mallocy free, asegurarse de que las asignaciones sean exitosas, anular cualquier asignación parcial en caso de error, etc. En C ++, simplemente agrega elementos a Retire los artículos del contenedor. Si hay un problema, se lanzará una excepción.
Del mismo modo, el manejo de errores en C es una molestia en comparación con las herramientas que proporciona C ++ (es decir, excepciones). Lo que es realmente divertido es cuando has asignado un montón de memoria y luego golpeas una pared en tu procesamiento; como debe retroceder, debe liberar esa memoria en el orden correcto. Con los principios C ++ y RAII, esto es (relativamente) fácil de hacer.
Entonces, ¿cuándo uso uno sobre el otro?
Si lo que estás escribiendo es un simple pantano, léelo / muck con él / deshazte de su aplicación, cuyo comportamiento se puede describir de manera clara en términos de entradas y salidas, y el rendimiento es importante, luego prefiere C sobre C ++. De lo contrario, prefiera C ++