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

21–30 of 157 posts

Re: OS X app in plain C

#21

Post by School-Cotton »

radarsat1 wrote: post #16
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.

Not OP but I'm guessing they were referring to the fact that this stuff is platform-specific and not specified by the C standard.

Re: OS X app in plain C

#22

Post by fit2rule »

santaclaus wrote: post #4

> For some reason if we run the app from command line than menu is not accesible by mouse at first time This happens with Qt apps on OS X, as well, and it drives me bonkers. If you launch from the command line you have to command tab away and back for the menu to work

Its because of the missing .app bundle and appropriate Info.plist. I just submitted a pull request to fix this - maybe its useful for you too, check it out:

https://github.com/jimon/osx_app_in_plain_c/pull/1

Re: OS X app in plain C

#23

Post by msbarnett »

radarsat1 wrote: post #16
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.

The C standard specifies absolutely no "C ABI" standard. The two "standard" calling conventions you cite, cdecl and stdcall, are Wintel conventions.

However, since C is the low-level implementation language for almost every dominant operating system, a given platform's Operating System ABI is almost always locally synonymous with the C ABI on that platform, and people tend to speak of "being compatible with the C ABI" when what they really mean is that they're compatible with the OS's ABI.

But if you move to, say, a Mainframe OS, the OS ABI is dramatically different than the "C ABI" you're imagining from Wintel.

Re: OS X app in plain C

#25

Post by btrask »

mikeash wrote: post #15
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…

You're right and thanks for the correction. One point I'd add is that C generally encourages not using casts because casts themselves can be error-prone. So it's debatable whether it adds any real type-safety.

Re: OS X app in plain C

#26

Post by coldtea »

ultramancool wrote: post #17
codemonkeymike wrote: post #13

Earlier quoted context omitted.

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.

Windows is written in C++ mostly.

As for X11 and Gtk, well, I argue with THEM.

Re: OS X app in plain C

#27

Post by [deleted] »

radarsat1 wrote: post #16
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.

[deleted]

Re: OS X app in plain C

#28

Post by tosseraccount »

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.

Few languages have intrinsic GUI components.

Re: OS X app in plain C

#29

Post by btrask »

msbarnett wrote: post #23
radarsat1 wrote: post #16

Earlier quoted context omitted.

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.

The C standard specifies absolutely no "C ABI" standard. The two "standard" calling conventions you cite, cdecl and stdcall, are Wintel conventions. However, since C is the low-level implementation language for almost every dominant operating system, a given platform's Operating System ABI is almost always locally synonymous with the C ABI on that platform, and people tend to speak of "being compatible with the C ABI…

Even on a platform that wasn't based on C, the C standard is flexible enough to match pretty much any native ABI. That's a small (and under-used) upside to all of that undefined behavior.

Re: OS X app in plain C

#30

Post by joewillsher »

hellofunk wrote: post #14
ddoolin wrote: post #10

Earlier quoted context omitted.

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++.

Most apple platform apps are written in mostly objc or Swift and not C++, I wouldn’t say it is one of the most widely used languages on these platforms by any means. The Cocoa SDK exposes an objc interface so many system framework calls have to use swift or objc.

Secondly, compilers are a very different programming task to developing GUI apps; the Swift team choosing to use it has nothing to do with Apple’s assessment of how you should write an application—Apple are the people who have been leading objc development (they own the objc IP) in the last 10 years and use it in all first party apps and many system frameworks.

Post reply on HN