That could work but I suspect it would be a fair amount of work to implement. I think at that point you would almost be implementing an alternative serialization format for protocol buffers. Would it make sense to just store the plain binary format in shared memory?
On Wed, Oct 28, 2020 at 11:29 AM Mario Not64 <staypriv...@gmail.com> wrote: > Thanks for the feedback. > > Would it make sense for protobuf to create a class as per the .proto > definition but with NO extra stuff, in its own .h file. Then the real > message proto class would derive from that. Any code that used the class > only need to include the .h of the class no need to drag all the protobuf > stuff with it. The message class would provide copy fonctions to easely > transfer data from and to the real and message class. ? > > Le vendredi 23 octobre 2020 à 12 h 03 min 10 s UTC-4, acoz...@google.com > a écrit : > >> You are right that C++ protos are not POD and therefore might not be a >> good fit for your use case. You could try looking at other protobuf >> implementations such as UPB and protobuf-c. Since they are written in C I >> think they meet the POD requirement. >> >> On Thu, Oct 22, 2020 at 8:56 PM Mario Not64 <stayp...@gmail.com> wrote: >> >>> Hello, >>> >>> New to protobuf. Like to implement it in our existing code base. We >>> currently use cereal to serialiaze the data. We have over 100 >>> structs/classes send over TCP/IP. However reading about protobuf I came >>> across an issue that I wounder if other have tackled and found a solution >>> for. >>> >>> My understanding of protobuf is you defined your objects in .proto >>> files, protobuf generates .h and .cc files (c++ in our case) creating >>> matching classes. However most of are structs need to be POD (plain old >>> data) because they also live in shared memory. That seems totally >>> incompatible with protobuf. That tells me when such struct need to be >>> protobuffed , they must be copied into a protobuf version of that struct. >>> That sounds like a high maintenancy, high risk proposition. >>> >>> Suggestion ? >>> >>> Regards, >>> Mario >>> >>> -- >>> You received this message because you are subscribed to the Google >>> Groups "Protocol Buffers" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to protobuf+u...@googlegroups.com. >>> To view this discussion on the web visit >>> https://groups.google.com/d/msgid/protobuf/de357190-edbb-442b-a952-39cec6a51814n%40googlegroups.com >>> <https://groups.google.com/d/msgid/protobuf/de357190-edbb-442b-a952-39cec6a51814n%40googlegroups.com?utm_medium=email&utm_source=footer> >>> . >>> >> -- > You received this message because you are subscribed to the Google Groups > "Protocol Buffers" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to protobuf+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/protobuf/5497b8fb-2887-4ee6-8c13-ce705c2fa932n%40googlegroups.com > <https://groups.google.com/d/msgid/protobuf/5497b8fb-2887-4ee6-8c13-ce705c2fa932n%40googlegroups.com?utm_medium=email&utm_source=footer> > . > -- You received this message because you are subscribed to the Google Groups "Protocol Buffers" group. To unsubscribe from this group and stop receiving emails from it, send an email to protobuf+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/protobuf/CADqAXr4CVmD1LKqdP_qFDujF9aZKg4GNGo92kYhBfoRb434CCg%40mail.gmail.com.
