Boost logo

Boost :

From: Martin Wille (mw8329_at_[hidden])
Date: 2006-11-23 03:14:19


Robert Ramey wrote:
> ...
>> BOOST_CXX0X_CONCEPTS: concepts (not yet accepted)
> ...
>
> This is slightly off-topic but it does bring up something that has been
> bothersome to me for some time.
>
> Suppose that I had a library which used the new concepts. Then
> I wrote a few tests to demonstrate the usage of and verify
> the specification of of the concepts. Then I add the tests
> to the Jamfile. Now I have a bunch of tests run on all compilers
> many of which don't support the new concepts. In an
> attempt to make the testing faster and more useful, I tweak
> the Jamfile so that these tests are run only with the compilers
> for which such tests are useful. That doesn't work very well
> as the test tools name vary quite a lot. gcc, mingw, ... etc
>
> What I need is a connection between the config tests and
> a particular set of tests - something like

How about this idea:

* we reserve a specific error code for indicating "not supported on this
platform".

* your test code diverts to int main() { return
BOOST_PLATFORM_NOT_SUPPORTED; } for unsupported platforms

* the postprocessing chain gets adjusted to deal with that specific result.

If using an exit code is not viable then we also could do something
along this: int main() { std::cout << "<platform_unsupported/>\n";
return EXIT_FAILURE; }

Or static_assert(platform_unupported) or even #error
"<platform_unsupported/>"

I think this would simplify managing expected failures a lot (no
specific markup needed) and it would also reduce the cost of needlessly
compiling and running tests that will fail.

Regards,
m
Send instant messages to your online friends http://au.messenger.yahoo.com


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