[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: PATCH: Merge objc-improvements-branch to mainline
From: |
Ziemowit Laski |
Subject: |
Re: PATCH: Merge objc-improvements-branch to mainline |
Date: |
Wed, 24 Sep 2003 12:09:34 -0700 |
On Wednesday, Sep 24, 2003, at 10:48 US/Pacific, Alexander Malmberg
wrote:
The documentation for these does not seem to be correct, or at least
not
consistent with the implementation. It seems that -fzero-link does what
-freplace-objc-classes is documented to do, and -freplace-objc-classes
emits a marker that tells the runtime that the implementations in the
file should override any earlier implementations.
Quite possibly, I've switched those around. :-) I'll double-check;
thanks
for noticing this.
-fobjc-exceptions
... this is not. This is just a bunch of syntactic sugar; making
language extensions and new keywords out of functionality that is
currently implemented in libraries.
Well, aside from the valid reasons Stan presented for adding exception
and
synchronization syntax, I'd like to add 2 more:
- Not all of it is syntactic sugar -- witness @finally (and hence
@synchronized, which relies on finalization), which is extremely
difficult do get right "by hand";
- The new exception syntax brings us closer to what C++ and
Javaoffers in
this regard. Although presently ObjC exceptions rely on
_setjmp/_longjmp
for binary compatibility with Foundation, in the future we may flip
the
switch and make it interoperable with C++ EH/RTTI machinery -- or
with Java
-- and just ask developers to recompile their code.
(Additionally, the documentation for @synchronize is very vague.)
I'm certainly open to suggestions as to how to improve this.
The only "known defect" of the patch is that not all of the
-fobjc-exceptions stuff
is as platform-independent as it could/should be.
Indeed. It seems that it's even hard-coding the size of libc structures
(jmp_buf), which is a bug problem for portability. (Are we even
guaranteed that the size is constant for a system and doesn't vary with
different libc:s?)
Yes, we should definitely rework this in the future, as I mentioned in
my patch.
As for the sizeof(jmpbuf) issue, I don't think we're in any more
trouble than
any vanilla C program utilizing setjmp/longjmp. :-)
--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
- PATCH: Merge objc-improvements-branch to mainline, Ziemowit Laski, 2003/09/23
- Re: PATCH: Merge objc-improvements-branch to mainline,
Ziemowit Laski <=
- Re: PATCH: Merge objc-improvements-branch to mainline, Ziemowit Laski, 2003/09/24
- Re: PATCH: Merge objc-improvements-branch to mainline, Pete French, 2003/09/24
- Re: PATCH: Merge objc-improvements-branch to mainline, Ziemowit Laski, 2003/09/24
- Re: PATCH: Merge objc-improvements-branch to mainline, Pete French, 2003/09/24
- Re: PATCH: Merge objc-improvements-branch to mainline, Ziemowit Laski, 2003/09/24
- Re: PATCH: Merge objc-improvements-branch to mainline, Alexander Malmberg, 2003/09/25
- Re: PATCH: Merge objc-improvements-branch to mainline, Ziemowit Laski, 2003/09/25
- Re: PATCH: Merge objc-improvements-branch to mainline, Alexander Malmberg, 2003/09/25
- Re: PATCH: Merge objc-improvements-branch to mainline, Ziemowit Laski, 2003/09/25
Re: PATCH: Merge objc-improvements-branch to mainline, Pete French, 2003/09/24