minor changes regarding long long (and the docs)
diff --git a/doc/markdown/faq.md b/doc/markdown/faq.md
index 4546c24..0f86490 100644
--- a/doc/markdown/faq.md
+++ b/doc/markdown/faq.md
@@ -17,4 +17,12 @@
- why c++98?
-- will the library support checking for memory leaks? no. use tools like valgrind or the sanitizers.
\ No newline at end of file
+- why no ```long long``` in gcc/clang when in the c++98 standard?
+ - http://stackoverflow.com/questions/35826731/detect-if-long-long-is-present-at-compile-time
+
+- will the library support checking for memory leaks? no. use tools like valgrind or the sanitizers.
+
+- is the VC++6 support full?
+ - no
+ - the stringification with ```ostream& operator<<(ostream&, myType)``` is disabled
+ - comparing C strings will compare the pointers and not the actual strings
\ No newline at end of file
diff --git a/doc/markdown/features.md b/doc/markdown/features.md
index 7aeb55b..277f96e 100644
--- a/doc/markdown/features.md
+++ b/doc/markdown/features.md
@@ -72,7 +72,6 @@
- floating point comparison support
- tdd in c++?
-- update tutorial - TEST_CASE and etc.
- more comments in source code
- look into https://github.com/Barro/compiler-warnings
- think about the expression decomposition static asserts
@@ -86,13 +85,13 @@
## FUTURE
- crash handling: signals on UNIX platforms or structured exceptions on Windows
-- add support for tags - like Catch
+- add support for tags - like Catch - https://github.com/philsquared/Catch/blob/master/docs/test-cases-and-sections.md#special-tags
- support for predicates (or zip or whatever)
- make a compact reporter
- output to file
- xml reporter (jUnit/xUnit compatible, etc.)
- ability for users to write their own reporters
-- gcc 6
+- test with gcc 6 and use it in the CI builds
- add the ability to query if code is currently being ran in a test - some global of doctest...
- timing reports of tests, duration restrictions, kill of longer than (will perhaps require threading), etc...
- a message macro (also tracepoint/passpoint/info/context and whatever - like in boost.test) (ALSO ERROR/FAIL - like boost)
@@ -101,30 +100,26 @@
- marking a test to run X times (should also multiply with the global test run times)
- test execution in separate processes - UNIX only with fork() (but windows has some .dll which could help)
- matchers?
+- ability to provide a temp folder to tests that is cleared between them
- detect floating point exceptions
+- Bitwise() class that has overloaded operators for comparison - to be used to check objects bitwise against each other (or maybe not - because of packing!)
- [CI] static analysis: msvc, clang, cppcheck
- [CI] mingw-w64 on appveyor
## UNSURE
+- wchar stuff in stringify and whatever - see <wchar.h>
- refactor the assertion macros - make proxy functions that do most of the things to minimize code bloat
- pool allocator for String class
- order option - ASC/DESC for sorting
- BDD based on subcases - like Catch
-- when an option is found - like "-dt-count=" - validate it - if a string has been passed instead of a number - there should be an error
-- think about long long support or maybe int64_t support
-- Bitwise() class that has overloaded operators for comparison - to be used to check objects bitwise against each other (or maybe not - because of packing!)
-- tagging? also see this: https://github.com/philsquared/Catch/blob/master/docs/test-cases-and-sections.md#special-tags
+- when an option is found - like "-dt-last=" - validate it - if a string has been passed instead of a number - there should be an error
- utf8?
-- full support for VC++6 - currently the stringification with ```ostream& operator<<(ostream&, myType)``` is disabled
- hierarchical test suites? using a stack for the pushed states - should be easy
-- ability to re-run only newly compiled tests - based on timestamps of the __FILE__ in which they are - and stored in some file
-- ability to provide a temp folder to tests that is cleared between them
+- ability to re-run only newly compiled tests - based on timestamps of the __FILE__ in which they are - and stored in some file
- put internals in anonymous namespace (even if already in detail) - even though clang-format will make everything more indented
-- wchar stuff in stringify and whatever - see <wchar.h>
- progress of tests being executed (and an option for it)
- think about adding support for std::exception and others (mainly catching them so the .what() method can be called)
-- think about parameterising the output alignment to 80 or some other column limit
- think about the ability to mix different versions of the library within the same executable (like stb libraries)
## Spreading the word after 1.0.0 is released
diff --git a/doc/markdown/tutorial.md b/doc/markdown/tutorial.md
index 48f83e9..4ae7506 100644
--- a/doc/markdown/tutorial.md
+++ b/doc/markdown/tutorial.md
@@ -22,7 +22,7 @@
int factorial(int number) { return number <= 1 ? number : factorial(number - 1) * number; }
-TESTCASE("testing the factorial function") {
+TEST_CASE("testing the factorial function") {
CHECK(factorial(1) == 1);
CHECK(factorial(2) == 2);
CHECK(factorial(3) == 6);
@@ -35,7 +35,7 @@
If you run this as written it will pass. Everything is good. Right? Well there is still a bug here. We missed to check if ```factorial(0) == 1``` so lets add that check as well:
```c++
-TESTCASE("testing the factorial function") {
+TEST_CASE("testing the factorial function") {
CHECK(factorial(0) == 1);
CHECK(factorial(1) == 1);
CHECK(factorial(2) == 2);
@@ -70,7 +70,7 @@
Although this was a simple test it's been enough to demonstrate a few things about how **doctest** is used.
1. All we did was ```#define``` one identifier and ```#include``` one header and we got everything - even an implementation of ```main()``` that will respond to command line arguments. You can only use that ```#define``` in one source file for (hopefully) obvious reasons. Once you have more than one file with unit tests in you'll just ```#include "doctest.h"``` and go. Usually it's a good idea to have a dedicated implementation file that just has ```#define DOCTEST_CONFIG_IMPLEMENT_WITH_MAIN``` and ```#include "doctest.h"```. You can also provide your own implementation of main and drive **doctest** yourself - see [**supplying your own ```main()```**](main.md).
-2. We introduce test cases with the ```TESTCASE``` macro. It takes one argument - a free form test name (for more see [**Test cases and subcases**](testcases.md)). The test name doesn't have to be unique. You can run sets of tests by specifying a wildcarded test name or a tag expression. See the [**command line**](commandline.md) docs for more information on running tests.
+2. We introduce test cases with the ```TEST_CASE``` macro. It takes one argument - a free form test name (for more see [**Test cases and subcases**](testcases.md)). The test name doesn't have to be unique. You can run sets of tests by specifying a wildcarded test name or a tag expression. See the [**command line**](commandline.md) docs for more information on running tests.
3. The name is just a string. We haven't had to declare a function or method - or explicitly register the test case anywhere. Behind the scenes a function with a generated name is defined for you and automatically registered using static registry classes. By abstracting the function name away we can name our tests without the constraints of identifier names.
4. We write our individual test assertions using the ```CHECK()``` macro. Rather than a separate macro for each type of condition (equal, less than, greater than, etc.) we express the condition naturally using C++ syntax. Behind the scenes a simple expression template captures the left-hand-side and right-hand-side of the expression so we can display the values in our test report. There are other [**assertion macros**](assertions.md) not covered in this tutorial - but because of this technique the number of them is drastically reduced.
@@ -85,7 +85,7 @@
This is best explained through an example:
```c++
-TESTCASE("vectors can be sized and resized") {
+TEST_CASE("vectors can be sized and resized") {
std::vector<int> v(5);
REQUIRE(v.size() == 5);
@@ -106,9 +106,9 @@
}
```
-For each ```SUBCASE()``` the ```TESTCASE()``` is executed from the start - so as we enter each subcase we know that the size is 5 and the capacity is at least 5. We enforce those requirements with the ```REQUIRE()``` macros at the top level so we can be confident in them. If a ```CHECK()``` fails - the test is marked as failed but the execution continues - but if a ```REQUIRE()``` fails - execution of the test stops.
+For each ```SUBCASE()``` the ```TEST_CASE()``` is executed from the start - so as we enter each subcase we know that the size is 5 and the capacity is at least 5. We enforce those requirements with the ```REQUIRE()``` macros at the top level so we can be confident in them. If a ```CHECK()``` fails - the test is marked as failed but the execution continues - but if a ```REQUIRE()``` fails - execution of the test stops.
-This works because the ```SUBCASE()``` macro contains an if statement that calls back into **doctest** to see if the subcase should be executed. One leaf subcase is executed on each run through a ```TESTCASE()```. The other subcases are skipped. Next time the next subcase is executed and so on until no new subcases are encountered.
+This works because the ```SUBCASE()``` macro contains an if statement that calls back into **doctest** to see if the subcase should be executed. One leaf subcase is executed on each run through a ```TEST_CASE()```. The other subcases are skipped. Next time the next subcase is executed and so on until no new subcases are encountered.
So far so good - this is already an improvement on the setup/teardown approach because now we see our setup code inline and use the stack. The power of subcases really shows when we start nesting them like in the example below:
@@ -124,7 +124,7 @@
#include <iostream>
using namespace std;
-TESTCASE("lots of nested subcases") {
+TEST_CASE("lots of nested subcases") {
cout << endl << "root" << endl;
SUBCASE("") {
cout << "1" << endl;
diff --git a/doctest/doctest.h b/doctest/doctest.h
index fffe796..13ad5ce 100644
--- a/doctest/doctest.h
+++ b/doctest/doctest.h
@@ -160,9 +160,9 @@
#endif // _LIBCPP_VERSION
#ifndef DOCTEST_CONFIG_WITH_LONG_LONG
-#if defined(__cplusplus) && __cplusplus >= 201103L
+#if __cplusplus >= 201103L || defined(_MSC_EXTENSIONS) || (defined(_MSC_VER) && (_MSC_VER >= 1400))
#define DOCTEST_CONFIG_WITH_LONG_LONG
-#endif // __cplusplus
+#endif // __cplusplus / _MSC_VER
#endif // DOCTEST_CONFIG_WITH_LONG_LONG
namespace doctest