"J . A . Magallon" wrote:
> I agree that C++ for kernel is not a good idea, libstdc++ should be in the
> kernel,
> code would be bigger, there's a complicated runtime under C++ doing things
> by itself (copy constructors-operators and so on), inheritance adds some
> little calling overhead.
>
You can profile C++ code very precisely. Avoiding copy constructors
is programmer's part. C++ doesn't require you to use polymorphism,
and if used carefully doesn't incur significant overhead.
I can't say whether putting libstdc++ in a kernel module is a bad thing
before I see one. This is a skel. code:
orion:opt$ ls -al app
-rwxrwxr-x 1 exa exa 14275 Oct 16 04:38 app
orion:opt$ ls -al /usr/lib/libstdc++-3-libc6.2-2-2.10.0.so
-rw-r--r-- 1 root root 271528 Oct 10 09:54
/usr/lib/libstdc++-3-libc6.2-2-2.10.0.so
orion:opt$ ls -al /usr/lib/libstdc++-3-libc6.2-2-2.10.0.a
-rw-r--r-- 1 root root 476494 Oct 10 09:54
/usr/lib/libstdc++-3-libc6.2-2-2.10.0.a
It seems to me that a somewhat big module binary wouldn't hurt
for many applications. Putting that into the "real" kernel isn't
a good idea of course.
Can't the unused code be stripped from libstdc++ for a single
kernel module? :(
> - <const &> args : dont break your untouchable data, and get rid of pointer mess
and const functions. This is such a good thing, it allows the compiler
to make great optimizations that are not possible in C. The C9x
standards had (IIRC) a similar "restricted" keyword for C, but
I don't know if gcc is going to implement it. You might want to
demand that from gcc developers :)
> Perhaps a g++-embedded mode could be the solution...
For embedded applications? ;)
Regards,
--
Eray (exa) Ozkural
Comp. Sci. Dept., Bilkent University, Ankara
e-mail: [EMAIL PROTECTED]
www: http://www.cs.bilkent.edu.tr/~erayo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
