Якими були б обмеження C ++ порівняно з мовою C? [зачинено]


116

Нижче наведено переваги C ++

  • C ++ надає конкретні функції, про які вони запитують
  • Їх компілятор C майже напевно є компілятором C ++, тому жодних наслідків щодо вартості програмного забезпечення немає
  • C ++ так само портативний, як і C
  • Код C ++ може бути таким же ефективним, як і C (або більше, або менше)

Чи є конкретні причини та конкретні сценарії, коли доводиться використовувати C над C ++?

Посилання на це запитання: Бібліотека для генеричної мови в С

Не дублікат, оскільки це питання задає питання про обмеження мови, а не про те, чи слід / не слід вивчати одну мову над іншою.

Пост Пітера Кірхема був для мене найбільш інформативним, особливо стосовно питань С99, які я не розглядав, тому я його прийняв. Дякуємо всім, хто взяв участь.


12
Це не має значення , на це питання , є чи призначений бути аргументованими чи ні, він все ще є. Вибір мови для проекту саме такий: вибір.
Бомбе

7
@bombe, ми не повинні обговорювати, як робити усвідомлений вибір?



10
Хіба не іронічно, коли ви даєте поради програмістам на C, щоб перейти до C ++, що вони приблизно так само сприйнятливі до вашої ідеї, як і ви, якби програміст C сказав вам, що ви повинні кинути C ++ і перейти до C?
Warren P

Відповіді:


136

Це підказує відповідь, яку я дав на поточне запитання, яке запитує про бібліотеку генерики для C - запитуючий конкретно заявляє, що вони не хочуть використовувати C ++.

C - повна мова програмування. C не є довільним підмножиною C ++. C взагалі не є підмножиною C ++.

Це дійсно C:

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

Щоб скласти його як C ++, потрібно написати:

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

що більше не є C. (ви можете використовувати C-стиль в ролі; в такому випадку він буде компілюватися в C, але його уникають більшість стандартів кодування C ++, а також багато програмістів на C; засвідчуйте коментарі "не кидайте malloc" у всьому Stack Overflow) .


Вони не є однаковою мовою, і якщо у вас є проект на C, ви не хочете переписувати його на іншій мові просто для використання бібліотеки. Ви б вважали за краще використовувати бібліотеки, до яких можна інтерфейсувати мовою, на якій ви працюєте. (У деяких випадках це можливо за допомогою декількох extern "C"функцій обгортки, залежно від того, яким є шаблон / вбудована бібліотека C ++.)

Знімаючи перший файл C у проекті, над яким я працюю, це те, що відбувається, якщо ви просто поміняєте gcc std=c99на 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

Загалом 69 рядків помилок, чотири з яких є недійсними перетвореннями, але здебільшого для функцій, які існують у C99, але не в C ++.

Це не так, як я використовую ці функції для задоволення. Знадобиться значна робота, щоб перенести його на іншу мову.

Отже, це неправильно припускати

[a] Компілятор C майже напевно є компілятором C ++, тому жодних наслідків щодо витрат на програмне забезпечення немає

Часто існують значні наслідки щодо витрат на перенесення існуючого коду С до процедурного підмножини C ++.

Отже, запропонувати «використовувати клас C ++ std :: queue» як відповідь на запитання про пошук бібліотеки черги в C, ніж далі, ніж пропонувати «використовувати ціль C» та «викликати клас Java java.util.Queue за допомогою JNI» або "зателефонуйте в бібліотеку CPython" - ціль C насправді є належним набором C (включаючи C99), і бібліотеки Java і CPython обидва можуть телефонувати безпосередньо з C без необхідності пересилати незв'язаний код на мову C ++.

Звичайно, ви можете надати C-фасад до бібліотеки C ++, але коли ви це робите, C ++ не відрізняється від Java або Python.


21
Так. C-стиль акторського складу є звичайним, коли ви використовуєте malloc. Використовуючи malloc, ви робите це в межах підмножини c. Якщо ви хочете запрограмувати стиль C ++, ви використовуєте новий оператор, а не static_cast + malloc.
Сума

33
Сказати, що C не є підмножиною C ++, неймовірно педантично. Звичайно, ви можете сказати, що будь-яка структура з членом, який називається "class", не буде компілюватися, але насправді потрібні лише незначні модифікації, і більшість компіляторів мають варіанти додати декілька функцій, лише для C, до C ++.
Kaz Dragon

27
що стосується вашого прикладу malloc, додавання амплуа буде не просто ухилятися програмістами C ++, але й (особливо) програмістами C. Є вагомі причини, щоб не залишити анотацію в коді С. Це не обов'язково, і додавання цього може приховати помилки. Тож так, ставитесь до них як до двох різних мов. +1 :)
jalf

26
@BlueRaja Уявіть собі, якби Гвідо вирішив не додавати об’єкти до своєї мови сценаріїв, а дві групи створили взаємно несумісні форки Python для додавання об'єктів, одна з об'єктною моделлю на основі Smalltalk, а інша із класовою системою на основі Simula. Тоді Гвідо продовжував удосконалювати Python, зосереджуючи своє основне використання. Це ближче до ситуації C / Цілі C / C ++.
Піт Кіркхем

