Hacker News Reader

Comment by FraKtus | Hacker News Reader

what is more interesting is his other project to make an application in pure C: https://github.com/richardjrossiii/CBasediOSApp. When you are doing cross-platform, you may be more at ease with a few lines of C for some utilities call if you don't want to learn objective C.

View on HN

It’s definitely NOT cross-platform. He’s just calling the objective-c runtime from C.

Maybe I'm reading wrong, but I read it more that if the Objective-C interface is small, i.e. the bulk of your app is cross-platform C, you could easily use C to interact with the runtime.

So why not just write the Objective-C part in C rather than calling the underlying machinery directly. It's a neat project to learn the internals, but I wouldn't ever structure a real app this way.

If you write part of it in C, then you can reuse that code on another platform.

Objective-C is a superset of C though, so you might as well write the platform specific stuff in an .m file rather than messing around with the .c API for Objective-C. :)

Yes, part of it should be in C. Even if the Objective-C calls were portable (last time I checked GNUStep was pretty much dead) the APIs it calls into aren't. Seems to me like there's more value to just write the Objective-C parts in a .m file normally & call into the shared C/C++ code.

> So why not just write the Objective-C part in C rather than calling the underlying machinery directly.

Because the "underlying machinery" isn't documented by Apple. It may not even be a stable interface!

In fact it basically is:

https://developer.apple.com/documentation/objectivec/objecti...

My understanding of the parent post was that they meant whatever "underlying machinery" AppKit is calling into -- not just the ObjC runtime.

I typo'ed. I meant to say why not right the Objective-C part in Objective-C. I see no value in writing it all in C because you lose all the compile-time checks the compiler is able to perform to catch bugs & the C interface, which AFAIK is ABI stable (would have to be since apps are forward-compatible), is really difficult to use.

I did not mean you can make cross-platform programming thanks to this example but that you may avoid having objective C code in your project thanks to this. I know from personal experience that objective C makes some colleague "nervous" :-)

Whoa that looks so much simpler to me than ObjC. Of course I'm being a little naive because I haven't looked for moment at what those headers contain or how the API works, but just the same—that C version looks clean.

I wonder what developing a more complex application would look like.

I don't think it looks "simpler" than ObjC. He's still making the ObjC method calls, but with even more verbosity. I'd abstract all that away into macros or function calls ... but then you're right back to ObjC.

He just de-sugared [foo bar] into objc_msgSend(foo, sel_getUid(“bar”))

And probably lost a ton of compiler assisted type checking in the process. I hope nobody considers doing anything remotely like this for any reason beyond learning a little about the low-level Objective-C machinery.

This is how SDL2 works for Cocoa it also is written in pure-C in some areas where there would normally be Mach files

The Cocoa implementation of SDL 2 uses plain Objective-C to access Apple's APIs: https://github.com/spurious/SDL-mirror/tree/master/src/video...

I couldn't find a call to objc_msgSend in other (.c) files using GitHub's code search. Objective-C and C/C++ are perfectly interoperable, there's rarely a reason to use the verbose and error-prone C API to call into Objective-C.

The .m file extension is not related to Mach: https://stackoverflow.com/a/652266

Reply on news.ycombinator.com