On 18/08/2012 19:25, Tobias Schlüter wrote:
>>> 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.
Initialization doesn't seem to be that important after all as only the
address of the variable is used.
It would be safer, I think, to define the variable as a pointer with
invalid (non-NULL) value.
> The benefit over the
> STL's map or a hashtable (which is better suited) is that we can
> traverse a tree in defined order. We use this property to write
> reproducible module files.
Indeed.
>> Could you post the not-yet-finished patch?
>
> Please find it attached. Note that two void* remain:
> gfc_{insert|delete}_bbt still need it, and I don't think there's a way
> around this without templates and without significantly changing the
> code. As I said before, I think a change needs to have a benefit. I'm
> disappointed by this outcome, but think this patch fails this
> requirement mainly because of the format_asterisk issue.
I'm not so much concerned about format_asterisk (see above).
My main concern is this: the increased type safety by changing the
(void*) -> (gfc_bbt*) change is balanced by the reduced type safety for
all the types inherited from gfc_bbt as the left and right pointer have
now gfc_bbt type instead of the derived type. And we better have type
safety for gfc_symtree which is used all over the place.
After digging some information on the web about C++ and casts, I'm not
even sure the casts are correct because of the following quote from the
standard:
"The order in which the base class subobjects are allocated in the most
derived object (1.8) is unspecified."
This tells me we shouldn't rely on the gfc_symtree, pointer_info,
etc having the same address as the corresponding gfc_bbt they derive
from (unless the explicit casts add/substract the necessary offset if
needed though).
We're probably safe with single inheritance, but still...
Mikael
