Prev: is this NP-Hard?
Next: An M/M/n queuing model simulation with Object Pascal and my Thread Pool Engine...
From: Keith Thompson on 2 May 2010 14:21
Ben Bacarisse <ben.usenet(a)bsb.me.uk> writes:
> Kenneth Brody <kenbrody(a)spamcop.net> writes:
>> On 5/1/2010 1:03 PM, Keith Thompson wrote:
>>> Juha Nieminen<nospam(a)thanks.invalid> writes:
>>>> In comp.lang.c++ Moi<root(a)invalid.address.org> wrote:
>>>>> Personally I tend to use:
>>>>>
>>>>> for ( begin_expr; test_expr; next_expr) {;}
>>>>>
>>>>> , which immediately makes clear that the empty loop is intended.
>>>>
>>>> And causes a compiler warning due to a lone ';' if enough warning flags
>>>> are used.
>>>
>>> It does? A lone semicolon in this context is a null statement, which is
>>> perfectly legal. Compilers can certainly warn about anything they like,
>>> but I don't see why it would warn about this.
>> [...]
>>
>> Consider:
>>
>> for ( begin_expr ; test_expr ; next_expr );
>> do_something();
>>
>> The "lone semicolon" could easily be a typo, and not easy to spot at
>> times. (Which is sort of what this sub-thread is all about.)
>
> The merits of various styles for empty loop bodies is frequently debated
> here, but here's a thought: does it actually matter? Has anyone ever
> encountered a hard bug caused by either the accidental inclusion of a
> semicolon (thereby excluding the while loop body) or by the omission of
> a null body (thereby sucking the following statement into the loop)? I
> don't think I ever have. I certainly don't recall one.
>
> I say "hard bug" because (of course) bugs are caused by this issue, one
> way or the other, but I imagine that they are always so detrimental to
> the intent of the code that they show up at the first test. Such bugs
> are not so different from syntax errors -- the compiler tests the syntax
> and your own tests test the basic functioning of a code fragment.
>
> Does anyone have a recollection of such a hard to find bug and, if so,
> do you recall enough to explain how it came about?
[...]

I have a vague recollection of a bug, discussed here, involving some
kind of iterative mathematical calculation, where each iteration
would yield a more accurate result. A lone semicolon on a loop
(could have been a either a for or a while) caused iterations after
the first not to be executed. The resulting answers were imprecise,
but not obviously wrong.

Something like this:

answer = first_approximation;
while (... more precision is needed ...); /* <-- OOPS! */
{
answer = better_approximation_of(answer);
}

Note that the indentation is still correct, and a typical compiler
probably wouldn't warn about it if the while condition might have
side effects.

--
Keith Thompson (The_Other_Keith) kst-u(a)mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
From: Richard Bos on 11 May 2010 10:05
Ben Bacarisse <ben.usenet(a)bsb.me.uk> wrote:

> Kenneth Brody <kenbrody(a)spamcop.net> writes:
>
> > Consider:
> >
> > for ( begin_expr ; test_expr ; next_expr );
> > do_something();
> >
> > The "lone semicolon" could easily be a typo, and not easy to spot at
> > times. (Which is sort of what this sub-thread is all about.)
>
> The merits of various styles for empty loop bodies is frequently debated
> here, but here's a thought: does it actually matter? Has anyone ever
> encountered a hard bug caused by either the accidental inclusion of a
> semicolon (thereby excluding the while loop body) or by the omission of
> a null body (thereby sucking the following statement into the loop)? I
> don't think I ever have. I certainly don't recall one.

Personally, no. But we seem to get a lot of newbies in here who do make
that mistake - usually in the form Kenneth mentions - and are confused
by it. One reason we ourselves don't is, I suspect, mainly that we have
enough experience that we _do_ take a single style that we find clear,
and stick to it.

Richard
First  |  Prev  | 
Pages: 1 2 3 4 5
Prev: is this NP-Hard?
Next: An M/M/n queuing model simulation with Object Pascal and my Thread Pool Engine...