Есть ли недостатки в использовании C ++ для сетевых демонов? - PullRequest
4 голосов
/ 16 января 2011

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

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

Демон должен будет обрабатывать несколько соединений (около 200 одновременно), управлять ими и передавать сообщения, как в чате.

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

Давно уже будучи администратором Linux, я заметил, что большинство сетевых демонов написаны на простом C (конечно, некоторые написаны и на других языках, но я чувствую, что> 80% из демонов написаны простым C).

Теперь мне интересно, почему это так. Это связано с чисто историческим фоном UNIX (например, KISS) или с простой переносимостью или уменьшением раздувания? По каким причинам не использует C ++ или любые языки "более высокого уровня" для таких вещей, как демоны?

Заранее спасибо!


Обновление 1:

Для меня использование C ++ обычно более удобно из-за того, что у меня есть объекты , которые имеют методы получения и установки и тому подобное. В некоторый момент «контекстные» объекты простого C могут быть настоящей болью, особенно когда вы привыкли к объектно-ориентированному программированию.

Да, я знаю, что C ++ является надмножеством C, и что код C в основном C ++ , вы можете скомпилировать любой код C с помощью компилятора C ++. Но дело не в этом. ;)


Обновление 2:

Я знаю, что в настоящее время может иметь смысл использовать язык высокого уровня (скриптовый), такой как Python, node.js или аналогичный. Я делал это в прошлом, и я знаю о преимуществах этого (по крайней мере, я надеюсь, что смогу;) - но этот вопрос касается только C и C ++.

Ответы [ 8 ]

6 голосов
/ 16 января 2011

Я, например, не могу придумать каких-либо технических причин, чтобы выбрать C над C ++.Не тот, который я не могу мгновенно придумать для контрапункта.

Редактировать в ответ на редактирование: я бы серьезно отговорил вас задуматься над тем, "... C-код - это в основном C ++".Хотя вы можете технически скомпилировать любую программу на C с помощью компилятора C ++ (если вы не используете какую-либо функцию в C, более новую, чем в C ++), я действительно стараюсь отговорить кого-либо от написания кода, подобного C, на C ++ или рассмотрения C ++.как «C с объектами».

В ответ на то, что C является стандартом в Linux, только в той мере, в которой разработчики C продолжают это говорить: p C ++ является такой же частью любого стандарта в Linux, как C, и естьогромное разнообразие программ на С ++, сделанных на Linux.Если вы пишете драйвер для Linux, вам нужно делать это на C. Кроме того ... Я знаю, что RMS любит говорить, что вы с большей вероятностью найдете компилятор C, чем C ++, но на самом деле это не так.правда уже довольно давно.Вы найдете оба или ни один на почти всех установках.

В ответ на ремонтопригодность - я, конечно, не согласен.

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

6 голосов
/ 16 января 2011

Сопротивление C ++ для разработки кода демона проистекает из нескольких источников:

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

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

  • , хотя это не относится к коду демона пользовательского режимаразработчики режима ядра избегают C ++, опять же из-за неявного кода, который генерирует C ++, и исключений, которые библиотеки C ++ используют для обработки ошибок.Большинство компиляторов c ++ реализуют исключения c ++ с точки зрения аппаратных исключений, и большая часть кода режима ядра выполняется в средах, где исключения не допускаются.Кроме того, весь неявный код, сгенерированный c ++, будучи неявным, не может быть заключен в директивы #pragma, чтобы гарантировать его размещение в страничной или нестраничной памяти.

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

2 голосов
/ 16 января 2011

Я бы порекомендовал, что вам удобнее.Если вам удобнее работать с C ++, ваш код станет чище и будет работать эффективнее, поскольку вы будете к нему привыкать, если вы понимаете, о чем я.

То же самое относится и к большемумасштабировать до чего-то вроде обсуждения Python против Perl.В зависимости от того, что вам удобнее, вы, вероятно, создадите лучший код, потому что у вас будет опыт.

1 голос
/ 16 января 2011

Boost позволяет невероятно легко писать однопоточные или многопоточные и легко масштабируемые сетевые демоны с библиотекой asio .

1 голос
/ 16 января 2011

Ты прав. Причиной не использования C ++ является KISS, особенно если вы когда-нибудь захотите, чтобы кто-то еще поддержал ваш код в будущем. Большинство людей, которых я знаю, научились писать демоны из существующих источников или читать книги Стивенса. В значительной степени это означает, что ваши примеры будут на языке C. С ++ - это нормально, я сам написал в нем демонов, но я думаю, что если вы ожидаете, что он будет поддерживаться, и вы не знаете, кто может быть в будущем показывает лучшее предвидение, чтобы написать на C.

1 голос
/ 16 января 2011

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

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

0 голосов
/ 16 января 2011

Как C, так и C ++ идеально подходят для написания демонов.

Кроме того, в настоящее время вы должны также рассматривать языки сценариев как Perl или Python.Производительность обычно достаточно высока, и вы сможете писать приложения более надежно и за меньшее время.

Кстати, взгляните на ACE , фреймворк для написания переносимых сетевых приложений на C ++.

0 голосов
/ 16 января 2011

Я бы порекомендовал использовать C ++ с оговоркой об использовании обработки исключений и динамического RTTI.Эти функции могут повлиять на производительность во время выполнения и могут плохо поддерживаться на разных платформах.

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

...