【问题标题】：Is generic resolution possible in Fortran with unlimited polymorphic entities具有无限多态实体的 Fortran 是否可以进行通用解析
【发布时间】：2018-07-16 08:39:16
【问题描述】：

当您尝试通过泛型接口、组合模块或通过类型绑定过程重载子例程时，必须考虑到任何具有相同泛型名称的过程必须具有可区分或不兼容的参数。

当使用无限多态实体时，您可以快速解决这个令人难以置信的教育示例中展示的问题：

INTERFACE foobar
  SUBROUTINE foo(x)
    INTEGER :: x
  END SUBROUTINE foo
  SUBROUTINE bar(x)
    CLASS(*) :: x
  END SUBROUTINE bar
END INTERFACE foobar

这里，foo(x) 与 bar(x) 冲突，因为 bar 的参数也可以是 INTEGER。

这个特殊的问题可以在一个新的子程序中使用SELECT TYPE 结构来解决，它取代了通用接口：

SUBROUTINE foobar(x)
  CLASS(*) :: x
  SELECT TYPE (x)
    TYPE IS INTEGER
      CALL foo(x)
    CLASS default
      CALL bar(x)
  END SELECT
END SUBROUTINE foobar

但是，有时这样的结构会变得乏味且不受欢迎。

在不使用SELECT TYPE 构造的情况下，是否有其他方法可以实现这种专业化？

【问题讨论】：

专业化不是 Fortran 标准使用的术语。我把它改成了generic disambiguation，也许generic resolution会更好。无论如何，专业化这个词让人想起 C++ 模板，至少对我来说是这样。
一种讨厌的方法是创建一个预处理器宏，它会根据提供的参数、接受的类型和相应的“处理程序”为您生成SUBROUTINE foobar... :)
@VladimirF 同意术语 specialisation 是有问题的，并建议将其替换为 generic resolution。我不会搜索“消歧”（但这只是个人意见）
@IanH 会很高兴拥有类似 CLASS(*, EXCEPT=INTEGER) 的东西，以使 INTERFACE 块有效...
@IanH，您能否详细说明您的评论“无限多态对象不是泛型编程的道具”。我知道它们肯定不如 C++ 中的模板强大和高效，但它是可能的，并且是目前我们所拥有的最好的。还是我错过了什么。

标签： fortran

【解决方案1】：

我认为 SELECT TYPE 构造的上述用法是实现此类要求的最佳方式。根据 Fortran 2018 规范，上述程序中 INTERFACE foobar 的使用不是确认整数 x 和 class(*) x 与 TKR 兼容的规范。编译器应为上述程序生成编译时错误。我认为除了用过程替换泛型接口并使用选择类型构造来调用特定过程之外，没有更好的解决方法。

Fortran 2018 规范的片段：

对泛型声明的限制：

如果满足以下条件，两个虚拟参数是可区分的：它们都是数据对象或已知为函数，TKR 也不兼容。

【讨论】：