On Friday, 1 July 2016 at 20:30:30 UTC, Steven Schveighoffer
wrote:
On 7/1/16 4:08 PM, Andrei Alexandrescu wrote:
On 7/1/16 2:46 PM, Steven Schveighoffer wrote:
On 7/1/16 2:15 PM, Andrei Alexandrescu wrote:
On 7/1/16 2:05 PM, Chris wrote:
On Friday, 1 July 2016 at 16:30:41 UTC, Andrei Alexandrescu
wrote:
https://issues.dlang.org/show_bug.cgi?id=16224 -- Andrei
I fail to see why it should not mark it as uncovered in the
`cube`
example. After all the statement is never covered, because
`do`
executes
before the condition in `while` is checked. Unless you mean
it
should be
optimized away by the compiler, which in turn has nothing
to do with
-cov.
Yah it's a bit subtle. That line is in fact pure
punctuation, so even
though there's no flow through it that's totally fine (as
much as you
wouldn't expect a line with a "}" to show no coverage). --
Andrei
Suppose one wants to check if you've covered all cases inside
the while
loop (with breaks or returns). Then, one would WANT to see 0
coverage
there (non-zero coverage would mean an error in logic).
To remove that feedback would mess up someone else's use case.
This argument is phony. Unconvinced. -- Andrei
I don't use while(0), so I have to invent a hypothetical use
case. It's not phony. I could just as easily say that your
coding style is illegitimate, and you should use while(true)
instead (and thereby get 100% coverage analysis). But I'm not
saying that.
There is a legitimate difference between breaking out of the
while loop using breaks, and breaking out using the while(0)
condition. Why do you want coverage analysis to ignore that
difference? Why would someone else's use case that relies on
executing or not executing while(0) be invalid?
-Steve
The do {} while(0) "trick" is generally used in C as a poor mans
scope(exit) construct without using goto. It is to have one point
where the resources used by a function can be freed without
duplicating the code everywhere, especially if the function has
multiple return points. So in practice it is only "useful" on
complex functions with acquisition of resources (memory, files
etc) and several exit points (error variants). These kind of
functions already have difficult execution flows and adding a
level of obfuscation on top of it is not the right solution.
Using a goto, while not being the best solution, has at least the
merrit of providing a searchable and meaningfull label (goto
error or goto finally or goto cleanup are obvious, break not so
much) to find the exit. With break it's a little bit more
difficult. Add loops and switch's to the equation and you're in
for a very confusing debugging session.