lkml.org 
[lkml]   [1999]   [Jan]   [12]   [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

-----Original Message-----
From: Chip Salzenberg <chip@perlsupport.com>
To: Anthony Barbachan <barbacha@Hinako.AMBusiness.com>
Cc: scherrey@proteus-tech.com <scherrey@proteus-tech.com>; tytso@mit.edu
<tytso@mit.edu>; oxymoron@waste.org <oxymoron@waste.org>;
linux-kernel@vger.rutgers.edu <linux-kernel@vger.rutgers.edu>;
alan@lxorguk.ukuu.org.uk <alan@lxorguk.ukuu.org.uk>
Date: Monday, January 11, 1999 1:42 PM
Subject: Re: C++ in kernel (was Re: exception in a device driver)


>According to Anthony Barbachan:
>> I would avoid the use of either exceptions or especially the STL
>> like the plauge as these features would lead to unfollowable/
>> unreadable code.
>
>I thoroughly disagree that either the STL (esp. the algorithms part)
>or exceptions inevitably leads to unreadable code.
>
>Exceptions may be a really useful way to (e.g.) return -ENOENT from
>three or four levels deep in filesystem code -- without testing for
>error conditions at each call level. But you have to go whole-hog;
>a hybrid part-exception- part-error-return system would simply add
>complexity.
>

The problem with exceptions (especially in the kernel):

1 - Error probably not handled locally in function, meaning the function is
relying on some higher level code to take care of the exceptions.

2 - Hampers readability as another programmer will find it difficult to read
the function and understand how it all works since the error handling may be
missing as it is suppose to be implemented at a higher level.

3 - Exceptions also adds overhead, perhaps not speedwise, but definately
bloatwise.

4 - Exceptions are one way, no way to continue executing if the problem was
resolved.

5 - Exception calls would be quite common as "errors" occur often in the
kernel.

>And STL iterators and algorithms *could* be useful for some kernel
>structures. You'd have to experiment to know for sure.
>

The STL is messy. The syntax is atrocious and cryptic and error messages
are extremly cryptic due to the teplatization. Besides to even use the STL
you would have to reimplement it as the kernel cannot call an external
library. The simplier, cleaner, more readable, safer, maintainable, and
more object oriented approach is to create classes that take care of
whatever needs to be taken care of. Furthermore, some algorithms need not
be implemented in a class, especially if they fit nicely within a regular
function.

>> I agree with you here. The problems bought in by threads usually aren't
>> worth the trade off.
>
>Ditto. The C++ Perl implementation I mentioned in a previous message
>undoes the threading experiment contained in Perl 5.005.
>--

Oh well, there goes my plans to experiment with that new feature.

>Chip Salzenberg - a.k.a. - <chip@perlsupport.com>
> "When do you work?" "Whenever I'm not busy."
>



-
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.102 / U:0.124 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site