On Fri 3/25/2011 10:33 PM, Emil Dotchevski wrote:
What does that have to do with anything?
This has to do with effect of BOOST_THROW_EXCEPTION on the time it takes to compile your program. I count that as cost.
That is true. I was under the impression that it you mentioned it to downplay the runtime cost. I apologize for my misunderstanding. I support any analysis of its various costs, as it lets users and (for now) library authors make a more informed choice about whether and how to use it.
Second, consider that this is only the default behavior. All this functionality disappears if you #define BOOST_EXCEPTION_DISABLE.
Huh? But that changes the behavior of the code, breaking it in places that depend on exceptions.
You seem to be confusing BOOST_NO_EXCEPTIONS with BOOST_EXCEPTION_DISABLE. Both change the behavior of BOOST_THROW_EXCEPTION:
Yes, you are correct. The macros have a clumsiness, though. If I have a library with both internal and external exceptions, it's only practical to enable or disable the features of BOOST_THROW_EXCEPTION() on a per-source file basis. Also, if a library with only internal exceptions uses BOOST_THROW_EXCEPTION() along with BOOST_EXCEPTION_DISABLE, then what benefit does that provide over just telling inspect to disregard use of 'throw' in the library (or certain parts of it)? Matt