This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [C++ PATCH] Compare binfo types directly
- From: Gabriel Dos Reis <gdr at cs dot tamu dot edu>
- To: Mark Mitchell <mark at codesourcery dot com>
- Cc: Nathan Sidwell <nathan at codesourcery dot com>,GCC Patches <gcc-patches at gcc dot gnu dot org>
- Date: 11 Oct 2004 10:23:04 -0500
- Subject: Re: [C++ PATCH] Compare binfo types directly
- Organization: Texas A&M University, Department of Computer Science
- References: <416A7936.8080102@codesourcery.com><416A97C1.4060404@codesourcery.com>
Mark Mitchell <mark@codesourcery.com> writes:
| Nathan Sidwell wrote:
|
| > Mark,
| > this patch replaces 'same_type_p (BINFO_TYPE (b), t)' with
| > 'BINFO_TYPE (b) == t'. I know you've expressed reservations about
| > omitting
| > same_type_p calls in this way, so I'm running this by you for comment
| > before committing.
|
| I guess the big question I have is not "does this work at the moment?"
| but "should it always work in the future?"
|
| For example, if the user writes:
|
| struct A {};
| typedef A T;
| struct B : public T {};
|
| should the BINFO for A-in-B actually be for T-in-B? In general, we've
| tried to preserve the type that the user used for better error
| messages, potentially better debug messages, and (ikn the distant
| future) better behavior when using the G++ front end independent of
| the GCC back end.
I strongly concur on all points you raised.
The ability for g++ to accurately represent C++ programs at their most
abstract/generic forms is crucial for both diagnostics and use of the
front-end to build other development tools.
Interestingly, we've been through the above tradeoffs in our
forthcoming paper "Representing C++ Directly, Completely and Efficiently".
I hope to make a draft available by the committee meeting (next week).
-- Gaby