[protobuf] implications of compiling protocol buffers without stl debugging info

2012-08-08 Thread Chris Morris
I have some file. Let's call it *Msg.proto* I use Google's protoc.exe compiler to take my proto file and it generates a *Msg.h* file, which contains the definition for a *Msg* class. When I *delete* a *Msg* object it can take a really long to deallocate the memory (when the debugger is

[protobuf] Re: implications of compiling protocol buffers without stl debugging info

2012-08-08 Thread Chris Morris
I'm updating my question: I have some file. Let's call it *Msg.proto* I use Google's Protocol Buffer protoc.exe compiler to take my proto file and it generates a *Msg.h* file, which contains the definition for a *Msg* class. When I delete a *Msg* object it can take a really long to deallocate

Re: [protobuf] implications of compiling protocol buffers without stl debugging info

2012-08-08 Thread Eric J. Holtman
On 8/8/2012 4:51 PM, Chris Morris wrote: I want to keep STL debugging *for the rest of my project*. This leads me to consider compiling the protocol buffers project without STL debugging info. What are the implications of this? Unless you are *very* careful, this is going to lead to

Re: [protobuf] implications of compiling protocol buffers without stl debugging info

2012-08-08 Thread Chris Morris
Let's pretend that file *X* is neither *Msg.h* nor any file in the Google Protocol Buffer library. And let's say that file *Y* is either *Msg.h* or some file in the Google Protocol Buffer library. In this case, any STL object created in *X **cannot* be passed to *Y*, and vice versa, correct?

Re: [protobuf] implications of compiling protocol buffers without stl debugging info

2012-08-08 Thread Christopher Smith
On Wed, Aug 8, 2012 at 3:08 PM, Eric J. Holtman e...@holtmans.com wrote: On 8/8/2012 4:51 PM, Chris Morris wrote: I want to keep STL debugging *for the rest of my project*. This leads me to consider compiling the protocol buffers project without STL debugging info. What are the implications

Re: [protobuf] implications of compiling protocol buffers without stl debugging info

2012-08-08 Thread Chris Morris
So how do I ensure that the STL containers are destructed w/ the proper STL library? Let me second this. Microsoft themselves is very clear that if the destructor doesn't do its cleanup on an STL container that was built with debug features, bad things will happen. -- You received

[protobuf] Re: Issue 351 in protobuf: Make protobuf_lite proto files not create any static initializers

2012-08-08 Thread protobuf
Issue 351: Make protobuf_lite proto files not create any static initializers http://code.google.com/p/protobuf/issues/detail?id=351 This issue is now blocking issue chromium:94925. See http://code.google.com/p/chromium/issues/detail?id=94925 -- You received this message because you are listed

[protobuf] Re: Issue 351 in protobuf: Make protobuf_lite proto files not create any static initializers

2012-08-08 Thread protobuf
Issue 351: Make protobuf_lite proto files not create any static initializers http://code.google.com/p/protobuf/issues/detail?id=351 This issue is now blocking issue chromium:94925. See http://code.google.com/p/chromium/issues/detail?id=94925 -- You received this message because you are listed

[protobuf] Re: Issue 298 in protobuf: protobuf jar's manifest should include OSGi metadata

2012-08-08 Thread protobuf
Comment #9 on issue 298 by cgruberatg...@gmail.com: protobuf jar's manifest should include OSGi metadata http://code.google.com/p/protobuf/issues/detail?id=298 Here's a patch to the pom, adapted from Guice's info, that doesn't require a packaging type change, and includes appropriate

[protobuf] Re: Issue 298 in protobuf: protobuf jar's manifest should include OSGi metadata

2012-08-08 Thread protobuf
Updates: Owner: xiaof...@google.com Comment #10 on issue 298 by liuj...@google.com: protobuf jar's manifest should include OSGi metadata http://code.google.com/p/protobuf/issues/detail?id=298 (No comment was entered for this change.) -- You received this message because you are