Related articles |
---|
Parsing questions e8rasmus@etek.chalmers.se (Rasmus Anthin) (2000-01-06) |
Parsing Questions sewing@uvic.ca (Stefan Ewing) (2002-06-13) |
Re: Parsing Questions sting@linguist.dartmouth.edu (Michael J. Fromberger) (2002-06-14) |
Re: Parsing Questions ian@cfmu.eurocontrol.be (Ian Wild) (2002-06-14) |
Re: Parsing Questions joachim_d@gmx.de (Joachim Durchholz) (2002-06-14) |
Re: Parsing Questions rcbilson@plg2.math.uwaterloo.ca (Richard C Bilson) (2002-06-14) |
Re: Parsing Questions vbdis@aol.com (VBDis) (2002-06-14) |
Re: Parsing Questions sewing@uvic.ca (Stefan Ewing) (2002-06-17) |
Re: Parsing Questions sewing@uvic.ca (Stefan Ewing) (2002-06-17) |
From: | "VBDis" <vbdis@aol.com> |
Newsgroups: | comp.compilers |
Date: | 14 Jun 2002 15:24:46 -0400 |
Organization: | AOL Bertelsmann Online GmbH & Co. KG http://www.germany.aol.com |
References: | 02-06-034 |
Keywords: | parse |
Posted-Date: | 14 Jun 2002 15:24:45 EDT |
"Stefan Ewing" <sewing@uvic.ca> schreibt:
>a = b++ + c;
>
>b will be incremented after b + c has been calculated. But the only
>place to put the operator (it seems to me) is between "b" and "+".
>But doesn't this imply we should increment b *before* adding it to c?
You have understood the difference between the prefix and postfix
operators, b++ and ++b?
In C, C++ and Java an operator serves 2 purposes:
it can modify the underlaying object (left hand side in binary
operators), and it executes the operation and returns the result of
the operation.
The result of the postfix operator is the value of the variable/object
before the modification, whereas the prefix operator returns the value
after the modification of the object. You'll find more operators with
different operations and results, e.g. with the input/output operators
<< and >>.
>Also, how should one represent the Java field access operator (.) in a
>parse tree? At first glance, it seems like a binary operator to me
>(given the object name and the field name, a memory address is
>returned), but one operator precedence chart I saw online shows . as a
>unary operator.
In this case the array selection operator [] also should be handled as
a unary operator. IMO such a classification is acceptable only for a
special (non standard) definition of unary operators.
Typically the number of operands is used to classify operators as
unary, binary or ternary operators, and then the . operator clearly is
a binary operator.
When you consider the implementation of user defined operators
(overloading), then you'll find different operator names, and
consequently different implementations, for the prefix and postfix
increment operators. This difference also must be reflected in the
parse tree.
With regards to the interpretation of the parsed tree, and to the
implementation of the operators, also the "primary" operand is of
importance. With "primary" here I mean that one operand (object),
whose operator method is called in order to execute the
operation. This distinction allows to overload and redefine e.g. the
<< operator, which normally is a shift operator, but which becomes an
input operator when the leftmost operand is a stream object.
IMO both the operator precedence and the associativity (left/right)
must be considered, in order to find the primary operand whose
operator method then is used to execute the operation.
DoDi
Return to the
comp.compilers page.
Search the
comp.compilers archives again.