• 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
Re: Programming style (was Accessors) revisited ; de-compiler ???
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Programming style (was Accessors) revisited ; de-compiler ???


  • Subject: Re: Programming style (was Accessors) revisited ; de-compiler ???
  • From: Victor Ng <email@hidden>
  • Date: Thu, 15 Aug 2002 21:14:50 -0400

I'm a newbie to Cocoa and Objective-C, but I know this problem from the Java
world.

Not sure about Cocoa, but on Java if you're doing pointer comparisons you
might get inconsistent results on multiprocessor machines (or just plain
multithreaded enviroments) because different threads of control may cache
local copies of objects for performance improvements.

The reason it will depend on your processor is that those kinds of
optimizations fall into the realm of how the computer's memory model is
defined. In Java, the memory model is defined enough so that you know that
these kinds of operations will work only under very specific conditions (you
explictly code a memory sync around your contentious code).

In other languages like C (and presumably Obj-C), you get the memory model
of the underlying CPU.

You can find Java related information on that kind of problem on bill pugh's
website: http://www.cs.umd.edu/~pugh/java/memoryModel/.

Hope that helps,
Vic


On 2002/08/14 9:10 PM, "Raff" <email@hidden> wrote:

> Sorry to come back about this topic, but I was on holliday;
>
> about the positive/negative test
> if (newObject == object) return;
> or
> if (newObject != object) {
> doIt !
> }
>
> I read it depended on the type of processors.
>
> I thought it would depend on the compilator : as far as I'm concerned, I
> would think the first method is faster because the code produced would
> be a test which leads to 'blr'.
>
> How can it be different on a different machine if I do use the same
> compiler ? (sorry if this is a silly question)
>
> ***
>
> By the way, is there a program to de-compile code in the developper
> utilities ? I didn't find it.
> (machine code > PPC/68k assembly language).
>
> Thanks for your attention.
>
> R.D.
> _______________________________________________
> 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.

--
Victor Ng
email: email@hidden
http://radio.weblogs.com/0108956/
_______________________________________________
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.

References: 
 >Programming style (was Accessors) revisited ; de-compiler ??? (From: Raff <email@hidden>)

  • Prev by Date: NSPopUpButton addItemsWithTitles is way slow
  • Next by Date: Re: Getting classes from bundles in an array
  • Previous by thread: Programming style (was Accessors) revisited ; de-compiler ???
  • Next by thread: NSView to CGL
  • Index(es):
    • Date
    • Thread