Coisas sobre C ++ que deixam os programadores em C nervosos
Há muita mágica acontecendo sob o capô; construtores, destruidores, métodos virtuais, modelos etc. podem tornar o código C ++ muito mais fácil e rápido de escrever do que o código C equivalente, mas mais difícil de entender e raciocinar (dependendo de quão bem você conhece C ++ e suas convenções associadas). Algo tão simples quanto Foo newFoo;invocar muito código, dependendo de como o construtor da classe Foo(e de qualquer classe de que dependa) foi definido. É também por isso que a convenção é escrever em ++itvez de it++iterar em um contêiner, pois o postfix ++geralmente envolve uma operação de cópia cara.
Dependendo do que você está fazendo, pode haver uma sobrecarga não trivial, especialmente para tarefas simples. Tome os dois programas a seguir, o primeiro em C, o segundo em 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 */
Comportamento idêntico, não muita diferença em termos de origem, mas na caixa SLES 10 em que trabalho com o gcc 4.1.2, o primeiro gera um executável de ~ 9kb de tamanho, enquanto o segundo ocupa 12,5kb (sem otimização ), quase 28% maior. O stringtipo C ++ é muito mais fácil de trabalhar com IMO do que a biblioteca de cadeias C, e os fluxos C ++ são muito mais flexíveis e personalizáveis que os fluxos C, mas, para códigos realmente inoperantes como esse, eles podem não valer a pena.
C ++ é uma linguagem enorme em comparação com C, com algumas semânticas extremamente complexas. Demora muito mais tempo para obter proficiência em C ++ do que em C, o que significa que muitas pessoas que afirmam conhecer C ++ não o conhecem tão bem quanto pensam.
Coisas sobre C que deixam os programadores em C ++ nervosos
C não é uma linguagem de programação segura por qualquer extensão da imaginação; nenhuma verificação de limites em matrizes leva a muitos comportamentos exploráveis (seja através da getsfunção agora desativada ou através scanfdos especificadores %se de %[conversão). C ++ pelo menos fornece contêineres que lançam exceções se você tentar acessar fora do intervalo definido atualmente; tudo o que C fornece é (se você tiver sorte) uma violação de segmentação.
O gerenciamento de memória em C é muito trabalhoso e propenso a erros, em comparação com as ferramentas que o C ++ fornece. Se você estiver construindo seu próprio contêiner, será responsável por fazer a correspondência de todas as chamadas malloce free, garantir que as alocações sejam bem-sucedidas, fazer backup de alocações parciais em caso de erro, etc. No C ++, você apenas adiciona itens a ou remova itens do contêiner. Se houver algum problema, uma exceção será lançada.
Da mesma forma, o tratamento de erros em C é um problema, comparado às ferramentas que o C ++ fornece (ou seja, exceções). O que é realmente divertido é quando você aloca um monte de memória e bate em uma parede no seu processamento; como você precisa se afastar, precisa liberar essa memória na ordem certa. Com os princípios C ++ e RAII, isso é (relativamente) fácil de fazer.
Então, quando uso um sobre o outro?
Se o que você está escrevendo é um pântano simples, leia-o / elimine-o / elimine-o, cujo comportamento pode ser descrito de maneira limpa em termos de entradas e saídas e questões de desempenho, em seguida, prefira C sobre C ++. Caso contrário, prefira C ++