在Gfortran中使用可选参数时接口不明确

我刚刚在编译一段代码时偶然发现了这个错误，我已经使用了很长时间没有出现问题了。我在Linux上使用Gfortran 8.2，我怀疑是编译器更新导致了这个问题

当我定义一个带有可选参数的接口时，该接口具有不同数量的非可选参数，Gfortran抱怨该接口不明确。例如，如果我编译以下内容，我会得到“在（1）处的'testinit1'和（2）处的'testinit2'的通用接口'test'中的不明确接口”：

如果我删除可选参数

opt

，那么它可以编译。如果我在

test1

中添加了一个

data

参数，该参数与

test2

的数据具有不同的等级，那么它可以很好地编译。如果向这两个函数添加另一个非可选参数，则会收到相同的错误消息

我在中偶然发现的实际代码是中的

Result

接口，正如我所说，它用于按预期编译

感谢您的帮助

Gfortran抱怨接口不明确

这是因为接口不明确。 在以下调用中应选择哪个过程

integer :: param
print *, Test(param)

test1

带有参数

opt

opted-in？或者

test2

参数

data

已通过且

opt

已退出

如果只是在更新之后才开始失败，那么这可能是一个非常受欢迎的bug修复

如果我删除可选参数opt，那么它可以编译。如果我向test1添加了一个与test2的数据具有不同等级的数据参数，那么它可以很好地编译

有道理。如果没有可选参数，这两个函数在参数数量上是完全明确的。更改参数的等级也会导致差异

如果向这两个函数添加另一个非可选参数，则会收到相同的错误消息

同样的问题。如果两个函数都有一个额外的非可选参数，该参数的类型为kind-rank一致性，您将如何解析该调用？ 假设新参数是

data\u extra

：

print*, Test(param1, param2)

test1

与参数

data\u extra

一起通过并

opt

选择了？或者

test2

的参数

data

和

data\u extra

已通过且

opt

已退出

Gfortran抱怨接口不明确

这是因为接口不明确。 在以下调用中应选择哪个过程

integer :: param
print *, Test(param)

test1

带有参数

opt

opted-in？或者

test2

参数

data

已通过且

opt

已退出

如果只是在更新之后才开始失败，那么这可能是一个非常受欢迎的bug修复

如果我删除可选参数opt，那么它可以编译。如果我向test1添加了一个与test2的数据具有不同等级的数据参数，那么它可以很好地编译

有道理。如果没有可选参数，这两个函数在参数数量上是完全明确的。更改参数的等级也会导致差异

如果向这两个函数添加另一个非可选参数，则会收到相同的错误消息

同样的问题。如果两个函数都有一个额外的非可选参数，该参数的类型为kind-rank一致性，您将如何解析该调用？ 假设新参数是

data\u extra

：

print*, Test(param1, param2)

test1

与参数

data\u extra

一起通过并

opt

选择了？或者

test2

的参数

data

和

data\u extra

已通过且

opt

已退出

---

我很惊讶这在以前版本的

gfortran

中会起作用。毕竟，如果您调用

Test（23）

，您是想调用

test1

，其中23是

opt

，还是想调用

test2

，其中23是

data

，no

opt

？这正是含糊不清的定义。我很惊讶这在以前版本的

gfortran

中会起作用。毕竟，如果您调用

Test（23）

，您是想调用

test1

，其中23是

opt

，还是想调用

test2

，其中23是

data

，no

opt

？这正是暧昧的定义。说得对！我的想法是，在您强调的情况下，是调用不明确，而不是接口本身。例如，您应该通过

Test（data=stuff）

和

Test（opt=stuff）

调用。然后调用

Test（stuff）

应该默认为非可选参数。有趣的是，最新的英特尔Fortran也没有对此抱怨。说得好！我的想法是，在您强调的情况下，是调用不明确，而不是接口本身。例如，您应该通过

Test（data=stuff）

和

Test（opt=stuff）

调用。然后调用

Test（stuff）

应该默认为非可选参数。有趣的是，最新的英特尔Fortran也没有对此抱怨。