[protobuf] Is there a pure c protocol buffers port?
In my project, I can only use c and any c++ dependence is not allowed. Anyone know any pure c port ? Thanks. -- You received this message because you are subscribed to the Google Groups Protocol Buffers group. To post to this group, send email to protobuf@googlegroups.com. To unsubscribe from this group, send email to protobuf+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/protobuf?hl=en.
Re: [protobuf] optional vs required
On Tuesday, 9 June 2015 01:27:24 UTC+1, Feng Xiao wrote: On Mon, Jun 8, 2015 at 7:43 AM, Colin Deasy cde...@demonware.net javascript: wrote: Hey, When reading https://developers.google.com/protocol-buffers/docs/proto#simple I see a stark warning indicating that Required is Forever advocating the use of optional with additional application level validation routines. This is because if at some point a required field is no longer written, the readers will break. However IMO, there are common cases where 'required' is a good thing - given that it's enforced only during encoding/decoding. For example there may be some field that is 'required' (right now) to both the reader and writer. Even if that changes at some point in the future to become optional, the reader would likely have to be updated regardless of the protocol decoding routine as it may make assumptions (reasonable considering it was required in the first place) on the presence of the field (e.g. the field being a key to a certain bit of data). In this case the approach would be to update the .proto of all readers to make that field optional, followed by updating all writers to remove the field. In simpler scenarios, yes, it's possible to migrate a required field to optional even though it's an incompatible change, but in a more complicated system, where you have many different binaries using the same proto file running on thousands of machines, it's hard to tell whether all readers of a proto has been updated or not. You have to be very careful with such changes, and if you miss one, bad things can happen. My point is that regardless of the size of the cluster, you will need to update every reader - it doesn't matter whether the 'required' constraint is within the protobuf deserialization logic or within the application logic itself. Similar to missing an update to a certain application instance's proto file, you could miss an update the to application's binary itself. This is precisely why I don't understand the logic behind deprecating the 'required' constraint. Given this, I feel that the current language of the linked document gives the impression that the 'required' attribute is a Bad Thing and should be avoided. I hope you can clarify if I'm missing some crucial bit of information regarding it's usage. Thanks Colin -- 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 javascript:. To post to this group, send email to prot...@googlegroups.com javascript:. Visit this group at http://groups.google.com/group/protobuf. For more options, visit https://groups.google.com/d/optout. -- 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 post to this group, send email to protobuf@googlegroups.com. Visit this group at http://groups.google.com/group/protobuf. For more options, visit https://groups.google.com/d/optout.
[protobuf] optional vs required
Hey, When reading https://developers.google.com/protocol-buffers/docs/proto#simple I see a stark warning indicating that Required is Forever advocating the use of optional with additional application level validation routines. This is because if at some point a required field is no longer written, the readers will break. However IMO, there are common cases where 'required' is a good thing - given that it's enforced only during encoding/decoding. For example there may be some field that is 'required' (right now) to both the reader and writer. Even if that changes at some point in the future to become optional, the reader would likely have to be updated regardless of the protocol decoding routine as it may make assumptions (reasonable considering it was required in the first place) on the presence of the field (e.g. the field being a key to a certain bit of data). In this case the approach would be to update the .proto of all readers to make that field optional, followed by updating all writers to remove the field. Given this, I feel that the current language of the linked document gives the impression that the 'required' attribute is a Bad Thing and should be avoided. I hope you can clarify if I'm missing some crucial bit of information regarding it's usage. Thanks Colin -- 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 post to this group, send email to protobuf@googlegroups.com. Visit this group at http://groups.google.com/group/protobuf. For more options, visit https://groups.google.com/d/optout.
[protobuf] CPP serialize always return empty string and cached size is 0 but i can get data
Hello I've got some troubles because when I build a message and try to serialize it, the func serializeToString return true but the string is empty and if I get the mutables values of my message it gives me the good values some ideas ? btw i'm using protobuf 3.15.8 -- 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/85ea1060-24a7-476f-b532-add15816a40en%40googlegroups.com.
[protobuf] Re: CPP serialize always return empty string and cached size is 0 but i can get data
here are some screenshots code : [image: Untitled.png] breakpoint info : [image: Untitled3.png] [image: Untitled2.png] Le vendredi 8 octobre 2021 à 11:49:35 UTC+2, Thomas Colin a écrit : > Hello I've got some troubles because when I build a message and try to > serialize it, the func serializeToString return true but the string is > empty and if I get the mutables values of my message it gives me the good > values some ideas ? btw i'm using protobuf 3.15.8 -- 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/30420761-5ed4-4b72-8de8-4871d882debfn%40googlegroups.com.
[protobuf] Reading FileOptions extension in C++?
I know how to read an option within Message by using GetExtension on the Message, but can I do that for a global option that is not encapsulated within a message? So in C++, how would I read the "my_file_name" option from the proto below? extend google.protobuf.FileOptions { string my_file_name = 1001; } extend google.protobuf.MessageOptions { optional string my_option = 51234; } option (my_file_name) = "filename.txt"; message MyMessage { option (my_option) = "Hello world!"; } -- 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/59b76f3b-faae-480b-94b0-c8945b6ccad2n%40googlegroups.com.