Чи використовуєте ви сьогодні C для проекту програмного забезпечення? [зачинено]

Якщо так, то де і навіщо це використовувати?

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

C - чудова мова для системного програмування

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

Це дуже гарна мова робити речі низького рівня, якщо вам доводиться мати справу з апаратними або низькорівневими API-інтерфейсами ОС для API API, Linux, Mac OS X, Solaris і так далі ... Вбудовані системи зазвичай мають хорошу підтримку C з компілятором + комплект розробки.

Так, звісно. Я б використовував C для написання критичних фрагментів системи або частин зв'язку низького рівня. Наприклад, я б використовував C для написання NIF в проекті Erlang лише тому, що це правильний інструмент (tm) для такої роботи. Або я б використав C для написання подібних частин (XS) у проекті Perl.

Я використовую C професійно, майже кожен день. Насправді С є найвищим мова рівня, на якій я регулярно програмую.

Де я використовую C: я пишу код бібліотеки низького рівня, який повинен бути максимально ефективним. Мій код клею написаний на С, внутрішні обчислювальні петлі записуються в збірку.

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

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

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

Я також бачив програміста на C ++, який намагався створити об'єкт 10K на стеці 1К, що не дуже добре.

Я працюю здебільшого з гіпервізором Xen, з різними бібліотеками, в яких є, та з ядром Linux. Іноді я мушу написати драйвер пристрою (або переписати його знову, щоб nxx віртуальні машини могли спільно використовувати один пристрій, наприклад HRNG). С - моя основна мова, і я цілком задоволений цим.

Чи спробую я написати програму електронних таблиць, використовуючи її? У жодному разі. Кожен інструмент має свої програми, і я радий, що у мене є багато інструментів.

Я люблю C, але не намагаюся молоти гвинти молотком.

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

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

Якщо він відповідає проекту, у мене немає проблем з цим.

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

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

Кожна окрема мова там має гідну нішу використання. Я часто можу реалізовувати речі на мовах вищого рівня, а потім поступово звожу їх до C-land, якщо мені потрібно, щоб вони були більш ефективними або навіть просто більш портативними. Існують компілятори C для майже всього існуючого, і якщо ви пишете в API, який є загальнодоступним (наприклад, POSIX), то це може бути дуже корисним.

Те , що я часто говорю людям , які зацікавлені у вивченні програмування сьогодні , щоб переконатися , що в деяких момент вони навчаються С та їм стає комфортно. Ви можете опинитися в обставинах, коли вам це потрібно. Мені вже не один раз доводилося складати крихітну стаціонарно пов'язану програму "швидкого перезавантаження" і використовувати scp, щоб розмістити її на диску оперативної пам'яті на сервері, звідки підсистема диска повністю відійшла. (Дешеві, дешеві сервери, відсутність надмірності в Інтернеті, і лише можливість завантаження невеликої програми? C - це шлях.)

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

Хоча я, звичайно, не використовую його для всього, а то й більшості речей, він має своє місце і він є майже універсальним: так, так, я використовував його в минулому і буду використовувати його в майбутньому (хоча я не знати, коли в даний момент).

Так, я роблю це постійно.

Якщо ви не викликаєте жодної бібліотеки, код, згенерований із C, не потребує підтримки ОС. Це також дає точний контроль над створеною машинною мовою. Тож він чудово підходить для написання драйверів або іншого коду, який живе у просторах ядра, та інших обмежених ситуацій, як-от багато видів вбудованих систем. Це також основна мова для проектів з відкритим кодом, з якими я працюю, як X Windows, GTK + та Clutter.

Хоча ви можете робити все, що на C, ви можете в C ++, часто механізми C ++ полегшують і швидше писати код. Я люблю OOP і те, як класи C ++ інкапсулюють функціональність, і я люблю RAII. Ретельне використання автоматичного виклику деструктора, коли об’єкт виходить із сфери застосування, виключає більшість витоків пам'яті та ресурсів, які є основою програмування на С. STL - це в основному гігантська бібліотека високооптимізованих алгоритмів та структур даних; якщо ви хотіли використовувати їх із C, вам доведеться написати їх самостійно або придбати їх десь.

На жаль, з незрозумілих мені причин, система виконання Linux в Linux потребує спеціальної бібліотеки спільних об'єктів (еквівалентної DLL в Windows, dylib на Mac) для запуску будь-якого C ++, і вона не знайдена при запуску програми C. Тому я не можу виконувати один з моїх улюблених трюків для Mac та Windows, а саме - написати спільний об’єкт на основі C ++ за допомогою API на основі C та викликати його з програми C.

Тож ось мій процес прийняття рішень:

1. Я працюю в обмеженій ситуації, як драйвер пристрою? Використовуйте C.
2. Я пишу бібліотеку Linux, хтось іншим доведеться користуватися? Використовуйте C.
3. Я працюю в коді, який уже написаний на С? Використовуйте C.
4. Я пишу бібліотеку Mac чи Windows, чи лише бібліотеку Linux, яку я буду використовувати? Введіть внутрішні записи в C ++, але розкрийте лише C-інтерфейс, щоб уникнути крихкої проблеми бінарного інтерфейсу.
5. Використовуйте C ++.

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

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

Напр. Для логіки бізнесу нормально, але не для користувальницького інтерфейсу.

якщо це повинно бути обом

• швидко, і
• портативний

то я використовую C. Можливо, C ++.

Так, насправді я останнім часом!

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

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

Так!

C - мова низького рівня, і є ситуація, коли C - це майже єдиний варіант, як я використовую C для програмування мікроконтролерів, або складаю якийсь код разом для взаємодії з пристроями з класичних портів, таких як паралельний, послідовний або навіть модем!

Так. Я витратив більшу частину своєї кар’єри на програмування на C ++, але зараз я пишу більшу частину свого коду в Ruby, і якщо мені потрібна продуктивність або доступ до матеріалів низького рівня, я пишу розширення на C. Це майбутня Людина!

Я б використовував C, якби писав операційну систему. Оскільки це не відбудеться у найближчі двадцять років, якщо я не потрапив у лото та не маю нічого іншого, як зробити свій дивовижний дистрибутив Linux, я, мабуть, просто дотримуватимуся C #, Java, Python тощо, тощо. У мене немає 'я не використовував C дуже довго, але мені завжди подобалося його використовувати; Я думаю, хоча в наші дні моя голова настільки обернута навколо ОО, якщо мені доведеться повернутися до цього, мені потрібно трохи повернутися.

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

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

Haskell є портативним на будь-яких платформах (ARM скоро з'явиться), але НЕ вбудовані пристрої, такі як мікроконтролери. Його швидкість порівнянна з C і C ++; але оскільки він функціональний, він використовує сміттєзбірник замість пакету виконання, тому він може бути швидшим і повільніше, ніж C у різний час (збирання сміття) та в різних ситуаціях (продовження замість підпрофільних викликів).

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

Я не віддаю перевагу іншим мовам, хоча знаю одну чи дві руки. … За винятком кількох випадків, ну, б'ють .

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