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.033 / U:31.724 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site