From: Gennadiy Rozental (rogeeff_at_[hidden])
Date: 2008-01-08 12:04:09
James Talbut <James.Talbut <at> omg3d.com> writes:
> >From searching, this was last discussed in Sep 2003, but didn't come to
> an adequate conclusion - and things have changed since then anyway.
> Including prg_exec_monitor.hpp on VS2005 produces the following warning:
> execution_monitor.ipp(216) : warning C4535: calling _set_se_translator()
> requires /EHa
In fact latest version of Boost.Test (see svn) doesn't use _set_se_translator
for SE handling. In only used to implement "throw;" trick in case user
requested not to catch SE.
> It is my opinion that the use of _set_se_translator here is a mistake
> for the following reasons:
> 1. It doesn't achieve what it's trying to achieve if my test
> involves multiple threads.
> The translator is thread specific and there is no way for my
> thread function to apply the translator (especially not when I may not
> have access to the thread function).
a) Boost.Test is not thread safe anyway at the moment
b) Thread-specific translator is what we would need in this case anyway, right?
> 2. It requires the use of /EHa which has an effect on the code
> being run.
> Code under test should be run using the same options as release,
> and /EHa is not appropriate for (most) release code.
a) I recommend testing debug builds
b) You can always add /EHa to your release build options. It may affect
performace of your application, but this is notthe point, right?
> 3. If I've really triggered a system fault then I can no longer
> trust the state of my app, so I cannot rely on it to correctly report
> its problem.
> I may have just destroyed the stack, attempting to unwind is
> just going to cause more problems - system errors should be handled
Message above is only a warning. If you don't specify /EHa SE are not going to
be caught anyway. The same result can be achieved by using --
catch_system_errors=no in case if you did specify above option during
compilation. Both cases shoudl serve your purpose.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk