Inheritance of gfc_symbol / gfc_component

[Tobias Schlüter]

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++ because of one issue: in io.c we have at file scope

gfc_st_label
format_asterisk = {0, NULL, NULL, -1, ST_LABEL_FORMAT, ST_LABEL_FORMAT, 
NULL,
                   0, {NULL, NULL}};

which doesn't work if I redefine gfc_st_label to inherit from a gfc_bbt 
which contains the balanced binary tree info, so I have
struct gfc_bbt {
   int priority;
   gfc_bbt *left;
   gfc_bbt *right;
};
and
struct gfc_st_label : public gfc_bbt
{
   int value;
  ...
}

Previously a macro made the first three elements of gfc_st_label what 
are now the elements of gfc_bbt.

The problem is that the initialization of format_asterisk is not allowed 
in the C++ standard (according to the error message, C++11 actually 
allows it).

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.

When I was investigating whether this theory is sound, I understood that 
anything involving inheritance is not POD (plain old data), and 
therefore I can't assume zeroing to be guaranteed.  Is that correct?  If 
that is correct, I will submit the patch.  Otherwise, I would be 
interested if there's an equally simple way of initializing 
format_asterisk once it uses inheritance.  Aternatively, I don't see 
what speaks against allowing C++11 in frontends (well, maybe the famous 
binary incompatibility with C++03 ...)

That said, I had to introduce lots of type-casts in the patch, because I 
didn't want to work with templates, while using typesafe interfaces 
wherever possible, so the functionally equivalent code actually became 
insignificantly larger with C++ replacing macro-based inheritance.

Cheers,
- Tobi