lkml.org 
[lkml]   [1999]   [Jan]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: C++ in kernel (was Re: exception in a device driver)
In <369995B2.7408BAB7@gte.net> Benjamin Scherrey (scherrey@gte.net) wrote:
> No No No No!!! See my previous message regarding your example. When you understand
> a few OO concepts and know how C++ as a language enforces them (not necessarily how
> the compiler implements them) then you know everything you need to understand how
> the language will treat your code.

Are you joking ? Even two constructs like
A. someclass var(1);
B. someclass var=1;
are NOT equal ! And there it's possible to write program where first construct
will be Ok while second will be considered as error (sample below) ! Or more
obscure sample (if sample above is not obscure enough :-):

-- cut --
struct A {
int a;
virtual fooa() {}
};

struct B {
int b;
virtual foob() {}
};

class C: public A, public B {
};

A *a;
B *b;
C *c;
-- cut --

What call is more effective: c->fooa(); or c->foob(); ? Or which assignment
is faster: a=c or b=c ? This is depends from compiler of course ! In case of
egcs 1.1.1 c->fooa(); and a=c is more effective ... C++ is FULL of such obscure
things :-(( And thus non-acceptable for ANY project if speed and reliability
matters.

> Alan Cox wrote:

>> > to prevent the self pointer from being passed, make it a non-member function
>> > or make it a static member function, and stop complaining...or depending
>> > on what foofunc is notionally supposed to do, leave it non-static so the
>> > A writers of child classes don't have to fix it for you.
>>
>> So to write optimal C++ I have to know at least as much as the internal
>> structure of the code than for C.

> Naturally, the closer you get to the metal the more you need to know what the
> compiler you're using is doing. This is the case for *any* language.

Yes. Of course. But C is small and very simple language while C++ is HUGE
complex monster :-(( And thus it's not so problematic to understood what
C compiler doing (especially without -O :-) and almost impossible to understood
the same about C++ ...

> However, C++ has some language features that let you specify optimal code
> constructs that would otherwise have to be hard-coded in C. The fact is that
> you don't need to know any more than you would with C and some times less.

You'll need to know HUNDREDS of C++ quicks instead ...

>> Thats the point I was trying to get across
>> C++ is less efficient because the compiler cannot perform some optimisations it
>> can in C without help from the code writer.

> This is 100% false. C++ is a superset of C. Any valid ANSI C code (with a very few
> well-specified specified exceptions) is by definition valid C++ code. Any "help" a
> coder can provide in C can be provided in C++. Indeed, C++ has the asm keyword
> which lets you get just about as efficient as it can get.

If you'll use C++ as C then may be (not sure). But if you'll use objects you
are tied to VERY LIMITED C++ object model.

>> Its exactly those kind of things that make C++ uninteresting for serious
>> performance sensitive and large projects. Poor language design - not poor
>> concepts - Linux is object oriented - but in C for example.

> I don't know how you can possibly make this claim given the previous related
> experiences and examples of C++ being used in just the kind of projects you
> describe. C++ was designed specifically for large projects that C couldn't handle
> well and without paying any language-imposed performance penalties. Since the
> language has some advanced constructs built in that must be hard coded in a
> C-equivalent program, the compiler has the opportunity to provide some performance
> benefits without the hassle of the code-base overhead.

Of course not ! Compiler is limited by object model and poor design. If you'll
use C++ as "C with classes" (it was initial name AFAIK :-) not as C that is...

> Now... I've seen a couple of people claim that Linux is object oriented. I would
> really like to know how the people using this term define "Object Oriented" and
> some examples of how Linux qualifies as such. Since the C language doesn't enforce
> these constructs then haven't we increased the complexity of the kernel for an
> unknown benefit?

We DECREASE complexity of kernel by using VERY SIMPLE language where are NO
automagic contructors, destructors, etc. Object model is created by hand and
as such not suffer from language limitations... Take a look on structures full
of pointers to functions -- this is exactly C++-style objects created by hand.
But we could do quite a lot of tricks with such objects not imaginable in C++...

> If this benefit wasn't unknown then please fill me in on what it
> was believed to be and whether or not you believe its been achieved.

Ok. Just a short example.

-- 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 is shoter, yes, but test() in C++ code will generate something like
-- cut --
movl 4(%esp),%eax
movl 4(%eax),%edx
pushl %eax
movl 8(%edx),%eax
call *%eax
addl $4,%esp
ret
-- cut --
while C code will generate
-- cut --
movl 4(%esp),%eax
pushl %eax
movl 4(%eax),%edx
call *%edx
addl $4,%esp
ret
-- cut --
One additional inevitable memory reference :-)

And more: uncomment few lines, commented in C sample above and you'll see
that C++ object model is even more limited :-))

Yes, I know that if there are will be a lot of functions in C version of
someclass then you'll got very big structure while size of C++ version
will not change. Big deal :-) Add table (just like C++ compiler does :-)
and be happy. But in C++ you COULD NOT remove this additional memory
reference even for simplest classes ! And you could not change nature of
your class in run-time -- it's hardcoded in compile-time.

