Professional Web Applications Themes

Objective C, Java, and Cocoa - Mac Programming

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. 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...

  1. #1

    Default Objective C, Java, and Cocoa

    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. 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

    J Guest

  2. #2

    Default Re: Objective C, Java, and Cocoa

    In article
    <tampabay.rr.com>,
    J <com> wrote:
     

    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.
     

    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.)
     

    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?
    Gregory Guest

  3. #3

    Default Re: Objective C, Java, and Cocoa

    On Mon, 9 Feb 2004 21:03:56 -0500, Gregory Weston wrote
    (in message <comcast.net>): 

    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

    J Guest

  4. #4

    Default Re: Objective C, Java, and Cocoa

    In article
    <tampabay.rr.com>,
    J <com> wrote:
     

    1) Obj-C syntax is exactly the same as C, just with a handful of
    syntactical *additions*. Nothing is changed, however.

    2) It sounds like you're upset with Cocoa mainly because it forces the
    developer to take a slightly more active role in memory management.
    Believe it or not, C requires much more from the developer than does
    Obj-C. It's also more efficient than Java because you can explicitly
    release objects that are all used up, rather than wait around for Java
    to take care of them.

    3) Perl is one of the most efficient syntaxes I've seen. It gets a lot
    done in a small space. I'm guessing you don't like it because it
    required learning?

    Stick with it, stop complaining, don't ever x-post a msg like to 5
    groups again.

    --
    |\/| /| |2 |<
    mehaase(at)sas(dot)upenn(dot)edu
    Mark Guest

  5. #5

    Default Re: Objective C, Java, and Cocoa

    On 2004.02.10 20:12, in article
    tampabay.rr.com, "J"
    <com> wrote:
     

    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

    C. Guest

  6. #6

    Default Re: Objective C, Java, and Cocoa

    In article <tampabay.rr.com>,
    J <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 p 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.).
    HiRez Guest

  7. #7

    Default Re: Objective C, Java, and Cocoa

    In article
    <tampabay.rr.com>,
    J <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.[/ref]

    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.
    Gregory Guest

  8. #8

    Default Re: Objective C, Java, and Cocoa

    In article <comcast.net>,
    Gregory Weston <com> wrote:
     

    ....and ONLY in these cirstances. 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!"
    James Guest

  9. #9

    Default Re: Objective C, Java, and Cocoa

    In article <160220040934198665%net>, James
    Spencer <net> wrote:
     

    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.?
    Chris Guest

  10. #10

    Default Re: Objective C, Java, and Cocoa

    In article <160220040934198665%net>,
    James Spencer <net> wrote: 
    >
    >...and ONLY in these cirstances. 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.[/ref]

    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 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 modi of security is a very expensive vice.
    Matthew Guest

  11. #11

    Default Re: Objective C, Java, and Cocoa

    In article <160220042049284189%net>, Chris Baum
    <net> wrote:
     
    >
    > 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.?[/ref]

    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.

    Spence

    --
    James P. Spencer
    Rochester, MN

    "Badges?? We don't need no stinkin badges!"
    James Guest

  12. #12

    Default Re: Objective C, Java, and Cocoa

    In article <160220042115433825%net>, James
    Spencer <net> wrote:
     

    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.
    Chris Guest

  13. #13

    Default Re: Objective C, Java, and Cocoa

    In article <160220042227443554%net>,
    Chris Baum <net> wrote:
     

    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.
     

    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.
    Michael Guest

  14. #14

    Default Re: Objective C, Java, and Cocoa

    Chris Baum <net> wrote:
     
    >
    > Thx for the response.
    >
    > What if you did that in a thread?[/ref]

    You're always doing it in a thread. :-)
     

    Autorelease pools can be created for any cirstance 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.
     

    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 Guest

  15. #15

    Default Re: Objective C, Java, and Cocoa

    Michael Ash <com> wrote:
     
    >
    > Every thread has its own autorelease pools. [..][/ref]

    ....if you create them. :-)
    Paul Guest

  16. #16

    Default Re: Objective C, Java, and Cocoa

    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


    "HiRez" <net> skrev i meddelandet
    news:sjc.giganews.com... [/ref]
    is [/ref]
    say 
    >
    > Just stick with it, you will learn to like it I predict. I also came from[/ref]

    without 

    the 
    things 
    get 
    have 


    Rolf Guest

  17. #17

    Default Re: Objective C, Java, and Cocoa

    >>>>> "RN" == Rolf Nilsson <nu> writes:

    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
    Charlton Guest

  18. #18

    Default Re: Objective C, Java, and Cocoa

    In article <8qPZb.83546$telia.net>,
    "Rolf Nilsson" <nu> wrote:
     

    this may be true, but its still a pretty good reason, no?

    --
    |\/| /| |2 |<
    mehaase(at)sas(dot)upenn(dot)edu
    Mark Guest

  19. #19

    Default Re: Objective C, Java, and Cocoa

    In article <8qPZb.83546$telia.net>,
    "Rolf Nilsson" <nu> wrote:
     

    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
    Uli Guest

  20. #20

    Default Re: Objective C, Java, and Cocoa

    In article <8qPZb.83546$telia.net>,
    "Rolf Nilsson" <nu> wrote:
     

    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
    driver 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 cirstances. Not all, and I won't opine
    about "most," but many.
    Gregory Guest

Page 1 of 2 12 LastLast

Similar Threads

  1. Objective C -> C
    By Bruce Coughlin in forum Mac Programming
    Replies: 6
    Last Post: September 7th, 03:26 AM
  2. java, MacOSX, and Cocoa
    By J in forum Mac Programming
    Replies: 0
    Last Post: August 2nd, 03:59 PM

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139