Буферы протокола, заставляющие C # общаться с C ++: проблемы с типами и схемами - PullRequest
Новая
       10

Буферы протокола, заставляющие C # общаться с C ++: проблемы с типами и схемами

5 голосов
/ 29 января 2012

Я собираюсь начать проект, чтобы соединить две программы, одну на c # и одну на c ++. У меня уже есть работающая программа на c #, которая может общаться с другими версиями самой себя. Прежде чем начать с версии c ++, я подумал о некоторых проблемах:

1) Я использую protobuf-net v1. Я так понимаю, файлы .proto из сериализатора - это именно то, что требуется в качестве шаблонов для версии c ++? В поиске Google упоминается кое-что о паскале, но я понятия не имею, важно ли это.

2) Что мне делать, если один из типов .NET не имеет прямого аналога в c ++? Что если у меня есть десятичная дробь или словарь? Нужно ли как-то модифицировать файлы .proto и изменять данные в другую форму? (Я проверю файлы и выясню, смогу ли я это выяснить)

3) Есть ли другие ошибки, о которых могут подумать люди? Двоичные форматы и тому подобное?

EDIT Я взглянул на один из прототипов файлов. Кажется, что .NET конкретные вещи помечены, например, bcl.DateTime или bcl.Decimal. Подтипы включены в прото определения. Однако я не уверен, что делать с типами bcl. Если моя прога с ++ видит десятичную дробь, что она будет делать?

Ответы [ 2 ]

4 голосов
/ 29 января 2012

  1. Да, прото-файлы должны быть совместимы.Обсуждаются условные обозначения, которые не должны влиять на реальную функциональность - только на сгенерированный код и т. Д.

  2. Не важно, существует ли в .NET тип, сопоставимый напрямую, или важно,поддерживают ли буферы протокола тип, который важен.Буферы протокола в основном довольно примитивны - если вы хотите создать что-то большее, вам нужно создавать свои собственные сообщения.

  3. Смысл буферов протокола - сделать его двоичным совместимымна проводе, так что на самом деле не должно быть должно быть получено ... прочитайте документацию, чтобы узнать о политиках управления версиями и т. д. Единственное, о чем я могу думать, это то, что по крайней мере в версии Java этохорошая идея сделать поля enum необязательными и присвоить самому типу enum нулевое значение «unknown», которое будет использоваться, если вы попытаетесь десериализовать новое значение, которое еще не поддерживается в десериализационном коде.

3 голосов
/ 29 января 2012

Некоторые незначительные дополнения к очкам Джона:

  • protobuf-net v1 имеет Getaproto, который может помочь с начальной точкой, однако для целей взаимодействия я бы порекомендовал начать с .proto; Protobuf-net может работать, это было где-то еще, либо через «protogen», либо через надстройку VS
  • кроме этого, у вас не должно быть моих проблем, если вы не забываете обращаться со всеми файлами как с двоичными; открытие файлов в текстовом режиме вызовет горе
...