On Tue, 18 Jan 2000, Urmil Parikh wrote:
*Hi
*
*That was an interesting one. Can't you put the detailed explanation on a
*website ? It will help new comers like me very much. I think linux-india
*itself should host explanations, solutions and step by step HOW-TOs on the
*site instead of each member putting what they have done on their own
*website. It will give one stop solutions to everyone.
*
*Regards
*Urmil Parikh
Hello ,
I really made an ernest attempt to draw the parse tree using ASCII
characters like \ , /, * , ++, etc. but my non WYSISYG mailer is real bad at
grafitti (Kmail).. its bad at a few other things too like Addressbook Handling,
threaded - retrieval of POP .. Basically a bad workman blames his tools.
I shall try to explain the behaviour of gcc 2.7.x.x which gives "4*5*6. " = 120
The solution is not very tough. You have to think like a compiler
and stop behaving like a human ;) Draw a parse tree for an expression :
++a * ++a * ++a. Remember that ++ is a unary operator , having precedence over
the binary operator * (standing for mult) { it has the same precedence as *, as
in *p, the dereference operator). Do a postfix search of the tree, create the
postfix expression . A checkpoint is that your post fix expression will be like
this :
a ++ a ++ * a ++ *
The stack simulation will be ( initialise a = 3 )
3
4
4,4
4,5
20,5
20,6
120 {Answer}
The stack grows to the right.
o Obserere that a is "fed" only once into the stack and since you cannot access
the variable a for writing more than once between sequence points (Look at
Binand's explanation and the C Faq at eskimo.com (Pramod's link) note 3.8 for a
detailed desc.)
o Whether a will finally become 6 is slightly hazy and I dont see any compiler
guarantee to that effect. Could Aseem check out the final value of a under gcc
2.7.x.x / Sol 2.5.1 ?
o Probably a wiser use will be that of constructon of temporary objects and
depth wise evaluation of the tree, finally updating the value of a (wroitten
only once) at a seq. pt. This is what egcs 2.91 (ie what u r running under
RH6.1) seems to do. Look at Suvendra's description of "Case 3" and try to
understand the parentheses. Things could get really tricky when the Compiler
tries to use temporary variables and results *could* vary with optimisation
(directives/compilation options) as Raj rightly pointed out.
o Finally, the standard disclaimer. This is what *me* *thinks* what is
happening and may not be wholly compliant with the truth. I do not have the
expertise need to to do a source code study of the Compilers and come up with a
detailed explanation. Analogous to the fact that nobody has ever seen an
electron but we are *made* to belive that it is a particle :) {Rejoinders to
this would be outside the purview of this list so please respond personally for
quarrels on that}
Aside :
*Get* the C FAQ.. its like rediscovering your loved one after 25 years
of marriage :) Check my .signature if you have missed Pramod's link.
Hope that helps
Regards
Shourya
--
_______________________________________________________________
Shourya Sarcar <[EMAIL PROTECTED]> <Tel:91-033-4710477>
Department of Computer Science and Engineering
Jadavpur University Calcutta, India 700 032
All the world's a stage..
And I am acting tonight
C - the difference : http://www.eskimo.com/~scs/C-faq/top.html
--------------------------------------------------------------------
The Linux India Mailing List Archives are now available. Please search
the archive at http://lists.linux-india.org/ before posting your question
to avoid repetition and save bandwidth.
