update example,tests

Author: tekezo

example/.gitignore

@@ -1,4 +1,4 @@
 /vendor/cget/cget.cmake
 /vendor/cget/pkg/pqrs-org__cget-recipes/
-/vendor/etc/
+/vendor/etc/cget/recipes/
 /vendor/**/pkgconfig/

tests/.gitignore

@@ -1,4 +1,4 @@
 /vendor/cget/cget.cmake
 /vendor/cget/pkg/pqrs-org__cget-recipes/
-/vendor/etc/
+/vendor/etc/cget/recipes/
 /vendor/**/pkgconfig/

tests/cget-requirements.txt

@@ -1,2 +1,2 @@
-catchorg/Catch2@v2.4.2
+catchorg/Catch2
 pqrs-org/cpp-string

tests/vendor/cget/pkg/catchorg__Catch2/install/include/catch2/catch.hpp

@@ -9,16 +9,16 @@
 # The variable CVF_VERSION must be set before calling configure_file().
 
 
-set(PACKAGE_VERSION "2.4.2")
+set(PACKAGE_VERSION "2.5.0")
 
 if(PACKAGE_VERSION VERSION_LESS PACKAGE_FIND_VERSION)
   set(PACKAGE_VERSION_COMPATIBLE FALSE)
 else()
 
-  if("2.4.2" MATCHES "^([0-9]+)\\.")
+  if("2.5.0" MATCHES "^([0-9]+)\\.")
     set(CVF_VERSION_MAJOR "${CMAKE_MATCH_1}")
   else()
-    set(CVF_VERSION_MAJOR "2.4.2")
+    set(CVF_VERSION_MAJOR "2.5.0")
   endif()
 
   if(PACKAGE_FIND_VERSION_MAJOR STREQUAL CVF_VERSION_MAJOR)

tests/vendor/cget/pkg/catchorg__Catch2/install/lib/cmake/Catch2/Catch2ConfigVersion.cmake

