Two styles of condition checking
Paul
How about in pascal or other similar languages?
I very often see the first, but the second seems much clearer and more tidy.
P.
One:
if (a)
{
if (b)
{
if (c)
{
x;
}
else
{
f;
}
}
else
{
e;
}
}
else
{
d;
}
Two:
if (!a)
{
d;
}
else if (!b)
{
e;
}
else if (!c)
{
f;
}
else
{
x;
}
Richard Heathfield
> Are the following two snippets equivelent in C?
Yes, provided that x, f, e, and d aren't concealing redirections of
control flow, in which case the answer may well be no. I haven't
actually constructed a counter-example but, if I were going to try,
I'd start with #defines of x, f, e, d that contain gotos, returns,
etc.
<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
Fred
> In <-fednb-yZumhiLTWnZ2dnUVZ8gOdn...@bt.com>, "Paul" <-> wrote:
>
> > Are the following two snippets equivelent in C?
>
> Yes, provided that x, f, e, and d aren't concealing redirections of
> control flow, in which case the answer may well be no. I haven't
> actually constructed a counter-example but, if I were going to try,
> I'd start with #defines of x, f, e, d that contain gotos, returns,
> etc.
>
And providing that the evaluation of a,b,c,d,e,and f have no side
effects that may alter the result of evaluation of one of the others.
--
Fred K
Squeamizh
>
> > Are the following two snippets equivelent in C?
>
> Yes, provided that x, f, e, and d aren't concealing redirections of
> control flow, in which case the answer may well be no. I haven't
> actually constructed a counter-example but, if I were going to try,
> I'd start with #defines of x, f, e, d that contain gotos, returns,
> etc.
>
The definitions of x, f, e, and d do not matter. Out of those four,
the same single block is executed in both code snippets. Perhaps you
meant a, b, and c instead?
Paul N
> On Dec 16, 9:39 am, Richard Heathfield <r...@see.sig.invalid> wrote:
>
> > In <-fednb-yZumhiLTWnZ2dnUVZ8gOdn...@bt.com>, "Paul" <-> wrote:
>
> > > Are the following two snippets equivelent in C?
>
> > Yes, provided that x, f, e, and d aren't concealing redirections of
> > control flow, in which case the answer may well be no.
>
> effects that may alter the result of evaluation of one of the others.
I wouldn't have thought that made any difference, as the same things
seem to get evaluated in the same order. Am I missing something?
Fred
Ah-- You're right.
--
Fred K
Fred
(off-topic)
However, this might not be true in C++, where the == and != operators
can be overloaded and one could produce side effects that the other
did not.
> - Show quoted text -
--
Fred K
Richard Heathfield
Fred wrote:
Oops, quite right - that is indeed another way to break it.
Ben Bacarisse
> In <c29a40b3-b23a-41e7...@u8g2000prd.googlegroups.com>,
> Fred wrote:
>
>> On Dec 16, 9:39 am, Richard Heathfield <r...@see.sig.invalid> wrote:
>>> In <-fednb-yZumhiLTWnZ2dnUVZ8gOdn...@bt.com>, "Paul" <-> wrote:
>>>
>>> > Are the following two snippets equivelent in C?
>>>
>>> Yes, provided that x, f, e, and d aren't concealing redirections of
>>> control flow, in which case the answer may well be no. I haven't
>>> actually constructed a counter-example but, if I were going to try,
>>> I'd start with #defines of x, f, e, d that contain gotos, returns,
>>> etc.
>>>
>>
>> And providing that the evaluation of a,b,c,d,e,and f have no side
>> effects that may alter the result of evaluation o=f one of the
>> others
>
> Oops, quite right - that is indeed another way to break it.
#define can obviously break it as can any textual (rather than
syntactic) substitution[1], but I don't see how side-effects alone can
break the equivalence. Can you give an example?
If you take the !a to be very literal (whist still not being textual)
you can make the !a form exceed an environmental limit by having one
of the tests be setjmp(env) == 42. The literal negation of that is
!(setjmp(env) == 42) which is more complex than any of the forms that
are guaranteed to work, but then I think even that is outside the
spirit of the question. The negation of the test should, I think, be
written setjmp(env) != 42 in this case.
[1] For example, saying "let a be p + q" causes !a to be quite
different from !(a) but I think the OP's meaning is that '!a' be the
negation of 'a', rather than the tokens of 'a' with a '!' in front of
them.
--
Ben.
Richard Heathfield
<0.66131b10266cdb7e2289.2009...@bsb.me.uk>,
Ben Bacarisse wrote:
> Richard Heathfield <r...@see.sig.invalid> writes:
>
>> In
>> <c29a40b3-b23a-41e7...@u8g2000prd.googlegroups.com>,
>> Fred wrote:
>>
>>> On Dec 16, 9:39 am, Richard Heathfield <r...@see.sig.invalid>
>>> wrote:
>>>> In <-fednb-yZumhiLTWnZ2dnUVZ8gOdn...@bt.com>, "Paul" <-> wrote:
>>>>
>>>> > Are the following two snippets equivelent in C?
>>>>
>>>> Yes, provided that x, f, e, and d aren't concealing redirections
>>>> of control flow, in which case the answer may well be no. I
>>>> haven't actually constructed a counter-example but, if I were
>>>> going to try, I'd start with #defines of x, f, e, d that contain
>>>> gotos, returns, etc.
>>>>
>>>
>>> And providing that the evaluation of a,b,c,d,e,and f have no side
>>> effects that may alter the result of evaluation o=f one of the
>>> others
>>
>> Oops, quite right - that is indeed another way to break it.
>
> #define can obviously break it as can any textual (rather than
> syntactic) substitution[1], but I don't see how side-effects alone
> can break the equivalence. Can you give an example?
Not after five minutes, which is all I was prepared to spend on it. So
I could be mistaken.
In general, I think the OP's question might reasonably be answered as
"if your coding style is reasonably conservative and if you're not
actually setting out to break the equivalence, they're effectively
equivalent".
Ian Collins
>
> In general, I think the OP's question might reasonably be answered as
> "if your coding style is reasonably conservative and if you're not
> actually setting out to break the equivalence, they're effectively
> equivalent".
You should get a job at the Copenhagen conference!
--
Ian Collins
Hallvard B Furuseth
>>> I wouldn't have thought that made any difference, as the same things
>>> seem to get evaluated in the same order. Am I missing something?
>
> However, this might not be true in C++, where the == and != operators
> can be overloaded and one could produce side effects that the other
> did not.
In this case it's operator ! which must be redefined to make a
difference.
(/off-topic)
Beyond that I only see cases already mentioned.
setjmp() which must be written a bit differently, and textual games:
if (i ? j : k) -> (!i ? j : k) without extra parenthesis is wrong,
and #define x } if (y) { can mess tings up.
Also rearranging the code blocks can make a difference in execution time
(branch prediction, jumps taken/not taken) - unless compiler rearranges
the code all to hell anyway, which it often will.
--
Hallvard