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

101–110 of 157 posts

Re: OS X app in plain C

#101

Post by jheriko »

poizan42 wrote: post #63
conradev wrote: post #56

Earlier quoted context omitted.

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

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

Re: OS X app in plain C

#102

Post by jheriko »

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.

there is no standard in theory... but in practice one exists.

its a subtle difference some devs will pull out when they want to boost their egos by talking about things that sound smart, but they don't realise it requires that special kind of "smart-yet-dumb naivete" to consider worth caring or talking about.

Re: OS X app in plain C

#103

Post by chris_wot »

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.

What C ABI? Can you point me to the spec?

Re: OS X app in plain C

#104

Post by comex »

dmytroi wrote: post #90
btrask wrote: post #89

Earlier quoted context omitted.

A .h file can be compiled as C, C++, or Objective-C. Isn't that how single-file libraries usually work?

Yes, and this .h file will be used from .c/.cpp because looks like it's way to bulky to add additional .m/.mm file just for OSX/iOS case when creating cross platform applications. Check tigr - it's possible to run exactly the same C/C++ code on Windows and OSX without any changes at all.

Since Objective-C is a true superset of C (unlike C++) and there's also Objective-C++, you can just tell the compiler to compile all .c/.cpp as if they were .m/.mm. That is, if you can figure out how to coax your build system to pass the right flags.

Re: OS X app in plain C

#105

Post by chris_wot »

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…

What, like C as a shell script? Gott in Himmel!

Re: OS X app in plain C

#106

Post by leonatan »

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…

I believe this is already the default for new projects.

Re: OS X app in plain C

#107

Post by astrange »

jheriko wrote: post #100
conradev wrote: post #20

Earlier quoted context omitted.

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

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.

Re: OS X app in plain C

#109

Post by poizan42 »

vardump wrote: post #94
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.

Sure you can. Just write an asm stub to call, that sets up ecx and other things right.

The claim was: 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.

This is clearly false since at least one C++ compiler generates functions that does not adhere to any of the common calling conventions for C on that platform (or "C ABIs" if you will).

Besides that, I said you could not call them from C. An asm stub is not C. Neither is inline assembly even though it's a common extension to C.

Re: OS X app in plain C

#110

Post by pixelglow »

msbarnett wrote: post #78
valarauca1 wrote: post #45

Earlier quoted context omitted.

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

> Objective-C was a modification of the GCC developed by NeXT. No. Objective-C was developed in the early '80s (as a C pre-processor, as the Grandparent post said) by Brad Cox, and commercialized by himself and Tom Love via a company they created together called Stepstone. Cox wrote a book about their product, Object Oriented Programming: An Evolutionary Approach, in 1986. I own a copy. It's pretty good! Some time la…

I have the book too. It's interesting as a history lesson and initial motivations for Objective-C.

In particular, in the beginning Objective-C was a lot looser typed at compile time than it is now: no NSString* or NSWindow*, it was all just id. It was an attempt to make C look like Smalltalk.

The language eventually evolved more toward the static-typed end of the spectrum, culminating in support for lightweight generics and ostensibly birthing Swift along the way.

Post reply on HN