This is the mail archive of the
mailing list for the libstdc++ project.
Re: [libstdc++ PATCH] libstdc++ debug mode
On Tuesday, July 15, 2003, at 2:57AM, Benjamin Kosnik wrote:
4) If running the libstdc++ testsuite, add the flag
into the flags returned from --build_cxx in the script
For 4, You should just change
I changed it in scripts/testsuite_flags because that's a non-permanent
change that one wouldn't accidentally check in. We really would like to
run the testsuite twice, once for debug mode and once for release mode,
but there's no machinery to do that (yet?).
and in /libstdc++-v3/testsuite/testsuite_hooks.h change
the define of
You mean the "#ifdef DEBUG_ASSERT"? That seems unrelated to the debug
Eh. For the time being, please just put the __is_null_pointer bits into
the string includes.
* include/bits/debug/support.h: New.
* include/bits/debug/vector.h: New.
* include/ext/debug/bitset: New.
* include/ext/debug/deque: New.
Please don't nest directories in here.
* include/debug: Add your stuff here.
Just to be clear about the purpose of the two separate directories:
- bits/debug contains the debug-mode wrappers and support code. So
when you compile with -D_GLIBCXX_DEBUG, an include of <list> will pick
up bits/debug/list.h and make it std::list.
- ext/debug contains the debugging wrappers for debug or release mode,
e.g., including <ext/debug/list> gets you __gnu_cxx::debug::list.
I can put everything into include/debug (files for containers from
bits/debug will get the prefix "dbg_") but it may be more confusing
One last comment on this: at Boost we generally try to match the
directory structure with the namespace structure, so that, e.g.,
including <outer/inner/foo> gets you outer::inner::foo. If we move all
of the debug code into include/debug, then including <debug/list> will
pull in __gnu_cxx::debug::list.
like the ext directory duplicate headers.
* debug/Makefile.am: New.
There's got to be a better solution than this. . . If you don't want to
keep the old, hacky src/Makefile.am rules, that is ok with me, but
try to come up with something that's an improvement that doesn't
duplicate so much of src/Makefile.am in the process. Alexandre Oliva
recently suggested looking at the multilib approach, which I believe
libjava uses: can you take a look at that approach please, or quiz him
to see what he means by this?
I'll look into multilibs.