Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

OS X app in plain C

github.com

Post reply on HN
Print view View original

11–20 of 157 posts

Re: OS X app in plain C

#11

Post by eridius »

btrask wrote: post #5

There was a thread the other day where people were talking about languages that were easily interoperable with the "C ABI" (although there is no such thing). Languages listed included C++, Rust, and maybe a few others--but no mention of Objective-C. The ability to use a high-level, dynamic language (ObjC), C, and even inline assembly in a single source file is unique to Objective-C (at least among the "mainstream" la…

You do actually need to cast the dispatch function, because there is no guarantee for all platforms that the ABI for calling a variadic function is the same as the ABI for calling a non-variadic function with the same arguments.

Re: OS X app in plain C

#12

Post by dmytroi »

btrask wrote: post #5

There was a thread the other day where people were talking about languages that were easily interoperable with the "C ABI" (although there is no such thing). Languages listed included C++, Rust, and maybe a few others--but no mention of Objective-C. The ability to use a high-level, dynamic language (ObjC), C, and even inline assembly in a single source file is unique to Objective-C (at least among the "mainstream" la…

Thanks for the comment!

On OS X if OBJC_OLD_DISPATCH_PROTOTYPES is not defined, you will get this declaration with zero arguments: void objc_msgSend(void /* id self, SEL op, ... */ ), which is possible to call from C without cast by using implicit function declaration, but this call will fail if compiled as Objective-C code with error "too many arguments to function call", I've decided to write in a style that compiles as C and Objective-C code.

PS. Would be nice to be able to use functions from clang Objective-C runtime [1], but for some reason they are not exposed in the public headers.

- [1] http://clang.llvm.org/docs/AutomaticReferenceCounting.html#r...

Re: OS X app in plain C

#13

Post by codemonkeymike »

Hydraulix989 wrote: post #2

It's amazing and sad for computing that somehow managing to use a sane language to develop software for a very commonly used platform is seen as a serious feat of accomplishment.

C was not designed to create gui's. So its a feat of accomplishment as opening a bottle with your teeth.

Re: OS X app in plain C

#14

Post by hellofunk »

ddoolin wrote: post #10
Hydraulix989 wrote: post #2

It's amazing and sad for computing that somehow managing to use a sane language to develop software for a very commonly used platform is seen as a serious feat of accomplishment.

Really? I don't write systems software but it seems most here would not recommend writing in C/C++ unless it's absolutely the best choice.

I don't know who you've been talking to, but that's ridiculous. C++ is one of the most widely-used languages for writing native apps for any OS. Adobe products, Chrome, anything built with Qt, even the Swift language itself, all made in C++.

Re: OS X app in plain C

#15

Post by mikeash »

btrask wrote: post #5

There was a thread the other day where people were talking about languages that were easily interoperable with the "C ABI" (although there is no such thing). Languages listed included C++, Rust, and maybe a few others--but no mention of Objective-C. The ability to use a high-level, dynamic language (ObjC), C, and even inline assembly in a single source file is unique to Objective-C (at least among the "mainstream" la…

You should still cast the dispatch function even when your return type is id.

For one, C vararg type promotion makes it impossible to pass certain types in as parameters otherwise. For example, you can't pass a float.

It's also easy to make mistakes because of type mismatches. For example, if you pass `42` to a CGFloat parameter, this works fine when you cast msgSend to the right type, but will fail amusingly if you rely on varargs to make it through.

Perhaps most importantly, vararg calls aren't guaranteed to be compatible with a non-vararg target (as most/all methods you call will be), and you'll see this in action on ARM64.

Currently, you can #define OBJC_OLD_DISPATCH_PROTOTYPES 0 to have the compiler enforce this requirement. (This declares the functions to take (void) rather than (id, SEL, ...).) It's likely that Apple will eventually make this the default.

Re: OS X app in plain C

#16

Post by radarsat1 »

btrask wrote: post #5

There was a thread the other day where people were talking about languages that were easily interoperable with the "C ABI" (although there is no such thing). Languages listed included C++, Rust, and maybe a few others--but no mention of Objective-C. The ability to use a high-level, dynamic language (ObjC), C, and even inline assembly in a single source file is unique to Objective-C (at least among the "mainstream" la…

So I will bite. Why does the C ABI not exist?

C calling conventions (cdecl, stdcall) and memory layout is pretty well standardized. So I'm not sure what else you could be referring to here.

Re: OS X app in plain C

#17

Post by ultramancool »

codemonkeymike wrote: post #13
Hydraulix989 wrote: post #2

It's amazing and sad for computing that somehow managing to use a sane language to develop software for a very commonly used platform is seen as a serious feat of accomplishment.

C was not designed to create gui's. So its a feat of accomplishment as opening a bottle with your teeth.

Windows, X11 and Gtk would argue with you.

Re: OS X app in plain C

#18

Post by mcmatterson »

A few years ago I dove into the idea of trying to make a C only iOS app (well actually, it was a quick exploration of how hard it would be to build your own UI kit without using UIKit). The dive bottomed out pretty quickly, as I couldn't figure out a way to access windows without resorting to UIWindow methods, and `UIGraphicsGetCurrentContext()` acted super wonky calling it without 'proper' bootstrapping around it. I was expecting more, given the usual layered approach that Apple takes with their system libraries.

Re: OS X app in plain C

#19

Post by dmytroi »

codemonkeymike wrote: post #13
Hydraulix989 wrote: post #2

It's amazing and sad for computing that somehow managing to use a sane language to develop software for a very commonly used platform is seen as a serious feat of accomplishment.

C was not designed to create gui's. So its a feat of accomplishment as opening a bottle with your teeth.

IMHO it depends, C/C++ work very nicely with immediate mode UI frameworks, for example nuklear [1], imgui [2]. Though retained mode C/C++ UI frameworks are also quite popular, for example Qt, wxWidgets, GTK.

- [1] https://github.com/vurtun/nuklear

- [2] https://github.com/ocornut/imgui

Re: OS X app in plain C

#20

Post by conradev »

btrask wrote: post #5

There was a thread the other day where people were talking about languages that were easily interoperable with the "C ABI" (although there is no such thing). Languages listed included C++, Rust, and maybe a few others--but no mention of Objective-C. The ability to use a high-level, dynamic language (ObjC), C, and even inline assembly in a single source file is unique to Objective-C (at least among the "mainstream" la…

> The ability to use a high-level, dynamic language (ObjC), C, and even inline assembly in a single source file is unique to Objective-C (at least among the "mainstream" languages), and something I think is often under-appreciated.

You can even use C++, too, which is awesome. Putting Objective-C objects in C++ structs "just works" thanks to ARC.

One thing most people don't know is that Objective-C was originally implemented as a precompiler for C.

Post reply on HN