libstdc++ debug mode ideas 2

[Benjamin Kosnik <bkoz at redhat dot com>]

Begin forwarded message:

Date: 30 Jul 2003 19:21:08 +0200
From: Gabriel Dos Reis <gdr@integrable-solutions.net>
To: Doug Gregor <dgregor@apple.com>
Cc: Benjamin Kosnik <bkoz@redhat.com>
Subject: Re: [libstdc++ PATCH] libstdc++ debug mode (second try)


Doug Gregor <dgregor@apple.com> writes:

| In a talk I gave at Apple about the debug mode, the first bullet
| describing the role of link_name was:
| 
| 	"It's an ODR violation: get over it."
| 
| The fact is that, in the absence of a perfect template aliasing model,
| compiling part of a program in release mode and part of it in debug
| mode is an ODR violation. If you agree with this, then I only see two
| options:
| 	(1) Find that perfect template aliasing model, or
| 	(2) Manage the ODR violation so that it can't cause trouble.

I do not think it is a template aliasing model and that finding that
template alising model makes the problem (if there is one) go away.

The template-name is primarily there to provide name commonality.
What is being violated is not the declaration of the template-name,
but the ODR for the entity being named by the template.

| 	I see that include <debug/vector> makes std::vector the debug
| version even if we are compiling in release mode.

I must confess my sympathy for this approach.  It is the most simple
semantics I would expect.

| This differs from my
| original patch, where <debug/vector> declares a debugging vector as
| __gnu_debug::vector (regardless of whether or not we're in debug
| mode). The benefit of your approach is that users can change one
| #include to get debugging for a certain container type; the
| disadvantage is that you can't change it for a single container
| instance (since there is no separate __gnu_debug::vector to use). The
| other issue is that
| 
| 	#include <vector>
| 	#include <debug/vector>
| 
| will fail to compile in release mode, because std::vector will be
| defined twice and __std::vector will not be defined at all. With this
| methodology, the best we could do would be to emit a warning that the
| debug-mode vector will _not_ be used, and then skip the debug
| version. I wonder how many users would leave a stray <debug/vector>
| somewhere in their program and wonder why things are running slowly.

I think we should simply take that, we should avoid inclusion order
dependency and we should avoid second-guessing the programmer, by
assuming that he is stupid.  I'm not sure how we can reconsile the
above criteria but I will certainly object to changing the semantics
behind the back of the user.

[...]

| FWIW, I'd be happy to consider implementation ideas (even half-baked
| ones <g>) without full implementations. I've already been through
| several design iterations since I started in June, so even if you just
| send me an outline of the idea I can compare it with the approach I've
| chosen.

I have embarked on several campaigns and C++0x-related works; but I'll
try to come up with something.

-- Gaby