如何避免为子模块中实现的延迟类型绑定过程重写相同的接口？答案

【问题标题】：How to avoid rewriting the same interface for a deferred type-bound procedure implemented in a submodule?如何避免为子模块中实现的延迟类型绑定过程重写相同的接口？
【发布时间】：2021-09-27 14:05:38
【问题描述】：

考虑以下代码，它定义了一个abstract 类型foo 和一个deferred 过程sub，以及一个扩展foo 的类型foo2：

MODULE m
  TYPE, ABSTRACT:: foo
  CONTAINS
    PROCEDURE(sub_int), DEFERRED:: sub
  END TYPE

  INTERFACE
    SUBROUTINE sub_int(THIS, x)
      IMPORT:: foo
      CLASS(foo), INTENT(IN):: THIS
      DOUBLE PRECISION, INTENT(INOUT):: x
    END SUBROUTINE
  END INTERFACE

  TYPE, EXTENDS(foo):: foo2
  CONTAINS
    PROCEDURE:: sub
  END TYPE

  INTERFACE
    MODULE SUBROUTINE sub(THIS, x)
      CLASS(foo2), INTENT(IN):: THIS
      DOUBLE PRECISION, INTENT(INOUT):: x
    END SUBROUTINE
  END INTERFACE
END MODULE

SUBMODULE (m) s
CONTAINS
  MODULE PROCEDURE sub
    x= x**2
  END PROCEDURE
END SUBMODULE

有没有办法避免写第二个interface？

我知道将sub 声明为module procedure 是必需的（否则需要在module 中完成实现，而不是在submodule 中完成），但这是唯一的怎么办？

换句话说，是否可以在不重写整个接口的情况下为foo2 实现过程sub？

【问题讨论】：

它不仅仅是重写。一旦你有class(foo)，然后是class(foo2)。一旦接口块是抽象的，以后就不是了。
在我的例子中 MODULE a 中的接口块不是ABSTRACT。另外，我不确定CLASS(foo2) 是否真的向CLASS(foo) 添加任何内容...任何扩展foo 的类型都将属于CLASS(foo)，因此扩展类型中的覆盖过程将需要foo 类型参数.如果我错了，请纠正我。无论如何，您知道这是否是实现我在示例中描述的唯一方法吗？
对不起，您的sub_int 接口块确实不是抽象的，但实际上应该是。但是subroutine 和module subroutine 之间仍然存在区别。你不只是复制同样的东西。
我实际上并没有故意使用抽象接口，以表明在我看来，至少有一些信息（过程的参数）是重复的，并且代码允许这样做。我在我的实际代码中使用抽象接口，用于延迟类型绑定过程，并且我同意它们应该用于此目的。但是，我只是想知道这是否是唯一的方法，或者是否有其他方法可以让我“节省”一些代码行。
我不相信目前可以做你想做的事。有proposals 将这些东西添加到未来的 Fortran 标准中。

标签： fortran

【解决方案1】：

这是不可能的。一个单独的模块子程序需要一个接口块，无论是在其定义子模块中还是在其定义子模块的祖先中。

一个过程是否碰巧被一个（或多个！）类型的一个（或多个！）绑定指定是完全无关的。

【讨论】：

感谢您的回答！在@veryreverie 对问题的评论中，有一个关于这个问题的讨论链接，并建议使用预处理器宏的解决方案。使用宏来避免整个界面的重写；而是编写宏。这对我来说似乎非常有用，但是否建议为此目的使用预处理器宏，或者它被认为（或多或少）不好的做法？如果这是不好的做法，为什么会这样？
这让我觉得这是一个不相关的问题。我不使用宏。我认为它们在“Fortran”代码中是不好的做法。一方面 - 一旦您使用它们，您的代码就不再是 ISO/IEC 1539-1 所定义的 Fortran。