Topic: Disambiguating declarators and expressions


Author: feb6399@osfmail.isc.rit.edu (Frank Barrus)
Date: 1996/12/30
Raw View
According to the draft standard (April 1995 DWP),
in section 6.8, any statement that could be an expression
or a declaration should be resolved as a declaration.
To what extent should this be applied?  For instance,
given the following code fragment:
/////////////////////////////////////////////////////////

class test {
public:
 test(int x, int y);
};

void blah()
{
 int a=1, b=2;

 test func(int(a), int(b));
 test notfunc(int(a+1), int(b));
 test maybefunc(int(a), int(b+1));
}

/////////////////////////////////////////////////////////
Using GNU's g++ (2.7.2.1), 'func' is correctly declared
as a function, 'notfunc' becomes a variable of type 'test'
and is constructed with 'a' and 'b',
but 'maybefunc' causes a parse error on the '+', because
g++ makes its decision based soley upon the tokens
before the comma.

Based on what the standard says, this seems to be wrong.
It seems like the entire statment should be looked at,
and should be treated as a declaration only if all parts
of it make a valid declaration.  Otherwise, it should
be parsed as an expression.  Of course, picking the
correct point at which to report an error, if there
is one, still seems tricky, since the compiler can't
really know what was intended.

So, is g++ right or wrong in this matter, and do other
compilers actually parse the entire statement, allowing
one single arithmetic operator way down at the end
of the statement to turn it into an expression instead
of a declaration?
(yes, I realize that in this case, they are all declarations,
but parts of them are either expressions for functional
initializers, or are parameter declarations, depending
upon the interpretation)

Thanks
 - Frank


--
Frank "Shaggy" Barrus: shaggy@csh.rit.edu; http://www.csh.rit.edu/~shaggy
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]





Author: jlilley@empathy.com (John Lilley)
Date: 1997/01/02
Raw View
Frank Barrus wrote:
>
> According to the draft standard (April 1995 DWP),
> in section 6.8, any statement that could be an expression
> or a declaration should be resolved as a declaration.
> To what extent should this be applied?
> /////////////////////////////////////////////////////////
> class test {
> public:
>         test(int x, int y);
> };
> void blah()
> {
>         int a=1, b=2;
>         test func(int(a), int(b));
>         test notfunc(int(a+1), int(b));
>         test maybefunc(int(a), int(b+1));
> }
> /////////////////////////////////////////////////////////
> but 'maybefunc' causes a parse error on the '+', because
> g++ makes its decision based soley upon the tokens
> before the comma.
>
> Based on what the standard says, this seems to be wrong.
> It seems like the entire statment should be looked at,

You are right and G++ is wrong, but it is in good company -- this is one
of the nastiest parts of the grammar short of templates.  The
declaration/expression decision is not LR(k) for any finite k.  In an
LL(1) C++ parser that I am working on, this construct and several others
require backtracking to resolve the problem.  I don't know what other
compilers do, but it in general requires some form of backtracking or
unbounded lookahead.

john lilley
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]