No you cant, on C++ bytes translates to string, wont allow for null.
Regards,
Sumit Kumar
On 14 Mar, 2013, at 2:39 AM, Feng Xiao xiaof...@google.com wrote:
You can just use bytes field.
On Wed, Mar 13, 2013 at 5:38 AM, Giri Guntipalli giri.guntipa...@gmail.com
wrote:
we need similar
Can we insert compiler warning for C++ builds as well in cases where deprecated
field is used ?
Regards,
Sumit Kumar
On 14 Mar, 2013, at 2:36 AM, proto...@googlecode.com wrote:
Comment #3 on issue 329 by sergei.s...@gmail.com: Add support for [deprecated
= true] on all types of
Int32 and such will see endianness issues when exchanging messages in-between
cross-endian platforms hence only byte type suffices.
On how we achieve fixed length string support once byte type is supported -
Just create a message with specific number of byte elements and can name it
like
Really? AFAIK C++ strings handle null's just fine... they're
pascal-style strings, not c-style strings.
$ cat test.cc
#include string
#include iostream
int main() {
std::string a(a\0b, 3);
std::cout a.size() std::endl;
return 0;
}
$ g++ -o test test.cc
$ ./test
3
Or are you saying that
On Thu, Mar 14, 2013 at 2:37 AM, Sumit Kumar kumar.su...@hotmail.comwrote:
No you cant, on C++ bytes translates to string, wont allow for null.
std::string handles NULs just fine, and protobuf's use of it for bytes
fields also works fine. (I have code that's been in production for a few
years
--
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
And what about a mixture: will (Java) classes generated by 2.4.1 work with
the 2.5.0 library ?
Op maandag 12 januari 2009 18:42:41 UTC+1 schreef Kenton Varda het volgende:
Just to add an official response: Yes, they will be compatible. If they
weren't, we would consider that a very serious
On Thu, Mar 14, 2013 at 1:42 AM, Ernest Micklei ernest.mick...@gmail.comwrote:
And what about a mixture: will (Java) classes generated by 2.4.1 work with
the 2.5.0 library ?
No. Only serialized data is ensured to be wire-compatible across all
protobuf versions, not the generated code. The
Thank you for confirming this.
^ Ernest
Op donderdag 14 maart 2013 21:35:00 UTC+1 schreef Feng Xiao het volgende:
On Thu, Mar 14, 2013 at 1:42 AM, Ernest Micklei
ernest@gmail.comjavascript:
wrote:
And what about a mixture: will (Java) classes generated by 2.4.1 work
with the
Giving this a bump. This might also be considered a feature request (the
ability to temporarily assign a string value to a protocol buffer during
serialization, rather than copying it).
--Kevin
On Friday, March 8, 2013 1:49:29 PM UTC-8, Kevin Regan wrote:
I often have situations like this:
A better solution should be to refactor your code a little bit to pass in a
mutable string object directly. You can expect protos to take movable
objects in the future, but even when that happens you will still need to
refactor your code.
I don't think we will change protobuf to share references
It is very common to have a const std::string argument. Indeed, just
about any API that you would export to the end user would probably support
taking aconst std::string key in this case.
--Kevin
On Thursday, March 14, 2013 6:31:54 PM UTC-7, Feng Xiao wrote:
A better solution should be to
12 matches
Mail list logo
