anchor.diff:  
   There is also one extra feature when you use C++, the `assert_throws` function.
   
  -NOTE: If you use the runner, as described in <<runner>>, and thus link your tests into a shared library, don't forget to link it with the same C++ library that was used to create the `cgreen-runner`.
  +NOTE: If you use the autodiscovering runner, as described in <<runner>>, and thus link your tests into a shared library, don't forget to link it with the same C++ library that was used to create the `cgreen-runner`.
   
   == Context, System Under Test & Suites
   
  
positive.code: It's automatic, and there is nothing to forget.
  
  
  === Using the Runner
  
  Assuming your tests are in `first_test.c` the typical command to build your library using `gcc` would be
  
negative.code: So, it's coverage __or__ POSIX-correct child exits and guaranteed output consistency.
  You can't have both...
  
  [appendix]
  == Legacy Style Assertions
  
  Cgreen have been around for a while, developed and matured.
  There is an older style of assertions that was the initial version, a style that we now call the 'legacy style', because it was more aligned with the original, now older, unit test frameworks.
  If you are not interested in historical artifacts, I recommend that you skip this section.
  
  But for completeness of documentation, here are the legacy style assertion macros:
  
  |=========================================================
  |*Assertion* |*Description*
  | `assert_true(boolean)` | Passes if boolean evaluates true
  | `assert_false(boolean)` | Fails if boolean evaluates true
  | `assert_equal(first, second)` | Passes if 'first == second'
  | `assert_not_equal(first, second)` | Passes if 'first != second'
  | `assert_string_equal(char *, char *)` | Uses 'strcmp()' and passes if
                                            the strings are equal
  | `assert_string_not_equal(char *, char *)` | Uses 'strcmp()' and fails
                                                if the strings are equal
  |=========================================================
  
  Each assertion has a default message comparing the two values.
  If you want to substitute your own failure messages, then you must use the `*_with_message()` counterparts...
  
  |=========================================================
  |*Assertion*
  | `assert_true_with_message(boolean, message, ...)`
  | `assert_false_with_message(boolean, message, ...)`
  | `assert_equal_with_message(tried, expected, message, ...)`
  | `assert_not_equal_with_message(tried, unexpected, message, ...)`
  | `assert_string_equal_with_message(char *, char *, message, ...)`
  | `assert_string_not_equal_with_message(char *, char *, message, ...)`
  |=========================================================
  
  All these assertions have an additional `char *` message parameter, which is the message you wished to display on failure.
  If this is set to `NULL`, then the default message is shown instead.
  The most useful assertion from this group is `assert_true_with_message()` as you can use that to create your own assertion functions with your own messages.
  
  Actually the assertion macros have variable argument lists.
  The failure message acts like the template in `printf()`.
  We could change the test above to be...
  
  [source,c]
  -----------------------------
  include::tutorial_src/strlen_tests4.c[lines=4..8]
  -----------------------------
  
  This should produce a slightly more user friendly message when things go wrong.
  But, actually, Cgreens default messages are so good that you are encouraged to skip the legacy style and go for the more modern constraints style assertions.
  This is particularly true when you use the BDD style test notation.
  
  IMPORTANT: We strongly recommend the use of BDD Style notation with constraints based assertions.
  
  
  [appendix]
  