This means that `REQUIRE(std::vector<int>{1, 2} == std::vector<int>{1,
2});` works as expected.
Note that assertion macros taking more than 1 argument are currently not
variadic, because variadic args have to come last, which would make the
interface of these ugly: `REQUIRE_THROWS_AS(std::exception const&, ....
)`
All C++11 toggles are now removed. What is left is either platform
specific (POSIX_SIGNALS, WINDOWS_SEH), or possibly still needed
(USE_COUNTER).
If current CLion is compatible with `__COUNTER__`, then we should also
force `__COUNTER__` usage.
Changed
* CATCH_AUTO_PTR -> std::unique_ptr
* CATCH_OVERRIDE -> override
* CATCH_NULL -> nullptr
* CATCH_NOEXCEPT -> noexcept
* CATCH_NOEXCEPT_IS -> noexcept
Removed
* CATCH_CONFIG_CPP11_UNIQUE_PTR
* CATCH_CONFIG_CPP11_SHUFFLE
* CATCH_CONFIG_CPP11_TYPE_TRAITS
* CATCH_CONFIG_CPP11_OVERRIDE
* CATCH_CONFIG_CPP11_LONG_LONG
* CATCH_CONFIG_CPP11_TUPLE
* CATCH_CONFIG_CPP11_IS_ENUM
* CATCH_CONFIG_CPP11_GENERATED_METHODS
* CATCH_CONFIG_CPP11_NOEXCEPT
* CATCH_CONFIG_CPP11_NULLPTR
* CATCH_CONFIG_VARIADIC_MACROS
This seems to give about 15% speedup when compiling tests using GCC.
The tradeoff is that under certain circumstances, there is a chance for
false negative result, when the expression under test throws exception
and the test code catches it before it gets to the test runner.
Example:
``` cpp
TEST_CASE("False negative") {
try {
REQUIRE(throws() == "");
} catch (...) {}
}
```
This test case will succeed, reporting no assertions checked, instead of
failing as it would with `CATCH_CONFIG_FAST_COMPILE` disabled. However,
just removing the try-catch block inside client's code will fix this, so
it is worthwhile.
This change does not apply to CHECK* macros, because these are currently
specified as continuing on exception and thus need the local try-catch
to work as intended.
- moved as much logic out of the macros as possible
- moved most logic into new ResultBuilder class, which wraps ExpressionResultBuilder (may take it over next), subsumes ResultAction and also takes place of ExpressionDecomposer.
This introduces many SRP violations - but all in the name of minimising macro logic!
Martin Hořeňovský