OS X app in plain C • Hacker News Board

Re: OS X app in plain C

#81

Post by dmytroi » Thu, May 05, 2016, 9:12 PM UTC

sdegutis wrote: post #75

My interest in this comes from wanting to build Objective-C based OSX-UIs using scripting languages that are only embeddable in C, like Lua. When (if?) that day comes, I'll be like a kid in a candy store all over again.

I would recommend you to try CodeFlow from celedev [1], it's a dynamically generated Lua binding to Objective-C. Plus a nice editor with hot reloading support and other cool features.

- [1] https://www.celedev.com/en/codeflow/

Re: OS X app in plain C

#82

Post by dmytroi » Thu, May 05, 2016, 9:19 PM UTC

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 manager but nicer - you only have one file! Great example of modern one header libs is probably the famous stb package [2].

- [1] https://bitbucket.org/rmitton/tigr/src

- [2] https://github.com/nothings/stb

Re: OS X app in plain C

#83

Post by btrask » Thu, May 05, 2016, 9:21 PM UTC

geofft wrote: post #72

msbarnett wrote: post #59

Earlier quoted context omitted.

> That seems slightly pedantic. While it's true that there's no cross-platform C ABI, most platforms have a C ABI, and it's well-defined (and defined in terms of C data types) on that platform. Every platform has an ABI, obviously, and yes it's generally formed in view of C. This doesn't change the fact that the phrase "The C ABI" is, in a vacuum, meaningless and that "The C ABI on Platform X" is just a convoluted, c…

But what an ABI does is specify a binding between language-level concepts and binary representations. That's why mentioning the language matters. If "Platform X's ABI" says that structs are passed on the stack, or ints are a certain size, or pointers have a certain alignment, or whatever, it (usually) means that C structures are passed on the C stack, C ints are a certain size, C pointers have a certain alignment, et…

C is merely flexible, not in some position of authority where it dictates what platforms must do. C would be ABI-compatible on a platform that wasn't designed for it, too (which, historically, was the case on many platforms it was ported to).

Re: OS X app in plain C

#84

Post by chillingeffect » Thu, May 05, 2016, 9:27 PM UTC

austinz wrote: post #79

jimjimjim wrote: post #66

Earlier quoted context omitted.

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

VHDL vs Verilog flame wars everywhere. Also, discussions on people's favorite idiosyncratic, vendor-specific dialect of C for embedded devices.

Gah, this. Also noobs who want to "replace their 2,000 device-per-year microcontroller application with an FPGA so that it can someday be put onto a ASIC." They're basically vinyl hipsters who fancy themselves "EE/chip designerz" and want to immortalize themselves.

Re: OS X app in plain C

#85

Post by btrask » Thu, May 05, 2016, 9:28 PM UTC

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…

I haven't looked at tigr yet (it seems interesting!) but could you just use '#ifdef __OBJC__'?

Re: OS X app in plain C

#86

Post by bluedino » Thu, May 05, 2016, 9:34 PM UTC

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…

>> I guess it would be easier to write a Objective-C to C converter

That's what the first Obj-C (and C++ compilers) were

Re: OS X app in plain C

#87

Post by pps43 » Thu, May 05, 2016, 9:36 PM UTC

That's a lot of boiler plate code. Is there a way to make it smaller? For example, if all I need is to open and process a file with no GUI (maybe a progress bar).

Re: OS X app in plain C

#88

Post by dmytroi » Thu, May 05, 2016, 9:36 PM UTC

btrask wrote: post #85

dmytroi wrote: post #82

Earlier quoted context omitted.

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…

I haven't looked at tigr yet (it seems interesting!) but could you just use '#ifdef __OBJC__'?

Not really, because everything is C/C++ there by means files are .c, .cpp and not .m or .mm, its a bit tricky from build system point of view to treat the file with extension .c/.cpp as Objective-C.

Re: OS X app in plain C

#89

Post by btrask » Thu, May 05, 2016, 9:50 PM UTC

dmytroi wrote: post #88

btrask wrote: post #85

Earlier quoted context omitted.

I haven't looked at tigr yet (it seems interesting!) but could you just use '#ifdef __OBJC__'?

Not really, because everything is C/C++ there by means files are .c, .cpp and not .m or .mm, its a bit tricky from build system point of view to treat the file with extension .c/.cpp as Objective-C.

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

Re: OS X app in plain C

#90

Post by dmytroi » Thu, May 05, 2016, 9:58 PM UTC

btrask wrote: post #89

dmytroi wrote: post #88

Earlier quoted context omitted.

Not really, because everything is C/C++ there by means files are .c, .cpp and not .m or .mm, its a bit tricky from build system point of view to treat the file with extension .c/.cpp as Objective-C.

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.