> Finally, if it has, please tell me why we wouldn't want to re-implement
> these design constructs in a language that supports and enforces them to
> further reduce the complexity of the kernel design?

Please reimplement full (with uncommented lines) C example in C++ classes
without loss of effectiveness :-))) This is not Linux kernel. This is just
short example.

> I'm tired of the attacks on C++ that come from people who obviously don't have an
> understanding of the design of the language or how it applies to large
> high-performance projects. As far as I'm concerned its not an issue of ASM vs. C
> vs. C++ vs. Java vs. Logo! In a previous message in this thread I bring up several
> issues regarding the future of the Linux kernel. I proposed C++ support as a
> potential solution to these issues. No one has bothered to address these issues at
> all, much less confirm or deny that they shared these concerns. Rather, all I've
> seen are attacks on C++ that are simply baseless. Certainly there are some features
> in C++ that aren't appropriate for the Linux kernel - the solution is DON'T USE
> THEM!

Not use classes ? Why in this case use C++ at all ? Just for templates and
for exceptions ? Hm. May be. I'm not sure if this is very wise idea though.

> You don't pay for what you don't use. On the other hand, there are many
> benefits of the C++ language. We may ignore the concerns that these benefits
> address but, rest assured, they will not ignore us.

C++ is just big non-shapen heap of different things, not clear language like
Ada or even Java. Some concepts there are usefull, some not. But it's total
mess as whole.

> Linux is going to grow beyond what the current select group of very talented yet
> temporally limited (i.e. not enough time) developers will be able to manage. Adding
> features will become a tremendous effort just in terms of predicting its impact on
> the rest of the system much less attempting to implement them.

And this is exactly where C++ is not big help. Since most problems in kernel
are some race conditions and obscure deadlocks not just size of codebase.

> This isn't going to happen overnight but just think back at how much the
> system has changed since 1994 (when I first started using it). If the
> solution to push back this inevitability is not to move to a language that
> was designed to address these issues then please tell me what it is!

C at least has one advantage: it's simple language very close to hardware
(and assembler :-) C++ language has poor object model, A LOT OF quicks and
REALLY BAD support for modular programming (all this "include files" stuff
is pure shame for modern language). Why use this monster ?

P.S. Ah, almost forgot about my example with var(1); and var=1; ...
Just
-- cut --
struct someclass {
explicit someclass(int) {}
};
-- cut --
will be enough, but if you need more obscure sample here it is:
-- cut --
struct someclass {
someclass(int) {}
private:
someclass(someclass&);
};
-- cut --




-
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/

\
 
 \ /
  Last update: 2005-03-22 13:49    [W:0.125 / U:0.008 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site