This is the mail archive of the
mailing list for the GNU Fortran project.
Re: RFC: Plan to implement FINAL (with polymorphism)
- From: Paul Richard Thomas <paul dot richard dot thomas at gmail dot com>
- To: Daniel Kraft <d at domob dot eu>
- Cc: Fortran List <fortran at gcc dot gnu dot org>, Janus Weil <jaydub66 at googlemail dot com>
- Date: Mon, 13 Sep 2010 14:19:25 +0200
- Subject: Re: RFC: Plan to implement FINAL (with polymorphism)
- References: <4C8E0591.email@example.com>
> Some questions I have:
> ?* This destructor table will be similar to the vtable structures, I guess;
> thus, I think we will generate a definition in the compilation-unit where
> the type is defined. ?This is probably what the vtable does, too?
There is no need for a destructor table. Use the vtable for CLASS
enties; the FINAL subroutine is just a specialized generic subroutine.
For derived types, extended or not, the FINAL subroutine(s) are always
accessible. From the standard:
Final subroutines are effectively always “accessible”. They are called
for entity finalization regardless
of the accessibility of the type, its other type-bound procedures, or
the subroutine name
I suggest that, for this purpose, a 'final' field be inserted in
gfc_symbol (if it has not been already!) and that the call be resolved
as any other generic call.
> ?* I have the impression that we need to generate destructor functions for
> each possible rank, not only those that are actually used -- because we do
> not know in advance all places where a type currently compiled may be used.
> ?Or can we avoid this?
Yes you can: see the FINAL description in the F2003. See 4. TKR must
be respected or the FINAL subroutine must be elemental.
1 18.104.22.168 The finalization process
2 Only finalizable entities are finalized. When an entity is
finalized, the following steps are carried out
3 in sequence:
4 (1) If the dynamic type of the entity has a final subroutine whose
dummy argument has the
5 same kind type parameters and rank as the entity being finalized, it
is called with the entity
6 as an actual argument. Otherwise, if there is an elemental final
subroutine whose dummy
7 argument has the same kind type parameters as the entity being
finalized, it is called with
8 the entity as an actual argument. Otherwise, no subroutine is called
at this point.
9 (2) Each finalizable component that appears in the type definition
is finalized. If the entity
10 being finalized is an array, each finalizable component of each
element of that entity is
11 finalized separately.
12 (3) If the entity is of extended type and the parent type is
finalizable, the parent component is
14 If several entities are to be finalized as a consequence of an
event specified in 22.214.171.124, the order in which
15 they are finalized is processor-dependent. A final subroutine shall
not reference or define an object that
16 has already been finalized.
17 If an object is not finalized, it retains its definition status and
does not become undefined.
> ?* Is it possible to create only a single destructor function that can
> handle all ranks alike? ?(I want to create it in the back-end.) ?In C terms,
> we could pass it a void* and the rank as well as other stuff necessary and
> have the code perform casting as required to distinguish between an array
> descriptor or direct pointer and so on. ?Does this sound like a good
> approach or should we rather create individual functions for each case?
> This seems cleaner but also a lot more expensive to me.
See previous. The necessity for this is explicitly excluded.
> ?* As an alternative approach: ?Instead of using the vtable, maybe we could
> try a dispatch based on the dynamic type ID (as SELECT TYPE would do,
> basically) -- does this seem to be advantageous for some reasons?
See the earlier discussion.