I would like to know about the platforms that Protocol Buffers support
for C++ generated code.
Please let me know.
Thanks,
Shirish
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Protocol Buffers group.
To post to
See discussion here: http://code.google.com/p/protobuf/issues/detail?id=57
On Apr 1, 5:03 pm, Jim Sermersheim j...@fusionio.com wrote:
In the generated Java code, a typical Builder set method might look like
this:
public Builder setSomething(java.lang.String value) {
In the binary file generated using Protocol Buffers, the new line
characters are present, not sure about the reason. Can't those be
removed to get more smaller size (compared against similar XML)? Just
a thought!
--~--~-~--~~~---~--~~
You received this message
Hi; I'm the author of protobuf-net, and I hope I can help you find
what is going on here...
The binary format should be compatible between platforms (that is the
point, after all). Are you able to share your OrderProto class with
me? Either here, or at marc.grav...@gmail.com. The base-64 should
Maybe I'm missing the point - but that would change the data? The
binary file doesn't include whitespace (etc) except for in strings
that are user data.
Marc
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Protocol
It seems I was wrong in trying to use ASCII or UTF-8 encoding. This
works.
private string Serialize(OrderProto proto)
{
using (MemoryStream stream = new MemoryStream())
{
Serializer.SerializeOrderProto(stream, proto);
using
No, the newlines are part of the binary data. (They aren't really
newlines though since the data is not text. They are bytes with the value
10.)
Or are you actually talking about the text format?
On Thu, Apr 2, 2009 at 3:02 AM, ShirishKul shirish...@gmail.com wrote:
In the binary file
Most Unix-like platforms (Linux, Mac OSX, FreeBSD, Solaris, Cygwin, etc.)
and Windows (MinGW, MSVC) are supported. libprotobuf does not use many
OS-specific features so it's likely to be easy to port to other platforms.
However, it is not well-designed for stripped-down embedded systems with
I think you're both right. Marc is talking about fields of type 'string'
that happen to include newlines, because that's what the user put in them.
I'd guess the reason Shirish is seeing newlines all over is because he has a
field
optional string foo = 1;
somewhere, which gets keyed to
Actually, I was wrong, this code produces an empty string. The
following code serializes *something* which fails on the server side
on ParseFromString. Any ideas what I have to do to correctly serialize
this?
private string Serialize(OrderProto proto)
{
using
Your point is valid, in that I need to update the documentation to
make things a bit clearer. So many tasks, so few hours...
If you have any other problems, please don't hesitate to ask,
Marc Gravell
--~--~-~--~~~---~--~~
You received this message because you are
Quick question - which build are you using? (at client and server)?
Based on the field names, the code-generation dates back to November;
if the dlls are aged similarly, it is possible that this is an old
bug. If possible, can you retry with the current build?
I'm just trying the code you
You can't use unicode to transport arbitrary binary data - it won't be
a valid unicode string. If you have to use strings, then base-64 is
the safest option:
private string Serialize(OrderProto proto)
{
using (MemoryStream stream = new MemoryStream())
{
(re last post)
As with unicode, you can't use ASCII to handle raw binary; either use
base-64 (previous post), or send binary.
Marc
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Protocol Buffers group.
To post to
14 matches
Mail list logo