@@ -36,3 +36,4 @@ Other:
 * [Open Source Projects using Catch](opensource-users.md#top)
 * [Contributing](contributing.md#top)
 * [Release Notes](release-notes.md#top)
+* [Deprecations and incoming changes](deprecations.md#top)

tests/vendor/cget/pkg/catchorg__Catch2/install/share/doc/Catch2/Readme.md

@@ -0,0 +1,88 @@
+<a id="top"></a>
+# Deprecations and incoming changes
+
+This page documents current deprecations and upcoming planned changes
+inside Catch2. The difference between these is that a deprecated feature
+will be removed, while a planned change to a feature means that the
+feature will behave differently, but will still be present. Obviously,
+either of these is a breaking change, and thus will not happen until
+at least the next major release.
+
+
+## Deprecations
+
+### `--list-*` return values
+
+The return codes of the `--list-*` family of command line arguments
+will no longer be equal to the number of tests/tags/etc found, instead
+it will be 0 for success and non-zero for failure.
+
+
+### `--list-test-names-only`
+
+`--list-test-names-only` command line argument will be removed.
+
+
+### `ANON_TEST_CASE`
+
+`ANON_TEST_CASE` is scheduled for removal, as it can be fully replaced
+by a `TEST_CASE` with no arguments.
+
+
+### Secondary description amongst tags
+
+Currently, the tags part of `TEST_CASE` (and others) macro can also
+contain text that is not part of tags. This text is then separated into
+a "description" of the test case, but the description is then never used
+apart from writing it out for `--list-tests -v high`.
+
+Because it isn't actually used nor documented, and brings complications
+to Catch2's internals, description support will be removed.
+
+
+## Planned changes
+
+
+### Reporter verbosities
+
+The current implementation of verbosities, where the reporter is checked
+up-front whether it supports the requested verbosity, is fundamentally
+misguided and will be changed. The new implementation will no longer check
+whether the specified reporter supports the requested verbosity, instead
+it will be up to the reporters to deal with verbosities as they see fit
+(with an expectation that unsupported verbosities will be, at most,
+warnings, but not errors).
+
+
+### Output format of `--list-*` command line parameters
+
+The various list operations will be piped through reporters. This means
+that e.g. XML reporter will write the output as machine-parseable XML,
+while the Console reporter will keep the current, human-oriented output.
+
+
+### `CHECKED_IF` and `CHECKED_ELSE`
+
+To make the `CHECKED_IF` and `CHECKED_ELSE` macros more useful, they will
+be marked as "OK to fail" (`Catch::ResultDisposition::SuppressFail` flag
+will be added), which means that their failure will not fail the test,
+making the `else` actually useful.
+
+
+### Change semantics of `[.]` and tag exclusion
+
+Currently, given these 2 tests
+```cpp
+TEST_CASE("A", "[.][foo]") {}
+TEST_CASE("B", "[.][bar]") {}
+```
+specifying `[foo]` as the testspec will run test "A" and specifying
+`~[foo]` will run test "B", even though it is hidden. Also, specifying
+`~[baz]` will run both tests. This behaviour is often surprising and will
+be changed so that hidden tests are included in a run only if they
+positively match a testspec.
+
+
+---
+
+[Home](Readme.md#top)

tests/vendor/cget/pkg/catchorg__Catch2/install/share/doc/Catch2/deprecations.md

@@ -57,20 +57,37 @@ The message is reported and the test case fails.
 
 AS `FAIL`, but does not abort the test
 
-## Quickly capture a variable value
+## Quickly capture value of variables or expressions
 
-**CAPTURE(** _expression_ **)**
+**CAPTURE(** _expression1_, _expression2_, ... **)**
 
-Sometimes you just want to log the name and value of a variable. While you can easily do this with the INFO macro, above, as a convenience the CAPTURE macro handles the stringising of the variable name for you (actually it works with any expression, not just variables).
+Sometimes you just want to log a value of variable, or expression. For
+convenience, we provide the `CAPTURE` macro, that can take a variable,
+or an expression, and prints out that variable/expression and its value
+at the time of capture.
 
-E.g.
-```c++
-CAPTURE( theAnswer );
+e.g. `CAPTURE( theAnswer );` will log message "theAnswer := 42", while
+```cpp
+int a = 1, b = 2, c = 3;
+CAPTURE( a, b, c, a + b, c > b, a == 1);
+```
+will log a total of 6 messages:
+```
+a := 1
+b := 2
+c := 3
+a + b := 3
+c > b := true
+a == 1 := true
 ```
 
-This would log something like:
+You can also capture expressions that use commas inside parentheses
+(e.g. function calls), brackets, or braces (e.g. initializers). To
+properly capture expression that contains template parameters list
+(in other words, it contains commas between angle brackets), you need
+to enclose the expression inside parentheses:
+`CAPTURE( (std::pair<int, int>{1, 2}) );`
 
-<pre>"theAnswer := 42"</pre>
 
 ---
 

tests/vendor/cget/pkg/catchorg__Catch2/install/share/doc/Catch2/logging.md

@@ -2,6 +2,7 @@
 
 # Release notes
 **Contents**<br>
+[2.5.0](#250)<br>
 [2.4.2](#242)<br>
 [2.4.1](#241)<br>
 [2.4.0](#240)<br>
@@ -17,6 +18,27 @@
 [Older versions](#older-versions)<br>
 [Even Older versions](#even-older-versions)<br>
 
+## 2.5.0
+
+### Improvements
+* Added support for templated tests via `TEMPLATE_TEST_CASE` (#1437)
+
+
+### Fixes
+* Fixed compilation of `PredicateMatcher<const char*>` by removing partial specialization of `MatcherMethod<T*>`
+* Listeners now implicitly support any verbosity (#1426)
+* Fixed compilation with Embarcadero builder by introducing `Catch::isnan` polyfill (#1438)
+* Fixed `CAPTURE` asserting for non-trivial captures (#1436, #1448)
+
+
+### Miscellaneous
+* We should now be providing first party Conan support via https://bintray.com/catchorg/Catch2 (#1443)
+* Added new section "deprecations and planned changes" to the documentation
+  * It contains summary of what is deprecated and might change with next major version
+* From this release forward, the released headers should be pgp signed (#430)
+  * KeyID `E29C 46F3 B8A7 5028 6079 3B7D ECC9 C20E 314B 2360`
+  * or https://codingnest.com/files/horenmar-publickey.asc
+
 
 ## 2.4.2
 

tests/vendor/cget/pkg/catchorg__Catch2/install/share/doc/Catch2/release-notes.md

@@ -8,11 +8,11 @@ When enough changes have accumulated, it is time to release new version of Catch
 These steps are necessary and have to be performed before each new release. They serve to make sure that the new release is correct and linked-to from the standard places.
 
 
-### Approval testing
+### Testing
 
-Catch's releases are primarily validated against output from previous release, stored in `projects/SelfTest/Baselines`. To validate current sources, build the SelfTest binary and pass it to the `approvalTests.py` script: `approvalTests.py <path/to/SelfTest>`.
-
-There should be no differences, as Approval tests should be updated when changes to Catch are made, but if there are, then they need to be manually reviewed and either approved (using `approve.py`) or Catch requires other fixes.
+All of the tests are currently run in our CI setup based on TravisCI and
+AppVeyor. As long as the last commit tested green, the release can
+proceed.
 
 
 ### Incrementing version number
@@ -27,7 +27,7 @@ version numbers everywhere and pushing the new version to Wandbox.
 
 ### Release notes
 
-Once a release is ready, release notes need to be written. They should summarize changes done since last release. For rough idea of expected notes see previous releases. Once written, release notes should be placed in `docs/release-notes.md`.
+Once a release is ready, release notes need to be written. They should summarize changes done since last release. For rough idea of expected notes see previous releases. Once written, release notes should be added to `docs/release-notes.md`.
 
 
 ### Commit and push update to GitHub
@@ -43,11 +43,8 @@ description should contain the release notes for the current release.
 Single header version of `catch.hpp` *needs* to be attached as a binary,
 as that is where the official download link links to. Preferably
 it should use linux line endings. All non-bundled reporters (Automake,
-TAP, TeamCity) should also be attached as binaries, as they are dependent
-on a specific version of the single-include header.
-
-
-## Optional steps
+TAP, TeamCity) should also be attached as binaries, as they might be
+dependent on a specific version of the single-include header.
 
-Because Catch's [vcpkg](https://github.com/Microsoft/vcpkg) port updates
-itself automagically, there are no optional steps at this time.
+Since 2.5.0, the release tag and the "binaries" (headers) should be PGP
+signed.

tests/vendor/cget/pkg/catchorg__Catch2/install/share/doc/Catch2/release-process.md

@@ -1,6 +1,12 @@
 <a id="top"></a>
 # Test cases and sections
 
+**Contents**<br>
+[Tags](#tags)<br>
+[Tag aliases](#tag-aliases)<br>
+[BDD-style test cases](#bdd-style-test-cases)<br>
+[Type parametrised test cases](#type-parametrised-test-cases)<br>
+
 While Catch fully supports the traditional, xUnit, style of class-based fixtures containing test case methods this is not the preferred style.
 
 Instead Catch provides a powerful mechanism for nesting test case sections within a test case. For a more detailed discussion see the [tutorial](tutorial.md#test-cases-and-sections).
@@ -86,6 +92,65 @@ When any of these macros are used the console reporter recognises them and forma
 
 Other than the additional prefixes and the formatting in the console reporter these macros behave exactly as ```TEST_CASE```s and ```SECTION```s. As such there is nothing enforcing the correct sequencing of these macros - that's up to the programmer!
 
+## Type parametrised test cases
+
+In addition to `TEST_CASE`s, Catch2 also supports test cases parametrised
+by type, in the form of `TEMPLATE_TEST_CASE`.
+
+* **TEMPLATE_TEST_CASE(** _test name_ , _tags_,  _type1_, _type2_, ..., _typen_ **)**
+
+_test name_ and _tag_ are exactly the same as they are in `TEST_CASE`,
+with the difference that the tag string must be provided (however, it
+can be empty). _type1_ through _typen_ is the list of types for which
+this test case should run, and, inside the test code, the current type
+is available as the `TestType` type.
+
+Because of limitations of the C++ preprocessor, if you want to specify
+a type with multiple template parameters, you need to enclose it in
+parentheses, e.g. `std::map<int, std::string>` needs to be passed as
+`(std::map<int, std::string>)`.
+
+Example:
+```cpp
+TEMPLATE_TEST_CASE( "vectors can be sized and resized", "[vector][template]", int, std::string, (std::tuple<int,float>) ) {
+
+    std::vector<TestType> v( 5 );
+
+    REQUIRE( v.size() == 5 );
+    REQUIRE( v.capacity() >= 5 );
+
+    SECTION( "resizing bigger changes size and capacity" ) {
+        v.resize( 10 );
+
+        REQUIRE( v.size() == 10 );
+        REQUIRE( v.capacity() >= 10 );
+    }
+    SECTION( "resizing smaller changes size but not capacity" ) {
+        v.resize( 0 );
+
+        REQUIRE( v.size() == 0 );
+        REQUIRE( v.capacity() >= 5 );
+
+        SECTION( "We can use the 'swap trick' to reset the capacity" ) {
+            std::vector<TestType> empty;
+            empty.swap( v );
+
+            REQUIRE( v.capacity() == 0 );
+        }
+    }
+    SECTION( "reserving smaller does not change size or capacity" ) {
+        v.reserve( 0 );
+
+        REQUIRE( v.size() == 5 );
+        REQUIRE( v.capacity() >= 5 );
+    }
+}
+```
+
+_While there is an upper limit on the number of types you can specify
+in single `TEMPLATE_TEST_CASE`, the limit is very high and should not
+be encountered in practice._
+
 ---
 
 [Home](Readme.md#top)

tests/vendor/cget/pkg/catchorg__Catch2/install/share/doc/Catch2/test-cases-and-sections.md

@@ -30,6 +30,36 @@ class UniqueTestsFixture {
 
 The two test cases here will create uniquely-named derived classes of UniqueTestsFixture and thus can access the `getID()` protected method and `conn` member variables. This ensures that both the test cases are able to create a DBConnection using the same method (DRY principle) and that any ID's created are unique such that the order that tests are executed does not matter.
 
+
+Catch2 also provides `TEMPLATE_TEST_CASE_METHOD` that can be used together
+with templated fixtures to perform tests for multiple different types.
+However, unlike `TEST_CASE_METHOD`, `TEMPLATE_TEST_CASE_METHOD` requires
+the tag specification to be non-empty, as it is followed by further macros
+arguments.
+
+Also note that, because of limitations of the C++ preprocessor, if you
+want to specify a type with multiple template parameters, you need to
+enclose it in parentheses, e.g. `std::map<int, std::string>` needs to be
+passed as `(std::map<int, std::string>)`.
+
+Example:
+```cpp
+template< typename T >
+struct Template_Fixture {
+    Template_Fixture(): m_a(1) {}
+
+    T m_a;
+};
+
+TEMPLATE_TEST_CASE_METHOD(Template_Fixture,"A TEMPLATE_TEST_CASE_METHOD based test run that succeeds", "[class][template]", int, float, double) {
+    REQUIRE( Template_Fixture<TestType>::m_a == 1 );
+}
+```
+
+_While there is an upper limit on the number of types you can specify
+in single `TEMPLATE_TEST_CASE`, the limit is very high and should not
+be encountered in practice._
+
 ---
 
 [Home](Readme.md#top)

tests/vendor/cget/pkg/catchorg__Catch2/install/share/doc/Catch2/test-fixtures.md

@@ -23,7 +23,7 @@ std::ostream& operator << ( std::ostream& os, T const& value ) {
 
 (where ```T``` is your type and ```convertMyTypeToString``` is where you'll write whatever code is necessary to make your type printable - it doesn't have to be in another function).
 
-You should put this function in the same namespace as your type and have it declared before including Catch's header.
+You should put this function in the same namespace as your type, or the global namespace, and have it declared before including Catch's header.
 
 ## Catch::StringMaker specialisation
 If you don't want to provide an ```operator <<``` overload, or you want to convert your type differently for testing purposes, you can provide a specialization for `Catch::StringMaker<T>`: