iOS What is the point of a structure?

1, to make it much easier to port apps from e.g. C. Socket programming, for example, makes HEAVY use of structs.

2, structure instances are much more lightweight than true class instances - there is absolutely no overhead in memory when using them, unlike with true objects.

3, they work exactly the same way as classes BUT can't incorporate methods, just data fields and have no fine-grained protection / visibility constraints / inheritance either.

(Actually, when it comes to the first and third in this list,

1, classes are generalizations of structs with additional methods inside. This is how, BTW, I teach the basics of OOP - starting with structs, explaining that classes are generally (physically) no more than structs with additional executable code in them etc.

2, how inheritance works physically (how the struct instances look like on the stack / in the heap) and the lack of restrictive inheritance resulting in type compatibility you can always depend on in both Java and Objective-C (as opposed to C++, where it's not guaranteed as C++ does support restrictive inheritance) can be very nicely shown by using structs. I just love structs when it comes to teaching OOP for C folks - they allow for explaining OOP really easy without any abstract stuff most OOP textbooks love to use (car + wheels, house + windows etc.).
)

Also see http://stackoverflow.com/questions/2750270/c-c-struct-vs-class for more info

Historically, C supported structures before Obj-C and C++ were created to use classes. It's not like structures and classes suddenly appeared together.
I've seen one IOS game developing book recommend using structures over classes whenever possible if you're trying for 60fps graphics. The author said classes had too much messaging overhead.

MickeyT said:

Yes, those sorts of examples are exactly how I picked up OOP and, to be honest, it did turn out to be understandable.

Click to expand...

Yup, this is why I too use them to teach OOP for purely C (or Pascal) folks. The "abstract" approaches (the ones most OOP textbooks use) are pretty hard to grasp if you have a strong C or other knowledge of procedural programming languages.

MickeyT said:

So, can I think of structs as classes without methods, and that they're the actual data rather than pointers?

Click to expand...

Yup, they can be stored on the stack (as a local variable) and can be, consequently, accessed w/o using pointers. (They can also be put on the heap with the standard malloc calls too.)

MickeyT said:

I followed one particular struct (MKCoordinateRegion) through to find out what data types its contained data members were. They were also all structs until I eventually reached CLLocationDegrees, which is just a double. I don't think this is a struct, because it just says:

Code:

typedef double CLLocationDegrees;

What is the point - why not just stop at the next level up (a struct called MKCoordinateSpan) and have that contain just doubles?.

Click to expand...

It's more understandable this way. If you look at the declaration, you immediately know it's some kind of a coordinate. Of course, you can always use simple doubles instead of CLLocationDegrees but it won't be as instructive for people reading your source code.

MickeyT said:

Okay, I think I understand. And I suppose using structs inside classes is pointless because you would normally have properties where the name of the accessor method would be the giveaway as to what the basic data type was meant to represent?

So, please could I also just briefly clarify the syntax. Are these made up examples essentially equivalent, albeit one is a class and one is a struct:

Code:

MyClass *classInstance = [[MyClass alloc] initWithAnInt:anInt andADouble:aDouble];

MyStruct structData = MyStruct(anInt, aDouble);

Click to expand...

1. The latter should read

struct MyStruct structData ={anInt, aDouble};

where you can leave the leading "struct" if you typedef the struct by, say, "typedef struct GenericStruct MyStruct;"

2. structs created this way are on the stack (as opposed to being on the heap - see the alloc + init method call pair) and, therefore, should not be referenced after the current method is finished (don't assign their address to any global variable / property for later access). This is a major difference between "first-class" objects (instantiated from true classes) and struct variables.

MickeyT said:

But actually, I think maybe MKCoordinateRegionMakeWithDistance is a function and not a struct - am I right? If I recall correctly, MKCoordinateRegionMakeWithDistance was denoted with an "f" in the Apple documentation.

Click to expand...

Yup, it's a function. You can't create struct variables with the () notation - there isn't anything like a constructor for pure structs.

(BTW, there are a lot of other, similar helper MK* functions in iOS / OS X programming. They generally also return struct variables.)

----------

MickeyT said:

If so, what owns the function? What am I calling when I use a function (as opposed to a method which I understand belongs to either the class or the class instance)?

Click to expand...

It's in the standard library of iOS - in the MapKit framework, declared in the MKGeometry.h / MKOverlayView.h headers. You just add the framework & import those headers in your app and you're set.

structs allow developers to create their own data types. Consider CGPoint and CGRect. It's hard to imagine doing computer graphics without point and rectangle data types, but these types are not fundamental to the computer language, so need to be created by the developers who developed the graphics API. You could imagine that the point and rectangle data types could be classes rather than structs, and probably in some OOP languages or graphics APIs these types are classes. On iOS Core Graphics is a C API, mostly, so these types need to be C constructs, which leaves only structs. You could also imagine that everyplace where the graphics APIs need points and rects that they just take two or four float values as parameters. That would be error prone and ugly.

typedef and enum also allow the developer to create their own data types. Creating your own data type serves mostly heuristic value but since it allows you to make your code simpler and easier to understand this is very important.

typedef also allows Apple to modify how the API works without breaking code that uses it. IE, they can change a typedef int to a typedef long, and your code needs not change anything as long as you were using their typedef types all along.