Recursive import problem

2009-08-13 Thread Justin Muncaster
I have the following message structure: ===A.proto=== message A { optional B1 b1 = 1; } message B1 { optional A a = 1; } Everything works as intended when the messages are in the same file. However, in my situation there are several child messages (B2, B3, ...) which all naturally all go in

Re: protobuf HPUX support

2009-08-13 Thread Kenton Varda
Please send a patch. Use "diff -u" to create it (see the man page), or if you made your changes against the SVN sources, just use "svn diff". On Wed, Aug 12, 2009 at 10:08 PM, COFF wrote: > > Hello Kenton! > > I succesfully merge my project on new version of protobuf. > I made patches that enab

Re: Recursive import problem

2009-08-13 Thread Kenton Varda
Sorry, but mutually recursive messages must be declared in a single file. It would be excessively complicated to support cyclically dependent files under the current implementation. On Thu, Aug 13, 2009 at 11:34 AM, Justin Muncaster < justin.muncas...@gmail.com> wrote: > > I have the following m

Protobuf-lite and ParseFromIstream/SerializeToOstream

2009-08-13 Thread Handyman
Those serializers seem to have been taken out for the MessageLite implementation. I'm migrating old code to the lite implementation -- I just create a std::ifstream/std::ofstream and hand it off to Message in my old code. Whats the best way to do this in the new code? The CodedStream stuff look

Re: Protobuf-lite and ParseFromIstream/SerializeToOstream

2009-08-13 Thread Kenton Varda
Deciding exactly where to draw the line for lite mode was hard -- different users want different things. There's two reasonable options here: 1) Read the entire istream to a string first, then call ParseFromString. Similarly, when writing, use SerializeToString() then write the entire string to t

Re: Protobuf-lite and ParseFromIstream/SerializeToOstream

2009-08-13 Thread Handyman
Thanks. That'll help. I'll try the second approach you mentioned (my messages are not complex but the chunks of data are fairly large -- often well over 100k so I didn't want to use solution #1). If there are any hiccups I'll post them here for posterity. There is no answer to the question of

Re: protobuf HPUX support

2009-08-13 Thread COFF
On 14 авг, 02:24, Kenton Varda wrote: > Please send a patch.  Use "diff -u" to create it (see the man page), or if > you made your changes against the SVN sources, just use "svn diff". > I also get worket MSVC 7.1 in this pathes (note on macro EXPECT_EQ produse Internal Compiller error on MSVC

Re: protobuf HPUX support

2009-08-13 Thread COFF
I does not find how to attach files in this group, and simple paste it in message. On 14 авг, 02:24, Kenton Varda wrote: > Please send a patch.  Use "diff -u" to create it (see the man page), or if > you made your changes against the SVN sources, just use "svn diff". > > On Wed, Aug 12, 2009 at

Re: protobuf HPUX support

2009-08-13 Thread COFF
I sent patches directly to you. Note on adding also VC 7.1 support (macro EXPECT_EQ produse Internal Compiller Error on non const std::string) On 14 авг, 02:24, Kenton Varda wrote: > Please send a patch.  Use "diff -u" to create it (see the man page), or if > you made your changes against the S

Re: protobuf HPUX support

2009-08-13 Thread Kenton Varda
Instead of changing everything that calls EXPECT_EQ on strings, can we change the implementation of EXPECT_EQ itself so that doesn't trigger this error? For example, could it be overloaded with an explicit implementation for non-const strings? Any changes to gtest will have to be submitted back to

Re: protobuf HPUX support

2009-08-13 Thread COFF
Thank you for answer. I will try doing this way too. On 14 авг, 10:18, Kenton Varda wrote: > Instead of changing everything that calls EXPECT_EQ on strings, can we > change the implementation of EXPECT_EQ itself so that doesn't trigger this > error?  For example, could it be overloaded with an e

Re: protobuf HPUX support

2009-08-13 Thread COFF
New patch avoid this sent. On 14 авг, 10:54, COFF wrote: > Thank you for answer. I will try doing this way too. > > On 14 авг, 10:18, Kenton Varda wrote: > > > Instead of changing everything that calls EXPECT_EQ on strings, can we > > change the implementation of EXPECT_EQ itself so that doesn't