Re: Xcode Release vs Debug Differences: Problem with Exception Types
Re: Xcode Release vs Debug Differences: Problem with Exception Types
- Subject: Re: Xcode Release vs Debug Differences: Problem with Exception Types
- From: Marshall Clow <email@hidden>
- Date: Tue, 17 Jun 2008 22:16:19 -0700
At 6:33 PM -0700 6/17/08, Chris Hanson wrote:
On Jun 17, 2008, at 12:13 PM, Marshall Clow wrote:
At 12:55 PM -0600 6/17/08, Matthew Tobiasz wrote:
I've reproduced this issue in a completely new project, started
from scratch. Here's exactly what I did.
[ snip ]
I suspect that you've run into a really ugly "feature" of gcc.
Actually, it's a feature of the C++ specification, and not one
that's likely to be resolved any time soon.
The issue is this: Different compilers and runtimes can and do
interpret the One Definition Rule differently.
Right. That's what makes it a "feature" (actually a misfeature) of
gcc. They _chose_ to implement it this way (and then to blame the
user when perfectly reasonable code fails at runtime).
In the specific case Matthew is running into, the GCC C++ runtime
compares type information -- for example, in a "catch ()" construct
-- based on the address of its typeinfo structure. Microsoft Visual
C++, on the other hand, compares the same type information based on
the name in its typeinfo structure.
GCC's interpretation could be argued to be more correct: For
example, if you have two libraries each with its own definition of
FooException, GCC's C++ runtime won't mistakenly interpret one
FooException as the other in a "catch ()" construct.
If gcc's runtime compared _the contents_ of the typeinfo structure,
it would (I believe) work correctly in all cases. (I could be wrong
here, but at the very least it would be _more correct_ than the
current implementation). Silent runtime failures are BAD.
How many times has this come up on this list? I have answered this at
least 5x in the last three years.
On the other hand, with GCC you have to be more pedantic about
ensuring type information for classes defined in a shared/dynamic
library is exported properly.
Alternately, you could say that you have to litter your source code
with gcc-specific "attribute" tags in order to make your code perform
in the way that you expect.
The last time I heard several C++ standards committee members talk
about it (C++ Live, November 2005), Bjarne Stroustrup himself stated
that the behavior of C++ when using shared/dynamic libraries was
something better left to the market (e.g. implementors) rather than
the standards committee.
I think that's a mistake, since it makes it harder to write portable C++ code.
However, the whole "packaging" problem in C++ is horribly mucked up anyway.
I'll second Marshall's recommendation to read TN 2185
<http://developer.apple.com/technotes/tn2007/tn2185.html> to get
more detail on this.
Cruddy up your source code. Oh, boy.
--
-- Marshall
Marshall Clow Idio Software <mailto:email@hidden>
It is by caffeine alone I set my mind in motion.
It is by the beans of Java that thoughts acquire speed,
the hands acquire shaking, the shaking becomes a warning.
It is by caffeine alone I set my mind in motion.
_______________________________________________
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