11
@BlueRaja: Це дві різні мови, які мають досить велике загальне ядро. Якщо ви програмуєте в цьому загальному ядрі, ви збираєтеся закінчити робити речі, які не є гарним кодом на будь-якій мові. Виберіть одну мову, щоб написати будь-яку програму, і зробіть її хорошою на цій мові.
Девід Торнлі

115

Я усвідомлюю, що це не є професійною, ані особливо хорошою відповіддю, але для мене це просто тому, що мені дуже подобається C. C невеликий і простий, і я можу вмістити всю мову в моєму мові, C ++ мені завжди здавався величезним розкиданим безладом з усіма видами шарів у мене важко грозити. Завдяки цьому я вважаю, що щоразу, коли пишу С ++, я закінчую витрачати набагато більше часу на налагодження та удари головою об тверді поверхні, ніж коли я кодую С. Знову я усвідомлюю, що багато цього значною мірою є результатом мого власного «незнання».

Якщо я вирішу вибрати, я напишу всі матеріали на високому рівні, такі як інтерфейс та взаємодія бази даних в python (або, можливо, C #), і всі речі, які повинні бути швидкими в C. Для мене це дає найкраще з усіх світів. Якщо писати все на C ++, ви хочете отримати найгірше з усіх світів.

Редагувати: Я хотів би додати, що я думаю, що C з кількома функціями C ++ є значною мірою поганою ідеєю, якщо у вас буде кілька людей, які працюють над проектом або якщо пріоритетність ремонту є пріоритетною. Буде розбіжність щодо того, що являє собою "кілька", і які біти слід зробити в C, а які біти в C ++, що призведе в підсумку до дуже шизофренічної бази даних.


24
Я використовував C ++ протягом декількох років і все ще витрачав 50% свого часу на рефакторинг, щоб бути "правильним C ++". Як ви кажете, це кошмар.
Кай

12
Ви завжди могли зробити це правильно з першого разу. Додавати const не складно.
GManNickG

14
Я використовував C ++ протягом десяти років, а повернення до C (для вбудованих систем у моєму випадку) було найкращим, що я коли-небудь робив.
Warren P

Я люблю цю відповідь. Ти теж прибив мої почуття. У мене були роки роботи як розробник C ++, моя щоденна робота все ще є C ++. Але це не означає, що мені подобається мова, я бачу красу в C.
Метт Столяр

10
+1, В зв'язку з цим я вважаю , що кожен раз , коли я пишу C ++ Я в кінцевому підсумку витрачають набагато більше часу для налагодження і стукати головою об тверду поверхню , ніж коли я коду C . Не можу більше погодитися з вами. Найкраща відповідь. :)
УченьHacker

58

C ++ просто не підтримується в деяких реальних умовах, як-от вбудовані системи низького рівня. І для цього є вагома причина: C легко досить хороший для таких речей, тож навіщо використовувати щось більше?


2
Правильно. Я бачив компілятори c для 8-бітових мікроконтролерів.
dmckee --- кошеня колишнього модератора

6
звичайно. У більшості, якщо не у всіх 8-бітових мікросхемах є компілятори C в наші дні.
Елі Бендерський

gbdk.sourceforge.net - GBDK для одного ..
Kelden Cowan

+1 це правильна відповідь. Компілятори на C ++ набагато складніше написати, ніж компілятори С, значною мірою через складність успадкування (багаторазове).
BlueRaja - Danny Pflughoeft

9
@BlueRaja: порівняно з шаблонами ... множинне успадкування може бути не справжнім стримуючим фактором. Адже шаблони складають повноцінну власну мову.
Матьє М.

49

Я ненавиджу програмування на C ++.


6
Лол мені подобається той
Тамас Цінеге

30
Дуже переконливо! Я думаю про перехід на Python на основі ваших аргументів.
Jimmy J

8
Можливо, не переконливо, але це справжня причина.
Георг Шоллі

@Jimmy J: Python неймовірний. Це найкраще для Unix, C та всіх ваших "сучасних" мовних функцій, зроблених правильно. Якщо у вас є проблеми з працездатністю, Python хоче, щоб ви потрапили в C, і це зробити легко.
Метт Столяр

2
@Georg: Я визнаю, що ніколи не дивився, я так вражений Python.
Метт Столяр

38

Причиною можуть бути:

  • Відсутність підтримки - Не кожен компілятор C також є компілятором C ++. Не всі компілятори особливо відповідають стандарту, навіть якщо вони заявляють, що підтримують C ++. А деякі компілятори C ++ генерують безнадійно роздутий і неефективний код. Деякі компілятори мають жахливі реалізації стандартної бібліотеки. Розробка в режимі ядра зазвичай не дозволяє використовувати стандартну бібліотеку C ++, а також деякі мовні функції. Ви все ще можете написати C ++ код, якщо дотримуєтесь ядра мови, але тоді, можливо, буде простіше перейти на C.
  • Ознайомлення. C ++ - складна мова. Легше навчити когось C, ніж C ++, і легше знайти хорошого програміста на C, ніж хорошого програвача C ++. (ключове слово тут "добре". Є багато програмістів на C ++, але більшість з них не вивчили мову належним чином)
  • Крива навчання - Як і вище, навчити когось C ++ - це величезне завдання. Якщо ви пишете додаток, який повинні підтримувати інші в майбутньому, а ці інші можуть не бути програмістами C ++, написання його на C значно полегшує роботу.

Я все-таки вважаю за краще писати в C ++, коли можу відмовитися від цього, і в цілому, я думаю, що переваги переважають за недоліки. Але я також бачу аргумент щодо використання C в деяких випадках.


4
Я додам, що C-код збирається набагато швидше, ніж C ++. Величезний проект нашої компанії (більше мільйона рядків) складає менше 30 секунд.
Кальмарій

31

Існує безліч аргументів щодо вбудованого програмування, продуктивності та іншого, я їх не купую. C ++ легко порівнюється з C у цих областях. Однак:

Зовсім недавно після програмування на C ++ протягом більше 15 років я знову відкривав свої корені на C. Треба сказати, що, хоча в C ++ є хороші особливості, які полегшують життя, є також безліч підводних каменів і такий спосіб "завжди - завжди - краще". Ви ніколи насправді не отримуєте задоволення від рішення, яке ви зробили. (Не зрозумійте мене неправильно, це може бути хорошою справою, але в основному ні).

C ++ дає вам нескінченну стрілянину. Що може бути добре, але якимось чином ви завжди використовуєте занадто багато цього. Це означає, що ви маскуєте свої рішення з "приємними" та "гарними" шарами абстракцій, загальності тощо.

Що я виявив, повертаючись до C, це те, що це було насправді знову цікаве програмування. Провівши стільки часу на моделювання та роздуми над тим, як найкраще використовувати спадщину, я вважаю, що програмування на C насправді робить мій вихідний код меншим та більш читабельним. Звичайно, це залежить від вашого рівня самодисципліни. Але дуже просто розміщувати занадто багато абстракцій прямого прямого коду, який ніколи насправді не потрібен.


8
Без образи, але це також може залежати від того, що ви думаєте, що це C ++. Спадщина - це те, що я більше асоціююсь з Java, ніж з C ++, і якщо ви ставитесь до C ++ строго як до мови OOP á la Java (C з класами), то я згоден з вами. Якщо ви дотримуєтесь більш сучасного смаку C ++, я вважаю, що це веселіше, ніж C
jalf

11
Знову ж таки, я не вважаю C ++ як мовою ОО, і це не повинно трактуватися як один. Я думаю, що загальне програмування є набагато сильнішою рисою C ++. Більшість кодів C ++, які я бачу, не намагаються бути особливо "OO" або містять непотрібний код. Це часто швидше, ніж еквівалентний код C
jalf

3
@jalf: Ще одна річ, яка мені здається, може стати відволіканням "там, де завжди є кращий шлях" у C ++ - це узагальнення речей із шаблонами. "Можливо, ми повинні дозволити користувачеві цього класу вирішити, який базовий цілий тип використовувати?" Але вам, мабуть, це не потрібно , і в С ви б не турбувались. І іноді мені здається, що я думаю: "Нам справді слід надати інтерфейс ітератора прямого переходу до цього класу", коли в C ви просто виставите вказівник на перший елемент і кількість, або (висоту фантазії!) Функцію, що приймає покажчик функції зворотного виклику.
j_random_hacker

2
Я знаходжу зробити крок назад, коли кодування в C ++ допомагає. Вирішіть мету і напишіть до неї (стиль C). Коефіцієнт в C ++ ізмах, оскільки їх корисність стає очевидною.
Метт Столяр

2
infinite gunfire, о так, так правда. Наші ноги буквально тремтять :)
quetzalcoatl

