Кроссплатформенный сетевой код на C ++? - PullRequest
2 голосов
/ 05 декабря 2011

Я начинаю разработку нового приложения, и хотя мой опыт в основном основан на Mac / iOS, мне нужно поработать над приложением Windows для участия в их Imagine cup.

Этот проект включает в себя связь между клиентами через сокетное соединение (с сервером, а не ad-hoc), и мне нужно, чтобы клиенты Mac и Windows могли общаться друг с другом. Я также хотел бы не писать этот сетевой код дважды и просто писать разные коды нативного интерфейса на обеих платформах. Это облегчает работу в сети (я уверен, что две разные платформы не будут взаимодействовать с сервером по-разному) и позволяет использовать собственный интерфейс на обеих платформах.

Является ли C ++ лучшим языком для этой задачи? Стандартная библиотека одинакова на обеих платформах? Я понимаю, что мне придется использовать библиотеку Microsoft Visual C ++, так как кажется, что трудно использовать код C ++ из C #; это правда?

Я никогда прежде не писал кроссплатформенное приложение, особенно такое, которое касается взаимодействия между платформами.

Ответы [ 3 ]

4 голосов
/ 05 декабря 2011

Если вы собираетесь использовать C ++, я второй «the_mandrill» выше, настоятельно рекомендую вам взглянуть на ASIO в Boost - это отличный способ написать код один раз и поддерживать обе платформы.

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

Причины выбора C ++ для реализации сетевого кода:

  • Возможно достичь очень низкогозадержки и высокая пропускная способность с очень тщательно разработанным и реализованным кодом.
  • Возможность явно контролировать управление памятью - избегая колебаний производительности, связанных со сборкой мусора.
  • Потенциал для тесной интеграции сетевого кода в-процесс с другими собственными библиотеками.
  • Потенциал для создания небольших компонентов, подходящих для развертывания в средах с ограниченными ресурсами.
  • Низкоуровневый доступ к API сокетов C предоставляет такие функции, как параметры сокетов, для использования протоколов, выходящих за рамки стандартного.TCP / IP и UDP.

Причины отказа от C ++:

  • Более низкая производительность при разработке кода по сравнению с языками высокого уровня (например, Java / C # / Python и т. Д.и т. д.)
  • Большой потенциал для значительного внедренияошибки обозначения (злоупотребление указателем и т. д.)
  • Требуются дополнительные усилия для проверки компиляции кода на каждой платформе.

Альтернативы, которые вы можете рассмотреть, включают:

  • Python ... напрямую используя низкоуровневую поддержку сокетов или высокоуровневую библиотеку Twisted.Быстрая разработка с использованием удобных высокоуровневых идиом и минимальных усилий по переносу.Самый большой недостаток - слабая поддержка использования нескольких процессорных ядер для систем с высокой пропускной способностью.
  • Ruby (socket) / Perl (IO :: Socket) ... Языки высокого уровня, которые могут быть особенно подходящими, если передаваемая информацияпредставлены в виде текстовых строк.
  • Java ... сборка мусора упрощает управление памятью;широкий спектр существующих библиотек.
  • языки CLR (C # и т. д.), а также сборщик мусора - например, Java ... WCF - эффективная структура, в рамках которой могут быть разработаны специальные протоколы ... что может оказаться полезным.

Вы также спросили: " Я понимаю, что мне придется использовать библиотеку Microsoft Visual C ++, так как кажется, что трудно использовать код C ++ из C #; это правда?"

Вы можете полностью избежать библиотек Visual C ++ - либо разработав язык, отличный от C ++, либо используя альтернативный компилятор C ++ - например, Cygwin или MinGW предлагают G ++ ... хотя я бы рекомендовал использовать VisualC ++ для построения кода C и C ++ для Windows.

Нетрудно использовать код C ++ из C # - хотя я не рекомендую его в качестве подхода ... он, вероятно, слишком сложен.Visual C ++ может (необязательно) скомпилировать «управляемый код» из исходного кода C ++ (есть несколько расширений синтаксиса для понимания и немного другой синтаксис для взаимодействия с использованием Mono, а не Visual C ++, но это не главные проблемы IMHO.) Эти объекты CLRнапрямую взаимодействовать с объектами C # и без проблем объединяться в одну сборку.Также легко получить доступ к собственным библиотекам DLL (потенциально написанным с использованием C ++ для собственной архитектуры) с помощью Pinvoke.Однако все это несколько неактуально, поскольку платформа .Net имеет хорошую поддержку для низкоуровневых сетей (аналогичную той, что предоставляется Winsock [2]) в system.net - это обеспечивает удобный C # -ориентированный интерфейс для аналогичных средств и будетскорее всего, предоставит более удобный API для разработки при использовании C # (или VB.Net или любого другого языка CLR.)

2 голосов
/ 05 декабря 2011

Я бы посоветовал вам взглянуть на Qt . IMO Qt - одна из лучших библиотек C ++ для создания кроссплатформенных приложений. Преимущества Qt по сравнению с Boost состоят в том, что в Qt есть даже классы GUI.

1 голос
/ 05 декабря 2011

Лучший язык очень субъективен, но если вам нужен переносимый быстрый код с полезными абстракциями и синтаксисом в стиле C, C ++ - хороший выбор.Обратите внимание, что если вы еще не знаете C ++, существует крутая кривая обучения.

Библиотека, как определено стандартом ISO, по определению одинакова на каждой платформе, однако ее реализация может быть менее или более совместимой,Тем не менее, и gcc, clang и MSVC (post .net) все очень хорошо реализуют C ++ 98.Пока вы не используете специфичные для компилятора расширения.

Я настоятельно рекомендую взглянуть на boost asio (и библиотеку boost в целом) для вашей сети, он использует шаблон проектирования proactor, который очень эффективен.Однако это займет некоторое время, чтобы разобраться с этим.

http://www.boost.org/doc/libs/1_48_0/doc/html/boost_asio.html

Придерживайтесь стандартной библиотеки и повышения, и по большей части кросс-платформенные проблемы не являются главной проблемой.

Наконец, я бы не использовал возможности C ++ 11 для написания кроссплатформенного кода, потому что MSVC, GCC и Clang реализовали разные части стандарта.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...