* Re: Could you please explain this code segment
@ 2009-12-17 20:11 Bill McEnaney
2009-12-17 20:22 ` Brian Budge
0 siblings, 1 reply; 11+ messages in thread
From: Bill McEnaney @ 2009-12-17 20:11 UTC (permalink / raw)
To: Bob Plantz, Joel Dice, W.H. Kalpa Pathum, gcc-help
Where's the meaningless(?) code?
> On Thu, 2009-12-17 at 10:40 -0700, Joel Dice wrote:
> > On Thu, 17 Dec 2009, Bob Plantz wrote:
> >
> > >
> > >
> > > I have seen many, many examples, both in industry and in academia,
where
> > > programmers write tricky code claiming it is more efficient. I
claim (a)
> > > efficiency is seldom an issue, and (b) looking at the generated
assembly
> > > language almost always shows it is not more efficient.
> > >
> > > I believe that the best code is that which (a) correctly solves the
> > > problem, and (b) is the most simple-minded in appearance.
> >
> > Perhaps, but the code in question here is not merely obscure - it's
simply
> > meaningless. I think it's a mistake to put such code in the same
category
> > as e.g. an affine transform implemented in inline assembly which has
> > well-defined meaning. The latter may pose a challenge for a
maintenance
> > programmer, but at least it will yield to persistence. In contrast,
> > undefined code is no better than a "todo" comment - you're only
option is
> > to replace it completely with something well-defined based on the
> > documentation and/or context.
> >
>
> I agree that there are situations where obscure code is the best,
> perhaps the only, way to solve the problem. For example, in 1984 I had a
> consulting job where one of my assignments was to write a logarithm
> function for an embedded MC68000 environment. The only way I could get
> the required speed and accuracy was to use double-precision integer
> arithmetic. I wrote it in assembly language and used several "magic
> numbers" to keep intermediate values in range while maximizing
> arithmetic significance. My comments took more space in the listing than
> the actual code. To their credit, the programming team asked for even
> more documentation during my walk-through of my code.
>
> These situations are uncommon -- and lots of fun to solve!
>
> The most common uses of obscure code that I've seen are programmers
> showing off their "understanding" of the language being used. I believe
> that a good programmer does not ask what his/her code does, but rather
> explains it -- either through simple, easy-to-read code, or with
> thorough commenting. I use the term "good" to mean relative to the
> programmer's skill level.
>
> --Bob
>
>
>
________________________________________________________________
Please visit a saintly hero:
http://www.jakemoore.org
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Could you please explain this code segment
2009-12-17 20:11 Could you please explain this code segment Bill McEnaney
@ 2009-12-17 20:22 ` Brian Budge
2009-12-17 20:28 ` Joel Dice
0 siblings, 1 reply; 11+ messages in thread
From: Brian Budge @ 2009-12-17 20:22 UTC (permalink / raw)
To: Bill McEnaney; +Cc: Bob Plantz, Joel Dice, W.H. Kalpa Pathum, gcc-help
If multiple increment and decrement operators (++ --) are used in the
same statement, it's undefined which ones happen first. Therefore:
int a = 0;
cout << a++ << a++ << endl;
could produce 0 1 or it could produce 1 0. It would be very bad to
rely on any specific compiler behavior as this would be extremely
fragile code. The only guarantee is that the variable is modified
before or after the usage.
Because it's undefined what should happen, it could be considered meaningless.
Brian
On Thu, Dec 17, 2009 at 11:52 AM, Bill McEnaney <bill@rkirkpat.net> wrote:
> Where's the meaningless(?) code?
>
>> On Thu, 2009-12-17 at 10:40 -0700, Joel Dice wrote:
>> > On Thu, 17 Dec 2009, Bob Plantz wrote:
>> >
>> > >
>> > >
>> > > I have seen many, many examples, both in industry and in academia,
> where
>> > > programmers write tricky code claiming it is more efficient. I
> claim (a)
>> > > efficiency is seldom an issue, and (b) looking at the generated
> assembly
>> > > language almost always shows it is not more efficient.
>> > >
>> > > I believe that the best code is that which (a) correctly solves the
>> > > problem, and (b) is the most simple-minded in appearance.
>> >
>> > Perhaps, but the code in question here is not merely obscure - it's
> simply
>> > meaningless. I think it's a mistake to put such code in the same
> category
>> > as e.g. an affine transform implemented in inline assembly which has
>> > well-defined meaning. The latter may pose a challenge for a
> maintenance
>> > programmer, but at least it will yield to persistence. In contrast,
>> > undefined code is no better than a "todo" comment - you're only
> option is
>> > to replace it completely with something well-defined based on the
>> > documentation and/or context.
>> >
>>
>> I agree that there are situations where obscure code is the best,
>> perhaps the only, way to solve the problem. For example, in 1984 I had a
>> consulting job where one of my assignments was to write a logarithm
>> function for an embedded MC68000 environment. The only way I could get
>> the required speed and accuracy was to use double-precision integer
>> arithmetic. I wrote it in assembly language and used several "magic
>> numbers" to keep intermediate values in range while maximizing
>> arithmetic significance. My comments took more space in the listing than
>> the actual code. To their credit, the programming team asked for even
>> more documentation during my walk-through of my code.
>>
>> These situations are uncommon -- and lots of fun to solve!
>>
>> The most common uses of obscure code that I've seen are programmers
>> showing off their "understanding" of the language being used. I believe
>> that a good programmer does not ask what his/her code does, but rather
>> explains it -- either through simple, easy-to-read code, or with
>> thorough commenting. I use the term "good" to mean relative to the
>> programmer's skill level.
>>
>> --Bob
>>
>>
>>
>
> ________________________________________________________________
> Please visit a saintly hero:
> http://www.jakemoore.org
>
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Could you please explain this code segment
2009-12-17 20:22 ` Brian Budge
@ 2009-12-17 20:28 ` Joel Dice
0 siblings, 0 replies; 11+ messages in thread
From: Joel Dice @ 2009-12-17 20:28 UTC (permalink / raw)
To: Brian Budge
Cc: Bill McEnaney, Bob Plantz, Joel Dice, W.H. Kalpa Pathum, gcc-help
[-- Attachment #1: Type: TEXT/PLAIN, Size: 3429 bytes --]
On Thu, 17 Dec 2009, Brian Budge wrote:
> If multiple increment and decrement operators (++ --) are used in the
> same statement, it's undefined which ones happen first. Therefore:
>
> int a = 0;
> cout << a++ << a++ << endl;
>
> could produce 0 1 or it could produce 1 0. It would be very bad to
> rely on any specific compiler behavior as this would be extremely
> fragile code. The only guarantee is that the variable is modified
> before or after the usage.
It's worse than that - it could produce 0 42, or 3.14 555, or "you lose",
or nothing at all. A compiler can do whatever it wants with such code and
still conform to the language. See also:
http://en.wikipedia.org/wiki/Undefined_behavior
>
> Because it's undefined what should happen, it could be considered meaningless.
>
> Brian
>
> On Thu, Dec 17, 2009 at 11:52 AM, Bill McEnaney <bill@rkirkpat.net> wrote:
>> Where's the meaningless(?) code?
>>
>>> On Thu, 2009-12-17 at 10:40 -0700, Joel Dice wrote:
>>>> On Thu, 17 Dec 2009, Bob Plantz wrote:
>>>>
>>>>>
>>>>>
>>>>> I have seen many, many examples, both in industry and in academia,
>> where
>>>>> programmers write tricky code claiming it is more efficient. I
>> claim (a)
>>>>> efficiency is seldom an issue, and (b) looking at the generated
>> assembly
>>>>> language almost always shows it is not more efficient.
>>>>>
>>>>> I believe that the best code is that which (a) correctly solves the
>>>>> problem, and (b) is the most simple-minded in appearance.
>>>>
>>>> Perhaps, but the code in question here is not merely obscure - it's
>> simply
>>>> meaningless. Â I think it's a mistake to put such code in the same
>> category
>>>> as e.g. an affine transform implemented in inline assembly which has
>>>> well-defined meaning. Â The latter may pose a challenge for a
>> maintenance
>>>> programmer, but at least it will yield to persistence. Â In contrast,
>>>> undefined code is no better than a "todo" comment - you're only
>> option is
>>>> to replace it completely with something well-defined based on the
>>>> documentation and/or context.
>>>>
>>>
>>> I agree that there are situations where obscure code is the best,
>>> perhaps the only, way to solve the problem. For example, in 1984 I had a
>>> consulting job where one of my assignments was to write a logarithm
>>> function for an embedded MC68000 environment. The only way I could get
>>> the required speed and accuracy was to use double-precision integer
>>> arithmetic. I wrote it in assembly language and used several "magic
>>> numbers" to keep intermediate values in range while maximizing
>>> arithmetic significance. My comments took more space in the listing than
>>> the actual code. To their credit, the programming team asked for even
>>> more documentation during my walk-through of my code.
>>>
>>> These situations are uncommon -- and lots of fun to solve!
>>>
>>> The most common uses of obscure code that I've seen are programmers
>>> showing off their "understanding" of the language being used. I believe
>>> that a good programmer does not ask what his/her code does, but rather
>>> explains it -- either through simple, easy-to-read code, or with
>>> thorough commenting. I use the term "good" to mean relative to the
>>> programmer's skill level.
>>>
>>> --Bob
>>>
>>>
>>>
>>
>> ________________________________________________________________
>> Please visit a saintly hero:
>> http://www.jakemoore.org
>>
>
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Could you please explain this code segment
2009-12-17 22:02 Bill McEnaney
@ 2009-12-18 5:11 ` Joel Dice
0 siblings, 0 replies; 11+ messages in thread
From: Joel Dice @ 2009-12-18 5:11 UTC (permalink / raw)
To: Bill McEnaney
Cc: Brian Budge, Bob Plantz, Joel Dice, W.H. Kalpa Pathum, gcc-help
[-- Attachment #1: Type: TEXT/PLAIN, Size: 5678 bytes --]
On Thu, 17 Dec 2009, Bill McEnaney wrote:
>
> Maybe it's too meaningful, i.e., too ambiguous. Were it literally
> meaningless, would it be compilable and executable?
It's not possible to detect all cases undefined behavior at compile time,
although GCC will warn you about many of them with -Wall:
$ cat test.cpp
#include "stdio.h"
int
main()
{
int a = 0;
printf("%d %d", a++, a++);
return 0;
}
$ gcc -Wall test.cpp
test.cpp: In function Β‘int main()Β’:
test.cpp:7: warning: operation on Β‘aΒ’ may be undefined
As I understand it, the reason the C standard leaves room for undefined
behavior is that it gives compiler writers freedom to optimize code in
ways which would be impossible if everything was precisely defined. The
standard committee could easily have defined every operator and comma as a
sequence point, but then there would be no way to tell the compiler, "This
code will behave the same way no matter what order the subexpressions are
evaluated, so do whatever is most efficient." When the order of
evaluation does matter, you can divide the code into separate,
semicolon-delimited statements and get exactly what you want. If you lie
to the compiler by saying order doesn't matter when it does, you might get
what you want or you might get garbage.
C is more than a cross-platform assembly language where every operation
maps directly to a series of machine instructions. If it was, writing a
compiler would be easy - and writing efficient, portable application code
would be much harder.
By the way, here it is from the horse's mouth [1]:
3.4.3
1 undefined behavior
behavior, upon use of a nonportable or erroneous program construct or of
erroneous data,
for which this International Standard imposes no requirements
NOTE Possible undefined behavior ranges from ignoring the situation
completely with unpredictable
2
results, to behaving during translation or program execution in a
documented manner characteristic of the
environment (with or without the issuance of a diagnostic message), to
terminating a translation or
execution (with the issuance of a diagnostic message).
EXAMPLE An example of undefined behavior is the behavior on
integer overflow.
3
[1] http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1124.pdf
>
> If multiple increment and decrement operators (++ --) are used in the
>> same statement, it's undefined which ones happen first. Therefore:
>>
>> int a = 0;
>> cout << a++ << a++ << endl;
>>
>> could produce 0 1 or it could produce 1 0. It would be very bad to
>> rely on any specific compiler behavior as this would be extremely
>> fragile code. The only guarantee is that the variable is modified
>> before or after the usage.
>>
>> Because it's undefined what should happen, it could be considered
> meaningless.
>>
>> Brian
>>
>> On Thu, Dec 17, 2009 at 11:52 AM, Bill McEnaney <bill@rkirkpat.net> wrote:
>>> Where's the meaningless(?) code?
>>>
>>>> On Thu, 2009-12-17 at 10:40 -0700, Joel Dice wrote:
>>>>> On Thu, 17 Dec 2009, Bob Plantz wrote:
>>>>>
>>>>>>
>>>>>>
>>>>>> I have seen many, many examples, both in industry and in academia,
>>> where
>>>>>> programmers write tricky code claiming it is more efficient. I
>>> claim (a)
>>>>>> efficiency is seldom an issue, and (b) looking at the generated
>>> assembly
>>>>>> language almost always shows it is not more efficient.
>>>>>>
>>>>>> I believe that the best code is that which (a) correctly solves the
>>>>>> problem, and (b) is the most simple-minded in appearance.
>>>>>
>>>>> Perhaps, but the code in question here is not merely obscure - it's
>>> simply
>>>>> meaningless. I think it's a mistake to put such code in the same
>>> category
>>>>> as e.g. an affine transform implemented in inline assembly which has
>>>>> well-defined meaning. The latter may pose a challenge for a
>>> maintenance
>>>>> programmer, but at least it will yield to persistence. In contrast,
>>>>> undefined code is no better than a "todo" comment - you're only
>>> option is
>>>>> to replace it completely with something well-defined based on the
>>>>> documentation and/or context.
>>>>>
>>>>
>>>> I agree that there are situations where obscure code is the best,
>>>> perhaps the only, way to solve the problem. For example, in 1984 I
> had a
>>>> consulting job where one of my assignments was to write a logarithm
>>>> function for an embedded MC68000 environment. The only way I could get
>>>> the required speed and accuracy was to use double-precision integer
>>>> arithmetic. I wrote it in assembly language and used several "magic
>>>> numbers" to keep intermediate values in range while maximizing
>>>> arithmetic significance. My comments took more space in the listing
> than
>>>> the actual code. To their credit, the programming team asked for even
>>>> more documentation during my walk-through of my code.
>>>>
>>>> These situations are uncommon -- and lots of fun to solve!
>>>>
>>>> The most common uses of obscure code that I've seen are programmers
>>>> showing off their "understanding" of the language being used. I believe
>>>> that a good programmer does not ask what his/her code does, but rather
>>>> explains it -- either through simple, easy-to-read code, or with
>>>> thorough commenting. I use the term "good" to mean relative to the
>>>> programmer's skill level.
>>>>
>>>> --Bob
>>>>
>>>>
>>>>
>>>
>>> ________________________________________________________________
>>> Please visit a saintly hero:
>>> http://www.jakemoore.org
>>>
>>
>>
>
> ________________________________________________________________
> Please visit a saintly hero:
> http://www.jakemoore.org
>
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Could you please explain this code segment
@ 2009-12-17 22:02 Bill McEnaney
2009-12-18 5:11 ` Joel Dice
0 siblings, 1 reply; 11+ messages in thread
From: Bill McEnaney @ 2009-12-17 22:02 UTC (permalink / raw)
To: Brian Budge, Bill McEnaney, Bob Plantz, Joel Dice,
W.H. Kalpa Pathum, gcc-help
Maybe it's too meaningful, i.e., too ambiguous. Were it literally
meaningless, would it be compilable and executable?
If multiple increment and decrement operators (++ --) are used in the
> same statement, it's undefined which ones happen first. Therefore:
>
> int a = 0;
> cout << a++ << a++ << endl;
>
> could produce 0 1 or it could produce 1 0. It would be very bad to
> rely on any specific compiler behavior as this would be extremely
> fragile code. The only guarantee is that the variable is modified
> before or after the usage.
>
> Because it's undefined what should happen, it could be considered
meaningless.
>
> Brian
>
> On Thu, Dec 17, 2009 at 11:52 AM, Bill McEnaney <bill@rkirkpat.net> wrote:
> > Where's the meaningless(?) code?
> >
> >> On Thu, 2009-12-17 at 10:40 -0700, Joel Dice wrote:
> >> > On Thu, 17 Dec 2009, Bob Plantz wrote:
> >> >
> >> > >
> >> > >
> >> > > I have seen many, many examples, both in industry and in academia,
> > where
> >> > > programmers write tricky code claiming it is more efficient. I
> > claim (a)
> >> > > efficiency is seldom an issue, and (b) looking at the generated
> > assembly
> >> > > language almost always shows it is not more efficient.
> >> > >
> >> > > I believe that the best code is that which (a) correctly solves the
> >> > > problem, and (b) is the most simple-minded in appearance.
> >> >
> >> > Perhaps, but the code in question here is not merely obscure - it's
> > simply
> >> > meaningless. I think it's a mistake to put such code in the same
> > category
> >> > as e.g. an affine transform implemented in inline assembly which has
> >> > well-defined meaning. The latter may pose a challenge for a
> > maintenance
> >> > programmer, but at least it will yield to persistence. In contrast,
> >> > undefined code is no better than a "todo" comment - you're only
> > option is
> >> > to replace it completely with something well-defined based on the
> >> > documentation and/or context.
> >> >
> >>
> >> I agree that there are situations where obscure code is the best,
> >> perhaps the only, way to solve the problem. For example, in 1984 I
had a
> >> consulting job where one of my assignments was to write a logarithm
> >> function for an embedded MC68000 environment. The only way I could get
> >> the required speed and accuracy was to use double-precision integer
> >> arithmetic. I wrote it in assembly language and used several "magic
> >> numbers" to keep intermediate values in range while maximizing
> >> arithmetic significance. My comments took more space in the listing
than
> >> the actual code. To their credit, the programming team asked for even
> >> more documentation during my walk-through of my code.
> >>
> >> These situations are uncommon -- and lots of fun to solve!
> >>
> >> The most common uses of obscure code that I've seen are programmers
> >> showing off their "understanding" of the language being used. I believe
> >> that a good programmer does not ask what his/her code does, but rather
> >> explains it -- either through simple, easy-to-read code, or with
> >> thorough commenting. I use the term "good" to mean relative to the
> >> programmer's skill level.
> >>
> >> --Bob
> >>
> >>
> >>
> >
> > ________________________________________________________________
> > Please visit a saintly hero:
> > http://www.jakemoore.org
> >
>
>
________________________________________________________________
Please visit a saintly hero:
http://www.jakemoore.org
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Could you please explain this code segment
2009-12-17 18:52 ` Joel Dice
@ 2009-12-17 19:53 ` Bob Plantz
0 siblings, 0 replies; 11+ messages in thread
From: Bob Plantz @ 2009-12-17 19:53 UTC (permalink / raw)
To: Joel Dice; +Cc: W.H. Kalpa Pathum, gcc-help
On Thu, 2009-12-17 at 10:40 -0700, Joel Dice wrote:
> On Thu, 17 Dec 2009, Bob Plantz wrote:
>
> >
> >
> > I have seen many, many examples, both in industry and in academia, where
> > programmers write tricky code claiming it is more efficient. I claim (a)
> > efficiency is seldom an issue, and (b) looking at the generated assembly
> > language almost always shows it is not more efficient.
> >
> > I believe that the best code is that which (a) correctly solves the
> > problem, and (b) is the most simple-minded in appearance.
>
> Perhaps, but the code in question here is not merely obscure - it's simply
> meaningless. I think it's a mistake to put such code in the same category
> as e.g. an affine transform implemented in inline assembly which has
> well-defined meaning. The latter may pose a challenge for a maintenance
> programmer, but at least it will yield to persistence. In contrast,
> undefined code is no better than a "todo" comment - you're only option is
> to replace it completely with something well-defined based on the
> documentation and/or context.
>
I agree that there are situations where obscure code is the best,
perhaps the only, way to solve the problem. For example, in 1984 I had a
consulting job where one of my assignments was to write a logarithm
function for an embedded MC68000 environment. The only way I could get
the required speed and accuracy was to use double-precision integer
arithmetic. I wrote it in assembly language and used several "magic
numbers" to keep intermediate values in range while maximizing
arithmetic significance. My comments took more space in the listing than
the actual code. To their credit, the programming team asked for even
more documentation during my walk-through of my code.
These situations are uncommon -- and lots of fun to solve!
The most common uses of obscure code that I've seen are programmers
showing off their "understanding" of the language being used. I believe
that a good programmer does not ask what his/her code does, but rather
explains it -- either through simple, easy-to-read code, or with
thorough commenting. I use the term "good" to mean relative to the
programmer's skill level.
--Bob
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Could you please explain this code segment
2009-12-17 17:04 ` Bob Plantz
@ 2009-12-17 18:52 ` Joel Dice
2009-12-17 19:53 ` Bob Plantz
0 siblings, 1 reply; 11+ messages in thread
From: Joel Dice @ 2009-12-17 18:52 UTC (permalink / raw)
To: Bob Plantz; +Cc: W.H. Kalpa Pathum, gcc-help
On Thu, 17 Dec 2009, Bob Plantz wrote:
> On Thu, 2009-12-17 at 12:23 +0530, W.H. Kalpa Pathum wrote:
>> The following block of code when compiled with gcc (gcc version 4.4.2
>> 20091027 (Red Hat 4.4.2-7) (GCC) ) resulted in the following output.
>> Could you please explain how the output differs (when assigned to the
>> variable b and in printf statement) and the way the compiler executes
>> each segment of the variable?
>>
>> int main(){
>> int a = 10;
>> int b = (++a) + (++a);
>> printf("%d %d %d %d\n", b, a++, a, ++a);
>> printf("%d %d %d %d\n", ++a + ++a, a++, a, ++a);
>> return 0;
>> }
>>
>> OUTPUT
>> 24 13 14 14
>> 36 15 18 18
>
> I spent much of my life trying to convince CS students that they should
> never write code like this. Not because of implementation issues, but
> because it's nearly impossible for the maintenance programmer to
> determine the intent of the algorithm here. And I always pointed out
> that the maintenance programmer might be them in a few weeks.
>
> I have seen many, many examples, both in industry and in academia, where
> programmers write tricky code claiming it is more efficient. I claim (a)
> efficiency is seldom an issue, and (b) looking at the generated assembly
> language almost always shows it is not more efficient.
>
> I believe that the best code is that which (a) correctly solves the
> problem, and (b) is the most simple-minded in appearance.
Perhaps, but the code in question here is not merely obscure - it's simply
meaningless. I think it's a mistake to put such code in the same category
as e.g. an affine transform implemented in inline assembly which has
well-defined meaning. The latter may pose a challenge for a maintenance
programmer, but at least it will yield to persistence. In contrast,
undefined code is no better than a "todo" comment - you're only option is
to replace it completely with something well-defined based on the
documentation and/or context.
>
> Thus my answer to your question is that you should rewrite the code such
> that it clearly shows what you are trying to do. This example would not
> have received a high grade in any of my classes.
>
> --Bob
>
>
>
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Could you please explain this code segment
2009-12-17 8:22 W.H. Kalpa Pathum
2009-12-17 8:46 ` Ineiev
2009-12-17 12:20 ` John (Eljay) Love-Jensen
@ 2009-12-17 17:04 ` Bob Plantz
2009-12-17 18:52 ` Joel Dice
2 siblings, 1 reply; 11+ messages in thread
From: Bob Plantz @ 2009-12-17 17:04 UTC (permalink / raw)
To: W.H. Kalpa Pathum; +Cc: gcc-help
On Thu, 2009-12-17 at 12:23 +0530, W.H. Kalpa Pathum wrote:
> The following block of code when compiled with gcc (gcc version 4.4.2
> 20091027 (Red Hat 4.4.2-7) (GCC) ) resulted in the following output.
> Could you please explain how the output differs (when assigned to the
> variable b and in printf statement) and the way the compiler executes
> each segment of the variable?
>
> int main(){
> int a = 10;
> int b = (++a) + (++a);
> printf("%d %d %d %d\n", b, a++, a, ++a);
> printf("%d %d %d %d\n", ++a + ++a, a++, a, ++a);
> return 0;
> }
>
> OUTPUT
> 24 13 14 14
> 36 15 18 18
I spent much of my life trying to convince CS students that they should
never write code like this. Not because of implementation issues, but
because it's nearly impossible for the maintenance programmer to
determine the intent of the algorithm here. And I always pointed out
that the maintenance programmer might be them in a few weeks.
I have seen many, many examples, both in industry and in academia, where
programmers write tricky code claiming it is more efficient. I claim (a)
efficiency is seldom an issue, and (b) looking at the generated assembly
language almost always shows it is not more efficient.
I believe that the best code is that which (a) correctly solves the
problem, and (b) is the most simple-minded in appearance.
Thus my answer to your question is that you should rewrite the code such
that it clearly shows what you are trying to do. This example would not
have received a high grade in any of my classes.
--Bob
^ permalink raw reply [flat|nested] 11+ messages in thread
* RE: Could you please explain this code segment
2009-12-17 8:22 W.H. Kalpa Pathum
2009-12-17 8:46 ` Ineiev
@ 2009-12-17 12:20 ` John (Eljay) Love-Jensen
2009-12-17 17:04 ` Bob Plantz
2 siblings, 0 replies; 11+ messages in thread
From: John (Eljay) Love-Jensen @ 2009-12-17 12:20 UTC (permalink / raw)
To: W.H. Kalpa Pathum, gcc-help
Hi W.H.Kalpa Pathum,
> Could you please explain how the output differs...?
The output differs because the increment operators are being used in such as way as to be undefined behavior.
> ...the way the compiler executes each segment of the variable?
Each compiler can execute each segment of the variable differently. And may vary from version of the compiler to another version of the compiler. And also may vary with the same compiler using different optimization levels.
HTH,
--Eljay
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Could you please explain this code segment
2009-12-17 8:22 W.H. Kalpa Pathum
@ 2009-12-17 8:46 ` Ineiev
2009-12-17 12:20 ` John (Eljay) Love-Jensen
2009-12-17 17:04 ` Bob Plantz
2 siblings, 0 replies; 11+ messages in thread
From: Ineiev @ 2009-12-17 8:46 UTC (permalink / raw)
To: W.H. Kalpa Pathum; +Cc: gcc-help
On 12/17/09, W.H. Kalpa Pathum <callkalpa@gmail.com> wrote:
> Could you please explain how the output differs (when assigned to the
> variable b and in printf statement) and the way the compiler executes
> each segment of the variable?
>
> int main(){
> int a = 10;
> int b = (++a) + (++a);
> printf("%d %d %d %d\n", b, a++, a, ++a);
> printf("%d %d %d %d\n", ++a + ++a, a++, a, ++a);
The program evaluates the arguments first and calls
printf then.
You can't do such things if you want to rely on the result, because
the order of the arguments evaluation is implementation-specific (to
begin with).
^ permalink raw reply [flat|nested] 11+ messages in thread
* Could you please explain this code segment
@ 2009-12-17 8:22 W.H. Kalpa Pathum
2009-12-17 8:46 ` Ineiev
` (2 more replies)
0 siblings, 3 replies; 11+ messages in thread
From: W.H. Kalpa Pathum @ 2009-12-17 8:22 UTC (permalink / raw)
To: gcc-help
The following block of code when compiled with gcc (gcc version 4.4.2
20091027 (Red Hat 4.4.2-7) (GCC) ) resulted in the following output.
Could you please explain how the output differs (when assigned to the
variable b and in printf statement) and the way the compiler executes
each segment of the variable?
int main(){
int a = 10;
int b = (++a) + (++a);
printf("%d %d %d %d\n", b, a++, a, ++a);
printf("%d %d %d %d\n", ++a + ++a, a++, a, ++a);
return 0;
}
OUTPUT
24 13 14 14
36 15 18 18
--
W.H.Kalpa Pathum
http://kalpapathum.blogspot.com
http://thiraya.wordpress.com
^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2009-12-17 22:02 UTC | newest]
Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2009-12-17 20:11 Could you please explain this code segment Bill McEnaney
2009-12-17 20:22 ` Brian Budge
2009-12-17 20:28 ` Joel Dice
-- strict thread matches above, loose matches on Subject: below --
2009-12-17 22:02 Bill McEnaney
2009-12-18 5:11 ` Joel Dice
2009-12-17 8:22 W.H. Kalpa Pathum
2009-12-17 8:46 ` Ineiev
2009-12-17 12:20 ` John (Eljay) Love-Jensen
2009-12-17 17:04 ` Bob Plantz
2009-12-17 18:52 ` Joel Dice
2009-12-17 19:53 ` Bob Plantz
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).