27

C має головну перевагу в тому, що ви можете просто побачити, що відбувається насправді, дивлячись на якийсь фрагмент коду (так, препроцесор: компілюйте з -E, а потім ви його бачите). Щось занадто часто не відповідає дійсності, коли ви дивитесь якийсь код C ++. Там у вас є конструктори та деструктори, які викликаються неявно на основі обсягу або через завдання, у вас є перевантаження оператора, яка може мати дивовижну поведінку, навіть коли це не дуже зловживано. Я визнаю, що я диригент від контролю, але я дійшов висновку, що це не така погана звичка для розробника програмного забезпечення, який хоче написати надійне програмне забезпечення. Я просто хочу мати справедливий шанс сказати, що моє програмне забезпечення робить саме те, що належить зробити, і не має одночасно поганого самопочуття в животі, тому що я знаю, що в ньому може бути ще стільки помилок, що я б не хотів '

У C ++ також є шаблони. Я ненавиджу їх і люблю, але якщо хтось каже, що він повністю розуміє їх, я називаю його брехуном! Сюди входять автори-компілятори, а також люди, які беруть участь у визначенні стандарту (що стає очевидним при спробі його прочитати). Існує так багато абсурдно оманливих кутових справ, що їх просто неможливо розглянути, поки ви пишете фактичний код. Я люблю шаблони C ++ за їхню потужність. Це дійсно дивовижно, що ви можете зробити з ними, але вони також можуть призвести до найдивніших і найскладніших помилок, які можна (не) уявити. І ці помилки насправді трапляються і навіть не рідко. Читання про правила, що стосуються вирішення шаблонів в AR + C ++, майже змушує мою голову вибухнути. І це дає мені погане відчуття даремно витраченого часу на те, щоб прочитати повідомлення про помилки компілятора, довжиною декілька 1000 символів, на які мені потрібно вже 10 хвилин або більше, щоб зрозуміти, що компілятор насправді хоче від мене. У типовому коді C ++ (бібліотека) ви також часто знаходите багато коду у файлах заголовків, щоб зробити певні шаблони можливими, що, у свою чергу, робить цикли компіляції / виконання болісно повільними навіть на швидких машинах і вимагає перекомпіляції великих частин коду, коли ви щось змінюєте. там.

