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: Chris Hanson <email@hidden>
- Date: Wed, 18 Jun 2008 01:11:24 -0700
On Jun 17, 2008, at 10:16 PM, Marshall Clow wrote:
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).
The GCC developers chose to implement the feature this way because the
spec gives them leeway to do so.
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.
Say an application used an embedded copy of libstdc++ 4.0, while a
framework used an embedded copy of libstdc++ 4.2. Should
std::exception in the application's copy of libstdc++ be considered
"the same as" the framework's? What if they wound up with different
vtable layouts due to declaration changes in intervening versions?
That's my understanding of the reason GCC behaves the way it does:
Only the same typeinfo compares equal, rather than an equivalent
typeinfo, because to do otherwise could cause non-interchangeable
types to be treated interchangeably. Furthermore, the C++
specification gives implementors this latitude.
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.
If the language standard won't address the issue, the implementations
still have to do so somehow.
You don't have to use __attribute__ syntax; you can either put the
declarations behind macros, or you can apply the visibility settings
on a whole-library/executable basis using the visibility build settings.
-- Chris
_______________________________________________
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