The obvious choice would be an output option for C++. The generated code could then use classes instead of structs; and the classes could have constructors, and be more OOP-y and syntactically compact. The goal is to use the same protocol.xml file but specify on the command line the 'C' or 'C++' dialect. Obviously C and C++ code would need to produce the same packet contents over the wire.
In the future one could imagine extending this concept to other languages: Go, Swift, C#, etc. That would obviously be a lot more work, but the same principles should be obeyed: the protocol file doesn't need to change, and the project just chooses the language that is most natural for it.
SchrodingersGat
commented
6 years ago
The obvious choice would be an output option for C++. The generated code could then use classes instead of structs; and the classes could have constructors, and be more OOP-y and syntactically compact. The goal is to use the same protocol.xml file but specify on the command line the 'C' or 'C++' dialect. Obviously C and C++ code would need to produce the same packet contents over the wire.
In the future one could imagine extending this concept to other languages: Go, Swift, C#, etc. That would obviously be a lot more work, but the same principles should be obeyed: the protocol file doesn't need to change, and the project just chooses the language that is most natural for it.