У C ++ також є пастка const. Ви або уникаєте const для всіх, крім самих тривіальних випадків використання, або вам рано чи пізно доведеться відкинути його або переробити великі частини бази коду, коли він розвивається, особливо коли ви збираєтеся розробити приємний і гнучкий дизайн OO.

C ++ має сильніший текст, ніж C, що чудово, але іноді мені здається, що я годую Tamagotchi, коли намагаюся скласти код C ++. Значна частина попереджень і помилок, які я зазвичай отримую від цього, насправді я не роблю те, що не працює, а лише те, що компілятор не любить, щоб я робив це так чи ні, не вводячи тут чи вводячи додаткові ключові слова та там.

Це лише деякі причини, чому мені не подобається C ++ для програмного забезпечення, яке я пишу самостійно, лише використовуючи деякі нібито надійні зовнішні бібліотеки. Справжній жах починається, коли ви пишете код в командах з іншими людьми. Це майже не має значення, чи дуже розумні вони хакери на C ++ чи наївні новачки. Усі роблять помилки, але C ++ робить їх навмисно важко їх знайти і ще складніше їх помітити, перш ніж вони трапляться.

З C ++ ви просто втрачаєтесь, не використовуючи налагоджувач весь час, але мені подобається, щоб я міг перевірити правильність свого коду в голові, і не потрібно покладатися на налагоджувач, щоб знайти свій код, що працює на шляхах, яких я ніколи не очікував. Насправді я намагаюся запустити весь свій код у своїй голові і намагаюся взяти всі гілки, які він має, навіть в підпрограмах і т. Д. І використовувати налагоджувач лише зрідка, щоб побачити, як гарно він проходить через усі затишні місця, які я підготував до нього. Написання та виконання стільки тестових випадків, що всі шляхи коду використовувались у всіх комбінаціях із усілякими дивними вхідними даними, просто неможливо. Тож ви можете не знати про помилки в програмах C ++, але це не означає, що їх там немає. Чим більше проектів на C ++, тим меншою стає моя впевненість у тому, що у нього не буде багато невизначених помилок, навіть якщо він ідеально працює з усіма даними тестових даних. Врешті-решт я його сміття і починаю заново з якоюсь іншою мовою або комбінацією інших мов.

Я міг би продовжувати, але, мабуть, я до цього моменту зрозумів свою думку. Все це змусило мене відчувати себе непродуктивно, коли я програмую на C ++, і змусило мене втратити впевненість у правильності власного коду, що означає, що я більше не буду його використовувати, в той час як я все ще використовую і покладаюся на код C, який написав більше 20 багато років тому. Можливо, це просто тому, що я не хороший програміст на C ++, або, можливо, я досить хороший на C та інших мовах дозволяє мені розпізнати, чим я є насправді ламер, коли мова йде про C ++, і що я ніколи не зможу його повністю зрозуміти. .

Життя коротке...


2
+1, не могла погодитися більше.
зниклий фактор

