"Martin Wille" <mw8329@yahoo.com.au> wrote in message news:44608D80.2060508@yahoo.com.au...
Gennadiy Rozental wrote:
"Martin Wille" <mw8329@yahoo.com.au> wrote in message news:44603D05.5080401@yahoo.com.au...
Wil Evers wrote:
4) test (please don't get me started)
for any reasonable degree of portability (takes over main(), maps OS signals to C++ exceptions, continues to run after failing assert()s, etc.) FWIW, I don't use Boost.Test for the same reasons.
Could you be more elebotate? Cause none of the above seems fair. I dont know about any portability issues related to main in static library (and it's optional nowdays anyway). SIGNAL catching is optional and doesn't constitute portabiltiy issues per se, whether to use it's up to you.
At least for a long time, the signal catching apparently was the default behaviour of Boost.Test. The signal handling is broken because it exploits undefined behaviour. It caused troubles for several of the tests in Boost.
See http://lists.boost.org/Archives/boost/2004/07/67298.php or http://lists.boost.org/Archives/boost/2003/10/55496.php
I familiar with there issues and potential UB. But Boost.Test provides both alternatives, so you couldn't say that it is broken. Every user is free to make a choice either catch system signals but be exposed to potential UB or don't and lost reporting in case of crash. As for which alternative is selected as a default here my view on this is: 1. In my experience catching signals did not cause any deadlocks in 99% of cases. IMO proper reporting prevail. 2. Opting to ignore system signals will cause halt for regression testing in some cases (unless we change the setup explicitly) 3. This default was selected from the very beginning. I would be wary to change it (the same as changing an interface IMO) 4. I suspect that selecting other alternative would cause more unhappy users than this one (someone is always unhappy - the fact of life ;). Gennadiy