是否有一个函数来转换C＆＃x2B;＆＃x2B;代码到Protobuf？
我正在使用MagicDraw的序列图表来建模GPB消息和Inter-App通信。
最终，我想使用MagicDraw的C ++代码生成工具将模型导出到C ++代码中，然后将其转换为.proto文件。目的是将图形模型从MagicDraw转换为.proto文件。
我花了5个小时的时间寻找方法来做到这一点，但是看起来代码转换仅通过编写.proto文件而起作用，然后使用Protoc将其转换为C ++，而不是相反。
有什么方法可以扭转这一过程？
I am working on modeling GPB messages and inter-app communication using MagicDraw's sequence diagramming.
Ultimately, I want to use MagicDraw's C++ code generation tool to export the models into C++ code, and then turn that into .proto files. The goal is to turn the diagrammed models from MagicDraw and convert them into .proto files.
I've spent 5+ hours looking for ways to do this, but it looks like code conversion only works from writing .proto files and then using protoc to turn them into C++, not the other way around.
Is there any way to reverse this process?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
啊，追求神圣的模型＆lt; ==＆gt; schema＆lt; ==＆gt; code＆lt; ==＆gt;型号三角形。
恐怕我实际上没有一个很好的答案。我最接近的是Enterprise Architect，XSD和ASN.1。但这还不完整； Enterprise Architect不同步XSD；这是一个直接的进出口，因此XSD中的更改不会反映回企业架构师。在EA中，您可以定义类（经典的UML内容），并导出一包作为XSD的类包，ASN.1工具将作为模式消费（XSD和ASN.1架构之间有正式翻译），并且ASN具有官方翻译 做得不好）。
.1编译器倾向于在生成的代码中实现和执行
minoccurs（许多XML/XSD编译器实际上都 。世界上大量的缓冲区覆盖，接口错误等），不介意同步代码 /模型 /模型。首先要开发工具的热情。可惜。使用诸如ASN.1或XSD（具有非常好的编译器）的强大模式系统，或者使用Pinch JSON（似乎更多地强调使用模式来检查对象，而不是使用方案来定义类别）。通往非常敏捷的发展路径。特别是对于ASN.1，您可以将系统的所有消息 /数据结构及其约束以及系统的所有常数在架构中定义一次。然后，您可以使用构建系统自动传播对项目每个角落的任何更改。借助这种模式，您可以非常轻松，安全地对系统界面进行后期的更改。
Ah, the quest for the hallowed model<==>schema<==>code<==>model triangle.
I don't actually have a good answer I'm afraid. The closest I've got to this is Enterprise Architect, XSD, and ASN.1. But this is not complete; Enterprise Architect doesn't sync to XSD; it's a straight forward import/export, so changes made in XSD don't reflect back to Enterprise Architect. In EA, you can define classes (classic UML stuff), and export a package of classes as XSD, which the better ASN.1 tools will consume as a schema (there is an official translation between XSD and ASN.1 schema, and ASN.1 compilers tend to be better at implementing and enforcing things like
minoccursin generated code (a lot of XML/XSD compilers actually do a bad job of such things).I've kind of given up looking. My suspicion is that tool developers will only do so if there is a market (or an enthusiastic user base willing to contribute donations for OSS). An awful lot of software gets developed without the use of schemas to define data structures (which leads to a large number of the world's buffer overruns, interface bugs, etc), never mind tools that sync code / schemas / models. So I think that there's precious few developers out there who see the actual value of such tooling, and so there's not that much enthusiasm for developing the tools in the first place. It's a classic chicken / egg situation.
Which is a pity. Using a strong schema system like ASN.1, or XSD (with a really good compiler) or perhaps at a pinch JSON (there seems to be more of an emphasis on using schema to check objects, rather than using scheme to define classes) leads to a very agile development path. Particularly with ASN.1, you can have all of a system's messages / data structures and their constraints and all of the system's constants defined once in a schema. You can then use the build system to propagate any changes to every corner of a project automatically. With this pattern embraced you can make late-breaking changes in system interfaces really quite easily and safely.