2
Це звучить надзвичайно паралельно аргументу Лінуса. (Менше контексту об'єкта = простіше зрозуміти.)
Warren P

20

У середовищі з низьким рівнем вбудованого середовища деякі з "інженерів програмного забезпечення" матимуть EE-досвід і ледве опановують C. C ++ є складнішим, а деякі з цих хлопців просто бояться вивчати нову мову. Таким чином, C використовується як найнижчий загальний знаменник. (Перш ніж запропонувати позбутися цих хлопців, вони, принаймні, такі ж важливі, як і спеціалісти CS, які не розуміють аналог хардкор.)

Якщо говорити з досвіду успадкування та збереження обох: жахливий дизайн на C важко зрозуміти, розкрутити і перетворити на щось корисне.

Жахливий дизайн на C ++ нескінченно гірший, оскільки випадкові шари абстракції направляють ваш мозок на екрани навколо кодової бази, намагаючись зрозуміти, який код буде виконуватися за яких обставин.

Якщо мені доведеться працювати з інженерами, які, як я знаю, не створюватимуть великих дизайнів, я б швидше мав перший, ніж останній.


Амінь, брате. Працюючи з джерелом C, що виробляється інженерами апаратури, я здригаюся думати, з чим я зіткнувся, якби це зробили в C ++.
Річард Чемберс

19

Я не бачу жодної причини, крім особистої неприязні, навіть до програмування вбудованих систем та подібних речей. В C ++ ви платите накладні витрати лише за функції, які ви використовуєте. Ви можете використовувати підмножину C для C ++ у деяких конкретних ситуаціях, коли накладні витрати C ++ для вас занадто високі. Це сказав, я думаю, що деякі програмісти на C переоцінюють накладні витрати деяких C ++ конструкцій. Перелічу кілька прикладів:

  • Функції класів та членів мають нульові накладні витрати порівняно із звичайними функціями (якщо ви не використовуєте віртуальні функції; у цьому випадку немає накладних витрат порівняно з використанням покажчиків функцій)
  • Шаблони мають дуже мало накладних витрат (найчастіше взагалі відсутні накладні витрати)

Однією з дійсних причин може бути те, що ви програмуєте для платформи, яка не має гідного компілятора C ++ (жодного компілятора C ++ або компілятора не існує, але погано реалізована і накладає зайві великі накладні витрати на деякі функції C ++).


3
Клас з віртуальними функціями має більше накладних витрат: кожен екземпляр повинен нести додаткове поле для ідентифікації типу.
bstpierre

6
Більше накладних, ніж що? Тип переноситься у vtbl. Якщо ви реалізуєте подібний механізм, використовуючи функціональні покажчики, вам потрібно принаймні один вказівник (або індекс, або будь-який інший), щоб вибрати вказівник функції, який потрібно використовувати.
Сума

3
bstpierre: Я думаю, що те, що говорить Suma, полягає в тому, що у неї немає більше накладних витрат, ніж самостійно реалізувати функцію в C.
Martin York

2
Вказівник на vtable класи зберігається у кожному екземплярі класу.
tstenner

5
Є накладні витрати, але я маю на увазі те, що якщо ви хочете отримати будь-яку динамічну роздільну здатність типу, вам потрібно певне сховище для ідентифікації типу навіть у C. Якщо ви не хочете, щоб динамічні типи не хотіли, вам не потрібно платити за накладні витрати ( не використовуйте віртуальні функції, якщо вони вам не потрібні).
Сума

13

Чому обмежувати розмову англійською? Можливо, ви були б більш креативним автором сербської мови.

Це той самий аргумент, з очевидними помилками. Якщо у вас є завдання, а ваші зручні інструменти вирішують завдання ефективно, ви, ймовірно, будете використовувати зручні інструменти з уважної причини.


3
Якби я володів англійською мовою та сербською, я впевнений, що я був би більш креативним. Ви не згодні?

2
@Neil, але зусилля, необхідні для вивчення сербської мови, не можуть бути виправданими для вирішення мого поточного блоку творчості.
стрункий

2
Я думаю, що Арно підкреслює той факт, що ти не пишеш для центрального процесора, ти пишеш для своїх колег, щоб читати, а інші твої бібліотеки посилатись тощо. Зрештою, якби я просто йшов на експресивність і швидкість, я писав би в OCaml.
Кен

10

C ++ має набагато більшу криву навчання. C має лише кілька конструкцій, про які вам потрібно знати, і тоді ви можете почати кодувати потужне програмне забезпечення. У C ++ вам потрібно вивчити базу C, потім OO і загальне програмування, виняток і т. Д. І через деякий час ви можете знати більшість функцій, і ви, можливо, можете їх використовувати, але ви все ще не знаєте, як буде компілятор перекладіть їх, які неявні накладні витрати мають чи ні. Це вимагає багато часу та енергії.

Для професійного проекту цей аргумент може не враховуватися, оскільки ви можете найняти людей, які вже дуже добре знають C ++. Але в проектах з відкритим кодом, де C все ще використовується Відлі, люди вибирають мову, яка їм подобається, і вони вміють користуватися. Вважайте, що не кожен ОС-програміст є професійним програмістом.


1
Ем ... ні? Ви дізнаєтесь базу C (можливо, за винятком масивів та керування рядками в стилі С, що випали на користь <vector> і <string>), і ви продовжуєте роботу. Ви можете забрати все інше, коли йдете разом. Вам не потрібно нічого знати про OO, GP або винятки, щоб розпочати роботу з C ++ ...
DevSolar

4
C може бути "меншим", але в перспективі використовувати його не простіше. Ручне управління пам’яттю? Ні, дякую.
Jimmy J

7
Немає такого поняття, як автоматичне управління пам'яттю в C ++.
Warren P

3
C ++ не вирішує проблему управління пам'яттю. Тільки коли ви думали, що у вас є ручка на покажчики, C ++ переходить і додає жахливу модель виключення. Приходьте на землю C99, За винятком структур даних, я впевнений, що я ледве торкаюся малоціка. Навіть тоді я можу "інкапсулювати" декілька дзвінків malloc. Це майже та сама історія в C ++ (неявне управління пам’яттю, лише її зроблено на купі замість стека), тільки з усім джазом розумних покажчиків.
Метт Столяр

1
@ereOn: Це правда, коментар, який я написав 3 роки тому, вже не відповідає. :)
Метт Столяр

10

Я хотів би продовжити відповідь Дена Олсона. Я вважаю, що люди бояться потенційно небезпечних та контрпродуктивних особливостей С ++, і це виправдано. Але на відміну від того, що каже Ден, я не думаю, що просто прийняти рішення про стандарт кодування є ефективним з двох причин:

  1. Стандарти кодування можуть бути важко суворо виконувати
  2. Придумати хороше може бути дуже важко.

Я думаю, що друга причина тут набагато важливіша, ніж перша, адже прийняття рішення щодо стандарту кодування легко може стати політичною справою і пізніше буде переглянуто. Розглянемо наступний спрощений випадок:

  1. Ви можете використовувати контейнери stl, але не використовувати шаблони в будь-якому власному коді.
  2. Люди починають скаржитися, що вони були б більш продуктивними, якби їм просто дозволили кодувати той чи інший клас шаблонів.
  3. Стандарт кодування переглядається, щоб це допустити.
  4. Пересуньте нахил до надто складного стандарту кодування, якого ніхто не дотримується, і використовуйте саме той тип небезпечного коду, який стандарт повинен був запобігти, поєднаний із зайвою бюрократією навколо стандарту.

