Re: Future Objective-C changes
Re: Future Objective-C changes
- Subject: Re: Future Objective-C changes
- From: Chris Meyer <email@hidden>
- Date: Tue, 20 May 2003 21:39:21 -0700
In my last job we went from:
- C
- C++
- C++ w/ exceptions
- C++ w/ exceptions & templates
During the "C++ without exceptions" phase (circa 1991) we had our own
homegrown exception mechanism that was similar, but slightly more
powerful, than Objective-C exceptions. The mechanism we used was close
to the one proposed in a 'd e v e l o p' magazine for those who
remember that. I think they're still available somewhere on the Apple
web site.
Now I've switched to Objective-C and from my experience it is clear
that the largest missing part of Objective-C is the lack of an
intrinsic exception mechanism. The exception mechanism must guarantee
that C++ destructors will be called.
For instance, using C++ I could define a class
class MyGraphicsContextSaver
{
MyGraphicsContextSaver( NSGraphicsContext *gc ) { [gc
saveGraphicsContext]; }
~MyGraphicsContextSaver() { [gc restoreGraphicsContext]; }
}
Then in my Objective-C++ method I could write:
- (void)drawMyObject
{
MyGraphicsContextSaver gcs;
DoSomeStuffWhichMightThrowExceptions();
}
No matter what the function did (including throwing exceptions) the
stack would be guaranteed to be unwound (i.e. the destructor for
MyGraphicsContextSaver would be invoked). I miss this functionality.
Similarly the use of smart pointers (see the Effective C++ books)
eliminates memory leaks.
The problem in Objective-C is that since the exception mechanism is
glommed onto the language, it can bypass destructors (in Objective-C++,
that is). As someone else pointed out, Objective-C exceptions and C++
exceptions don't play well together. If the
DoSomeStuffWhichMightThrowExceptions() above were to throw an exception
using the Objective-C macros, it would bypass the destructor for
MyGraphicsContextSaver. ugh!
If Objective-C++ is the future, then integrating the exceptions
mechanisms is essential.
If Objective-C is the way to go, then an extension to move towards the
functionality of smart pointers would be nice. It might solve issues
with reference counting (which aren't difficult once you master them,
but definitely error prone), issues with dealloc (I often forget to
invoke [super dealloc]), and other assorted memory leak problems.
Imagine that you could write code like the following:
- (void)myThread
{
smart_pointer<NSAutoreleasePool> pool = [[NSAutoreleasePool alloc]
init];
my_thread_code();
}
And [pool release] would guarantee to be called no matter what
exceptions were thrown in my_thread_code()!
I'm not proposing the syntax above, but the functionality. The syntax
is just based on C++ smart_pointer<> template.
Food for thought...
Chris Meyer
On Thursday, May 15, 2003, at 09:04 PM, David Cittadini wrote:
Is there anywhere to monitor or suggest changes to the Objective-C
language? For example, I am interested to know if one day Objective-C
classes will support:
a) Namespaces/packages.
b) Generics/parameterized types.
c) Abstract classes, or at least some way to enforce that a class
cannot be instantiated directly.
d) Method overloading.
I know that Objective-C++ provides this support but only if you are
using C++ classes. I am interested if the above will be supported in
"native" Objective-C classes. I know that people will have lots of
for-and-against arguments for the above but being a simple programmer
some of the above would be very useful.
Thanks, David.
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.