lkml.org 
[lkml]   [2006]   [Apr]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    SubjectRE: C++ pushback
    Date

    Linus wrote:

    > On Wed, 26 Apr 2006, Jan-Benedict Glaw wrote:

    > > There's one _practical_ thing you need to keep in mind: you'll either
    > > need 'C++'-clean kernel headers (to interface low-level kernel
    > > functions) or a separate set of headers.

    > I suspect it would be easier to just do
    >
    > extern "C" {
    > #include <linux/xyz.h>
    > ...
    > }

    > instead of having anything really C++'aware in the headers.

    I agree. This could include things like:

    #define class class_

    You'd need two includes, one that goes first and one that goes last (to
    undefine these things). Yeah, it's ugly, but it imposes the minimum cost on
    those who don't care.

    > If by "clean" you meant that the above works, then yeah, there might be
    > _some_ cases where we use C++ keywords etc in the headers, but
    > they should
    > be pretty unusual and easy to fix.

    They can be fixed ugly ways or nice ways, depending on a cost/benefit
    analysis.

    > The real problem with C++ for kernel modules is:
    >
    > - the language just sucks. Sorry, but it does.
    > - some of the C features we use may or may not be usable from C++
    > (statement expressions?)
    > - the compilers are slower, and less reliable. This is _less_ of
    > an issue
    > these days than it used to be (at least the reliability part),
    > but it's
    > still true.
    > - a lot of the C++ features just won't be supported sanely (ie
    > the kernel
    > infrastructure just doesn't do exceptions for C++, nor will it run any
    > static constructors etc).

    I would phrase the argument as such: any project that can really benefit
    from what C++ adds to C is probably too big and complex to belong in the
    kernel. Better to do what you need to get it out of the kernel.

    A better project might be some compromise between kernel space and user
    space that doesn't abuse the kernel stack and where things like exceptions
    can be supported.

    > Anyway, it should all be doable. Not necessarily even very hard. But I
    > doubt it's worth it.

    If FUSE made it so that you could just as well put a filesystem in user
    space as kernel space, I'd agree with you. File systems are the only kernel
    drivers I can think of that can justify sufficient complexity to get much
    benefit from C++. This may change though, and this could just be a lack of
    imagination on my part.

    By the way, I am not a proponent of C++ in the kernel or of making changes
    to the kernel to support C++. I'm just someone who labels bullshit as such
    when he sees it.

    DS


    -
    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: 2006-04-26 22:46    [W:0.027 / U:30.264 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site