Buffers de protocolo, obtener C# para hablar con C++: escribir problemas y problemas de esquema

Question

Estoy a punto de embarcarme en un proyecto para conectar dos programas, uno en C# y otro en C++. Ya tengo un programa C# en funcionamiento, que puede hablar con otras versiones de sí mismo. Antes de comenzar con la versión de C++, he pensado en algunos problemas:

1) Estoy usando protobuf-net v1. Considero que los archivos .proto del serializador son exactamente lo que se requieren como plantillas para la versión de C++. Una búsqueda en google mencionó algo sobre el revestimiento pascal, pero no tengo idea si eso es importante.

2) ¿Qué debo hacer si uno de los tipos de .NET no tiene una contraparte directa en C++? ¿Qué sucede si tengo un decimal o un diccionario? ¿Tengo que modificar los archivos .proto de alguna manera y aplastar los datos en una forma diferente? (Voy a examinar los archivos y ver si puedo resolverlo)

3) ¿Hay otros problemas que las personas puedan pensar? Formatos binarios y cosas así?

EDIT He echado un vistazo a uno de los archivos proto ahora. Parece que las cosas específicas de .NET están etiquetadas, por ejemplo, bcl.DateTime o bcl.Decimal. Los subtipos están incluidos en las definiciones de proto. Aunque no estoy seguro de qué hacer con los tipos de bcl. Si mi programa de C++ ve un decimal, ¿qué hará?

Answer 1

1. Sí, los archivos de protocolo deberían ser compatibles. La carcasa es sobre convenciones, que no deberían afectar la funcionalidad real: solo el código generado, etc.

2. No es si hay o no un tipo directamente comparable en .NET que sea importante, es si los búferes de protocolo admiten el tipo que es importante. Los búferes de protocolo son en su mayoría bastante primitivos: si desea construir algo más grande, deberá crear sus propios mensajes.

3. El punto de búferes de protocolo es para hacer que todo compatible a nivel binario en el cable, así que realmente no debería haber trampas ... leer la documentación para averiguar acerca de las versiones políticas, etc. La única cosa que puede pensar en que, al menos en la versión de Java, es una buena idea hacer que los campos enum sean opcionales, y darle a la enumeración en sí un valor cero de "desconocido" que se usará si intenta deserializar un nuevo valor que no es compatible con el código de deserialización aún.

Answer 2

Algunas adiciones de menor importancia a los puntos de Jon:

• v1-protobuf neta tiene un Getaproto que puede ayudar con un punto de partida, sin embargo, para los propósitos de interoperabilidad que recomendaría a partir de una .proto; protobuf-net puede funcionar, esto también estuvo disponible, ya sea a través de "protogen", o mediante el complemento VS
• que no sea eso, no deberías tener mis problemas mientras recuerdes tratar todos los archivos como binarios; abrir archivos en modo texto causará dolor