lkml.org 
[lkml]   [2002]   [Apr]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: C++ and the kernel
On Tue, 9 Apr 2002, Dr. David Alan Gilbert wrote:

> * Richard B. Johnson (root@chaos.analogic.com) wrote:
> >
> > I would like to rewrite the kernel in FORTRAN because this was
> > one of the first languages I learned.
> >
> > Seriously, the kernel MUST be written in a procedural language.
> > It is the mechanism by which something is accomplished that defines
> > an operating system kernel.
> >
> > C++ is an object-oriented language, in fact the opposite of a
> > procedural language. It is not suitable.
>
> Bollox!
>
> There are many places in the kernel that are actually very OO - look at
> filesystems for example. The super_operations sturcture is in effect a
> virtual function table.
>

The file operations structure(s) are structures. They are not object-
oriented in any way, and they are certainly not virtual. The code that
manipulates them is quite physical and procedural, well defined, and
visible to the rest of the kernel.

> Sure making every file an object is probably OTT; but large scale things
> like a filesystem, a network device or the like probably actually fit
> very well.

Err. From the outside-in, any well-defined software functionality
can look like an "object". In fact, any well-defined and well functioning
software is indistinguishable from magic, therefore can be represented
as an object in the true object-oriented sense.

>
> Sure, there are a lot of features of C++ to stay clear of - exception
> handling probably being one of them, and I wouldn't let the C++ stuff
> anywhere near the memory management code.
>


C++ is designed for user-mode programming. It expects to interface
with a complete operating system with well-defined characteristics.
It is not designed to be part of an operating system kernel.


> Point being that it is a case of using the write tool for the job. C++
> douesn't add any extra overhead just by calling it C++ and not using any
> of the features; careful use of the features where appropriate does no
> harm and might actually make the code cleaner, and possibly more
> efficient.
>

It is quite unlikely that a C++ compiler will make more efficient
code than a C compiler. In fact, the code generator will likely
be the same. The C++ compiler will end up generating some preamble
code as part of the function-calling mechanism, that is not necessary
in C. This means that it will generate a bit more code.

Making code "cleaner" is a matter of perspective.

class A {
public: void func(char *st) { cout << st << endl; }
};
using A::func;
A a;
a.func("Hello World!");


Is not all that clean. In fact, I'm not sure I have it right. It's
easier and clearer to write puts("Hello World!");

> I will agree going head in and just throwing C++ at it is a bad thing.
>
> Dave


Cheers,
Dick Johnson

Penguin : Linux version 2.4.18 on an i686 machine (797.90 BogoMips).

Windows-2000/Professional isn't.

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

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