From: Peter Dimov (pdimov_at_[hidden])
Date: 2007-10-06 18:42:49
>>> typedef boost::custom_exception<
>>> base,tag_a,tag_b /*...*/> my_exception;
> Certainly. Now, reassembling the original thought: This kind of
> interface could be exploited by the library to implement the 'throw
> e(a,b,c)' case with (almost) no overhead compared to the traditional
> approach - that is, without having to use a custom allocator.
Sure, but I'm afraid that this somewhat misses the point. The idea of the
proposed exception class is to allow intermediate layers to stuff additional
data into the exception as it passes through; data that is not available at
the throw point.
You could say that only people that actually use this functionality ought to
pay for dynamic allocation, and superficially, you'd be right. But layering
doesn't quite work that way. In general, the user of the upper layer (who is
presumably trying to avoid dynamic allocation) has no control over the
middle layer (which is a third-party library). I'm not seeing a practical
way to reconcile the "no dynamic allocation" requirement with the current
goals of the library.
Now that I think of it, a custom allocator won't help much either, as you'd
need to pass it down to every low-level component that is throwing