Can I get a small explanation about this bit of code?

You are confusing instances with variable names. holdings is not an instance. It points to an instance. A pre-existing instance. Not a new one. Each iteration through the loop the pointer is updated to point at the next instance from the collection stocks.

 

What you have there is called Fast Enumeration. It's a way of iterating through an array really fast. You are not creating a new instance of StockHolding you are merely accessing an existing instance from the array.

You can have a peek here under fast enumeration https://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/ProgrammingWithObjectiveC/FoundationTypesandCollections/FoundationTypesandCollections.html

Code:

for (NSString *myString in allMyStrings) {
    NSLog(@"String: %@", myString);
}

for (int i = 0; i < allMyStrings.count; i++) {
    NSString *myString = [allMyStrings objectAtIndex:i];
    NSLog(@"String: %@", myString);
}

These two loops provide the same functionality but the former one is much faster. If you look at the second loop, you are just accessing the object, not creating a new instance.

 

Can you prove the former is faster? I honestly believe it won't be faster. My understanding is the name is related to it being faster to type rather then faster to execute.

 

Let's not take my word for it.

Code:

	NSMutableArray *myArray = [[NSMutableArray alloc] init];
	for (int i = 0; i < 10000000; i++) {
		[myArray addObject:[NSString stringWithFormat:@"String %i", i]];
	}
	
	NSDate *t0 = [NSDate date];
	NSMutableArray *forArray = [[NSMutableArray alloc] init];
	for (int i = 0; i < myArray.count; i++) {
		
		NSString *myString = [myArray objectAtIndex:i];
		[forArray addObject:[myString copy]];
	}
	NSDate *t1 = [NSDate date];
	

	NSDate *t2 = [NSDate date];
	NSMutableArray *enumArray = [[NSMutableArray alloc] init];
	for (NSString *myString in myArray) {
		
		[enumArray addObject:[myString copy]];
	}
	NSDate *t3 = [NSDate date];
	
	
	NSLog(@"\nFor loop: %f\nEnum loop: %f", [t1 timeIntervalSinceDate:t0], [t3 timeIntervalSinceDate:t2]);

Code:

For loop: 2.092580
Enum loop: 1.366328

That's pretty significant I recon.

 

Cool: I know in Java tests have shown that using the Iterator is slower than a straight for loop. I would be interested in seeing the results if you saved the count into a variable instead of checking it every iteration of the for loop...

 

Modified the code slightly to read the count of the array into an int before setting the t0 time stamp and then using the int instead of querying the array.count.

Code:

For loop: 1.946401
Enum loop: 1.407935

It did improve the result. Considering as well the fast enumeration loop was slightly slower this time the for loop can be considered improved a good bit.

 

stocks contains a number of instances of StockHolding. Instances don't have names: it makes no sense to ask if an instance is "stockholding" or any other name. Instances do, however, have memory addresses.

If we step aware from Objective-C for a bit and pretend that stocks is a plain old array (not a NSArray which I assume it is). An array is a contiguous block of memory starting at an address like this:

Code:

Memory:   0000 0001 .... 0100
Contents: [       ] [       ]  [       ]

If this is an integer array then the contents could be numbers:

Code:

Memory:   0000 0001 .... 0100
Contents: [   1] [  5]      [-10]

So far, so simple. But what if our array contains pointers:

Code:

Memory:   0000   0001    .... 0100
Contents: [1001] [1100]      [1111]

So now the first element of our array does not contain a value: it contains a pointer to a value. This is the situation we have in this example. An instance of any class is simply a structure in memory. This structure is, in reality, quite complicated but we can simplify it to something like this:

Code:

Offset Item
0        isa
1        1st instance variable
2        2nd instance variable
....

where isa is a pointer to the class and the rest are the instance variables. These will either be the raw value in the case of primative types or a pointer to another object in the case of object types.

When we create the array stocks what is actually happening is something like this:

Code:

Stocks: [00100000, 00100010, 00100111]
0010000: isa pointer -> StockHolding class
0010001: 100
0010010: isa pointer -> StockHolding class
0010011: 400
0010100: isa pointer -> StockHolding class
0010101: -200

So we have an array which contains 3 pointers. These pointers point to 3 instances of StockHolding (3 memory addresses). Each of these objects has a single instance variable, the amount of the holding for this instance (100, 400 and -200). As we loop over the array holdings points first to 0010000 then the second time 0010010 and the third time 0010100. So it points to the existing instances, not new ones. When we as for the holding amount we get the amount from the instance we are pointing at: instance variables are at an instance level, not the class level:

Code:

StockHolding a = [[StockHolding alloc] init];
[a setSharePrice:100];
StockHolding b = a; // so now b and a point to the same instance
[b setSharePrice:200];
NSLog(@"%i",[a getSharePrice]);

200 will be printed as both a and b point to the same instance: they point to the same object in memory.

 

This is probably a good idea. Sometimes stepping away and coming back makes everything just snap into place. The one thing I would suggest is learning plain old C. Pointers, memory etc are all based on that and a good understanding of that could help here.

 

Definitely.

The take-away is this:

Any variable with a "*" in it's declaration is a pointer variable. It's a memory address that points to something else.

Example:

Code:

MyObject *anObject;
anObject = [[MyObject alloc] init];

anObject is a pointer variable that points to an object of type MyObject.

Note the asterisk in the declaration.


After the first declaration line, the pointer anObject may point to garbage memory, or to nil, depending on how your compiler is set up.

The RIGHT PART of the second line creates a new MyObject, initializes it, and returns it. The "=" operator then saves the result into the local POINTER variable anObject.

After that second line, the local variable anObject contains the address of a MyObject object.

In practice, everybody says "anObject contains the newly created object" because it's easier to say, but it's not really correct.


That is different than this line:

Code:

int anInt;

Note that there is no asterisk in the declaration of anInt.

Ih that code, the variable anInt actually holds an integer value, not a pointer. The compiler defines anInt as a block of memory that can hold an integer.

 

That is, essentially, the C book. The OG if you like.

 

You just have to say K&R - that's it. I recon most of us have a copy within reach.

 

It is the book written by the guys who designed an implemented C. As such it has everything. The book recommended when I was at Uni was "A Book on C" by Kelly and Pohl. It was good enough to learn from

 

I've read both the K&R book and the "A book on C" book by Kelly and Pohl. The K&R book is better written.

K&R is very clear and well written. It requires work from you in order to learn from it. If you read the entire teaching section of the book and do all the exercises, you will have a good working knowledge of C (including pointers) when you are done.

 

If you were reading the Big Nerd Ranch Objective C book I would say you could just read that book, as the first several chapters teach you a crash course in C.

I'm not as familiar with the other book even though I own it. (I teach classes on this stuff sometimes so I have quite a few books at different levels.)

I would not suggest reading a chapter of K&R, then a chapter of Objective C, then another chapter of K&R. That's going to leave you very confused.

If you're going to study C, read the entire K&R teaching section and do all the exercises, including creating linked lists, etc. If you do that, you will have not only a solid grounding in C, but a solid grounding in computer science. If I remember correctly, it goes through exercises in Linked Lists, binary trees, stacks, etc. Great fundamentals that many people starting out never get.

Expect it to hurt your head more than a little. Remember that by reading all of K&R you're covering a lot of the fundamentals of computer science, written by the guys who created UNIX and C.