On 2020-04-13 at 18:54, Vinnie Falco via Boost wrote:
On Mon, Apr 13, 2020 at 9:44 AM Edward Diener via Boost
wrote: Maybe code coverage is not all it is cracked up to be <g>. Sorry, but I distrust something that is so unsubtle.
Code coverage is simply tool, and like all good things requires effort and attention to detail to use correctly. Depending on how the code is structured, yes the tool will claim a lack of coverage if the particular toolchain used to run the tests does not exercise a code path used for a separate work-around. There are of course ways to mitigate this. You can compile using both toolchains, and run the resulting tests, and accumulate the coverage reports into one merged report which does include the workaround code.
Another solution is to express the workaround code using function or class templates. These don't count as uncovered lines unless they are instantiated. Yes, I realize that this could be considered a "trick" (i.e. sleight of hand)
A problem here is that code coverage could be used either to see if the tests are complete, or to see if some parts of the code is never used at all. If some new code (like Edward's PR) makes some other code redundant, it is good if that shows up in the coverage report. Hiding dead code in templates that are now never instantiated is not that good. :-) Bo Persson