(Альтернатива того, що стандарт не переглядається на етапі 3, є емпірично надто малоймовірним для розгляду і не буде набагато кращим.)

Хоча я кілька років тому використовував C ++ майже для всього, я починаю сильно відчувати, що C є кращим у завданнях низького рівня, з якими потрібно впоратися або C, або C ++, і все інше слід робити в деяких інших мова цілком. (Тільки можливі винятки - деякі конкретні високоефективні проблемні домени, wrt. Blitz ++ )


10

Я використовую C або принаймні експортую інтерфейс С, коли пишу код бібліотеки.

Я не хочу чітко визначених клопотів ABI.


Те саме. Суворий C лише в інтерфейсах. Останнє, чого я хочу, - це чужі смішні рамки об'єкта, що на мене наштовхнулися.
Метт Столяр

9

Я ніколи не бачив жодних аргументів щодо використання C над C ++, які вважав би переконливими. Я думаю, що більшість людей побоюються певних функцій, які пропонує C ++, часто виправдано. Але це не переконує мене, оскільки можна примусити використовувати чи не використовувати певні функції за допомогою стандартів кодування. Навіть у С є багато чого ви хочете уникнути. Відмова від C ++ повністю, по суті, говорить про те, що вона не дає відчутних переваг над C, що допомогло б написати кращий код, що, на мою думку, я дуже невідомий.

Крім того, люди, як видається, завжди піднімають ситуацію на платформах, де немає компілятора C ++. Звичайно, C тут буде доречним, але я думаю, що вам би важко було знайти таку платформу в наші дні.


3
Погоджено, що "C краще, ніж C ++", тиражі ніколи не витримують перевірки.
Jimmy J

6
Я вважаю, що C ++ пропонує мені ДУЖЕ МАЛУ вигоду, і ВЗАЄМО МЕНЮ величезну кількість випадкових складностей. Я вважаю, що для отримання знань C ++, як я зараз перебуваю на C, Pascal, Python та Objective-C, знадобиться близько 1500 сторінок підручників C ++ та десять років зусиль. Кожна з перерахованих вище мов приблизно в 20 разів більш ортогональна, компактна та розумово зручна у використанні, не кажучи вже про більш потужну, в середовищах, де я їх використовую. В моїх звичайних середовищах розробки просто НЕ є раціонально виправданим використання C ++.
Warren P

@Warren Ви платите лише за те, що використовуєте, як і будь-яка мова. Якщо ви не в змозі вирішити, як розумно кодувати в C ++, це на вас, а не на мові.
Ден Олсон

2
Не так. Якщо ви єдиний розробник проекту, це може бути так. Але як тільки у нас є два розробники, у нас є битви. Що? Ви наполягаєте на контейнерах IoC, тоді як я вважаю за краще інший спосіб робити делегатів ... Вам подобаються три рівні вкладених шаблонів, а я віддаю перевагу нульовим шаблонам. Безлад.
Warren P

Я знаю, що цій посаді 10 років, але чи справді справедливо навіть порівнювати C і C ++? Вони обидві окремі, розбіжні мови (починаючи з C99), і обидві мають свої переваги та недоліки, які стосується кожного. С ++ важко налагоджувати та підтримувати? Ясність C дозволить вам налагодити краще. C не має дженерики? C ++ має дженерики! На даний момент часу жодна мова не краща за іншу.
Нергал

9

Я ще не бачив піднятого моменту, який, на мою думку, є найважливішим:

Більшість бібліотек, якими я користуюсь щодня, - це бібліотеки C із прив’язками для Python, Ruby, Perl, Java тощо. З того, що я бачив, набагато простіше обернути бібліотеки C із 19 різними мовними прив’язками, ніж це обернути C ++ бібліотеки.

Наприклад, я дізнався Каїр один раз, і з тих пір використовував його на 3-х чи 4-х різних мовах. Великий виграш! Я вважаю за краще написати програму, яку можна буде знову використовувати в майбутньому, і написання тієї, яка легко може бути прийнята для інших мов програмування, є крайнім випадком цього.

Я знаю, що можливо зв’язувати бібліотеки C ++, але AFAICT це не те саме. Я використовував Qt (v3 та v4) іншими мовами, і це не дуже зручно використовувати: вони відчувають, що пишуть C ++ якоюсь іншою мовою, а не як рідні бібліотеки. (Ви повинні передавати знаки методу C ++ як рядки!)

C ++ - це, мабуть, краща мова, якщо ви пишете функцію, яку потрібно використовувати один раз, або якщо ви думаєте, що весь світ - це C ++. Здається, це легше мови, якщо ви проектуєте для перенесення мови з самого початку.


"Методи передачі як рядки!" річ - дефект Qt, а не C ++. Насправді у вас може бути той самий дурний механізм із рамкою С, який би ви хотіли. Навіть хлопці з Qt погоджуються, що робити це було помилкою. Тоді не було кращої альтернативи в їхній свідомості на той час, і було вже пізно, щоб змінити її назад, коли вони зрозуміли.
ereOn

7

Розробка ядра Windows не підтримує c ++ (на жаль).


Як у тому, що? Чому? Чи відрізняється двійковий файл, що виробляється з компілятора C ++, від компілятора C? Чи не розробка драйверів просто дотримується API?
Дейв Ван ден Ейнде

