Re: Replacement for MS STL?
"Garry W" <ListMail3@extremelyserious.org> wrote in message
news:0ef0i2hs7apgsec86olnn1388ghtj490qs@4ax.com...
Pardon the pause in replying. It was one of those weeks where the code
started flowing =really= well...
Here's one of the STL bugs things I found. Rather inelegantly and rapidly
written up.
#1: _HAS_ITERATOR_DEBUGGING.
(This was discussed here recently, but only after I had to find it on my
own.)
Background: Because I'm dealing with a huge data collection, I had been
compiling most of my program "Release", for needed speed, while compiling
only the bit that I'm actively working on as "Debug". Fair enough. But,
as
recently discussed here, the slimly-documented switch
_HAS_ITERATOR_DEBUGGING
- and, in particular, the completely-undocumented changing memory layout
that
depends on _DEBUG/NDEBUG - can cause all he.. to break loose when you mix
modes. Because the switch triggers different, incompatible, memory layouts
of
STL data.
By "undocumented" (it could be argued that the lack of documentation is
the
real bug here)
Then it's not a bug. There are *oodles* of macros and names beginning
with an underscore and a capital letter in the Standard C++ library.
Clause 17 of the C++ Standard tells you that these are part of the
implementation. Attempting to fiddle with such names, or second guess
how you might change them, is a dangerous and unsupported exercise.
.....
Nothing in those words would lead me to suspect that _DEBUG and NDEBUG
template-library code might be unmixable. Nothing at all is mentioned
about
C++ or the C++ STL.
Well, they are. Perhaps Microsoft's top-level documentation might
make such things clearer for beginners, but I'm astounded that a
putative expert would think it wise to mix libraries compiled with
different settings.
My workaround is now to completely delete the _DEBUG and NDEBUG symbols
from
my projects, while hoping that there are not any other ways for the MS
headers to behave differently in "Debug" and "Release" modes.
I love the existence of iterator debugging. Nice idea - the default
iterators
lend themselves to mistakes. My suggested fix would simply be to have the
user explicitly turn the feature on and off, rather than doing it by
implication.
There are compiler switches for doing just that.
Garry
PS - There have been rumors that the MS "_DEBUG" C++ operator-new/delete
is
incompatible with the MS "NDEBUG" C++ operator-new/delete. Are the rumors
true?
Dunno. That's not my diocese.
(It would be simple to make the debug/release heap calls mutually mixable
and
compatible (at a "normal case" cost of, hmmmmm.... one memory 'read' and
three Intel instructions) but I do not know whether Microsoft has chosen
to
do that.)
It ain't that simple.
P.J. Plauger
Dinkumware, Ltd.
http://www.dinkumware.com