[lkml]   [2002]   [Apr]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: C++ and the kernel

    ----- Original Message -----
    From: "Martin Dalecki" <>
    To: "T. A." <>
    Cc: "Linux Kernel Mailing List" <>
    Sent: Tuesday, April 09, 2002 5:54 AM
    Subject: Re: C++ and the kernel

    > > So far my overloading of "new" works if I compile the module without
    > > exceptions (-fno-exceptions). This is fine for myself as I prefer
    >> snip <<
    > > include exception support if possible so those whom may want to use it,
    > This will turn out to be nearly impossible. Please note that
    > the exception mechanisms in C++ are basically a second function
    > return path and are therefore not desirable at all for the following
    > 1. It's silly becouse we have already a return path and page fault based
    > exception mechanisms in kernel, which is far better suited for the
    > of the kernel then the C++ semantics. (Remarkable the KDE people
    > that C++ exceptions are not a good thing...)
    > 2. It's changing the stack layout for the kernel functions, and there
    > are few of them which rely on a particular stack layout (namely the
    > scheduler and some *.S files - look out for the asmlinkage

    Well I don't really need (or like) exceptions so forgetting about them
    works for me. However currently there is no other efficient means of
    determining if an error has occured during a objects construction. No
    return value. Would have to waste memory on a flag variable. Would the
    above problems also be present on the module level? I don't really want
    exceptions leaving the module, so to speak.

    > >
    > > int init_module()
    > > int cleanup_module()
    > > __attribute__((alias(mangle_name("unload__9my_module"))));
    > I guess the above wouldn't work due to the games which the linkage scripts
    > play already on the init_module and cleanup_module function.
    > Maybe you would rather wan't to have a look at those scripts themself
    > and adjust them accordingly? (Possibly having a mangling tool at hand...)

    Do you mean the module_[init|exit] macros? If so I've already taken a
    look at them. Thats where I got the alias from. And the above does work.
    However currently I have to compile the module, do nm on it, find the magled
    name, and enter it manually as above; then recompile. Works though.

    > > my_module mod1;
    > Well the "hidden C++" initializations you should propably forget
    > about - they are not desirable inside the kernel, becouse this
    > C++ mechanism is annihilating the expliciticity of the programm controll
    > flow of C.

    Oh well works for me. Pointers to objects will get the job done.

    > > Would patches be welcomed for one or more of these issues?
    > Personally I would just like to have the ability to compile the
    > kernel with C++ just for the following two reaons:
    > 1. C++ is a bit tighter on type checking, which would give better
    > 2. Modern GCC versions generate generally better code for C if compiled as
    > files, since the language gives tighter semantics to some constructs.
    > However I wouldn't for certainly like to see the kernel beeing transformed
    > in to C++. Expierence has shown over time that the chances for abuse of
    > programming language are just too high. Language design idiocies like the
    > following come immediately in to mind:
    > 1. Templates.
    > 2. Runtime Type Information.
    > 3. Operator overloading. This makes the language morphable which is
    > nearly the ability to understand code by reading it.
    > 4. Syntactically hidden code paths
    > (exceptions, constructors with side effects, destructors which you never
    > when they tis you...) make the readability even worser...
    > 5. Instability of compiler implementations (ever wondered how many
    libstdc++ you
    > have on your linux system?)

    Don't worry, not looking to do a C++ rewrite. Just looking to be able
    to setup a C++ framework for use in modules.
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 13:25    [W:0.059 / U:1.864 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site