This is the mail archive of the fortran@gcc.gnu.org mailing list for the GNU Fortran 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: Inheritance of gfc_symbol / gfc_component


Dear Janus,

I had wondered the same sort of thing myself.  However.....

On 16 August 2012 11:11, Janus Weil <janus@gcc.gnu.org> wrote:
> Dear gfortraners,
>
> after GCC is converted to C++ now, I guess one might think about
> taking advantage of this in the Fortran front end ...
>
> One of the first things that comes to my mind, when thinking in this
> direction, is that the structs 'gfc_component' and 'gfc_symbol' have a
> lot in common (name, ts, attr, as, just to name a few), so that one
> could think about having gfc_symbol inherit from gfc_component (in
> Fortran this would be called "type extension", but I think the correct
> C++ term is "inheritance"). There are a couple of routines in the
> front end which basically act the same way on components and symbols
> and which could be unified with such an approach (by receiving a
> pointer, which can either point to a gfc_symbol or a gfc_component).
> Examples: gfc_copy_formal_args, gfc_expr_replace_symbols,
> resolve_procedure_interface.
>
> Attached you find a very short and simple patch, which implements the
> trivial part of this inheritance approach: It makes gfc_symbol inherit
> from gfc_component, and removes those 7 members from gfc_symbol, which
> are literally equivalent in both structs. (The patch compiles cleanly,
> but is not regtested.)
>
> In addition to these 7 'common' members, there are three more members
> which are more-or-less equivalent, but named differently:
>  * 'loc' vs 'declared at'
>  * 'initializer' vs 'value'
>  * 'next' vs 'components'
> These could be replaced by purely mechanical efforts.
>
> This leaves only two members of gfc_component, which are not shared by
> gfc_symbol:
>  * norestrict_decl
>  * tb
>
> In the current simple form of the patch, these would slightly blow up
> gfc_symbol (being unused there). An alternative could be to set up a
> base struct, from which both gfc_component and gfc_symbol would
> inherit.
>
> I would greatly appreciate some general comments on using C++isms in
> the Fortran front end (and possibly further ideas in this direction),
> and also on the inheritance idea proposed above. Does this make sense
> to you? Further thoughts and ideas?

...does it buy us anything in temrs of clarity or efficiency of the
compiler?  I am with Tobi on this one. (BTW - hi, Tobi and Daniel!)

Cheers

Paul


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