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