Objective C, Java, and Cocoa
J
developer for the last 7 years. I have to say that Objective C syntax is
almost as bad as perl. I know that I will get use it it, but I have to say
moving from java, objective C is not fun. Having to think about object
memory again is not really all that fun.
J
Gregory Weston
<0001HW.BC4D89E1...@news-server.tampabay.rr.com>,
J <webs...@fluidic.com> wrote:
> I'm a starter / newb cocoa programmer. I have been a c/c++/delphi/java
> developer for the last 7 years. I have to say that Objective C syntax is
> almost as bad as perl.
Replace "almost as bad" with "unfamiliar to you." Seriously. If you
can't get past thinking of the Smalltalkish message-send syntax as "bad"
you're in for a needlessly bumpy ride. And there's no way Objective-C is
anywhere close to the ... opacity, let's say, of Perl. It's C with a
little tiny bit of extra syntax.
> I know that I will get use it it, but I have to say
> moving from java, objective C is not fun.
That'd just be the newness again, I assure you. There's those of us that
looked at Java as something that wants to be Smalltalk when it grows up.
(Note past test. Java and I have both changed since I first looked at
it.)
> Having to think about object
> memory again is not really all that fun.
Actually, once you get into it you _really_ don't have to worry about it
that much at all. Abstractly, Cocoa doesn't include transparent GC, but
the way they got things set up it's really not something that takes a
whole lot of synapses to stay on top of.
Um. Was there a question or were you just venting?
J
(in message <gwestonREMOVE-A4C...@netnews.comcast.net>):
> Um. Was there a question or were you just venting?
Just venting. I'm still doing it. I just hope I don't have a lot of memory
leaks. We will have to see what will happen.
John
C. S. Wyatt
0001HW.BC4F15DC...@news-server.tampabay.rr.com, "J"
<webs...@fluidic.com> wrote:
> Just venting. I'm still doing it. I just hope I don't have a lot of memory
> leaks. We will have to see what will happen.
>
> John
>
Actually, I have to agree that Objective-C is not for everyone. I would love
to see any number of tools competing on OS X, as they did under OS 6-9.2, so
you could try them and see what fits your style best. It isn't that one is
better than another (except some make a lot of sense for particular jobs),
but many of us like to code in a few languages.
Pascal should still exist on the Mac (FreePascal isn't ready, and GNU Pascal
is a work in progress -- I miss Delphi, so I still use my PC a lot). The IBM
FORTRAN was a lot of fun to play with, just for kicks. I downloaded the free
beta on my G3 and G4. I think REALbasic is missing too many features (I
wanted a ComboBox, which is coming. "5.5 will fix that!" they say.) Only
three desktop databases exist (4D, Omnis, FileMaker) and they're OK, but
programming / scripting is so-so.
Objective-C is a powerful. I love IB. I just wish there were more options
from commercial vendors -- options ready for primetime. While MS rules on
Windows, there are still tools from Borland, Mars, Watcom/Sybase, and others
that are solid and interesting. Borland pushed MS to get better -- and MS
hired the Delphi creator to make C# and .Net what they are.
Learn Objective-C, hope the Mac expands market share enough to bring back
more competition and more cool toys.
- CSW
Gregory Weston
<0001HW.BC4F15DC...@news-server.tampabay.rr.com>,
J <webs...@fluidic.com> wrote:
There's a pretty simple rule of thumb to avoid memory leaks with Cocoa:
You are responsible for sending a release or autorelease message to any
object:
1) Which you got by sending an alloc... message to a class.
2) Which you got by sending a message that copies an object.
3) To which you previously sent retain.
That pretty much does it. Note that Cocoa's classes often have non-alloc
creation methods that parallel the init... methods.
- (id)initWithInteger:(int)blah;
+ (id)fooWithInteger:(int)blah;
So if you want something to hang around for a while (past the current
event loop) you're likely going to write
my_slot = [[Foo alloc] initWithInteger:x];
Later you will send [my_slot release] or [my_slot autorelease].
If you're just creating a temporary, you might expect that you'll have
to write
my_slot = [[[Foo alloc] initWithInteger:x] autorelease];
You can, but you could also write
my_slot = [Foo fooWithInteger:x];
and you never have to worry about releasing my_slot unless you go out of
your way to send it a retain before you're done with it. The existence
of those convenience allocators is why I noted that memory management
under Cocoa is less intrusive than it might seem at first glance.
James Spencer
Gregory Weston <gwesto...@CAPSattbi.com> wrote:
> You are responsible for sending a release or autorelease message to any
> object:
> 1) Which you got by sending an alloc... message to a class.
> 2) Which you got by sending a message that copies an object.
> 3) To which you previously sent retain.
...and ONLY in these circumstances. The solution for newbies is that
if you do one of these three things, then immediately write a release
or autorelease statement somewhere. If you don't, you will leak. If
you haven't done one of these things and you release an object, the
program will probably crash. That's ALL you absolutely have to know to
make memory management work.
Just to note a programmer obligation that follows from these rules and
which I missed at first is that if you return an object to a caller in
one of your own methods, you should return it autoreleased as the
caller is entitled to assume they will be receiving an autoreleased
object. The caller can retain it if they want Thus:
- (id)createAnInstanceOfMyObject
{
MyObjectClass *newObject = [[MyObjectClass alloc] init];
[newObject autorelease]; // Note: this complies with with #1 rule
return newObject;
}
What follows from this is that your get accessor methods need to return
autoreleased objects too. If its your own code, you can of course do
whatever you want but if you are religious in making any "return"ed
object autoreleased no matter where it comes from, it makes these rules
awfully easy to comply with.
Spence
--
James P. Spencer
Rochester, MN
"Badges?? We don't need no stinkin badges!"
Chris Baum
Spencer <jspencer...@charter.net> wrote:
> The solution for newbies is that
> if you do one of these three things, then immediately write a release
> or autorelease statement somewhere. If you don't, you will leak.
How do you avoid the leak in the event of a thrown exception? C++
allows you to write stack-based resource de-allocators like
boost::scoped_ptr. What's the Obj-C/Cocoa equiv.?
Matthew Russotto
James Spencer <jspencer...@charter.net> wrote:
>Gregory Weston <gwesto...@CAPSattbi.com> wrote:
>
>> You are responsible for sending a release or autorelease message to any
>> object:
>> 1) Which you got by sending an alloc... message to a class.
>> 2) Which you got by sending a message that copies an object.
>> 3) To which you previously sent retain.
>
>...and ONLY in these circumstances. The solution for newbies is that
>if you do one of these three things, then immediately write a release
>or autorelease statement somewhere. If you don't, you will leak. If
>you haven't done one of these things and you release an object, the
>program will probably crash. That's ALL you absolutely have to know to
>make memory management work.
Not quite: tree and list structures still present problems. IIRC,
Cocoa always has the parent retain the child and not vice-versa.
--
Matthew T. Russotto mrus...@speakeasy.net
"Extremism in defense of liberty is no vice, and moderation in pursuit
of justice is no virtue." But extreme restriction of liberty in pursuit of
a modicum of security is a very expensive vice.
James Spencer
<cbau...@atlantic.net> wrote:
There is no direct equivalent but autoreleased objects can be used
pretty safely within any particular method so when I create an object
in a method that is going to do something that might throw an
exception, I autorelease the object before I do the thing that might
throw the exception:
- (id)myMethod
{
MyClass * myObject = [[[MyClass alloc] init] autorelease];
...// do something that might throw an exception
return myObject; // it's already autoreleased
}
I also retain in my set accessors and if, in the above, I needed to
assign myObject to some instance variable, I would, even if myMethod is
in the same class as the instance variable, call the set accessor AFTER
doing whatever might throw an exception.
It's not as clean as C++'s exceptions but it is pretty rare for it to
be a problem.
Chris Baum
Spencer <jspencer...@charter.net> wrote:
> I autorelease the object before I do the thing that might
> throw the exception:
>
> - (id)myMethod
> {
> MyClass * myObject = [[[MyClass alloc] init] autorelease];
>
> ...// do something that might throw an exception
>
> return myObject; // it's already autoreleased
> }
Thx for the response.
What if you did that in a thread? Is it possible the main thread would
autorelease myObject before completing this method? Sorry for newbie
questions, I'm C++ and considering Cocoa.
Another question related to exception safety: I have thin stack-base
classes to open/close files, open/close network connections, etc. I
see how autorelease might help me with resource allocations, but what
do you do in Cocoa to ensure other open/close type paired operations
are exception safe?
Thx.
Michael Ash
Chris Baum <cbau...@atlantic.net> wrote:
> What if you did that in a thread? Is it possible the main thread would
> autorelease myObject before completing this method? Sorry for newbie
> questions, I'm C++ and considering Cocoa.
Every thread has its own autorelease pools. The only time you need to
worry about cross-contamination like this is if you actually
autoreleased the object in another thread. If you autorelease an object
in thread A and use it in thread A, the autorelease will happen when you
go back to thread A's runloop.
> Another question related to exception safety: I have thin stack-base
> classes to open/close files, open/close network connections, etc. I
> see how autorelease might help me with resource allocations, but what
> do you do in Cocoa to ensure other open/close type paired operations
> are exception safe?
If you're using 10.3, you can use the new ObjC exception syntax which
includes a @finally clause. This can be useful for both releasing
objects and freeing other resources:
@try {
open file descriptor
obj = [[Class alloc] init];
... stuff that can throw exceptions
} @finally {
close file descriptor
[obj release];
}
I find that most of my code almost never explicitly copies or allocs
objects anyway, it's almost all autoreleased objects. In that case,
there is nothing to worry about in terms of exceptions.
You could also make a wrapper class around these resources that releases
them upon dealloc. But in that case the resource won't get released
until you get back to the main event loop (if the object was
autoreleased), which could lead to problems. Cocoa is more like Java in
this way, in that it's better to have explicit resource releases than to
have it be implicit in the object's deallocation.
Paul Mitchum
> In article <160220042115433825%jspencer...@charter.net>, James
> Spencer <jspencer...@charter.net> wrote:
>
> > I autorelease the object before I do the thing that might
> > throw the exception:
> >
> > - (id)myMethod
> > {
> > MyClass * myObject = [[[MyClass alloc] init] autorelease];
> >
> > ...// do something that might throw an exception
> >
> > return myObject; // it's already autoreleased
> > }
>
> Thx for the response.
>
> What if you did that in a thread?
You're always doing it in a thread. :-)
> Is it possible the main thread would autorelease myObject before
> completing this method? Sorry for newbie questions, I'm C++ and
> considering Cocoa.
Autorelease pools can be created for any circumstance you think they'll
fit into. Cocoa is smart enough to put an autoreleased object in the
most recently-created pool per-thread.
Unless you want to run into the problem you cite, you should create your
own pool on the new thread, and then release it before the method ends.
So if you expect to run the the method above as a thread, you'd
alloc/init a pool at the top of the code, and release the pool at the
bottom.
<http://www.cocoadev.com/index.pl?AutoreleasePool> and
<http://www.cocoadev.com/index.pl?NSThread> talk about this, and have
sample code.
> Another question related to exception safety: I have thin stack-base
> classes to open/close files, open/close network connections, etc. I
> see how autorelease might help me with resource allocations, but what
> do you do in Cocoa to ensure other open/close type paired operations
> are exception safe?
You should look at <http://www.cocoadev.com/index.pl?AutoreleasePool>,
mentioned above. You can control the way objects are autoreleased by
creating a new pool before creating the objects, and then releasing the
pool on your own terms. This might fit your needs, or it might not.
Paul Mitchum
> In article <160220042227443554%cbau...@atlantic.net>, Chris Baum
> <cbau...@atlantic.net> wrote:
>
> > What if you did that in a thread? Is it possible the main thread would
> > autorelease myObject before completing this method? Sorry for newbie
> > questions, I'm C++ and considering Cocoa.
>
> Every thread has its own autorelease pools. [..]
...if you create them. :-)
Rolf Nilsson
C++ is the only language that is used on any/every platform
and it's a great language
the only reason to learn/use Objective-C is to be able to work with Coccccoa
on Mac OS X, else Objective-C is dead
my two cents
R
"HiRez" <hi...@render.net> skrev i meddelandet
news:hirez-37DDCF....@news-50.sjc.giganews.com...
> In article <0001HW.BC4D89E1...@news-server.tampabay.rr.com>,
> J <webs...@fluidic.com> wrote:
>
> Just stick with it, you will learn to like it I predict. I also came from
a
> mostly-Java background and I hated the Objective-C syntax when I first
> started with it. It's more your eyes and brain learning to parse it
without
> stumbling on the brackets than anything. It's a rather verbose language,
> what with having to type the parameter names in your messages but that has
> great benefits. In Java, I remember many many times being confronted with
a
> long list of comma-sparated parameters in a function call within my own
> code, and having to go look up the function definition because I forgot
the
> parameters.
>
> The memory management also takes time but it really isn't that hard. The
> benefit of it is you get a deeper understanding of what's going on, and
> you'll find yourself writing more efficient and controlled code because of
> it.
>
> My only real complaint with Cocoa is that not enough of the APIs are
> "Cocoaized" (rewritten or wrapped in Objective-C) yet. For many many
things
> you still have to dig into the ugly Carbon APIs, which kind of defeats the
> elegance factor of using Objective-C in the first place. Then things can
get
> very confusing because you start mixing the different data types (which
have
> varying levels of compatability) and mixing memory management (using
> retain/release/autorelease together with malloc/free/etc.).
Charlton Wilbur
RN> why care about Objective-C when there is C++?
Because Objective-C has a simpler, more elegant design than C++, and
because there are things that C++ gets badly wrong that Objective-C
gets right. If nothing else, you could care about Objective-C to
learn about new ideas that can be used to improve C++.
RN> C++ is the only
RN> language that is used on any/every platform
The users of Java, LISP, and C would take issue with that.
RN> and it's a great language
C++ a mediocre language, made worse by scattershot creeping featuritis
and a paranoid-obsessive avoidance of deferring any typing decisions
to runtime. It happens to be widely used, but that's not a sign of
greatness, only the herd mentality.
Charlton
--
cwilbur at chromatico dot net
cwilbur at mac dot com
Uli Kusterer
"Rolf Nilsson" <nos...@nomail.nu> wrote:
> why care about Objective-C when there is C++?
>
> C++ is the only language that is used on any/every platform
>
> and it's a great language
>
> the only reason to learn/use Objective-C is to be able to work with Coccccoa
> on Mac OS X, else Objective-C is dead
>
> my two cents
>
> R
shhh.... do not feed the trolls ... The number of crossposts alone
should tip you off to that.
follow-up set to csmp.help
--
Cheers,
-- M. Uli Kusterer
http://www.zathras.de
Gregory Weston
> why care about Objective-C when there is C++?
>
> C++ is the only language that is used on any/every platform
>
> and it's a great language
>
> the only reason to learn/use Objective-C is to be able to work with Coccccoa
> on Mac OS X, else Objective-C is dead
Well, every assertion you made is either wrong or subjective, so let's
just ignore them and concentrate on the question right up top.
Programming languages are tools. Tools are created to aid in the
completion of certain tasks. The reason people create _new_ tools is
that they have a task and cannot find an existing tool which they find
suitable for that need. So the reason to "care about tool_A when there
is tool_B" is that you have a task before you for which tool_A is the
more appropriate. The tool which will allow you to achieve your goal
more effectively and/or more efficiently. You can drive a nail with a
screwdriver if you hold it backwards, but given the existence of the
hammer, would you?
Objective-C, which is realistically usable anywhere you have a C
compiler, can beat the crap out of C++ in terms of programmer efficiency
and effectiveness in many circumstances. Not all, and I won't opine
about "most," but many.