Будете ли вы использовать C сегодня для программного проекта? [закрыто]

Если да, где и зачем вы это используете?

Если нет, пожалуйста, объясните, почему C не приемлем для вас.

C - отличный язык для системного программирования

Я бы использовал C, если бы внедрил некоторые драйверы. И я бы использовал C, если бы внедрил свое собственное ядро ​​операционной системы или собственную виртуальную машину.

Это очень хороший язык для выполнения низкоуровневых задач, если вам приходится иметь дело с аппаратными средствами или низкоуровневыми API-интерфейсами ОС для Windows 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 ++, потому что это облегчает продвижение сильных интерфейсов между программными компонентами, но только в том случае, если все инженеры, работающие над проектом, понимают, что C ++ легко использовать неправильно, что приводит к раздутию размера кода (виртуальные функции и шаблоны - примеры того, чего следует избегать ).

Я также видел программиста на C ++, который пытался создать 10K-объект в стеке 1K, но это не очень хорошая идея.

Я работаю в основном с гипервизором Xen, различными библиотеками и ядром Linux. Иногда мне приходится писать драйвер устройства (или переписывать его так, чтобы виртуальные машины nxx могли использовать одно устройство, такое как HRNG). C мой основной язык, и я вполне доволен этим.

Буду ли я пытаться написать программу для работы с электронными таблицами, используя ее? Ни за что. У каждого инструмента есть свои приложения, и я рад, что у меня есть много инструментов.

Я люблю C, но я не пытаюсь стучать винтами молотком.

Если С - разумный выбор для нового проекта, конечно. Если нет, я буду использовать что-то еще.

Я бы для некоторых проектов. Определенно, если бы мне пришлось внедрить встроенную систему, скажем, для контроллера автономного самолета. Может даже понизиться на некоторых деталях при сборке.

Если это соответствует проекту, у меня нет проблем с ним.

Если вы хотите разработать веб-приложение, хм, вероятно, нет (или мне нужно увидеть очень веское и обоснованное обоснование).

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

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

Я часто говорю людям, которые заинтересованы в изучении программирования сегодня, чтобы убедиться, что в какой-то момент они изучат C и освоятся с ним. Вы можете оказаться в обстоятельствах, когда вам это нужно. Неоднократно мне приходилось компилировать крошечную статически связанную программу «быстрой перезагрузки» и использовать scp, чтобы поместить ее на диск RAM на сервере, на котором дисковая подсистема полностью исчезла. (Дешевые, дешевые серверы, без онлайн-резервирования и только возможность загрузить небольшую программу? C - это путь.)

Кроме того, изучение того, как работать в C, не стреляя себе в ногу, может значительно повысить способность эффективно писать на других языках и в других условиях. По крайней мере, это был мой опыт.

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

Да, я делаю это все время.

Если вы не вызываете никаких библиотек, код, сгенерированный из C, не требует поддержки ОС. Это также дает вам прекрасный контроль над сгенерированным машинным языком. Так что он отлично подходит для написания драйверов или другого кода, который находится в пространствах ядра, и других ограниченных ситуациях, таких как работа многих встроенных систем. Это также основной язык для проектов с открытым исходным кодом, с которыми я работаю, таких как X Windows, GTK + и Clutter.

В то время как вы можете делать все в C, вы можете в C ++, часто механизмы C ++ делают его более быстрым и простым в написании кода. Я люблю ООП и то, как классы C ++ инкапсулируют функциональность, и я люблю RAII. Тщательное использование автоматического вызова деструктора, когда объект выходит из области видимости, устраняет большую часть утечек памяти и ресурсов, которые являются проблемой программирования на Си. STL - это в основном гигантская библиотека высокооптимизированных алгоритмов и структур данных; если вы хотите использовать их из C, вам придется написать их самостоятельно или купить где-нибудь.

К сожалению, по причинам, которые я не понимаю, системе времени выполнения в Linux требуется специальная библиотека совместно используемых объектов (эквивалент DLL в Windows, dylib на Mac) для запуска любого C ++, и она не обнаруживается при запуске программы на Си. Поэтому я не могу выполнить один из моих любимых трюков для Mac и Windows, а именно написать общий объект на C ++ с API на основе C и вызвать его из C-программы.

Итак, вот мой процесс принятия решений:

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

Одна приятная вещь заключается в том, что, поскольку C ++ может компилировать C, если вам действительно нужен детальный контроль над кодом, сгенерированным для конкретной ситуации, вы можете просто написать C для этого и C ++ для остальных и скомпилировать все это с помощью компилятора C ++. ,

Да, но зависит от проекта. C очень хорош для некоторых низкоуровневых проектов или для части большого решения.

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

если это должно быть как

• быстро и
• портативный

тогда я использую C. Может быть, C ++.

Да на самом деле я недавно!

Мне нравится программирование на C. Я больше всего программирую на python, но бывают моменты, когда мне нужен быстрый код, и я действительно наслаждаюсь элегантностью, которая проистекает из простоты языка.

Проект, над которым я сейчас работаю, - это база данных, которая, как вы можете себе представить, критична для производительности. На данный момент я использую C и немного Python, но в конечном итоге это будет преимущественно, если не полностью C.

Да!

C - это язык низкого уровня, и есть ситуация, в которой C является почти единственным вариантом, как я использую C для программирования микроконтроллеров, или соединяю некоторый код для взаимодействия с устройствами из классических портов, таких как Parallel, Serial или даже Modem!

Да. Я посвятил большую часть своей карьеры программированию на C ++, но теперь я пишу большую часть своего кода на Ruby, и если мне нужна производительность или доступ к низкоуровневым материалам, я пишу расширение на C. Это будущий Человек!

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

C ++ переносим между платформами и встроенными устройствами, такими как микроконтроллеры. (C ++ может быть скомпилирован в C, поэтому микроконтроллеры.)

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

Haskell переносим на разные платформы (скоро появится ARM), но НЕ встраивает такие устройства, как микроконтроллеры. Его скорость сравнима с C и C ++; но поскольку он функционален, он использует сборщик мусора вместо стека времени выполнения, поэтому он может работать быстрее и медленнее, чем C в разное время (сборщик мусора) и в разных ситуациях (продолжение вместо вызовов подпрограмм).

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

Я не предпочитаю другие языки, хотя знаю одну или две руки в полном объеме. ... за исключением нескольких случаев, хорошо, Баш .

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