* Empty strings are now direct constructed as `std::string()`, not as empty string literals.
* `startsWith` and `endsWith` no longer construct new a string. This should be an improvement
for libstdc++ when using older standards, as it doesn't use SSO but COW and thus even short
strings are expensive to first create.
* Various places now use char literal instead of string literals containing single char.
** `startsWith` and `endsWith` now also have overload that takes single char.
Generally the performance improvements under VS2015 are small, as going from short string
to char is mostly meaningless because of SSO (Catch doesn't push string handling that hard)
and previous commit removed most string handling if tests pass, which is the expect case.
This fixes the case when we pass signal to previously registered
handler, and it needs to transform the signal into different one.
Still problematic: What if the signal handler we replaced does not
terminate the application? We can end up in a weird state and loop
forever.
Possible solution: Deregister our signal handlers, CALL the previous
signal handler explicitly and if control returns, abort. This would
however complicate our code quite a bit, as we would have to parse the
sigaction we delegate to, decide whether to use signal handler or signal
action, etc...
Only some "signals" are handled under Windows, because Windows does not
use signals per-se and the mechanics are different. For now, we handle
sigsegv, stack overflow, div-by-zero and sigill. We can also
meaningfully
add various floating point errors, but not sigterm and family, because
sigterm is not a structured exception under Windows.
There is also no catch-all, because that would also catch various
debugger-related exceptions, like EXCEPTION_BREAKPOINT.
Also stops Catch from assuming its the only signal user in the binary,
and makes it restore the signal handlers it has replaced. Same goes for
the signal stack.
The signal stack itself probably shouldn't be always reallocated for
fragmentation reasons, but that can be fixed later on.
Now if we detect C++11 compiler, or MSVC in version corresponding to VS2015,
we switch from using `std::random_shuffle` to `std::shuffle`.
`std::random_shuffle` was officially deprecated in C++14, and removed in C++17.
Also removed guarded inclusion of `<random>` header, as there was nothing
in the header that used it.
Catch passes ::tolower into std::transform with string iterators.
::tolower has the signature int(int), which triggers a stealth narrowing
warning inside std::transform, because transform calls
*_Dest = _Fn(*_First), which implicitly narrows an int to a char.
For this particular application the narrowing is fine, so explicitly
narrow in a lambda.
Catch passes an RNG which accepts int to random_shuffle. Inside
random_shuffle, the STL tries to call that RNG with the difference_type
of the user provided iterators. For std::vector, this is ptrdiff_t,
which on amd64 builds is wider than int. This triggers a narrowing
warning because the 64 bit difference is being truncated to 32 bits.
Note that this RNG implementation still does not produce a correctly
uniformly shuffled result -- it's currently asserting that std::rand
can produce 1000000 which is false -- but I don't know enough about
how much repeatable shuffles are necessary here, so I'm leaving that
alone for now.
This commit fixes the following scenario:
* You have a test that compares strings with embedded control
characters.
* The test fails.
* You are using JUnit tests within TeamCity.
Before this commit, the JUnit report watcher fails on parsing the XML
for two reasons: the control characters are missing a semicolon at the
end, and the XML document doesn't specify that it is XML 1.1.
XML 1.0 --- what we get if we don't specify an XML version --- doesn't support embedding control characters --- see
http://stackoverflow.com/questions/404107/why-are-control-characters-illegal-in-xml
for all of the gory details.
This is based on PR #588 by @mrpi
Instead of `exit(1)`, it now throws `std::runtime_error` with the details
of the failure. This exception is handled in `run()` at a higher level where
the log is printed to cerr and the test gracefully exits.
- it was forward declared as a class, which caused warnings on some compilers. It should really have been a class anyway.
- this addresses the same issue as PR #534, albeit from the other angle.
I've incremented the minor release number. This is a slight abuse of semantic versioning so let me explain:
I've slightly changed how matchers are used. The matcher macro (REQUIRE_THAT/ CHECK_THAT) used to introduce the Catch::Matchers namespace before the macro token for the matcher, to save you having import the namespace yourself.
The trouble is if the matcher token is not a simple matcher (can now be an expression) this breaks!
So I've removed that qualification. Now if you use Matchers you'll have to do somethings like using namespace Catch::Matchers to bring them in.
This is a breaking change - but, OTTOH, Matchers are an undocumented "beta' feature that I've stated in the past is not guaranteed to have a stable API - so I don't think this warrants a major version change - but I did want to make it significant enough that people do notice that something is going on - and perhaps lead them to this commit message.
- simpler, polymorphic hierarchy-based, approach
- less bitty conditionals spread across the code
- all resolved up-front so now config class is immutable
(it had evolved the way it was and in need of a clean-up sweep for a long time)
This commit fixes the white background that appears in windows powershell
when catch outputs messages with colour. The previous implementation
ignored the original background colour and defaulted to a white background.
as prompted by #365, #430, #447 and a thread on the google group.
- split version bumping out of generateSingleHeader script
- separate scripts for bumping each version component
- "build" number only incremented for "develop" builds
