By binary format, you mean the serialized data. In our scenario, shared memory is not used as a transport medium, it's the data itself. Think of it as variables not shared between threads but between processes.
Le mercredi 28 octobre 2020 à 17 h 38 min 29 s UTC-4, [email protected] a écrit : > 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 <[email protected]> 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, [email protected] >> 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 <[email protected]> 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 [email protected]. >>>> 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 [email protected]. >> > 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/protobuf/8181c7db-5a75-49c1-811a-8bb2ae614782n%40googlegroups.com.
