Re: Replacement for MS STL?
Garry W wrote:
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.)
Yeah, it's subtle. The (mostly, if not completely) undocumented truth is:
You can't reliably mix Debug and Release in a single build. There are too
many things that are simply undefined. In any case, this can't really be
blamed on the STL implementation.
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?
If you're talking about a single image (i.e. the result of a single
invocation of the linker), then there aren't any issues, because your image
will be linked with either the debug heap OR the release heap. Exactly
which one will depend on a bunch of things not worth going into here
(suffice it to say, you should never do this on purpose unless you really
know what you're doing).
If you're talking about multiple images, e.g. two different DLLs, then you
do indeed have an incompatibility. If you link two DLLs, both with the DLL
runtime library, but one's a release build and the other is a debug build,
then an object allocated in one of the DLLs can't be freed in the other (and
vice-versa). This is because you're now running a program with two
completely separate implementations of the runtime library in memory. It's
no different in principle than allocating something with CoTaskMemAlloc and
then freeing it with free() - they're simply two different heaps that can't
be mixed.
-cd