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

111–120 of 157 posts

Re: OS X app in plain C

#111

Post by bdrool »

justsaysmthng wrote: post #61

Don't do this at home. It looks so ugly because it's dangerous and vice-versa. If you really want to write (and read) code like this: id titleString = ((id ( )(id, SEL, const char ))objc_msgSend)((id)objc_getClass("NSString"), sel_registerName("stringWithUTF8String:"), "sup from C"); ((void (*)(id, SEL, id))objc_msgSend)(window, sel_registerName("setTitle:"), titleString); instead of this [window setTitle:@"sup"]; th…

> a Objective-C to C converter (if there isn't one already)

Incidentally, that's pretty much how the language got started -- as a pre-processor add-on for plain C:

https://en.wikipedia.org/wiki/Objective-C#History

Re: OS X app in plain C

#112

Post by Hydraulix989 »

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.

Why recommend Objective-C over C/C++ though? It's more or less subject to the same "pitfalls" that go against C, PLUS it is a syntactical nightmare.

[whatTheHell:is this:shit];

Is ARC really that much of a savior here? At least method calls get resolved at compile time.

Re: OS X app in plain C

#113

Post by poizan42 »

jheriko wrote: post #101
poizan42 wrote: post #63

Earlier quoted context omitted.

At least MSVC on x86 uses "thiscall" by default which puts the this pointer in ecx. You cannot call those functions from C without specific compiler support.

thats not true if you inspect the details of the specific ABI and cheat a little or use some inline assembler... but cl is easily the worst compiler for a C++ ABI. they break it on tiny incremental updates sometimes... at least historically (in fairly recent history at least).

> thats not true if you inspect the details of the specific ABI and cheat a little or use some inline assembler...

Some x86 C compilers supports calling conventions that lets you put things in registers, e.g. Microsofts "fastcall". But I wouldn't consider that part of the standard "C ABI" for Windows given that it's practically never used for externally visible functions. As I said "without specfic compiler support".

Using inline assembler is just cheating, it's not C.

> but cl is easily the worst compiler for a C++ ABI. they break it on tiny incremental updates sometimes... at least historically (in fairly recent history at least).

That is more about name mangling schemes and layout of standard library classes though. As far as I know the calling conventions has been quite fixed for a long time.

Re: OS X app in plain C

#114

Post by coldtea »

q3k wrote: post #32
coldtea wrote: post #26

Earlier quoted context omitted.

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.

Yeah, but nobody (ie. very few if anybody) does GUI programming in WinAPI, so I don't see how it's relevant in determining whether C is good for GUIs.

Re: OS X app in plain C

#115

Post by mikeash »

btrask wrote: post #80
mikeash wrote: post #76

Earlier quoted context omitted.

I don't understand what's debatable about that. Maybe an example would help? objc_msgSend(window, sel_registerName("setAlphaValue:"), 1); Versus: ((void (*)(id, SEL, CGFloat))objc_msgSend)(window, sel_registerName("setAlphaValue:"), 1); The former will set a garbage alpha value, the latter works. More generally, the former requires much more care and attention to get the types right, whereas the latter just requires…

((void (*)(id, SEL, double))objc_msgSend)(window, sel_registerName("setAlphaValue:"), 1); If the method signature changes (unlikely for a system header, but possible if you're calling into your own code) then you're hosed. Or you could just mess up and copy/paste the wrong signature, or forget to change it. Basically, it's pretty error-prone no matter what you do. Using Objective-C directly is much safer (and luckily…

I totally agree on all counts here. The cast saves you from this one specific thing but there's plenty more to go wrong. I think some people may overestimate the difficulty of adding some ObjC wrappers to a plain C project.

Re: OS X app in plain C

#116

Post by themartorana »

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…

I'm going to miss Objective C terribly. It is, hands down, still my favorite language (and ecosystem). It's interoperability with C got me into C. It was insanely powerful and fun.

I know not many people agree with me. I liked the square braces and crazy long function names. I know Swift is decent... It's not the same.

Oh well. Lamenting my path to software engineering doesn't mean much for anyone else. But I really am going to miss it.

Re: OS X app in plain C

#117

Post by _asummers »

astrange wrote: post #107
jheriko wrote: post #100

Earlier quoted context omitted.

you mean objective-c++? c++ has no idea about obj-c... another thing most people forget is that the entire programming community rejected obj-c as deficient in its very early days... it only persists thanks to the ego of former nextstep employees afaik. and now apple employees got lumped with it... which i'd suspect helped create the internal pressure for swift... so some good came at the end of it all. :)

Objective-C was the major inspiration for Java - you'll notice how little it looks like C++ - and therefore C# and co, so it's been very influential ever since the 90s. It's not worth listening to anyone who dislikes Obj-C just because of the [] syntax, which doesn't matter after the first 48 hours.

This about mirrors my opinions about Objective-C.

http://twistedoakstudios.com/blog/Post8237_a-years-worth-of-...

Re: OS X app in plain C

#118

Post by userbinator »

Someone wrote: post #96
btrask wrote: post #29

Earlier quoted context omitted.

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.

Most of the time, you will need a tiny bit of non-standard stuff in your compiler to do so. For example, I don't think there is a portable way to let your compiler use Pascal calling conventions, or to pass information in specific registers or in processor flags. As an extreme example, in classic Mac OS, you could register a function to be called for line breaking in text input boxes that had the ABI "Parameters are…

So, apparently, one cannot even count on C compilers to push arguments from left to right.

Right-to-left is pretty much the most sensible way to implement variadic functions with a stack-based calling convention - the argument that the function uses to interpret the rest of them must be found at a known location relative to the stack "top", and due to how stacks work, that implies the varying portion has to be pushed first, thus right-to-left.

Maybe if C decided to design things a little differently:

    int printf(..., const char *format);
    ...
    printf(5, "There are %d lights.\n");
we would instead have right-to-left being the dominant C calling convention.

Re: OS X app in plain C

#119

Post by fit2rule »

dmytroi wrote: post #82
justsaysmthng wrote: post #61

Don't do this at home. It looks so ugly because it's dangerous and vice-versa. If you really want to write (and read) code like this: id titleString = ((id ( )(id, SEL, const char ))objc_msgSend)((id)objc_getClass("NSString"), sel_registerName("stringWithUTF8String:"), "sup from C"); ((void (*)(id, SEL, id))objc_msgSend)(window, sel_registerName("setTitle:"), titleString); instead of this [window setTitle:@"sup"]; th…

One practical example would be tigr [1] - a cross platform window framework for making simple applications, could be compiled as one header drop-in only lib. You simply cannot make it one header without making calling ObjC runtime from C. Why it's necessary to make it work as one drop-in header? Well it's a new trend in C libraries, which allows using libraries with the least resistance possible, it's like a package…

For the record, this isn't a new trend - its been fashionable in C for decades to create single-header 'library' drop-ins and is pretty much par for the course ..

Re: OS X app in plain C

#120

Post by userbinator »

As someone who has done a lot of Win32 programming in plain C, I can recognise some common patterns like an event loop and window creation, but it's quite amazing how much extra "cruft" there is just to deal with what appears to be the contortions of OOP'ing everything. All those string constants are rather surprising too. The interesting thing is, the few times I've had to use a Mac the GUI didn't feel quite as responsive as Windows on the same hardware --- it wasn't jerky/stuttering, just what I'd describe as "smooth but sluggish", and the binaries were noticeably larger, and I now wonder if this increased abstraction and complexity has anything to do with it.

For comparison, a similar Win32 app in plain C:

http://www.winprog.org/tutorial/simple_window.html

X Windows app in plain C:

http://www.paulgriffiths.net/program/c/srcs/helloxsrc.html

...and just for fun, the same simple Win32 app from above in Assembly language:

http://win32assembly.programminghorizon.com/tut3.html

Looking at the code again, if I were forced to write an OS X app in plain C, there would be plenty of macro usage around objc_msgSend.

Post reply on HN