4
Оскільки для багатьох функцій C ++ потрібна підтримка часу виконання, яка може бути нетривіальною для реалізації у режимі ядра. З одного боку, використовуються різні функції розподілу пам'яті, тому шматки стандартної бібліотеки повинні бути замінені. Винятки, як правило, теж погані.
jalf

3
Додам, що Linux Torvalds, на щастя, виграв будь-який шанс на C ++ в Linux з більшої причини, ніж винятків. Існувало декілька ОС на інших мовах: Java, C ++, асемблер. З розумним використанням вижили лише асемблери.
Метт Столяр


Зверніть увагу, що це для Visual Studio 2015?
LegendLength

6

Ви можете прочитати розважальну рент про те, чому Лінус Торвальдс надає перевагу C тут


6
Це скоріше наполовину узгоджена протидія об'єктно-орієнтованому дизайну, ніж скандал проти C ++.
Ден Олсон

16
Містер Торвальдс має довгий перелік речей, які йому не подобаються, C ++, emacs, Subversion, OO. Іноді хочеться, щоб він трохи

11
Лінус любить грішити і намагатися провокувати і засмучувати людей. На жаль, він не намагався вивчати C ++, перш ніж заявив, що це гарно. На жаль, його наступний культ вважає, що все, що він говорить, повинно бути правдою.
jalf

9
Посилання було скоріше для розваги, ніж для освіти
Пол Діксон

6
Доказ того, що навіть генії іноді можуть бути дольтами.
Kaz Dragon

5

Рідний код на mac - об’єктивний-c. Рідний код на ПК - це c (window.h) або c ++ (mfc). Обидва ці середовища дозволять вам використовувати c з незначними або відсутніми змінами. Коли я хочу, щоб бібліотека коду була перехресною платформою ansi c, здається, хороший вибір.


4

Я можу придумати кілька причин.

Можливо, не буде задовільного компілятора C ++. C ++ - набагато більша мова, і я запускав компілятори C у системах, які не змогли б обробити сучасний C ++.

Запитуючий, або люди, з якими він працює, можуть бути знайомі з C, але не C ++.

Проект може бути в C. Хоча можна додати деякі функції C ++ до C, що може легко призвести до незбагненного безладу. Я б запропонував вибрати одну чи іншу мову (як правило, C ++, коли це практично).

Питучий може мати застарілий вигляд кривої навчання C ++. (При правильному підході це простіше, ніж у C. Більшість вступних книг, які я бачив, не підходять до нього правильно.)

Пам'ятайте, що C і C ++ - це дві різні мови, які з часом стають все більш різними. Кодування в обох одразу є поганою ідеєю, а використання C-подібного підмножини C ++ втрачає більшість переваг C ++.


3

Якщо ви працюєте в середовищі з двома мовами, ви можете використовувати C для деяких критичних функцій низького рівня та більш функціональної мови / мови високого рівня, як C # / Java для бізнес-логіки. Якщо для цих функцій використовується код C ++, для JNI / некерованого коду навколо потрібні C-Wrappers, і це робить речі більш складними, ніж виключно використання C.


3

Я використовую C ++ з програмуванням на C з двох причин:

  • vectorі stringвідірвати мене від управління пам’яттю масиву
  • строга перевірка типу та касти для попередження та / або виловлення всіх неприємностей, я б пропустив інакше.

Тож це C справді запозичив кілька c ++, але використовуючи компілятор c ++ наскільки я можу. Як хтось інший каже у відповідях, я вважаю, що я насправді набираю більше C ++ таким чином, і коли C буде занадто задіяний, я використовую C ++. Монітор / блокування за допомогою RAII - одна з таких, яку я нещодавно використовував для роботи з багатопотоковими програмами та іншою подібною конструкцією для відкриття / закриття файлів.


3

Я думаю, що C більш портативний. Я дещо працював близько 5 років тому, переносячи код на багато ароматів unix (AIX, Irix, HPUX, Linux). Код С був легким для перенесення, але у нас виникли різні проблеми з перенесенням деякого коду С ++. Можливо, це були просто незрілі середовища розвитку, але я з цього приводу скоріше використовую C над C ++ ...


1
П'ятнадцять років тому я був провідним розробником проекту C ++, орієнтованого на HPUX, AIX та Solaris. У нас було дуже мало проблем з портативністю на C ++ - майже всі, що ми мали, були з несумісністю виклику системи C.

1
Менше десяти років тому я працював над проектом, використовуючи HPUX, Solaris та Tru64, використовуючи традиційні компілятори. Наші солов’ї ніколи не будували. Коли ми додали AIX, ми вирішили перейти на стандартний C ++.
Девід Торнлі

Можливо, люди, які написали ваш код, були кращими кодерами, ніж лайно, з яким я мав мати справу :-)
Гордон Томпсон,

