lkml.org 
[lkml]   [2006]   [Apr]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Compiling C++ modules
Alan Cox wrote:
> On Maw, 2006-04-25 at 00:03 +0300, Avi Kivity wrote:
>
>> Alan Cox wrote:
>> I think it's easy to show that the equivalent C++ code would be shorter,
>> faster, and safer.
>>
>
> Mathematically the answer is "no you couldn't". You might be able to
> argue that a fortran implementation would be faster but not a C++ one.
>
Maybe not mathematically, but I can try to hand-wave my way through.

By using exceptions, you free the normal return paths from having to
check for errors. The exception paths can be kept in a dedicated
section, avoiding cache pollution. The total code (and data) size
increases, but the non-exception paths size decreases significantly and
becomes faster.

Using C++ objects instead of C objects allows you to avoid void
pointers, which are difficult for the compiler to optimize due to aliasing.
> And for strings C++ strings are suprisingly inefficient and need a lot
> of memory allocations, which can fail and are not handled well without C
> ++ exceptions and other joyous language features you don't want in a
> kernel. C with 'safe' string handling is similar - look at glib.
>
> We have to make tradeoffs and the kernel tradeoffs have been to keep C
> type fast string handling but to provide helpers in the hope people will
> actually use them to avoid making mistakes.
>
You might keep C strings (or something similar) for the vfs paths and
use C++ strings for non performance critical code.

--
error compiling committee.c: too many arguments to function

-
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-25 09:22    [W:0.484 / U:0.416 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site