Boost logo

Boost :

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


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk