Re: _GLIBCXX_DEBUG _GLIBCXX_DEBUG_PEDANTIC nuttiness causing debug build crashes...
Re: _GLIBCXX_DEBUG _GLIBCXX_DEBUG_PEDANTIC nuttiness causing debug build crashes...
- Subject: Re: _GLIBCXX_DEBUG _GLIBCXX_DEBUG_PEDANTIC nuttiness causing debug build crashes...
- From: "Clark Cox" <email@hidden>
- Date: Wed, 5 Dec 2007 11:00:01 -0800
On Dec 5, 2007 8:29 AM, Graham Reitz <email@hidden> wrote:
> Thanks Tom,
>
> > That is what goes wrong - the passed in values don't survive
> > validation. Either one of them is uninitialized, they are in the
> > wrong order or don't belong to the same container.
>
> Why does the exact same code and libraries run fine under the release
> build?
This is the whole point of these extra checks. Many people do things
with the STL that *seems* to work, but which isn't guaranteed to work
by the C++ standard. Some examples of this that I have seen in
people's code:
1) Assuming that every iterator is just a pointer or can be
constructed from one (setting an iterator to NULL is a very common
example of this).
2) assuming that it is legal to compare iterators that don't belong to
the same container
3) assuming that you can decrement an input iterator, output iterator
or forward iterator
4) assuming that you can store a copy of an input iterator to
"remember your place"
...and many others.
Out of sheer luck (or lack thereof, when you really think about it),
many of these things will seem to work in many cases or on certain
platforms. The debug settings in GCC are being helpful by pointing
these problems out in debug mode (i.e. *before* you've shipped the bad
code to your customers).
You would be well served to leave these settings as they are, and to
track down every crash that they cause.
--
Clark S. Cox III
email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden