[protobuf] Re: Seek in a codedoutputstream

2009-11-16 Thread Jason Hsueh
Oh, I see. No, CodedOutputStream doesn't support seek functionality, so I guess you'd have to go with b). Just make sure that you're using WriteLittleEndian64 and not WriteVarint64. On Sat, Nov 14, 2009 at 12:05 PM, Fishtank saptarshi.g...@gmail.com wrote: That's because I don't know the size

[protobuf] unexpected result from TextFormat::PrintToString in c++

2009-11-16 Thread edan
I have the following class: package PB_SimpleMessage; message SimpleMessage { required RootNode header = 1; required RootNode payload = 2; } message RootNode { repeated string parameters = 1; } In my code i am do the following:

[protobuf] Re: unexpected result from TextFormat::PrintToString in c++

2009-11-16 Thread Kenton Varda
The output is correct. You have not initialized the header field. You need to call mutable_header() once to initialize it. On Mon, Nov 16, 2009 at 1:45 AM, edan edan.sha...@gmail.com wrote: I have the following class: package PB_SimpleMessage; message SimpleMessage {

[protobuf] Re: Regd: Resolving Wire type ambiguities

2009-11-16 Thread Jason Hsueh
You can decode the protocol buffer with just wire type + tag number, but you won't know the original types without a proto definition. Everything would be treated as an unknown field. You could access these by iterating through the UnknownFieldSet, but again, you can't recover the original types.

[protobuf] question about creating message classes dynamically (known at runtime)

2009-11-16 Thread JC-MAD-SP
Hi I'm new to ProtocolBuffer. Until now all is going ok with Protocol Buffers for my needs. But, now I'm struggling for a while with a Message-New issue without a clue. I'm trying to create concrete messages, which are known at runtime using DynamicMessageFactory (C++). Following is the

[protobuf] Re: question about creating message classes dynamically (known at runtime)

2009-11-16 Thread Kenton Varda
On Mon, Nov 16, 2009 at 11:35 AM, JC-MAD-SP public.cebal...@gmail.comwrote: ConcreteMessage* concreteMessage = reinterpret_castConcreteMessage* (mesage-New()); This line is invalid. Here, *message is a DynamicMessage, and New() also returns a DynamicMessage, not a ConcreteMessage.

[protobuf] Re: question about creating message classes dynamically (known at runtime)

2009-11-16 Thread Kenton Varda
BTW, you could catch this problem more easily if you defined a down_cast function like: template typename To, typename From To down_cast(From from) { #ifdef NDEBUG return static_castTo(from); #else To result = dynamic_castTo(from); assert(result != NULL); return result; #endif } This

[protobuf] Re: question about creating message classes dynamically (known at runtime)

2009-11-16 Thread JC-MAD-SP
(I think my previous reply didn't arrive) Thanks Kenton, this worked fine for me. Probably, with DynamicMessageFactory I was trying to solve in a single attempt, dynamic generation of both classes known in compile-time and unknown. I forgot then to check back again with MessageFactory. I guess,

[protobuf] Regd: Resolving Wire type ambiguities

2009-11-16 Thread rahul prasad
Hi, Thanks for the clarification. I did try one dirty method of finding the original types, because of my .proto-less situation. I relied on exception statements thrown out when I iterated through the protobuffers by trying to extract a known wiretype with a wrong-type getter. I know it sucks,

[protobuf] Re: Regd: Resolving Wire type ambiguities

2009-11-16 Thread Kenton Varda
It sounds like you actually have the message class available, not just a serialized instance of the message. In that case, you can derive the original type by reading the generated code. If you only have a compiled copy of the class, you can derive the type from its descriptor -- use