From: Gennadiy Rozental (rogeeff_at_[hidden])
Date: 2008-01-09 16:17:34
James Talbut <James.Talbut <at> omg3d.com> writes:
>
> I am bothered by two aspects of the handling of SEH:
> 1. The whole idea of handling SEH from within the proc affected is
> doomed to fail in some circumstances (though only in some, so I'm not
> saying it's not worth doing anything).
> 2. Boost libraries should not produce any warnings on any supported
> compiler (or, at least, should be configurable so as to not produce any
> warnings).
specify /EHa and use --catch_system_errors=no and you got both
> > a) Boost.Test is not thread safe anyway at the moment
> What aspects of it aren't?
In many aspects. Starting with proper SEH handlign to the guarding internal
framework structures.
> I don't think the test harness should expect to have test macros used in
> other threads,
why not?
> but it should expect that other threads exist and do
> things unrelated to it.
> > b) Thread-specific translator is what we would need in this case
> anyway,
> > right?
> Well, it's not possible to put any translators in place (you don't have
> control of the threads) so that won't help.
> You could try doing something with SetUnhandledExceptionFilter, but that
> still won't always work (threads could be created in DllMain before you
> get the chance to install the filter).
I will have to revisit the status quo when/if I'll work on multithreading
support.
> > b) You can always add /EHa to your release build options. It may
> affect
> > performace of your application, but this is notthe point, right?
> On the contrary, it's absolutely the point.
> I want to test the code that I will actually be releasing - and this is
> performance sensitive code.
For many reasons I believe it may not be a good idea. But if you insist you
can go ahead and build without /EHa.
> > 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.
> But I want to get rid of the warning.
you can always suppress it in your code.
Gennadiy