From: Paul Hilfinger <hilfingr@CS.Berkeley.EDU>
To: gdb <gdb@sources.redhat.com>
Cc: carlton@math.stanford.edu
Subject: Re: c-exp.y
Date: Tue, 17 Dec 2002 13:43:00 -0000 [thread overview]
Message-ID: <200212172143.NAA14438@tully.CS.Berkeley.EDU> (raw)
> Basically, I want to revamp the way that GDB handles qualified names
> in C++: these are names like C::x or C::D::y or whatever, where C
> and/or D might be classes or namespaces.
A noble goal, but rather difficult, to say the least.
> Unfortunately, some sort of distinction between types and
> non-types seems to be hard-wired into the parser at a deep level: it
> seems to be the parser's job to actually evaluate expressions
> corresponding to types, whereas other expressions get evaluated by
> somebody else.
Yes. This is a well-known issue with C++ parsing. Consider
(T) *x
We must know whether T is a type to know whether this is a cast.
Of course, the most infamous characteristic of C++ syntax is even
worse. Even if you know that T is a type name,
T(x);
may be parsed either as a declaration of x or as an invocation of the
constructor for T on argument x (yielding a value of type T that is
voided). The rule is that this is a declaration.
> Question 2: What should I do about it?
I hesitate to bring this up, but the newest versions of Bison support
GLR parsing, which can handle the infamous case. In principle, one
could use GLR parsing to push off the distinction between types and
non-types to a later stage of the compiler, but this is probably not a
wise way to use it. Still, I suspect that GLR parsing could clean up
at least some things in the C++ grammar. Unfortunately, the feature
is new and experimental, and will need shaking down. It is also not
in yacc or (at least for now) byacc, which may or may not be a problem.
On the other hand, I know for a fact that, starting next month, GLR's
contributer would be willing to work on getting the kinks out (;->).
Paul Hilfinger
next reply other threads:[~2002-12-17 21:43 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-12-17 13:43 Paul Hilfinger [this message]
2002-12-17 13:59 ` c-exp.y David Carlton
2002-12-18 19:36 ` c-exp.y Paul Hilfinger
2002-12-19 11:58 ` c-exp.y David Carlton
-- strict thread matches above, loose matches on Subject: below --
2002-12-17 12:59 c-exp.y David Carlton
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200212172143.NAA14438@tully.CS.Berkeley.EDU \
--to=hilfingr@cs.berkeley.edu \
--cc=carlton@math.stanford.edu \
--cc=gdb@sources.redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox