This is the mail archive of the
mailing list for the GCC project.
Re: [PATCH 0/6] Convert gimple to a C++ class hierarchy
- From: Michael Matz <matz at suse dot de>
- To: David Malcolm <dmalcolm at redhat dot com>
- Cc: gcc-patches at gcc dot gnu dot org
- Date: Wed, 4 Sep 2013 15:22:19 +0200 (CEST)
- Subject: Re: [PATCH 0/6] Convert gimple to a C++ class hierarchy
- Authentication-results: sourceware.org; auth=none
- References: <1377793216-22549-1-git-send-email-dmalcolm at redhat dot com> <alpine dot LNX dot 2 dot 00 dot 1308301532490 dot 9949 at wotan dot suse dot de> <1377890482 dot 29222 dot 32 dot camel at surprise> <alpine dot LNX dot 2 dot 00 dot 1309021310510 dot 9949 at wotan dot suse dot de> <1378257127 dot 18117 dot 41 dot camel at surprise>
On Tue, 3 Sep 2013, David Malcolm wrote:
> > I can't really say I find this shorter, easier to read, more
> > expressive or even safer than what was there before. And the
> > repetition for adding the helpers for const and non-const types
> > all the time doesn't make it better.
> Part of this is the verbose struct names. I mentioned getting rid of
> the "_statement" part of the typenames, I think I'll do that.
Yep, IMO makes sense.
> The other part is that the accessor functions become redundant, and that
> you'd be able to do the cast once, and then use all of the various
> fields of a gimple_whatever, bypassing the getters/setters.
Well, you can do that today with unions too, it's just not prevalent
style; but you could do:
if (gimple_has_mem_ops (g))
struct gimple_statement_with_memory_ops_base *gm = &g->gsmembase;
gm->vuse = ...;
Obviously the naming of the struct here also is a bit excessive. Using
accessors has one large advantage over accessing the fields directly, you
can change the semantics of them. One reason why the above style isn't
used. But if that is true one of your reasons doing the change (downcast
once, access fields directly, obsoleting the accessors) becomes moot,
because we don't _want_ to access the fields directly. That is, until you
add member functions doing the accesses, which has its own problems (of
stylistic nature, because then we'd have a very weird and clumsy mix in
GCC sources of some data structures having member function accessors and
others using the traditional C style).
Hmm. After some nights sleeping over this, I'm oscillating again between
not liking the change and being indifferent; as in, I do see some of the
advantages you mentioned but I don't regard them outweighing the