Object Oriented Programming really an Advantage

[cracauer@]

Well, you can argue that both hardware drivers and filesystems in operating system kernels are very object-oriented, including inheritance.

They just don't use an OO language. Except on macOS.

 

[mer]

Well, you can argue that both hardware drivers and filesystems in operating system kernels are very object-oriented, including inheritance.

They just don't use an OO language. Except on macOS.

Some may make an argument that kernel things like VM or VFS are "object oriented".
I'm not making that argument, but I've seen others do so.

 

[ralphbsz]

writing an interrupt driver in OO doesn't make sense,

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.

I did that in VxWorks once, several decades ago. The compiler magic required for taking a C++ member function of an object and casting it to math the prototype for an ISR (which is probably void ()(void*) or something bland like that) required half a day of figuring out, and a screen full of comments to explain. Kind of tricky to cast the "this" pointer of an object that exists silently in each member function to be explicitly visible on C. Worked extremely well, and was ludicrously fast. For a little while, our prototype system (which used multiple VME backplanes with a dozen Motorola mVME1xx boards and a dozen SCI coherent networked memory boards, from Dolphin Systems) was the fastest TCP/IP stack in the world, and we set some sort of record of the most CORBA transactions per second (half a million). Didn't hurt to have the (Lawrence-) Berkeley group helping with our network drivers.

 

[ralphbsz]

They just don't use an OO language. Except on macOS.

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

Sadly, I can't remember the name of the guy. The book is probably in a cardboard box in the basement, not having been looked at in a few decades. Chuck or Charles Something?

If you look at OO this way, you quickly see that kernels tend to be very very OO. From there, it is only a small leap to use languages that explicitly support OO in the kernel, which can be done; I know some commercial projects that use C++ in the Linux kernel.

EDIT: Mer said the same thing above already, while I was typing.

 

[kent_dorfman766]

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

Sadly, I can't remember the name of the guy. The book is probably in a cardboard box in the basement, not having been looked at in a few decades. Chuck or Charles Something?

If you look at OO this way, you quickly see that kernels tend to be very very OO. From there, it is only a small leap to use languages that explicitly support OO in the kernel, which can be done; I know some commercial projects that use C++ in the Linux kernel.

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.

 

[mer]

If one looks at some of the current frameworks like Qt and GTK (less than v3?) Objects in C.
MacOS/IoS with Objective C? Objects in C done differently than in C++. My opinion once you get past some of the syntactic thing in ObjectiveC, it's not that hard to understand.

 

[mer]

kent_dorfman766 good insight. One "problem" I've run into is "library C++ but someone wants to call it from C" or the converse of "Library in C and caller is C++". Doable, but you need to figure out the interface and compiler/linker options to constrain things.

 

[kent_dorfman766]

kent_dorfman766 good insight. One "problem" I've run into is "library C++ but someone wants to call it from C" or the converse of "Library in C and caller is C++". Doable, but you need to figure out the interface and compiler/linker options to constrain things.

calling C code from a C++ program is the preferrable direction, and it's not hard. just remember to wrap the C func declarations in an extern "C" wrapper so they don't get name mangled. I generally warn people against going the other direction, although it is also possible.

 

[Alain De Vos]

OOP in crystal,

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

 

[mer]

calling C code from a C++ program is the preferrable direction, and it's not hard. just remember to wrap the C func declarations in an extern "C" wrapper so they don't get name mangled. I generally warn people against going the other direction, although it is also possible.

Agree it's not hard. But if one is providing a shared library you need to think about it before you get complaints.

 

[drhowarddrfine]

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

Maturin posted the link to the pdf in post #40 here.

 

[ralphbsz]

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.

 

[Maturin]

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.
I am very much interested in that. ty

 

[Jose]

I ended up with a negative view of OO programming.

C++ of course invests most of the recent development (much of those 1000 pages) into facilities that are not object-oriented.

"I invented the term 'Object-Oriented', and I can tell you I did not have C++ in mind."

- Alan Kay

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.

 

[Maturin]

“I’m sorry that I long ago coined the term ‘objects’ for this topic because it gets many people to focus on the lesser idea. The big idea is ‘messaging’.”
Alan Kay @ Wikipedia

 

[drhowarddrfine]

ralphbsz Dr. Charles Severance, also known as "Dr. Chuck"?