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

41–50 of 157 posts

Re: OS X app in plain C

#41

Post by dep_b »

conradev wrote: post #20
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 impl…

I think it actually was a precompiler for C up til a point. Still Objective-C objects have underlying C functions that are being called whenever you try to call a method or anything on an Objective-C object. Theoretically you should be able to call functions on Objective-C objects from C.

Re: OS X app in plain C

#42

Post by ultramancool »

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.

Windows itself perhaps, but not the Windows API. If you've ever done any low-level Windows development, it's pure C.

See here for a tutorial using it for basic GUI stuff:

http://zetcode.com/gui/winapi/firststeps/

I've even seen several games that use it directly for keyboard handling and such to this day. And all the new, fancy GUI frameworks which exist on Windows are basically just wrappers on top of WinAPI.

Re: OS X app in plain C

#43

Post by izacus »

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…

Is there an actual half-popular production app for OS X written in Swift yet?

Re: OS X app in plain C

#44

Post by hunterwerlla »

icodestuff wrote: post #37

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

So obviously it's impossible to write a linux app in anything pure but C because the kernel is written in C. That makes no sense.

Re: OS X app in plain C

#45

Post by valarauca1 »

conradev wrote: post #20
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 impl…

Objective-C was a modification of the GCC developed by NeXT. NeXT didn't publicly release their patches and the FSF/GNU threatened legal action. NeXT released their sources and the GCC now supports Obj-C.

Source: https://en.wikipedia.org/wiki/GNU_General_Public_License#Leg...

Re: OS X app in plain C

#46

Post by avar »

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)[...]
Well Perl is mainstream enough to be installed on every *nix box, here's examples of assembly and C functions interoperating with Perl in the same source file: https://metacpan.org/pod/distribution/Inline-ASM/ASM.pod#SYN... & https://metacpan.org/pod/distribution/Inline-C/lib/Inline/C....

    > The "C ABI" (although there is no such thing)
Of course if you do this in Perl every one of your calls will need to go through a foreign function interface where Perl's structures are translated back & forth between its idea of datastructures and the OS's idea, avoiding that is what people really mean when they talk about the "C ABI".

Re: OS X app in plain C

#47

Post by thought_alarm »

icodestuff wrote: post #37

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

Look at the makefile again. It builds five different binaries from the same source file, one of which using a C compiler.

This is no different than writing a COM application in C. Both COM and objc runtimes provide similar dynamic OO services over a plain C API.

Re: OS X app in plain C

#48

Post by astrange »

izacus wrote: post #43
joewillsher wrote: post #30

Earlier quoted context omitted.

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…

Is there an actual half-popular production app for OS X written in Swift yet?

Probably not, but Lyft is an iOS app written in Swift.

Re: OS X app in plain C

#49

Post by btrask »

mikeash wrote: post #39
btrask wrote: post #25

Earlier quoted context omitted.

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

I said you're right and I wasn't trying to disagree. I'm also a big fan of your blog and comments here (FWIW).

As for whether casts add much safety, I admitted it's debatable. C++ prefers casts (e.g. on malloc) whereas C doesn't. A downside of using explicit casts is that if the type changes elsewhere in the program, the casts (spread throughout the code) can mask errors. If you write code such that casts are unnecessary (which I'm agreeing is not possible in this case!), you will get a compile warning/error right away.

I think both perspectives are valid and there are risks either way. I try to avoid casts when writing plain C though.

Post reply on HN