Matthew,
Thanks! Looks like I should RTFM.
:-(
Ciao,
Peter K.
On Sep 30, 12:12 pm, Michael Matthews heav...@gmail.com wrote:
I'm using VC++ 8.0+ with protobuf 2.2.0 and as long as I add the call
toShutdownProtobufLibrary() before
exiting I don't see any memory leaks.
Michael Matthews
We are using protocol buffers in an embedded application.
On the server side (protobuf-c), we are getting the error too short
after 64 bit wire type.
On the client side (VC++, modified to read the protobuf-c
implementation) we get a received packet, but it seems to be zero
bytes long.
The
Good job, Kenton!
Thanks for your efforts.
Ciao,
Peter K.
--~--~-~--~~~---~--~~
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
Thanks, Kenton, I'll try it out tomorrow and post the results.
We're sticking with 2.0.3 for now, but will switch once 2.1 goes to
full release.
Ciao,
Peter K.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
!
Ciao,
Peter K.
--~--~-~--~~~---~--~~
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
Hi,
I'm not a PB expert, but I don't believe that the basic types support
bitfields.
One way to do it is to just expand each bitfield into a uint32.
Another way might be to just refer to all the bitfields as bytes.
We chose the first approach, but YMMV.
Ciao,
Peter K.
On May 8, 2:02 am
D'oh. Hold that thought. It looks like the C runtimes were different,
I'm just re-doing everything making sure they're the same.
Watch this space.
Ciao,
Peter K.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
the solution
file.
2. cl : Command line warning D9035 : option 'Wp64' has been deprecated
and will be removed in a future release
Ciao,
Peter K.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Protocol Buffers group
OK. That didn't help. Working on generating more information.
--~--~-~--~~~---~--~~
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
), but I'll need to come back to it with a fresh mind
on Monday to analyze root cause.
Thanks helps for the suggestions!
Ciao,
Peter K.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Protocol Buffers group.
To post
We've had some success with the protobuf-c implementation for embedded
systems. I second Kenton's recommendation.
Ciao,
Peter K.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Protocol Buffers group.
To post
libprotobuf and libprotoc as
DLLs and see if that changes the behavior.
Ciao,
Peter K.
--~--~-~--~~~---~--~~
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
and the associated headers with my project seems to
avert the problem.
Thanks! I look forward to the release; I realize these things are
fraught with peril.
Ciao,
Peter K.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Protocol
On May 4, 7:57 pm, Kenton Varda ken...@google.com wrote:
On Mon, May 4, 2009 at 11:12 AM, Peter K. koots...@gmail.com wrote:
OK, there seems to be projects called gtest and gtest_main that
are in the solution file, but don't seem to be in the repo.
Oh yeah, you're expected to run
14 matches
Mail list logo
