Inheritance of gfc_symbol / gfc_component

[Mikael Morin]

On 17/08/2012 23:32, Tobias Schlüter wrote:
> 
> Following up on myself:
> 
> On 2012-08-16 14:59, Tobias Schlüter wrote:
>> A place where C++ inheritance is a trivial improvement is the red-black
>> tree used for storing various objects (gfc_symtree, gfc_gsymbol,
>> gfc_st_label, I think).  This is currently implemented with macro-based
>> inheritance.  It is trivial to replace the macro with C++ inheritance,
> 
> So I have a patch for this which passes the testsuite, but I'm not sure
> if it's valid C++ 
[...]
> The problem is that the initialization of format_asterisk is not allowed
> in the C++ standard
> 
So it's not valid ;-)

> I thought I could work around this problem without introducing a
> constructor by:
> 1) using 0 instead of -1 as value for this fake label (which is also
>    not a valid value for a label, so it can't collide
> 2) setting ST_LABEL_FORMAT = 0
> and then
> 3) not initializing at all, assuming that as for a C struct
>    format_asterisk would end up in .bss and thus be zero initialized.
> 
I would use a constructor.

> That said, I had to introduce lots of type-casts in the patch, because I
> didn't want to work with templates,
I don't like templates as it looks ugly in the code, but I think that in
this case it is the proper way to represent a bbt: the bbt is a way to
access the data, not part of the data itself.  By the way, I'm not sure
the bbt has any value over the STL's map.

> while using typesafe interfaces
> wherever possible, so the functionally equivalent code actually became
> insignificantly larger with C++ replacing macro-based inheritance.
>
The bbt is a well separated part of the frontend with a small set of
well defined "methods" working on it.  As a result of this, it is easy
to change it's internal implementation or the way it is accessed; as
long as the interfaces remain the same, any change to it would be
basically "insignificant".  To put the story short, I don't think the
bbt is that important (which doesn't mean I'm opposed to any change).

On the other hand, If we go the inheritance way, I think that we could
save some code by moving manual bbt walking functions from symbol.c and
module.c into member functions (i.e. start doing some real cleanup).

Could you post the not-yet-finished patch?

Mikael