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

31–40 of 157 posts

Re: OS X app in plain C

#31

Post by gumby »

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…

SVR4 specified standard-conformant calling conventions (stack layout, register use etc). IIRC VMS went one "better" and tried to specify a standard calling convention that was supposed to apply to all programs (sadly, there's more to interoperability than calling convention).

Re: OS X app in plain C

#32

Post by q3k »

coldtea wrote: post #26
ultramancool wrote: post #17

Earlier quoted context omitted.

Windows, X11 and Gtk would argue with you.

Windows is written in C++ mostly. As for X11 and Gtk, well, I argue with THEM.

Yes, but WinAPI (which is all that is required to do GUI programming in Windows) is C-centric.

Re: OS X app in plain C

#34

Post by marssaxman »

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.

Ummm... I wrote plenty of GUI code in C and so did lots of other people back in the late '80s and early '90s. Quite common. I don't know what it would mean for it to have been "designed to create" GUIs; it's a general-purpose language.

Re: OS X app in plain C

#35

Post by wtallis »

eyeareque wrote: post #24

I'm not a developer, but does it count when they use objc header files? #include #include #include #include

I think those are all valid C header files. They just define typedefs and macros that are about ObjC, but themselves are plain C.

Re: OS X app in plain C

#36

Post by chillingeffect »

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.

This is a very particular crowd, largely into web software and ecosystems for rapid growth of SaaS. I wouldn't extrapolate this crowd into software languages in general. You should always use the best tool for the job.

Many people write quite excellent software in C/C++ every day. Just as many people use chainsaws, drive cars, fire guns and take pills every day. These are all productive activities with low floors and high ceilings. Anyone can jump in and make a mess. It takes care and attention to do them well.

Re: OS X app in plain C

#37

Post by icodestuff »

I don't buy it. Yes, the language may be C, but if you're linking the ObjC runtime and frameworks, all you're really avoiding here is the nib-loading machinery.

To be fair, I think that's a perfectly reasonable goal in and of itself - showing how to set up an OS X app "from scratch" is definitely something I'm interested in - but we shouldn't pretend this isn't strongly relying on Objective-C to actually get things done.

EDIT: indeed, the makefile copies main.c to main.m before invoking clang, which means it's using the Objective-C compiler.

What would be much more impressive is if this used only the C Core* frameworks (Core Foundation and Core Graphics in particular) to do the same thing.

Re: OS X app in plain C

#38

Post by dmytroi »

joewillsher wrote: post #30
hellofunk wrote: post #14

Earlier quoted context omitted.

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 assessmen…

It depends, most of important and heavy lifting stuff in Apple platform, aka Core frameworks, are written in C, for example a quote from Core Text documentation [1]:

> Many of the low level libraries in OS X and iOS are written in plain C for speed and simplicity.

And don't forget that OSX/iOS are based on Darwin BSD, where most of heavy lifting is done by programs written in C.

- [1] https://developer.apple.com/library/mac/documentation/String...

Re: OS X app in plain C

#39

Post by mikeash »

btrask wrote: post #25
mikeash wrote: post #15

Earlier quoted context omitted.

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.

I don't see how it's debatable. The version without a cast is just plain incorrect, but happens to work anyway through luck and happenstance on many platforms. Even ignoring that, getting the types right without the cast requires looking at the type of every parameter, which could be variables declared far away, and understanding and applying C's vararg type promotion rules. Getting the types right for a cast just requires writing out those types correctly at the point of the cast.
Post reply on HN