Prev: Lockfree_mpmc was updated ...
Next: Young girls showing off their bodies on personal webcams
From: Keith Thompson on 11 May 2010 14:18
Nick Keighley <nick_keighley_nospam(a)hotmail.com> writes:
[...]
> I think he proposed
>
> for (loop_incomplete OR not_found)
> for (loop_incomplete OR not_found)
> for (loop_incomplete OR not_found)
> if ... found <- T
>
> that is an extra boolean (and some extra testing)
[...]

(In the above, "he" refers to Richard Heathfield; the above is obviously
a pseudocode summary of what Richard posted.)

One problem I have with the above is that the "OR not_found"
condition has to be written 3 times. I'm not very concerned
about the CPU time spent testing the variable. I'm more concerned
about the conceptual complexity of having to write the same thing
multiple times, with the attendant risk that a typo in one of the
three occurrences (forgetting the "!" operator, for example) won't
be caught by the compiler.

Richard has made it clear that that's a price he's willing to pay.
And I completely agree with him on that point; he *is* willing to
pay that price. Furthermore, I don't think it's an unreasonable
position. (But it's not how I'd do it.)

--
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 Heathfield on 11 May 2010 15:14
Keith Thompson wrote:

<snip>

> One problem I have with the above is that the "OR not_found"
> condition has to be written 3 times. I'm not very concerned
> about the CPU time spent testing the variable. I'm more concerned
> about the conceptual complexity of having to write the same thing
> multiple times, with the attendant risk that a typo in one of the
> three occurrences (forgetting the "!" operator, for example) won't
> be caught by the compiler.

In my experience, the more common mistake is:

for(x = 0; !found && x < xlim; x++)
{
for(y = 0; !found && y < xlim; y++)
{
for(z = 0; !found && z < xlim; z++)
{
if(haystack[x][y][z] == needle)
{
found = 1;
}
}
}
}

and of course you're going to be vulnerable to that with the SEME
version too.

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
"Usenet is a strange place" - dmr 29 July 1999
Sig line vacant - apply within
From: Willem on 11 May 2010 15:49
Richard Heathfield wrote:
) In my experience, the more common mistake is:
)
) for(x = 0; !found && x < xlim; x++)
) {
) for(y = 0; !found && y < xlim; y++)
) {
) for(z = 0; !found && z < xlim; z++)
) {
) if(haystack[x][y][z] == needle)
) {
) found = 1;
) }
) }
) }
) }
)
) and of course you're going to be vulnerable to that with the SEME
) version too.

I would, however, conjecture that you will be less vulnerable because
the SEME version doesn't have the 'found' condition cluttering it up:

for(x = 0; x < xlim; x++)
{
for(y = 0; y < xlim; y++)
{
for(z = 0; z < xlim; z++)
{
if(haystack[x][y][z] == needle)
{
goto end_loops;
}
}
}
}
end_loops:


SaSW, Willem
--
Disclaimer: I am in no way responsible for any of the statements
made in the above text. For all I know I might be
drugged or something..
No I'm not paranoid. You all think I'm paranoid, don't you !
#EOT
From: Richard Heathfield on 11 May 2010 16:38
Willem wrote:
> Richard Heathfield wrote:
<snip>

> )
> ) and of course you're going to be vulnerable to that with the SEME
> ) version too.
>
> I would, however, conjecture that you will be less vulnerable because
> the SEME version doesn't have the 'found' condition cluttering it up:

I haven't found this to be the case. (That is, I make this mistake
myself from time to time, and the number of conditions doesn't appear to
make any difference.)

<snip>

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
"Usenet is a strange place" - dmr 29 July 1999
Sig line vacant - apply within
From: Willem on 11 May 2010 17:58
Richard Heathfield wrote:
) Willem wrote:
)> Richard Heathfield wrote:
)<snip>
)
)> )
)> ) and of course you're going to be vulnerable to that with the SEME
)> ) version too.
)>
)> I would, however, conjecture that you will be less vulnerable because
)> the SEME version doesn't have the 'found' condition cluttering it up:
)
) I haven't found this to be the case. (That is, I make this mistake
) myself from time to time, and the number of conditions doesn't appear to
) make any difference.)

First, if it doesn't make a difference to you, but it does to me, then on
average there is a difference.

Second, there is also the issue of a maintenance programmer (I.E. not you)
having to look at the code and spotting that error. So it is actually
important to have an idea of what the average programmer would find easier
to understand. In this specific case, Early-Exit seems to have the
advantage.


SaSW, Willem
--
Disclaimer: I am in no way responsible for any of the statements
made in the above text. For all I know I might be
drugged or something..
No I'm not paranoid. You all think I'm paranoid, don't you !
#EOT
First  |  Prev  |  Next  |  Last
Pages: 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72
Prev: Lockfree_mpmc was updated ...
Next: Young girls showing off their bodies on personal webcams