Some may make an argument that kernel things like VM or VFS are "object oriented".
It's possible: one particular interrupt could serve one particular device, there are multiple devices in the system (each using one object), and the ISR is then a method of a particular device.
In the late 1980s, there was a really nice guy from Stanford's SLAC accelerator control group who wrote a little text book: "Object oriented programming in C". And no, he didn't mean C++, he meant C. It's doable. The resulting code tends to look a bit verbose and scattered, but once you learn the idiom, it's pretty obvious. It relies on lots of calling via function pointers; and if you want virtual functions in the inheritance graph, you either put function pointers into your struct, or each struct has a pointer to another per-class struct that holds the function pointers (equivalent to the vtable).
absolutely...I've always strived to use an opaque pointer handle to an object with a well defined API when I wrote SO libraries. In fact, my embedded code frequetnly uses OO idioms so that it makes sense to me (if it reaches a certain degree of complexity)...However, I still prefer writing classes in C++. Well, other than an application God class...I've never had use for such things, although some OO guys are in love with the bloody things.
class Counter
@x : Int32
def initialize(x : Int32)
@x=x
end
def setx(x : Int32)
@x=x
end
def getx : Int32
@x
end
def add1
@x=@x+1
end
end
c : Counter=Counter.new(3)
c.setx(5)
c.add1
puts c.getxAgree it's not hard. But if one is providing a shared library you need to think about it before you get complaints.
Maturin posted the link to the pdf in post #40 here.
Same topic, different book. I haven't found the one I remember yet; it was quite a few years earlier than the one Maturin linked to.
You don't need to link it, but it was nice if you could remember at least title, and author.
There's also a quote "Object orientation is in the mind of the programmer, not in the compiler" or something like that. I think it was Alan Cox, but I can't find a reference and am not sure.
This is unfortunately a bit true. It seems like the standards committee is hell bent on pythonizing c++ sometimes. One of the best arguments I've ever read against using c++ in commercial development came from a forum years ago and I did a screen capture but doubt I could find it at 1:30AM after drinking beer.
Note that Simula67, a superset of Algol60, came out 6 years before Smalltalk (designed in 1965). It introduced pretty much everything OO: objects, classes, subclasses, virtual procedure, inheritance, dynamic lookup etc. It even had coroutines! It was the first OO language and influenced pretty much every other OO language.
So that to me is Alan Kay's central idea: each of his objects is simulating a little special purpose computer! These little computers communicate via messages is why he says "messaging" is the big idea. Though note that Simula 67 was already providing this but most every other OO language missed the boat by not providing coroutines to simulate independent objects. [Of course, concurrency brings in its own set of problems but simula 67, Smalltalk avoided them as coroutines are easier to reason about.]
I guess that's why the language he and others created was named smalltalk.
I have spent about half hour searching. And I can't find it. I know the following tidbits: It is about OO in C (not C++!). It was published in the late 80s; when I started by job at SLAC (in November 91), it was already in print. The author worked at SLAC, in the accelerator controls department, on the SPEAR accelerator. I think the author's first name is Chuck or Charles, but I'm not 100% sure. I think I have a copy of the book ... alas, there are about 20 cardboard boxes of older books in the basement, and searching through all of them would take me a day. Those boxes are supposed to be 100% cataloged, but I can't find anything resembling the book in my catalog.
Sadly, definitely not. Wrong CV, wrong side of the continent. Interesting guy though.
Thank you very much!
