• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Objective-C vs. Java
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Objective-C vs. Java


  • Subject: Objective-C vs. Java
  • From: Ondra Cada <email@hidden>
  • Date: Fri, 27 Jul 2001 22:02:39 +0200

[automatic, ie. stack-based, objects]
>Yep. It' very handy, especially with small utility classes that with the
>constructor saves state, does a thing, and the destructor at the end
>triggers that the state is restored. Good with graphics programming, for
>example.

True, but you would pay too dearly for that (having another type of objects,
principially unretainable: you would not be able to use that objects as
arguments to other methods /if you would, and the method would retain the
object--since the other method would not know its stack-based!--all hell
would break loose, etc.).

OTOH, there already is a *SLIGHLY* less effective, but *INCOMPARABLY* more
flexible, efficient, and robust, solution:

{
NSAutoreleasePool *pool=[[NSAutoreleasePool alloc] init];
// anything you create here (presumed nobody retains it!)...
...
[pool release]; // gots _released_ here!
}

> Also, small objects that are constantly created/deleted makes the heap
> fragmented, even with a VM system it's an issue.

It's not. Believe me, I program in both Cocoa (read it OpenStep) and C++ for
_many_ years.
---
Ondra Cada
OCSoftware: email@hidden http://www.ocs.cz
private email@hidden http://www.ocs.cz/oc


  • Prev by Date: Re: Runtime class info in ObjC/Cocoa
  • Next by Date: Simple IB Question...
  • Previous by thread: Re: Objective-C vs. Java
  • Next by thread: Color/Number List
  • Index(es):
    • Date
    • Thread