This is the mail archive of the
fortran@gcc.gnu.org
mailing list for the GNU Fortran project.
Re: [Patch,Fortran] Add polymorphic type support (OOP, RTTI) - merge from Fortran-dev branch
- From: Daniel Kraft <d at domob dot eu>
- To: Paul Richard Thomas <paul dot richard dot thomas at gmail dot com>
- Cc: Tobias Burnus <burnus at net-b dot de>, Janus Weil <janus at gcc dot gnu dot org>, gfortran <fortran at gcc dot gnu dot org>
- Date: Wed, 30 Sep 2009 09:44:10 +0200
- Subject: Re: [Patch,Fortran] Add polymorphic type support (OOP, RTTI) - merge from Fortran-dev branch
- References: <4AC26DD8.8060001@net-b.de> <339c37f20909292242m3e5aac2y541f2abe084912e2@mail.gmail.com>
Hi Paul,
Paul Richard Thomas wrote:
Dear All,
Please find attached the patch for dynamic dispatch that Tobias
referred to. It is incomplete, in that subroutines do not yet work
and the testcases have not yet been supplied. However, it does handle
both specific and generic functions correctly.
here are some comments regarding your patch:
Your dynamic dispatch is done (if I understood it correctly) by building
a switch on the vindex which has labels for each subtype of the CLASS'
declared type and where the then-appropriate procedure is called. Am I
right here?
I'm not sure about what we would expect in that case, but from a C++
point of view, one should be allowed to declare a derived-type in a
module and use it there with CLASS, but the compiled code should also
work when passed a CLASS object whose actual type is some subtype that
was unknown at compile-time of the original module. Would this work?
Tobias mentioned a possible rework of the internal structure for 4.6, so
I guess this is not something really important... But later on, we
could instead use a vtable of procedure-pointers for dynamic dispatch;
IIRC, you even mentioned one some time, didn't you? Just some thoughts,
though.
+ /* If we have to match a passed class member, force the actual
+ expression to have the correct type. */
+ if (!tbp->n.tb->nopass)
+ {
+ if (e->value.compcall.base_object == NULL)
+ {
+ e->value.compcall.base_object = gfc_get_expr ();
+ e->value.compcall.base_object->expr_type = EXPR_VARIABLE;
+ e->value.compcall.base_object->symtree = e->symtree;
+ e->value.compcall.base_object->ref = gfc_copy_ref (e->ref);
+ }
You could replace those four lines generating the base_object by a call
to extract_compcall_passed_object if you want, but of course you don't
save much. I'd still do it, I guess.
All in all, I think the patch is ok. But as I've not yet really read
the other polymorphism patch, I don't feel confident to give a review
here (and you didn't yet request one, did you?).
Thanks for your and Janus' work here!
Daniel
--
Done: Arc-Bar-Cav-Ran-Rog-Sam-Tou-Val-Wiz
To go: Hea-Kni-Mon-Pri