This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Why does casting a function generate a run-time abort?



On 21 Jun, 2004, at 21.42, Mark Mitchell wrote:


Ziemowit Laski wrote:


Hm... I can't really claim that I never consider aesthetics in my hac^H^H^Hengineering activities, although technical considerations always trump them, as they should. I guess I'll just wait for your METHOD_EXPR work, and then will decide which approach is more disgusting. :-)

I'm going to jump in here and say that I strongly agree with Richard.


In over a decade of working on front ends, I've long since concluded that you want to express special things as special nodes. A good example is exception-handling; a C++ front end could just transform it all into setjmp/longjmp (as Cfront did), but then you get bad performance.

Special nodes are good if you need to propagate semantics to the back end, as your C++ EH example shows. In ObjC, all we need to do is cast a function to a different signature and then call it. While you certainly _may_ create a special node for this, I don't see what this buys you...


If you want good performance, you must send it to the back end as try/catch. As Richard says, virtual function calls really ought to be the same; there's no reason to devolve into the vtable-indexing C-ish stuff until you have optimized as much as you can.

...except that ObjC message dispatches have nothing whatsoever to do with C++ or Java virtual dispatches. As I said, I'll wait for Richard's METHOD_EXPR to see if his stuff is applicable.


--Zem
--------------------------------------------------------------
Ziemowit Laski                 1 Infinite Loop, MS 301-2K
Mac OS X Compiler Group        Cupertino, CA USA  95014-2083
Apple Computer, Inc.           +1.408.974.6229  Fax .5477


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]