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