有没有理由写.eqv。。真的。？答案

【问题标题】：Is there ever a reason to write .eqv. .true.?有没有理由写.eqv。。真的。？
【发布时间】：2015-03-13 11:55:02
【问题描述】：

在逻辑中，在 *ahem* 正确设计的编程语言中，将布尔值与 true 进行比较总是多余的，即 a == True 应该简单地替换为 a。（同样，a == False by not a）。

包括 C 在内的许多语言都没有正确的布尔类型，因此它可以与 true 进行比较（例如，2 == true 产生 0，它作为布尔值表示假，而2本身可以代表真）。

这在 Fortran 中是否也是一个问题，还是我可以始终将 a .eqv. .true. 替换为 a？

（我在一些遗留代码中发现了这一点，我严重怀疑这只是作者没有真正考虑过的众多事情之一......但我很好奇是否真的隐藏了一些我应该隐藏的特殊情况小心。）

【问题讨论】：

请注意，我发现了一个案例，其中 nvfortran, for write(6,*) var1, .true., var1 .eqv. .true. 写入 T T F。这一定是一个错误，我正在尝试将其简化为一个小测试用例，但到目前为止还没有运气。

标签： boolean fortran fortran95

【解决方案1】：

不，没有理由这样写。 a .eqv. .true. 与 a 相同。只是不要使用==，它用于不同的数据类型。

关于遗留代码中的内容，不要忘记，即使不是大多数，也有很多 Fortran 用户不是专业程序员，也从未接受过适当编程技术方面的全面培训。通常，他们只是学习语言规则。

【讨论】：

【解决方案2】：

这真的是一个普遍的问题吗？

既然您问“曾经一个原因”，我可以想象在开发/调试期间将其用作占位符：

 c if(a.eqv.b) .. 
   if(a.eqv..true.)

类似地，我可以看到是否有人修改了最初将 a 作为整数并转换为逻辑的代码，您最终可能会将 a.eq.1 切换为 a.eqv..true. 我可以想象，如果您有很多复杂的逻辑表达式，这可能是一种安全/简单的方法。

如果a 未声明为逻辑事件，您可能会使用它来强制编译错误。（这需要在一些不需要逻辑的用法中，例如，作为子例程参数、写语句等）

【讨论】：

这对某些人来说是个问题。上次我在 Coursera 上上一门课程时，他们为这些肤浅的比较扣分。但在不同的语言中，而不是在 Fortran 中。

【解决方案3】：

对于 a 一个逻辑类型，如前所述，您确实需要 a 和 a.eqv..true. 是等价的。

受agentp's answer 启发，其中a.eqv..true. 是代码开发的自然结果，我将给出一个反常的答案。这使用运算符.eqv. 来强制进行某种形式的测试，因此该部分并非无用。

module tdef
  implicit none

  type t
    integer i
  end type

  interface operator (.eqv.)
    module procedure teqv
  end interface

 contains

  logical function teqv(a,b)
    type(t), intent(in) :: a
    logical, intent(in) :: b

    teqv = (a%i.eq.1).eqv.b
  end function teqv 

end module

use tdef
implicit none
print*, t(1), t(2), t(1).eqv..TRUE., t(2).eqv..TRUE.
end

这里有一个教训，也很愚蠢：人们会做奇怪的事情。在将a.eqv..true. 替换为a 之前，请务必仔细检查。

【讨论】：