Re: Strong language about Cocoa and Qt.
Re: Strong language about Cocoa and Qt.
- Subject: Re: Strong language about Cocoa and Qt.
- From: Rich Warren <email@hidden>
- Date: Wed, 02 Jul 2003 00:58:19 +0900
On 7/1/03 10:29 PM, "publiclook" <email@hidden> wrote:
>
When I started this post, I was hoping for a discussion of the relative
>
development styles and advantages for Qt vs. Cocoa given that some
>
people seemed willing to use exotic pre-processors, forego an IDE
>
completely, and program in C++ in PREFERENCE to using Cocoa even on the
>
Mac. I am trying to understand what it is about Cocoa that makes it
>
less approachable (for some) than Qt. In my limited experience with
>
Qt, it seems very unapproachable to me.
I can try to address that. I just recently started programming in Objective
C, while I've been using C++ (and particularly QT) for quite a while.
Coming from programming Windows, QT seemed to be a streamlined and elegant
system. In some ways it is similar to Cocoa. Cocoa's notifications remind me
of QTs slots and sockets (which is one of the best features of QT).
Before I go any farther, let me say that I really do love Cocoa. You get a
lot of power at your fingertips. I'm sure there are some inventive ways to
use Objective C's features that I haven't even thought of yet--and I wish
there were more books (particularly intermediate to advanced books) on
Objective C and Cocoa (though it sounds like some have recently come out or
will come out soon).
However, learning to use Cocoa has not been entirely painless. I'm sure that
some of the problems I ran into would stop others completely. So take the
following in the spirit it is intended. It's not meant to be an attack on
Cocoa or Objective C.
Here are some of the areas that have either given me headaches or otherwise
caused me to lose sleep:
Memory Management:
This was a big one for me. It took a long time before I felt that I really
understood what I was doing. And I still feel like I have to write a ton of
boilerplate whenever I add a member variable to a class. It would be nice if
Project Builder could automate this.
While most books and articles make it seem like a simple topic, it actually
can get quite complex. You need to make sure you don't create circular
references. You don't typically need to retain and release UI controls when
you access them... Etc. etc.
In my first Objective C application, I thought I had everything set up
right, but when I checked it, I was leaking a lot of memory. Left out a
vital "release" command, and only half my objects deallocated themselves.
QT claims that it has a built-in memory management system. That, like Java,
you can just create objects without worrying about destroying them. Unlike
Java, you can request that an object is destroyed for efficiency purposes.
Now, I must admit. I haven't done any QT programming in about a year. I know
a lot more about memory management gotchas now than I did back then. So I
never examined QTs memory management with the same scrutiny that I've looked
at Cocoas.
In particular, it uses smart pointers and reference counting (I believe). In
particular I don't know how it avoids circular references. A problem I'd
never really considered until after I'd read something about cocoa memory
management.
Still, I wish I didn't have to retype the same boilerplate again and again.
It's slow and error prone.
Private Methods/Variables:
I assume (though I haven't really tried) that you can hide a method (by
putting it in a category instead of in the header file), but you can't
prevent people from calling it.
Similarly you can declare a variable as private, but others can still write
code that slips around that.
The inability to really lock down my private functions and data, and keep it
away from prying and probing fingers makes me uneasy. It probably shouldn't.
After all, I'm writing applications, not libraries. But the c++/java habits
of locking down the classes is heard to break.
Strongly Typed vs. Dynamic:
Again, this is probably because of the way I've been trained, but using a
dynamic language always makes me a little uneasy. Now I know there are
legitimate arguments about why strongly typed languages do not necessarily
produce better code--but I just can't shake the feeling that changing an
error from a runtime error (which could be hard to track down) to a
compile-time error is a good thing. Yeah, it might not guarantee there are
no errors. But it can save your bacon from time to time.
Similarly, I prefer the newer C++ typecasting to the older, simpler C
typecasting. Yes it's more typing, but I have caught errors that otherwise
would have driven me crazy trying to root out.
While writing my first Cocoa application, I tried to avoid id wherever
possible. But, there comes a point where you just have to take the plunge
and assume that the data you're working with will behave the way you expect
it to.
Similarly, while I think it's cool and potentially very useful that (as I
understand it) in Objective C you can send any message to any object. If the
object doesn't have a matching method, it just ignores the message.
On the other hand, having code that crashes and burns when you send an
object the wrong message does make debugging a little simpler. It's more
obvious when you make a mistake (again, I like the fail-fast theory of
design). Being anal about compiler warnings and carefully reading the log as
you test the program can help ferret these out. But I didn't realize that
when I first started programming Cocoa.
I vividly remember compiling my application. Yeah, I got a few warnings, but
it compiled fine and seemed to run. Only later did I discover that some
things weren't working properly. I cleaned and recompiled to regenerate
those warnings that I'd skimmed over the first time through, and found my
mistake. In C++ the compiler would not have compiled the program until I
fixed the typos.
Documentation:
Apples documentation doesn't include a search feature. Until someone on this
list suggested some third-party applications--this was a screaming
nightmare.
In general I found QT's documentation very thorough and easy to use.
Again, in general I really like Objective C. If I could just get project
builder to generate more of the boilerplate for me (I love the way both
kdevelop and vc++ allow me to right-click on a class icon and select "add
new function". I fill out a form, press OK, and BAM it drops in my
declaration in my header file and a stub in my implementation file.) If I
could make private methods and variables truly private. And if I remember to
turn on the "treat warnings as errors" option when building, then I would be
truly happy.
-Rich-
_______________________________________________
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.