So, you learned Objective C...
category: general [glöplog]
...what experience can you share with someone who just started coding in ObjC (especially for the iPhone)? I am asking for things that you don't find in tutorials (wich are written from a certain, neutral point of view): tips, warnings... Just personal experience.
Thanks!
Oh, and I originally wanted to create such a topic on mac.scene.org, but the log in doesn't work anymore. Anyone knows when (if) this can be fixed?
Thanks!
Oh, and I originally wanted to create such a topic on mac.scene.org, but the log in doesn't work anymore. Anyone knows when (if) this can be fixed?
probably the guys at mac.scene.org just need to remove the :8080 port in their call to sceneid
idevgames.com has got some nice people and has an iPhone board, so yeah.
My background is c++. I have no experience with iPhone.
autorelease is an elegant way to avoid dealing with nasty ownership issues when you pass data around.
delegate is useful for creating classes that doesn't have zero knowledge about the surroundings.
key-value-binding is difficult. I don't get it.
key-value-observing is difficult. I don't get it neither.
autorelease is an elegant way to avoid dealing with nasty ownership issues when you pass data around.
delegate is useful for creating classes that doesn't have zero knowledge about the surroundings.
key-value-binding is difficult. I don't get it.
key-value-observing is difficult. I don't get it neither.
Quote:
delegate is useful for creating classes that doesn't have zero knowledge about the surroundings.
that has zero
Only non-sucky explanation of memory management I found online when I started 3 years ago: Hold Me, Use Me, Free Me
mac.scene.org login seems to be fixed at last \o/
Key-value-binding.. at least the interface builder side, it's pretty easy once you get how the different types are bound, I use it a lot. The interface takes or passes it's value from a slider or whatever.. if you move the slider, the value is passed to whatever you bind it to, if the value changes in your code then the slider will move automatically to the new value.
Key-value-binding.. at least the interface builder side, it's pretty easy once you get how the different types are bound, I use it a lot. The interface takes or passes it's value from a slider or whatever.. if you move the slider, the value is passed to whatever you bind it to, if the value changes in your code then the slider will move automatically to the new value.
I've finnished to port my pinball game on the iphone, it takes me 3 weeks to perform without the sound that I've developped on another side and that must be tested being a registered developper on the machine. thing that takes several weeks.
The sample code of and openGL ES application is relatively simple to extend with a C++ class that allows to port the entire game in the case of linear coding. (cf dr dobbs 3d sample of july 2008)
For the pinball I'm developping, it takes one week to port my graphic library with opengles restrictions.
There exist some lacks in compilation with the simulator that could have been thought with the sound for faster development.
The problem of absent malloc and free is quickly resolved.
The sample code of and openGL ES application is relatively simple to extend with a C++ class that allows to port the entire game in the case of linear coding. (cf dr dobbs 3d sample of july 2008)
For the pinball I'm developping, it takes one week to port my graphic library with opengles restrictions.
There exist some lacks in compilation with the simulator that could have been thought with the sound for faster development.
The problem of absent malloc and free is quickly resolved.
aharonid, what do you mean by "absent malloc and free"?
so, how is objective c in general?
is it hard to learn if you come from a c++ background?
how forgiving is it in relation to programming errors? (i.e. bad memory allocation, leaks)
is it hard to learn if you come from a c++ background?
how forgiving is it in relation to programming errors? (i.e. bad memory allocation, leaks)
for the iPhone, what some ppl have been doing is to make only the main file in ObjectiveC and link to C++. I don't know how much of a problem it is to setup, but i guess it can save you some time if you're more fluent in cpp than oc.
Why not using C++? :|
Because there are no good bindings to Cocoa.
I just discovered "delegate" – quite nice!
on iphone malloc and free are forbidden, only new and delete works with the cocoa platform.
I've just ssen that some openAL functionnalities arent allowed too.
And at this moment, I have some leaks of synchronisations in my thread for module player.
Oh so, the iphone have limited 3d capabilities.
I've just ssen that some openAL functionnalities arent allowed too.
And at this moment, I have some leaks of synchronisations in my thread for module player.
Oh so, the iphone have limited 3d capabilities.
Quote:
Unfortunately, reference counting doesn't remain this simple. For example, suppose that we are writing a method which is expected to respond by returning a string object. In order to generate the response, a string object is allocated and used to prepare the response. At the end of the method we will return this temporary string as our "answer". A problem crops up here: if we relinquish ownership of the string before the caller gets a chance to retain it, then its reference count will reach zero and the string will cease to exist. Yet we want to do a -release before the return statement so that we follow the rule of one release for every retain/allocation.
The answer is very clever. What we do is create an auxilliary object called a "release pool" which can be a temporary holding place for the object during the short limbo between the end of our method and our method's caller accepting the object. What we do is add the object to the pool and the pool will retain the object. Next, we release the object. (It still has a reference count of one, due to the pool). After that, we return from our method. If the caller wants to keep the object, it will send a -retain message--and it has time to do so before the object disappears. At some later point in time, the release pool will be deallocated, decreasing the reference counts of all the objects it contains by one.
That's quite a "clever" solution for getting your call semantics wrong in the first place, yes... *sigh*
...switch to a serious platform?
Quote:
so, how is objective c in general?
objc is well chosen for for UI programming. I can imagine it bad at graphics programming, but for this you can use c++. I would say its halfway a scripting language much similar to ruby, though it doesn't look like ruby. All arguments is named which was totally alien for me for a long time, now I cannot live without it.
Quote:
is it hard to learn if you come from a c++ background?
objc wasnt' that difficult. what takes time is learning the apple frameworks.
Quote:
how forgiving is it in relation to programming errors? (i.e. bad memory allocation, leaks)
in objc you can safely invoke a method on a NULL pointer and the program will continue unaffected.
Code:
c++
person = NULL;
person->age(); // boom
objc
person = nil;
[person age]; // ok
also objc and c++ can be mixed.
@kb, yes autoreleasepools are clever.
I don't even dare to think of all this memory management stuff. At first I thought it was simple, but I'm not quite sure anymore...
Neoneye, in a certain "a clever solution for a problem that shouldn't even exist at all" way perhaps.
Quote:
...switch to a serious platform?
yeah,good idea,but NOT in C,man ;) also theres no motorola anymore in any cell-phone,even not in motorolas emselves i think!
yeah memory management is difficult. Out of the box objc has very good support for memory management (refcounting + gc), where c++ has none. Maybe boost has something like that, which I never have used because I find it too big. I use my own gc lib for my c++ projects.
So I told you the truth : Dune is Earth ! How the humans beings can have found the spice to space travel without knowing the planet that produce it at the starting point ?
@kb, autorelease are less clever than many other programming concepts. for people that havn't dealt with the nastyness of memory management I can imagine its bad.
I've made good experiences with a slightly upgraded version of smart pointers - every object tracks every reference to it via a doubly linked list, and furthermore pointers can be marked as "weak" and automatically NULLed (including throwing errors or exceptions when dereferenced, or even better: pointing to a dummy object that does nothing) when the object they point to is invalidated. In one game that we've made this reduced the over 9000 places in the code where people had (and often forgot) to check references to eg. sound effects that might still be running (or might not) to a convenient 0.
All algorithms involved are still O(1), and the few nanoseconds and bytes that this solution takes aren't that bad, actually :)
All algorithms involved are still O(1), and the few nanoseconds and bytes that this solution takes aren't that bad, actually :)