I've never worked with a language that didn't provide for some form of memory management, and thus managed to get by without ever really groking pointers.
I can dabble in C I guess, as a result of coding in Objective-C for a little while.
Hmmm, maybe it's the single linked list.
Try it: create, populate, reverse, release a single linked list
struct node {
int data;
struct node *next;
};
I wouldn't call this "canonical", but I'm recreating [arrayOfStrings sortUsingSelector:#selector(compare:)]; using char * arrays and pure C code. It's sloppy and frustrating, but great practice and I'm loving it.
http://github.com/jkubicek/Objective-Sort/blob/master/Objective-Sort.m
I've started a small github project to collect objective-c katas: https://github.com/twobitlabs/xcode-katas
Related
Is it at all possible to have Xcode create a .playground file for Objective-C instead of Swift? Are there any available Xcode plugins that allow that?
You can quickly test code snippets using a test case in a new project. Just create a new project and go to the Navigator in the left pane and hit the Test Navigator button. Then follow this guide
The setup code will look a little different than a swift playground, but it still allows you to prototype and play around.
There is a very good library developed by Krzysztof Zabłocki in Github entitled KZPlayground that support both code in Playgrounds for Objective-C and Swift and a lot of cool features.
I hope this can help you.
If the only purpose is to test out Objective-C snippets, i would really recommend you an OS X command line Tool project.
There are enough moving parts in a playground, and all of those would have to be reimplemented for Objective-C. Reliable playgrounds also depend on definite initialization which Objective-C does not have.
For instance consider:
var d: NSData // this is not initialized, so I can't use it
vs.
NSData *d; // this is also not initialized, but now I can use it
If I am the person storing the description of your NSData for the sidebar, now I know that I am not supposed to do
describe(d)
in the Swift case, but for the Objective-C case, I don't have equal knowledge and I run the risk of saying
[d description]; // even though d is a random pointer now.. oops, I just crashed!
In short, I don't think any such thing exists, and making one work would also involve some trickery
I have the following code here that won't run on ARC since it combines Objective-C objects in structs:
struct SingleToManyRelation {
id singleObject;
NSSet* manyObjects;
}
I know this is reminiscent of Core Data, but that's not the point ;) I am just looking for a solution to implement something like that without having to create a "container" class.
Thanks in advance for your advices,
Christian
Give your objects the __unsafe_unretained attribute and ARC will stop complaining (but keep in mind that they aren't retained! So you have to somehow store a strong relationship to them, if you don't want to lose them)
Is it possible to get a list of pointer to a pointers to an objective c object.
something like
id **pointers(id object, int *out_count)
Pretty crazy, huh? =)
Unfortunately, no. If such a thing were generally possible, then writing a precise garbage collector would be rather simple:
int count;
pointers(obj, &count);
if (count == 0) {
free(obj);
}
Since the objective-c garbage collector has to chase pointers from roots, control the allocator, and scan the stack conservatively to achieve something like this, I think it's reasonable to assume that you'd need to do the same.
It might be possible to leverage the garbage collector's implementation of this, though, if running in GC mode. Not a good idea, not simple, and won't work on iOS, but maybe possible. libauto is open source after all.
Can I, in the GNU Objective-C runtime, attach semi-arbitrary pieces of data to instance variables?
Challenge:
I'm currently working on a kind of Cocoa workalike for Linux, as a sort of pet project. (Please, let's not get sidetracked by all the "use GNUStep" stuff. I know about it, but it doesn't suit my needs. Moving on…) For this purpose I'm trying to cobble together a simple ORM system, reminiscent of DBIx::Class for Perl. The general idea is to make the declaration as simple (read: short) as possible, and if at all possible, without the need to provide +(id)constantClassAttribute methods for overriding.
The general idea is to declare my result classes as follows:
#interface SomeTable : ORMResult {
unsigned long long id;
ORMResult *toOneRelation;
ORMResultSet *toManyRelation;
}
#end
So far, so hoopy. I can now access these fields using [ORMResult self]->ivars, and do all manner of nasty stuff, like automagically generating accessors like -[toManyRelation] or -[setToOneRelation]. Piece of cake. Unfortunately, there are two pieces of information I cannot add using this setup; one is simple enough to solve, the other not so much:
What is the actual result class?
This is solved by subclassing ORMResult (like SomeTable), and plugging that in
there, using runtime dynam(ag)ics to figure out it's to-ness (toMany, toOne).
(And this is the tricky one!) Is the relationship nullable?
This is less easily solved. My initial ideas were
(ab)using protocols, like so:
#interface SomeTable : ORMResult {
unsigned long long id;
ORMResult <ORMNullable> *toOneRelation;
}
#end
This compiles, but unfortunately, when I try to use GDB to inspect the
ivars->ivar_list entries I find that the protocol information isn't actually kept
for the runtime to toy with. This makes, I suppose, some kind of twisted sense,
as protocol declarations are mostly for the compiler.
Abusing the protocol identifiers (byref, bycopy and friends, using defines:
#interface SomeTable : ORMResult {
unsigned long long id;
nullable OMRResult *toOneRelation;
}
#end
This has the rather obvious drawback of not actually working, as these
specifiers apparently only work in protocol method declarations.
The question, then, is how can this attachment of information to the ivars be pulled off in practice?
Note: As mentioned initially, I'm using the GNU Objective-C runtime, as supplied by GCC on Linux; and not the one supplied by Apple!
Edit: Starpox! I forgot a central point: An alternative, of course, is to simply make all relations nullable. This I don't really want, but if no other alternative exists, I guess that's the path I'll end up going down.
Well, how we used to do this in ye olde days on the Mac was to create a global variable holding an NSMutableDictionary into which we put the data we want to attach to an object. Simply use a string representation of the pointer as the key.
The only difficulty becomes figuring out when an object has gone away and making sure that its entry in the dictionary is removed as well. You may have to resort to hackery like method swizzling -dealloc to achieve that.
You might look at objc_setAssociatedObject and friends, which allow you to attach arbitrary data to an object. However, I'm not sure if they're supported in the version of libobjc that you're running.
Hopefully, this question isn't a dumb as I fear it sounds, but it may still be pretty dumb.
I'm new to Objective-C, and Cocoa. In fact, I'm completely new to C in general. I'm trying to implement an iPhone game using Cocos2d-iPhone. It's a game I've made before in Flash, so I thought it would be a nice way to lean Objective C, cocoa and cocos2d.
One thing I am having a big problem with is understanding why all the Chipmunk code looks different to all the normal Objective-C stuff. For example, there's stuff like
chipmunkBody->position.x
which I thought would have been
chipmunkBody.position.x or maybe [[chipmunkBody position] x] (bad example maybe).
One way this keeps on biting me in the ass is with cpVect. cpVect is pretty important, but I can't for the life of me figure out how to pass it around. CGPoint, no problem, I can make pointers, pass them around in methods and what not, but the second I use cpVect instead, it's "welcome to Errorville, population you".
So that's the question, what is Chipmunk, so I can start finding out more about working with it.
thanks
-t
I haven't used Chipmunk, but it's probably written in C/C++. That's the reason.
EDIT: Yup, it's written in C.
chipmunkBody is a pointer to a struct, and the arrow operator (->) is how you access the members of a struct through a pointer to the struct in C.
In case you're looking for an easy way to use Chipmunk thru way of Objective-C, Theres a nice little post about an Objective-C class called SpaceManager here: http://www.mobile-bros.com/?p=126