121–130 of 157 posts
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.
Even Word and Excel were still C (although Office shared much C++ code in a common DLL)
Gotta love legacy code from the 1980s/1990s.
I'm sure the Windows version would be just as bad. Most of the useful parts of the Windows API don't have a C interface, so you have to use COM, which essentially means editing vtable-like structures by hand. https://en.wikipedia.org/wiki/Component_Object_Model
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 resp…
Personally, I'd blame UI latency more on a deeper composition stack and rendering sophistication rather than object orientation. Unless you're using late bound method calls for pixel-level drawing primitives, they shouldn't be a significant percentage of the event dispatch loop that turns input into visual results.
I'm sure the Windows version would be just as bad. Most of the useful parts of the Windows API don't have a C interface, so you have to use COM, which essentially means editing vtable-like structures by hand. https://en.wikipedia.org/wiki/Component_Object_Model
I have also used COM from C, and while it's not as pleasant as the pure Win32 API, it doesn't involve the massive amounts of function pointer casting shown here. vtables are involved but they can be defined as C structures, whereas this example seems to show objc_msgSend() returning a very large number of different possible function pointer types.
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…
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.
What C ABI? Can you point me to the spec?
Earlier quoted context omitted.
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!
Also it's Gott im Himmel ;-) (unless it's a reference I didn't get)
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 resp…
> If I were forced to write an OS X app in plain C, there would be plenty of macro usage around objc_msgSend
You will have re-invented the early versions of Objective C which were all done in the preprocessor :)
Earlier quoted context omitted.
C was not designed to create gui's. So its a feat of accomplishment as opening a bottle with your teeth.
Windows, X11 and Gtk would argue with you.