faq
flatforty
contribute
subscribe
configure
search
rdf
main
parent
thread
|
Re: Native code FUD
by Richard Dale on Sunday 08/Aug/2004, @21:33
|
"Just imagine a C++ programming style where all functions and inheritances are virtual, all classes inherit from a common base class that does central object registration, all objects are always allocated on the heap and every single pointer or array access is checked beforehand"
Well I've used Objective-C/OpenStep (ie Apple Cocoa) a lot. It was easily fast enough 10 years ago, and it certainly is now. In Objective-C every method is effectively virtual, including the equivalent of 'static' methods. All classes inherit from NSObject, and the NSArray class doesn't allow you to drop off the end and crash. All Objective-C instances are allocated on the heap.
"If you then create an API that encourages the creation of massive amounts of small objects that call into each other through listener interfaces, and requires dynamically checked type casts to narrow objects, then you would not end up with the speed we see with Qt and KDE today"
This is where Objective-C diverges from the java approach. In Cocoa there are many fewer instances required to do something, and the inheritance heirachies are flatter. You can use delegation or categories (ie dynamically adding/changing methods to running instances) where you would need to subclass in java. Listener interfaces are a design disaster as they ignore the dynamic reflection possibilities in java. Qt takes a static language and makes it more dynamic via the moc and signals/slots, while Swing java takes a dynamic language and implements a clunky api based entirely on static typing.
I'm fussy and I don't like a lot of software, but I really think Qt/KDE is the best application framework since NeXTStep (especially with the KDE 3.3 ruby bindings). |
|
|
The Fine Print: The following comments
are owned by whomever posted them.
( Reply )
|
Re: Native code FUD
by Tim Jansen on Monday 09/Aug/2004, @00:38
|
"All Objective-C instances are allocated on the heap."
BTW this is not strictly necessary in Objective-C, and neither in Java or C#. They could use stack-allocation for many short-lived objects. It would require more/better analysis of the code though, to determine for which objects it is possible.
(Similarly all the other performance problems listed by Matthias can be solved by more intelligent compilers - we're just not there yet)
|
[
Reply To This | View ]
|
Re: Native code FUD
by Richard Dale on Monday 09/Aug/2004, @00:50
|
"BTW this is not strictly necessary in Objective-C,"
It isn't possible in Objective-C - you create an instance by messaging a class object, and then sending an initialization message to the new instance. Only string literals of the form @"mystring" can be statically allocated
Instances are allocated in 'autorelease pools'. You can create you're own autorelease pools, and you would do that if you have a lot of short lived objects.
C# already allows to allocate short lived objects on the stack.
|
[
Reply To This | View ]
|
Re: Native code FUD
by Rayiner Hashem on Monday 09/Aug/2004, @08:09
|
Lot's of compilers are already at that point. Stalin, CMUCL, d2c, Bigoo, etc, all do these sorts of optimizations. It's just something that hasn't come to C# and Java compilers yet (and will never come to C/C++ compilers, because of their semantics).
|
[
Reply To This | View ]
|
|
The Fine Print: The previous
comments are owned by whomever posted them.
( Reply )
|
|
![[KDE Dot News]](http://www.kde.org/dot/Images/kdedotnews.gif)
