Re: C++ in kernel (was Re: exception in a device driver)

Khimenko Victor (khim@sch57.msk.ru)
Wed, 13 Jan 1999 09:21:22 +0300 (MSK)


In <016d01be3eb3$fb4abd40$04c809c0@Fake.Domain.com> Anthony Barbachan (barbacha@Hinako.AMBusiness.com) wrote:

>>In <003101be3db0$d4d945e0$04c809c0@Fake.Domain.com> Anthony Barbachan
AB> (barbacha@Hinako.AMBusiness.com) wrote:
>>
>>>>In <00e101be3d21$96b03ce0$04c809c0@Fake.Domain.com> Anthony Barbachan
>>AB> (barbacha@Hinako.AMBusiness.com) wrote:
>>>>
>>>>> There is a huge difference in the feel of using classes over structures
>>AB> and
>>>>> their loosely associated functions.
>>>>
>>>>And since C++ does not have real classes (they are only tricks of
AB> compiler
>>AB> and
>>>>not exists in compiled program) and still lead to speed loss why use it
AB> at
>>AB> all ?
>>>>
>>
>>AB> 1 - It does not lead to speed loss.
>>
>>It does. Take a look:

AB> Nobody is going to use the iostream library in the kernel. That is a C++
AB> library issue not an issue witht the basic language, which is what would be
AB> used in any C++ kernel. And that library is slower for a reason, it was
AB> made for easy integration with other people's modifications of the class.
AB> Basically its structure allows for easy implementation of other classes that
AB> can share the same interfaces as the standard streams.

I know all this. Yes, iostream is has some benefits over stdio. I know. But
iostream is not point of this sample. Function test() is.

>>-- C++ code --
>>#include <iostream>
>>
>>class someclass {
>> int i;
>>public:
>> explicit someclass(int _i) : i(_i) {}
>> virtual foo() {
>> std::cout << i << endl;
>> }
>>};
>>
>>void test(someclass& x) {
>> x.foo();
>>}
>>
>>void main (void) {
>> someclass a(1);
>> test(a);
>>}
>>-- C code --
>>#include <stdio.h>
>>
>>struct someclass {
>> int i;
>> int (*foo)(struct someclass*);
>>};
>>
>>int someclass_deffoo(struct someclass* x) {
>> printf("%d\n",x->i);
>>}
>>
>>/*
>> * int someclass_otherfoo(struct someclass* x) {
>> * printf("%d\n",x->i<<1);
>> * }
>> */
>>
>>void test(struct someclass* x) {
>> x->foo(x);
>>}
>>
>>int main (void) {
>> struct someclass a={1,someclass_deffoo};
>> test(&a);
>>/*
>> * a.foo=someclass_otherfoo;
>> * test(&a);
>> */
>> return 0;
>>}
>>-- cut --
>>
>>C++ code has one additional INEVITABLE memory reference. Not much, perhaps
AB> but
>>still this shows that main idea: in C coult realize far more flexible
AB> object
>>model then built-in object model of C++ (note commented lines of C sample
AB> :-)
>>

AB> This memory reference is not one additional because it is passed for a
AB> reason. It is C++'s implementation of passing a structure's address. At
AB> its basic level this is what the passing of "this" does. If the data's
AB> address is not needed to be know for the function to work it can be declared
AB> as static; in which case "this" is not passed.

Gosh. TAKE A LOOK IN SAMPLE. PLEASE. BEFORE writing answer. In C++ sample
function ALSO has reference on object. Still:
-- C++ test() --
movl 4(%esp),%eax
movl 4(%eax),%edx
pushl %eax
movl 8(%edx),%eax <-- this is additional instruction
call *%eax
addl $4,%esp
ret
-- C test() --
movl 4(%esp),%eax
pushl %eax
movl 4(%eax),%edx
call *%edx
addl $4,%esp
ret
-- cut --
I KNOW WHY C++ is designed this way: " if you'll have a lot of virtual
functions and ...". Ok. But what if I'm not have a lot of virtual functions
and want speed instead ? I'm stuck -- there are only one object model and
it could not be changed ... And you could change class in runtime (commented
out code in C sample)... That was the point of my first letter :-)) Looks
like it was not understood by many readers :-((

>>AB> 2 - Your statement about no real classes is baseless at best. The same
>>AB> could be said about any language or even a C structure. Only an
AB> interpited
>>AB> or partially interpited language could have "real" classes by your
AB> apparent
>>AB> definition.
>>
>>Not at all. Take Java. Replace bytecode with real native code and all is
AB> done :-)

AB> This is basically what the C++ compiler does. A Java JIC is a compiler too.

Not at all. Take some C++ class. Make .o file. Take drived class. Make .o file.
Add in first class few fields and recompile ONLY first class. Link program
and try to start it. Good luck. With Java this all will work just fine :-)
BTW if you have .class file you could SCAN AND FIND all functions -- not so
with .o file. BTW this does not mean that we need real classes in kernel :-))
But nature of C++ when even slighest change in some basic class lead to full
recompilation is REALLY annoying for big projects :-(( So my basic point
reamains the same: C++ is total crap NOT USEFULL FOR ANYTHING. It's like
cake with salt fish -- both cake and salt fish and good things but when combined
together it's something horrible :-(( There are a lot of good concepts but the
end result is useless language. When you need speed you could not get it (see
sample C++ vs C above) and when you need something for big projects you could
not use it either due lack of modularity (include files is just plain shame
for modern language). And when there are exceptions in language but they are
not used in standard library (STL, iostream) it's also not good for that
language... It's really bad for perl if it's really being rewritten on this
monster :-(((

>>Just to use well-know language for samples. AFAIK latest versions of Oberon
>>also include support for real classes... Where you could change base class
AB> and
>>got derived class with changed behaviour without recompilation...

AB> Oberon was interpited last I heard. And if it compiles the same applies to
AB> it. Of course it may be psuedo-compiling; basically just linking a runtime
AB> with the executable. Like Clipper does. Hey I can do that with Clipper
AB> too.

Oberon use two-stage compilation. Last stage is performed by loader. But in the
end it's true compiled code (not pseudo-code!) loaded in memory.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/