On 23/06/2012 20:33, Robert Ramey wrote:
But this facility is included in the same library as another facility useful to users. So addressing of one problem - non-conforming compilers is not orthogonal to the other problem - helpful facilities for users. It's not fine grained enough for my taste.
At that we agree, I never use the arbitrary data transport facilities of Boost.Exception myself when I write library code. I think of that facility as a end-user only kind of facility, but its still nice that the users of my library can leverage it if they want to (and I do use it when I myself am the user of my library). I wouldn't know if its either possible or sensible to implement the two features as separate components, perhaps its something worth researching. Regarding the overhead payed for something that I may not want to use, according to Boost.Exception documentation is negligible. For me negligible its usually too much, but if we are talking exceptions then we are talking about exceptional situations (yes, I'm one of those purists). The documentation for the library states: The cost of this integration is: - In terms of space: a pointer and 3 ints are added to the static size of exception objects. - In terms of speed: the pointer is initialized to null at the point of the throw. - In terms of coupling: about 400 self-contained lines of C++ with no external includes. at http://www.boost.org/doc/libs/1_49_0/libs/exception/doc/frequently_asked_que... . It's placed as an answer to "Why is boost::exception integrated in boost::throw_exception?" rather than "What is the space overhead of the boost::exception base class?" which is a bit unfortunate. I don't see html anchors to each of the questions either, sorry about that. Agustín K-ballo Bergé.-