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

61–70 of 157 posts

Re: OS X app in plain C

#61

Post by justsaysmthng »

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"];

then I guess it would be easier to write a Objective-C to C converter (if there isn't one already) and convert your Objective-C app into C for added coolness. I

Re: OS X app in plain C

#62

Post by mintplant »

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…

Haskell has support for inline C [1] and inline Objective-C [2] implemented as libraries.

[1] https://github.com/fpco/inline-c/blob/master/README.md

[2] https://hackage.haskell.org/package/language-c-inline

Re: OS X app in plain C

#63

Post by poizan42 »

conradev wrote: post #56
dep_b wrote: post #41

Earlier quoted context omitted.

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.

> 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. The same goes for C++ or Swift. Getting the function pointer for a method can be involved, but all functions adhere to the C ABI.

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.

Re: OS X app in plain C

#64

Post by mikeash »

btrask wrote: post #49
mikeash wrote: post #39

Earlier quoted context omitted.

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

I agree that unnecessary casts are undesirable, but that seems like a completely irrelevant point here, seeing as how the casts are not optional.

C++ doesn't prefer casts, it requires them in places where C doesn't. Casting the return value from malloc isn't optional in C++ (unless you're assigning to a void *, anyway).

Re: OS X app in plain C

#65

Post by joewillsher »

dmytroi wrote: post #38
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…

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/libr…

Yeah, I still wouldn’t say that c++ is “one of the most widely-used languages for writing native apps” for OS X.

And internally apple use other languages a lot, but frameworks like UIKit, AppKit, and many of the other public frameworks they expose in the SDK are objc, with foundation for example abstracting a lot of CoreFoundation C code.

Re: OS X app in plain C

#66

Post by jimjimjim »

chillingeffect wrote: post #36
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.

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…

agree.

If this was an enterprise/cio/it/gov discussion web site then all the conversations would be java and .net vs c++

if this was a scientific computing website then python, c/c++ and fortran and would be mentioned etc.

if this was a hardware/firmware website it would be c vs (whatever black magic is used by hardware wizards).

Re: OS X app in plain C

#68

Post by blt »

derefr wrote: post #55
msbarnett wrote: post #23

Earlier quoted context omitted.

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…

To put it another way: C doesn't have an ABI; C has an API (or a wire protocol, if you prefer.) The abstraction layer of C doesn't exist between the machine-architecture and the C compiler; rather, the abstraction layer of C exists between the C compiler and the user, and takes the form of uncompiled C source code. The design of C is predicated on an approach to portability that involves shipping source code , not bi…

Check out the architecture of TempleOS.

Re: OS X app in plain C

#69

Post by deanCommie »

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…

Seriously, I don't know who's downvoting you. This needs a huge "for academic purposes only disclaimer". Higher level abstractions exist for a reason.
Post reply on HN