Tobias Schwinger:
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 exceptions.