Про C ++, які нервують програмістів на C
Під кришкою відбувається багато магії; конструктори, деструктори, віртуальні методи, шаблони тощо можуть зробити C ++ кодом набагато простіше і швидше написати, ніж еквівалентний код C, але важче зрозуміти та аргументувати їх (залежно від того, наскільки добре ви знаєте C ++ та пов'язані з ним умови). Щось таке просте, як Foo newFoo;може викликати багато коду, залежно від того, як було визначено конструктор для класу Foo(та будь-яких класів, від яких це залежить). Ось чому умовна умова полягає в написанні ++itзамість it++ітерації через контейнер, оскільки постфікс ++часто передбачає дорогу операцію копіювання.
Залежно від того, що ви робите, можуть бути деякі нетривіальні накладні витрати, особливо для простих завдань. Візьміть дві наступні програми: перша на C, друга в 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 */
Ідентична поведінка, не велика різниця в джерелі, але на графі SLES 10, над якою я працюю з gcc 4.1.2, перший генерує виконуваний файл розміром ~ 9 кб, тоді як другий займає 12,5 кбіт (без оптимізації) ), майже на 28% більше. Тип C ++ stringнабагато простіше працювати з IMO, ніж бібліотека струн C, а потоки C ++ набагато гнучкіші та налаштованіші, ніж потоки C, але для справді таких, як мозг мертвих кодів, вони можуть не коштувати накладних витрат.
C ++ - це величезна мова порівняно з C, яка має надзвичайно складну семантику. Знадобитися набагато більше часу, щоб здобути знання C ++, ніж C, тобто багато людей, які стверджують, що знають C ++, не знають цього добре, як вони думають.
Про C, які нервують програмістів на C ++
C не є захищеною мовою програмування за будь-якої ділянки уяви; ніяких обмежень перевірки на масивах не приводить до великої кількості вразливостей поведінки (будь то через нині мертвої getsфункції, або через scanfз %sта %[специфікаторів перетворення). C ++ принаймні надає вам контейнери, які викидають винятки, якщо ви намагаєтесь отримати доступ поза їх визначеним на даний момент діапазоном; все, що дає C, - це (якщо вам пощастило) порушення сегментації.
Управління пам'яттю в C дуже трудомістке і схильне до помилок, порівняно з інструментами, які надає C ++. Якщо ви створюєте власний контейнер, ви несете відповідальність за узгодження всіх mallocта freeвикликів, переконуючись, що розподіли є успішними, резервне копіювання будь-яких часткових розподілів у разі помилки тощо. У C ++ ви просто додаєте елементи до вийміть предмети з контейнера. Якщо є проблема, буде викинуто виняток.
Аналогічно, поводження з помилками в C - це біль у попці порівняно з інструментами, які надає C ++ (а саме - винятки). Що насправді цікаво - це коли ти виділив купу пам’яті, а потім потрапив у стіну під час обробки; як вам доведеться відмовитися, ви повинні звільнити цю пам'ять у потрібному порядку. З принципами C ++ та RAII це зробити (відносно) просто.
То коли я використовую один над іншим?
Якщо те, що ви пишете, - це просто багняне прочитання, прочитайте його / розмовляйте з ним / позбудьтесь його програми, поведінку якої можна чітко описати з точки зору входів та результатів, а також щодо продуктивності, тоді віддайте перевагу C над C ++. В іншому випадку віддайте перевагу C ++