lkml.org 
[lkml]   [1999]   [Jan]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: C++ in kernel (was Re: exception in a device driver)
Date
>On the contrary
>foo1.C
> blah->foofunc();
>foo2.C
>blahobject::foofunc()
>{
> printf("Hi");
>}
>
>a C++ compiler ends up passing "this" needlessly because it can't tell that
>foofunc of object blahobject need not know who it is.
>
>Thats only one example.

If the programmer makes foofunc a static member function you're fine (or in
this case static and inline). This would only be a problem if you wanted it
to be a virtual call, in which case the extra few bytes on the stack is the
least of your performance worries. Anyways, the code being called chooses
how it can be called to perform best.

A colleague and I have a templated vector class (actually an evolution of a
class library that was started 10 years ago) that makes a good abstraction
and blows asserts in debug versions, but in release versions it is
equivalent to a new'd pointer and a size being passed around.

I'm not advocating C++ in the kernel, but for other reasons than
performance.
- bad C++ is worse than bad C
- I'd prefer my compiles not to take a lot longer
- I don't trust the gcc compiler to parse and optimize correctly... I have
problems enough with the commercial Windows compilers (Watcom, Borland,
Microsoft). I deal with it in applications but don't want to play this game
with my kernel.

Brian Macy



-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:49    [W:0.030 / U:0.244 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site