macOS Why *pointer = &foo and not pointer=&foo?

[zippyfly]

OK thanks yet again. I can sense the frustration from some of you, and apologize for that. It's also the main reason why I've not really pursued this train of thought for so long, but just decided to keep at it this time despite annoying people.

And it has been worth it because there were a number of key aspects you guys just highlighted, which pretty much escaped me in my infinite loop of questioning why it is done the way it is (since I was oblivious to the "goings on" in the background).

So, I guess I can probably say, "I get it now!" Thanks to all of you.

The key things that I didn't really know before (and kept hammering on the syntax of the * operator usage being inconsistent) are:

"One of the main difficulties stems from the fact that they gave the * symbol multiple meanings."

and

"...it's not printing whatever is at that address directly. Instead it's handing the address of the object off to the Objective-C runtime in order to extract out the printable information."

and

"It's also much cheaper to pass around small pointers than large objects."

(same as "it's much more efficient to pass the address of a large object to a function.")

These things might obvious to you old hands but I didn't know this. I didn't, for example, realize that it's done this way to gain higher efficiency, or that the method doesn't actually handle the task directly and keeps passing it on to lower level routines (which is why the passing by reference is involved, so as to optimize this process).

I guess I'm the type of person that needs these explanations about something before I will be happy to move onto to the next thing.

Once again, thanks. I am currently having a lot of fun building GUI apps, following along in Cocoa® Programming for Mac® OS X, Third Edition (Aaron H.).

Cheers!

 

[imaxx]

This is wrong.

hehe my fault, i did remove a whole lengthy chunk of my post explaining the difference between 32 and 64 bit pointers.
No offence, after all you just implicitly affirmed that a skilled reverse code engineer doesnt know such difference

 

[Cromulent]

Ultimately, pointers and memory management is quite a complex area. Using direct addresses in modern computers is often meaningless as the hardware enables the use of segmented memory. This basically means that each application has its own address space. This has an impact on the use of direct memory access as the same memory address used in two different applications actually points to completely different areas of memory depending on the underlying architecture.

Also in modern operating systems programs are restricted to the memory that they themselves have been allocated and can not access memory outside of their memory space (with the exception of shared memory - but this must be explicitly allocated by the process).

As you can probably tell there is far more under the surface than you can actually see when using C which is why C is still considered a high level programming language. You do not need to get involved in such areas and can just make assumptions based on the C standard and let the implementer and operating system developer work out this kind of thing for you.

Hopefully that is somewhat helpful.

 

[Cinder6]

This is why I think a lot of schools are crazy backwards in the order they teach languages. At mine, it went Java -> Assembly -> C, which just seemed...odd. I bet people would have gotten much better grades (my assembly class's average grade was a 60, I think) had the progression been C -> Assembly -> Java.

 

[zippyfly]

I would agree although I'd reckon doing very simple Assembler first might give a good idea of how things work at the CPU level, then going up to either C or Java. Although Java (which I learned some 10 years ago, also by reading books) does not have pointers! ;-)

Anyway eventually I will dabble into modern Assembler to understand how things really translate into object code but will stick with Obj-C so long as OS X continues kicking ass in the real world ;-)