implications of compiling protocol buffers without stl debugging info

[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 attached). This is because it is using the STL debug library. So, I want to disable STL debugging when I delete Msg objects, but 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?

This means that all Msg objects will not have STL debugging info, right? Consequently, no STL objects created with STL debugging info can be passed into any of Msg's functions/constructors/etc, right?

[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 the memory (when the debugger is attached). This is because it is using the STL debug library. So, I want to disable STL debugging when I delete Msg objects, but I want to keep STL debugging for the rest of my project. This leads me to consider turning off STL debugging info for Msg.h and for the Google Protocol Buffer project (because this is used by the Msg class, and only by the Msg class).

What are the implications of this?

What I'm guessing is:

1. no STL objects created with STL debugging info can be passed into any of Msg's functions/constructors/etc, because that would mean that an STL object created w/ one version if the STL library is then being passed to a portion of the code that uses a different version of the STL library
2. others?

[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
problems:

The basic problem is that you will have two versions of
the C++ runtime library loaded, so there will be two
copies of "new" and two copies of "delete".

If you get a pointer back from "debug new", you need to
make sure it passed to "debug delete", or you're going
to end up with extreme pain.

That problem is hard to overcome, but not impossible.

There are some problems that might not be solvable though:
if the runtime libraries (that contain new and delete)
have designs where they "want to be first or last" in
a program's startup or shutdown, there's no way to make
everyone happy. If both the debug and the release versions
want to be "first", they can't both be happy.

[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?

The way to use iterator debugging or not is with the following symbol: _HAS_ITERATOR_DEBUGGING

Are you saying that whether or not this symbol is set to 0 or 1 will cause a different version of the C++ runtime library to be used?

[Christopher Smith]

On Wed, Aug 8, 2012 at 3:08 PM, Eric J. Holtman <er...@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 of this?
>
> Unless you are *very* careful, this is going to lead to
> problems:

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.

I think the best you could do is build all your protocol buffer stuff
(including the base library) with _HAS_ITERATOR_DEBUGGING=0. Your
container types likely won't match, so you'll have to use std::copy
and such to move data between other parts of your code and protocol
buffers, but otherwise it might work.

This would likely introduce as many bugs as it might fix, and the
debug stuff for STL containers has some other nasty side effects as
well (scoping rules for for loops change). I'd recommend instead just
doing without... maybe use a 3rd party checked iterator library in the
places you really want it.

--
Chris

[Chris Morris]

So how do I ensure that the STL containers are destructed w/ the proper STL library?