适用于ABSTRACT类型的Fortran FINAL程序 [英] Fortran FINAL procedure for ABSTRACT type

问题描述

我可以在抽象类型中添加 final 过程吗？

Can I add a final procedure to an abstract type?

假设最终过程如下：

subroutine finalize(this)
   type(bin_tree_t), intent(inout) :: this

   deallocate(this%head)
end subroutine finalize

我的编译器（ifort 18.0 .1）给出错误＃8313：TYPE（派生类型规范）不得指定抽象类型。我明白了，但是最终子例程的伪参数不能是多态的。

My compiler (ifort 18.0.1) gives "error #8313: The TYPE(derived-type-spec) shall not specify an abstract type". I get this, but the dummy argument of a final subroutine cannot be polymorphic.

如果这不可能，那么是否有可能是自觉选择了标准

If this is not possible, is it then likely to have been a conscious choice of the standards committee, or just an oversight?

推荐答案

抽象类型不可能有最终的子例程。如您所述，此类子例程的参数一定不能是多态的，我们不能使用 type（spec）实例化抽象类型。

It is not possible for an abstract type to have a final subroutine. As you note, the argument for such a subroutine must not be polymorphic and we can't instantiate an abstract type with type(spec).

最终确定对象时，选择的最终子例程是参数类型为要最终确定的对象的 dynamic 类型的子例程。任何对象都不能具有动态类型的抽象类型。最终子例程不会被继承（并且可能不会被覆盖）。

When an object is finalized, the final subroutine selected is one with argument type the dynamic type of the object to be finalized. No object may have dynamic type an abstract type. Final subroutines are not inherited (and may not be overridden).

我可以想象用例中抽象类型的最终子例程会很好。实际上，我们希望抽象类型执行的所有终结处理都应由扩展类型完成。请注意，抽象父级的可终结组件仍将被终结。

I can imagine use cases where a final subroutine for an abstract type would be nice. As it is, any finalization we'd want the abstract type to perform should be done by the extending type. Note that finalizable components of the abstract parent will still be finalized.

我无法对标准委员会的想法发表评论，但这些案例似乎没有

I can't comment on the thinking of the standards committee, but those cases don't seem to have greater value than the simple specification of finalization that we now have.

我说过，最后一个子例程的参数一定不能是多态的。这是Fortran 2008标准的C480。问允许多态参数导致什么问题是什么？是一个完全合理的问题。

I said that the argument for the final subroutine must not be polymorphic. This is C480 of the Fortran 2008 standard. It's a perfectly reasonable question to ask "what problems are caused by allowing a polymorphic argument?".

由于我们没有确定最终的子程序，所以它的定型过程就实体的通用解析，覆盖或继承而言。选择是如果动态类型有合适的子例程，则使用它。相反，如果允许使用多态参数：如果动态类型有合适的子例程，请使用它；否则，请遍历父类型...。后一个概念在其他地方不会出现很多。

The finalization process as we have it doesn't express the chosen final subroutine for an entity in terms of generic resolution, overriding or inheritance. The choice is "if there's a suitable subroutine for the dynamic type, take it". Instead, if polymorphic arguments were allowed: "if there's a suitable subroutine for the dynamic type, take it; if not, iterate through parent types...". This latter concept doesn't appear much elsewhere.

请注意，一旦扩展类型已完成，则父类型也将完成（即使该扩展类型没有相应的最终子例程） ）。

Note that the parent type is finalized once the extending type has been finalized (even if that extending type has no corresponding final subroutine).

最后，在我看来，没有积极的愿望禁止抽象类型的最终子例程，但是允许它们的代价太高了。当前的方法非常简单地定义。可以用不同的方式写定稿吗？是。 las，我们需要一个更详细的知识的人士，向我们详细说明为什么选择这种特定方式。

In conclusion, it seems to me that there's no active desire to prohibit final subroutines for abstract types but the cost to allow them was too great. The current approach is quite simply defined. Could finalization have been written in a different way? Yes. Alas, we'd need someone with more detailed knowledge to give us details on why this particular way was chosen.

这篇关于适用于ABSTRACT类型的Fortran FINAL程序的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！