Re: debug extension overhead

[Jonathan Wakely <jwakely dot gcc at gmail dot com>]

2009/5/20 tom fogal:
> Benjamin Kosnik writes:
>>
>> > Have you considered adding a knob that would turn on a subset of
>> > _GLIBCXX_DEBUG checks that have lower overhead, e.g., guaranteed
>> > constant factor? ?Some users are giving up on it due to high overhead
>> > in certain cases, but they could benefit from cheap checks, such as
>> > vector subscript checks.
>>
>> Hmm. The idea was that for fine-grained checks, one would just select
>> the debug extension on a per-header basis, instead of using
>> _GLIBCXX_DEBUG. Ie, including debug/vector and
>> using __gnu_debug::vector if all you want is vector subscript checks.
>
> Does this work in practice?

Yes, very well.  I often do temporary, localised changes such as

class MyClass {
   // typedef std::vector<int> list_type;
   typedef __gnu_debug::vector<int> list_type;
...
};

then recompile and test.

> I haven't tried, but:
> ?... you can only link code compiled with debug mode and code compiled
> ?without debug mode if no instantiation of a container is passed
> ?between the two translation units. [1]
>
> implies that doing so in a large application would be very difficult,
> unless you didn't use containers as part of your interfaces.

That's talking about linking code with _GLIBCXX_DEBUG defined to code
with it undefined, because that changes the type  of std::vector
(including among other things, its layout and behaviour).  That change
might not be detectable by the linker, so would give a runtime
disaster, if you're lucky.

If you explicitly change a single container to be a
__gnu_debug::vector instead of std::vector (as above, *not* by
defining _GLIBCXX_DEBUG) then you're using a distinct type and will
get a compile-time or link-time failure.  To resolve that you "only"
have to recompile everything that is affected by the change in type,
just as you would if you changed MyClass::list_type from a vector to a
deque.

Jonathan