>On Sat, 16 Jan 1999, Chip Salzenberg wrote:
>
>> You're working too hard (or at least proposing that someone _else_
>> work too hard). Just follow Stroupstrup's design rule: "Constructors
>> acquite resources; destructors release them."
>>
>> Because destructors are automatically called as stacks unwind.
>
>It's still not that simple. Imagine this simple case of linked list
>insertion:
>
>template<class E>
>void insert(E *current, E *add)
>{
> E *tmp;
>
> if(current&&add)
> {
> tmp=current->next();
> current->next(add);
> add->next(tmp);
> add->prev(current);
> if(tmp) tmp->prev(add);
> }
>}
>
>What happens to our list if _any_ of the above member functions throw an
>unexpected exception? You certainly wouldn't expect a function as trivial
>as next() to do such a thing, but it might. And if it does, exception
>handling will save us, right? The exception is caught and handled a level
>or two up, and the program continues as though nothing happened.
>Meanwhile, our list is corrupted. If the list is a DMA scatter-gather list
>we could really be in trouble. The language forces us to be paranoid in
>ways that C just doesn't.
>
>This case is trivial, and there are far uglier cases. Half of the problem
>is that "error" is poorly defined. Is it an error to ask a list element
>for next if you're at the end of a list? A given implementation of E might
>say "yes, because I don't trust you not to dereference null." Seem
>unlikely? It's not much different than a malloc implementation throwing an
>"out of memory" exception.
>
This is why I would oppose any use of C++ exceptions in the kernel, I
probably would also limit creativity in templates as they also have their
inefficiencies.
>--
> "Love the dolphins," she advised him. "Write by W.A.S.T.E.."
>
-
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/