• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: Catching C++ exceptions thrown from a framework
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Catching C++ exceptions thrown from a framework


  • Subject: Re: Catching C++ exceptions thrown from a framework
  • From: Howard Hinnant <email@hidden>
  • Date: Tue, 18 Jul 2006 12:16:29 -0400

On Jul 18, 2006, at 11:03 AM, Steve Baxter wrote:

Does this still work if you use CFBundle to load your code? CFBundle loads DLLs with private visibility which breaks all the RTTI fixes. I have been told that this "behaves correctly".

I have not personally run this experiment and trust the previous support you have received.


Basically we want the same behaviour as CW and VC++ - the performance "improvement" of the Xcode way is negligible (who needs high-performance exceptions) and causes a lot of trouble! This all used to work - Xcode's approach has stopped it working.

Just to clarify, the rationale for this behavior isn't performance. You and others have correctly pointed out that the performance of type_info comparisons is a non-issue. The issue is to allow, perhaps even accidentally, two types with identical names to be safely hidden in two linkage units, with no chance that they will be mistaken for the same type.


This should be used as a transitional flag or "quick fix" flag. The more robust approach is to decorate your sources with visibility attributes (or pragmas).

This is not exactly a developer-friendly option - why is this not a permanent fix? What does it actually do?

My apologies. We understand that hidden visibility is currently more difficult and error prone than we would like. We will continue to try to improve the situation.


The reason this isn't recommended as a long term solution is that we believe (and has been my personal experience with previous tool sets) that decorating the source code (i.e. like the VC++ / CodeWarrior declspec dance) is a more robust technique. However that's just a recommendation, nothing more. I don't want to imply that - fvisibility-ms-compat has a limited shelf life. If this is the solution that works for you, we are very happy that we could help.

Can I beg once more for Apple to compile the runtimes to compare using type names not type_info addresses? This is a single switch that would make all this pain go away for everyone.

<nod> We will continue to listen to you, our customer, and genuinely appreciate your feedback.


-Howard

_______________________________________________
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


References: 
 >Re: Catching C++ exceptions thrown from a framework (From: Eric Slosser <email@hidden>)
 >Re: Catching C++ exceptions thrown from a framework (From: Steve Baxter <email@hidden>)
 >Re: Catching C++ exceptions thrown from a framework (From: Steve Baxter <email@hidden>)
 >Re: Catching C++ exceptions thrown from a framework (From: Howard Hinnant <email@hidden>)
 >Re: Catching C++ exceptions thrown from a framework (From: Steve Baxter <email@hidden>)

  • Prev by Date: Re: Passing '-t' to the linker
  • Next by Date: Re: Catching C++ exceptions thrown from a framework
  • Previous by thread: Re: Catching C++ exceptions thrown from a framework
  • Next by thread: Re: Catching C++ exceptions thrown from a framework
  • Index(es):
    • Date
    • Thread