This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH 0/6] Convert gimple to a C++ class hierarchy


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 


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]