One of the most popular libraries for doing such things is gobject. Compared with C++ it also offers much better interop with other languages. For example, gobject-based GTK has decent bindings for lots of languages, but C++-based Qt has only for few (for other languages bindings are incomplete, outdated or QML-only). Also there is Vala for this system, which is more like object syntax preprocessor for C than separate language (AFAIK, Objective C used similar approach in earlier versions).
Indeed. I have extremely ambivalent feelings about GObject, but it’s largely COM done a bit more sanely. The plethora of language bindings testifies to that. My main complaint is that they didn’t literally just build off GNU’s already existing ObjC runtime.
It makes relatively few syntactical additions to C: square brackets to denote method invocations, plus a bunch of keywords and some literal syntax all prefixed by @. It’s quite dynamic; the runtime API is quite powerful. It’s also a superset of C in a way C++ isn’t; any valid C source is valid Objective-C source as well, and any C API is trivially accessible from an Objective-C program.
However, it’s got some issues that have probably stood in the way of wider adoption. At this point it’s quite firmly tied in many developers’ minds to Apple’s Cocoa ecosystem and macOS/iOS application development, even though OpenStep/GNUstep exist. Its dynamism is both a blessing and a curse: for example, method swizzling (changing out the implementation of a method at runtime) can easily be misused, and the same message-sending mechanism used to invoke methods (which enables much of this dynamism) is somewhat slower than vtable-based dynamic dispatch (although not by all that much). Its abstractions aren’t zero-cost: there’s no easy way to opt your classes out of support for reflection or reference counting. Finally, although the popular Objective-C mantra is “use classes when performance doesn’t matter, C when it does”, converting code dependent upon Objective-C objects/classes/protocols to use C static dispatch instead is non-trivial.
Anyways, I wish more people would give it a try for things other than Apple platform app development (since it really does have quite a bit to offer, especially in its most modern incarnation), but at this point that seems unlikely.
Yes and even on OSX it’s becoming less relevant for a lot of new developers and existing use cases as a result of Swift (which I’m rather fond of truth be told).
I recall being very excited about Objective C when I first heard about it, after Apple had eaten NeXT but before OSX had actually been released. I was particularly excited when I heard that early versions were literally a preprocessor/macro language on top of C (and that unlike C++, which started out the same way, modern ObjC still could be used that way).
Unfortunately, actually reading the OpenStep specs for the ObjC standard library, it looked pretty dissapointing – particularly with regard to strings, which seemed to be thin wrappers over normal null-terminated C strings. (It was more than ten years ago that I last even glanced at Objective C, and I was looking at NeXTSTeP-era specs, so you’ll have to forgive me if I mischaracterize the current state of the art.)
I recall reading something about Objective C’s message passing working transparently over a LAN to machines with different architecture, and some kind of multiarch binary format being experimented with, back at NeXT or maybe even before NeXT took over primary development on ObjC. However, I haven’t been able to confirm it! Maybe somebody here remembers the feature & can tell me why nobody uses it / it’s forgotten / gone (or that I’m confusing it with some feature of Smalltalk or something).
I think you’re thinking of Distributed Objects. I can’t find Apple’s documentation on it anymore, but Mike Ash wrote a pretty comprehensive blog post about it which might be of interest.
Yeah, I’m pretty sure this is what I was thinking of. Thanks!
If I was trying to solve the problem mentioned in the post, I would probably have a remote-host-to-local pointer map with holes, and page stuff in and out of the network. It’d be slow in extreme cases, but it wouldn’t require the app developer to care. (Of course, every host would need information about which other hosts had copies, so they could be marked stale on write. And you’d have to override pointer ops with a heavier-weight piece of managed-pointer code. Too slow for 1993, but probably fine on a modern mac.)
I recall reading something about Objective C’s message passing working transparently over a LAN to machines with different architecture, and some kind of multiarch binary format being experimented with, back at NeXT or maybe even before NeXT took over primary development on ObjC. However, I haven’t been able to confirm it!
This brings to mind the meme of ‘software agents running at arbitrary locations on the network” that was popular in the 90’s that also begat java rmi and related c++ stuff from sun. None of that ever played out in practice (see: java applets). But some think there could be a resurgence with webassembly.
It’s surprising to me that it never played out, and it’s surprising to me that applets and similar client-server stuff was considered part of it.
I would expect that distributed computation via message-passing in a heterogenous network would be seen as obviously desirable, even by suits. But, I obviously have a really poor mental model of suits!
I knew a couple people in the 90s who thought C++ was a mess and did things similar to this using C. Not these actual things but were trying to accomplish the same general goals.
One even turned up in the Duqu malware. That article also answers the question the OP article opened with:
“Having spoken to some of the people who prefer such techniques, they gave two main reasons for it:
They don’t trust C++ compilers; these are usually people who started programming in the old days, when assembler was the top choice. C was a direct evolutionary step over assembler and quickly became a standard. When C++ was published, many old school programmers preferred to stay away from it because of distrust in memory allocation and other obscure language features which cause indirect execution of code (for instance, constructors).
Extreme portability. Once again, in the old days (10-12 years ago) C++ was not entirely standardized and it was possible to have C++ code that would compile with MSVC but would not compile with (say) Watcom C++. If you wanted to go for extreme portability and target every existing platform out there, you’d go with C.
Both reasons appear indicate the code was written by a team of experienced, “old-school” developers.”
I remember making a procedure that dynamically generated functions with “bound” this pointer. It worked by allocating a trampoline and writing the object’s address. It was horrible.
One of the most popular libraries for doing such things is gobject. Compared with C++ it also offers much better interop with other languages. For example, gobject-based GTK has decent bindings for lots of languages, but C++-based Qt has only for few (for other languages bindings are incomplete, outdated or QML-only). Also there is Vala for this system, which is more like object syntax preprocessor for C than separate language (AFAIK, Objective C used similar approach in earlier versions).
Indeed. I have extremely ambivalent feelings about GObject, but it’s largely COM done a bit more sanely. The plethora of language bindings testifies to that. My main complaint is that they didn’t literally just build off GNU’s already existing ObjC runtime.
I got reminded of this book from the 90s: Object Oriented Programming with ANSI C (link is PDF)
I was thinking about it few minutes ago, reading this wonderful response about Rust.
How does Objective C figure in? I’d already heard that lauded as OO C done “right”.
Objective-C is pretty great.
It makes relatively few syntactical additions to C: square brackets to denote method invocations, plus a bunch of keywords and some literal syntax all prefixed by
@. It’s quite dynamic; the runtime API is quite powerful. It’s also a superset of C in a way C++ isn’t; any valid C source is valid Objective-C source as well, and any C API is trivially accessible from an Objective-C program.However, it’s got some issues that have probably stood in the way of wider adoption. At this point it’s quite firmly tied in many developers’ minds to Apple’s Cocoa ecosystem and macOS/iOS application development, even though OpenStep/GNUstep exist. Its dynamism is both a blessing and a curse: for example, method swizzling (changing out the implementation of a method at runtime) can easily be misused, and the same message-sending mechanism used to invoke methods (which enables much of this dynamism) is somewhat slower than vtable-based dynamic dispatch (although not by all that much). Its abstractions aren’t zero-cost: there’s no easy way to opt your classes out of support for reflection or reference counting. Finally, although the popular Objective-C mantra is “use classes when performance doesn’t matter, C when it does”, converting code dependent upon Objective-C objects/classes/protocols to use C static dispatch instead is non-trivial.
Anyways, I wish more people would give it a try for things other than Apple platform app development (since it really does have quite a bit to offer, especially in its most modern incarnation), but at this point that seems unlikely.
Yes and even on OSX it’s becoming less relevant for a lot of new developers and existing use cases as a result of Swift (which I’m rather fond of truth be told).
I recall being very excited about Objective C when I first heard about it, after Apple had eaten NeXT but before OSX had actually been released. I was particularly excited when I heard that early versions were literally a preprocessor/macro language on top of C (and that unlike C++, which started out the same way, modern ObjC still could be used that way).
Unfortunately, actually reading the OpenStep specs for the ObjC standard library, it looked pretty dissapointing – particularly with regard to strings, which seemed to be thin wrappers over normal null-terminated C strings. (It was more than ten years ago that I last even glanced at Objective C, and I was looking at NeXTSTeP-era specs, so you’ll have to forgive me if I mischaracterize the current state of the art.)
I recall reading something about Objective C’s message passing working transparently over a LAN to machines with different architecture, and some kind of multiarch binary format being experimented with, back at NeXT or maybe even before NeXT took over primary development on ObjC. However, I haven’t been able to confirm it! Maybe somebody here remembers the feature & can tell me why nobody uses it / it’s forgotten / gone (or that I’m confusing it with some feature of Smalltalk or something).
I think you’re thinking of Distributed Objects. I can’t find Apple’s documentation on it anymore, but Mike Ash wrote a pretty comprehensive blog post about it which might be of interest.
Yeah, I’m pretty sure this is what I was thinking of. Thanks!
If I was trying to solve the problem mentioned in the post, I would probably have a remote-host-to-local pointer map with holes, and page stuff in and out of the network. It’d be slow in extreme cases, but it wouldn’t require the app developer to care. (Of course, every host would need information about which other hosts had copies, so they could be marked stale on write. And you’d have to override pointer ops with a heavier-weight piece of managed-pointer code. Too slow for 1993, but probably fine on a modern mac.)
This brings to mind the meme of ‘software agents running at arbitrary locations on the network” that was popular in the 90’s that also begat java rmi and related c++ stuff from sun. None of that ever played out in practice (see: java applets). But some think there could be a resurgence with webassembly.
It’s surprising to me that it never played out, and it’s surprising to me that applets and similar client-server stuff was considered part of it.
I would expect that distributed computation via message-passing in a heterogenous network would be seen as obviously desirable, even by suits. But, I obviously have a really poor mental model of suits!
I knew a couple people in the 90s who thought C++ was a mess and did things similar to this using C. Not these actual things but were trying to accomplish the same general goals.
One even turned up in the Duqu malware. That article also answers the question the OP article opened with:
“Having spoken to some of the people who prefer such techniques, they gave two main reasons for it:
They don’t trust C++ compilers; these are usually people who started programming in the old days, when assembler was the top choice. C was a direct evolutionary step over assembler and quickly became a standard. When C++ was published, many old school programmers preferred to stay away from it because of distrust in memory allocation and other obscure language features which cause indirect execution of code (for instance, constructors).
Extreme portability. Once again, in the old days (10-12 years ago) C++ was not entirely standardized and it was possible to have C++ code that would compile with MSVC but would not compile with (say) Watcom C++. If you wanted to go for extreme portability and target every existing platform out there, you’d go with C.
Both reasons appear indicate the code was written by a team of experienced, “old-school” developers.”
I remember making a procedure that dynamically generated functions with “bound” this pointer. It worked by allocating a trampoline and writing the object’s address. It was horrible.
[Comment from banned user removed]