> > So far my overloading of "new" works if I compile the module without
> > exceptions (-fno-exceptions). This is fine for myself as I prefer
checking
>> 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
reasons:
>
> 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
purposes
> of the kernel then the C++ semantics. (Remarkable the KDE people
recognize
> 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
attribute...)
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()
__attribute__((alias(mangle_name("load__9my_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
regreesions.
>
> 2. Modern GCC versions generate generally better code for C if compiled as
C++
> 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
this
> 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
killing
> nearly the ability to understand code by reading it.
>
> 4. Syntactically hidden code paths
> (exceptions, constructors with side effects, destructors which you never
know
> 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 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/