3
  1. C - проста мова, C ++ - ні. Для багатьох людей C ++ просто надто складний, щоб повністю оволодіти, див. Http://en.wikipedia.org/wiki/C%2B%2B#Criticism .

  2. Через складність різні програмісти зазвичай лише опановують різні підмножини мови. Це робить читання коду інших людей болючим.

  3. Складність, підводні камені мови додають занадто багато відволікань, а іноді і шкодять продуктивності. Замість того, щоб зосередитися на самій роботі, я часто опинявся як битися із самою мовою. Java / python - це більш продуктивні альтернативи.

  4. Налагодження зламаного коду С зазвичай набагато простіше, ніж налагодження зламаного коду С ++.

  5. На відміну від Java / C #, стандартна бібліотека C ++ досягає мало того, що виходить за межі стандартної бібліотеки C.

  6. Деякі відомі програмісти, як Лінус Торвальдс (Linux) та Річард Сталлман (Emacs), не люблять C ++.


3
Я розглядав питання щодо голосування, поки я не прочитав аргумент №6.
fuz

1

Більшість програмістів сприймають як належне, що кожен вважає якість пріоритетною. Це не завжди так. Якщо ви звикли до C, C ++ може здатися, що він робить занадто багато для вас за кадром. Строгість перевірки типу в C ++ також може здатися обмежуючою. Багато людей готові ризикувати введенням типів помилок, які C ++ можуть допомогти запобігти уникненню цих "неприємностей".


1
Хм, причина, що я перейшов з C на C ++ (давно), полягала в тому, що більш сувора перевірка типу. Мені подобається, щоб компілятор знаходив мої помилки, а не користувач відчував дамп ядра.

1

Я думаю про три причини. Одне полягає в тому, що C більше підходить для вбудованих систем через невеликий розмір його двійкових файлів та більш широку доступність компіляторів C у будь-якій системі. Друга - портативність: C - це менша мова, і ANSI C-код буде компілюватися де завгодно. Легше порушити портативність у C ++. Останнє - сама мова. C ++ складніше і, безумовно, дуже погано розроблена мова. Зчеплення Торвальда повідомляються вище. Ви також можете переглянути відповіді, що часто запитують на C ++ ( http://yosefk.com/c++fqa/ ).


5
І якщо ви розумні, подивившись на FQA, ви зрозумієте, що це зламана робота того, хто насправді не розуміє C ++, але ненавидить його.
Девід Торнлі

1

Переносність може бути проблемою. Я не думаю, що відповідь Гордона Карпентера-Томпа припускає, що це швидше підтримка часу виконання різних версій libstdc ++ у різних версіях linux / unix. Дивіться це посилання для хорошої дискусії з цього приводу. Невеликий уривок:

Код підтримки для виконання, який використовується різними частинами програми C ++, повинен бути сумісним. Якщо одна частина програми потребує динамічної передачі або вилучення об'єктів, наданих іншою, обидві частини повинні узгодити певні деталі реалізації: як знайти vtables, як розмотувати стек тощо.

Для C ++ та декількох інших мов, що підтримуються GCC, з подібними функціями, такі деталі визначаються за допомогою C ++ ABI. Щоразу, коли ABI, який використовується GCC, змінюється, ви отримуєте несумісні бібліотеки, що створюються різними версіями GCC. Те саме стосується звичайного C, але C ABI набагато простіший і значно довший, тому він досить стабільний.


1

Я можу дотримуватися багатьох пропозицій тут в обох напрямках. Але врешті-решт це зводиться до а) порівнянного простого б) порівнянного складного.

Я не маю уявлення, чи хтось "винайшов" якесь вимірювання складності мови.

За шкалою від 0 до 10 я, мабуть, оцінював би С у 2 або 3, тоді як С ++ був би між 8-10. Я б заперечував, що C ++ є однією з найскладніших мов, але я не знаю, наприклад, Ada, PL1 тощо, тому, можливо, це не так складно порівняно з якоюсь іншою мовою.

C ++ успадковує всю складність C, тому він не може бути нижче рівня складності C.

Мені зі свого боку було б набагато зручніше використовувати якусь мову сценаріїв і С. Отже, врешті-решт треба відповісти на наступне питання. "Чи завжди краще?"


1

Найбільш корисне, що я знайшов у C, - це відсутність просторів імен та перевантажень: імена функцій та символів є унікальними ідентифікаторами. Щоб знайти місця, де ці символи використовуються, ви можете просто grepчерез файли вихідного коду, а результати пошуку покажуть місця.

Це важливо при підключенні нової функції або компонента до старої та заплутаної системи.

Це неможливо зробити легко на C ++ без складного інструменту побудови графіків викликів.


0

Більшість людей, здається, думають, що C і C ++ якимось чином пов'язані, але вони сумно помиляються. C ++ - це зовсім інша мова, ніж C.

В C ++ ви думаєте, що стосується об’єктів та як вони пов’язані один з одним. В мові ви думаєте з точки зору API. Це як різниця між днем ​​і 17.

Погана аналогія: якщо хтось додає китайську до англійської та називає її англійською ++, вам, мабуть, не буде комфортно додати китайську лінію до свого останнього любовного листа, адже так набагато простіше виразити любов у цій частині англійської ++.


0

Нижче наведено всі причини, чому може бути вигідно обмежити проект на C:

  • швидша компіляція, оскільки мова набагато простіша
  • вимагає меншої підтримки часу виконання, що робить його більш підходящим для низького рівня
  • набагато простіше інтерфейс з іншими мовами
  • підтримує масиви змінних розмірів у стеці
  • простіше читати збірний код, оскільки немає імені mangling
  • дозволяє код, створений різними компіляторами, легко поєднуватися, оскільки це фактично стандартний двійковий інтерфейс програми
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.