>Anthony Barbachan wrote:
>
>> There's also usually a huge amount of overhead associated with C++
>> exceptions, probably not a good idea for a Linux driver. Furthermore the
>> simpliar method of checking the returned value(s) of functions is also
>> easier to understand, read, and debug.
>
> A huge amount compared to what? C++ exception handling is not just a
fancy
>replacement for checking return values. It allows an expressiveness and
more
>flexible flow of control within the code that may have to deal with that
>situation. Used properly, exception handling should result in little or not
>overhead compared to the explicitly coded option and sometimes can result
in
>less overhead. I've seen this happen in several situations when a well
>organized exception handling policy was present. Lots of code that had to
check
>for error conditions simply went away. The best part is that most of the
>overhead never had to be paid unless an exception actually did occur. My
code
>was smaller and faster as a result. Obviously I completely disagree with
your
>last sentence.
And in order to get a decent amount of control over the handling of
exceptioned errors you end up with a bunch of crap (try { } catch { })
throughout your code adding to its conplexity. And if you decide to
centralize error handling with exceptions, you've got a major problem.
There's no way to return to the exceptioned statement if you can correct the
error and can continue processing (aka, your able to free up some memory
within the out of memory exception handler). If this feature was available
then this could actually lead to cleaner code, but its not. Furthermore,
you'll then have a nightmare that some non "new" allocated variables or
non-selfcleaning "new" allocated variables will not get freed because an
unexpected and unhandled exception happened to throw execution of the code
to some other caller function. This would definately be a severe problem
within the kernel, especially with the current C code base. I actually like
the idea of being able to use exceptions, but without the ability to
continue processing where execution left off your error handling gets
severly limited and you end up having to code something that looks very
similar, if not more complicated and verbose, than the original error
condition check. And as far as understandability, debugability, and
clearness go, exceptions can cause the execution of unexpected code or the
lack of execution of code that was expected to be executed and these
problems are not as easy to trace down as the original error check. With
error checks a simple read through of the relevent function easly bring to
light most error checking bugs. An exception bug however, causes you to
have to hunt through the relevant function, the functions who call that
function, and the caller's of those, and so on. Not a fun way to spend
coding time.
>
> Now... what Alan says about the difficulty of supporting it within the
>kernel may very well be the case - I don't know. That said, its time to
start
>considering the future. C++ cannot be ignored by the kernel forever. The
I can see at least some good uses. Start by using it as a better C, strong
type checking, etc. Perhaps use some of its features to get rid of fancy
uses of preprocessor macros, which are usually somewhat cryptic. Port
various structures to classes. The programming of modules may be especially
enhanced, perhaps by having all modules inherit from a generic module. Even
better this would allow for easy changes of different parts of the kernel,
like interchangable parts. For example, choose from different memory
managers when cutomizing your kernel. Perhaps one optimize for low memory
systems, another for normal users, and yet another for those who must have 4
Gigs. If each MM is derived from a common virtual parent, this cound even
be doable at runtime. Or perhaps you want to be able to choose amoung
differing disk caches. This could definately be very useful.
>language just offers too much over plain C and was designed specifically
with
>large-scale systems programming in mind. The biggest limitation to full
>adoption of C++ that I've seen is the whole ABI/method call convention/name
>mangling fiasco which I feel really should have been addressed by the ANSI
>committee (at least guidelines and suggestions for future standardization).
>Since the egcs team has started reworking their code for an upcoming
"de-facto
>standard", it wouldn't surprise me if more compiler vendors saw the need to
at
>least support this as an option. At that point even public interfaces into
the
>kernel could be class method calls.
>
> Until then, its time to start considering getting the kernel's code
>buildable by g++ a little at a time. Just using it as a "better C" rather
than
>bringing all its features in at once would make for a cleaner system and
extend
>the life of the code by preventing cod rot. I know that this was attempted
>briefly a while back (with disastrous results) but the kernel was really
out of
>ANSI spec then and the C++ compilers were not really there. How about
>evaluating this as a feature for release 2.3?
>
> regards,
>
> Ben Scherrey
>
>PS: I can just feel the cringing from the "C bigots" right now... sorry
guys -
>I really don't mean to stomp your turf!
>
-
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/