[lkml]   [1999]   [Jan]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: C++ in kernel (was Re: exception in a device driver)
    According to Anthony Barbachan:
    > 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.

    You may not realize that this is already true in C. In C the kernel
    says e.g. 'return -ENOENT'. That's not 'handling' the error at all!
    It's just *reporting* the error.

    Replace the 'return' with a 'throw' in C++, and nothing's different,
    except that it's effectively a multi-stack-frame return that's used
    to _report_ errors.

    > 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.

    Use of exceptions makes error-handling logic less localized. But to
    the extent that the overall code is less cluttered as a result, the
    results can end up *more* readable.

    Besides, I believe in optimizing for maintainability, and easy
    browsing is only one factor in ease of maintenance. Far more
    important, IMO, is the ability to specify design decisions exactly
    once; careful use of exceptions can assist toward that goal.

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

    The word 'bloat' is unnecessarily pejorative; it's not bloat if it's
    actually useful.

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

    Exceptions don't clean carpets or make coffee, either, but that
    doesn't make them useless.

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

    Which shows just how useful they would be! This is a point in favor
    of exceptions, not against them.

    > >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.

    "It's a fair cop, but society's to blame."

    The STL is single-mindedly general and orthogonal, which I find
    refreshing. Its design goals lead to tradeoffs in ease-of-typing and
    clarity-of-errors, which I can live with.

    > Besides to even use the STL you would have to reimplement it as the
    > kernel cannot call an external library.

    You'd just have to borrow some of the EGCS library and put it into the
    Linux 'lib' directory, so it's always available. No biggie.

    > 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.

    Readability, I'll grant you... :-/ But the STL *is* simple (in its
    thorough implementation of simple concepts), clean (in orthogonality),
    safe (in static type checking), and maintainable (by its helping you
    to localize your design decisions).

    Learn to appreciate the STL's strong points, and it'll help you.
    Chip Salzenberg - a.k.a. - <>
    "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
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 13:49    [W:0.024 / U:0.092 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site