有没有理由写.eqv。 。真正。？

Question

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

许多语言，包括C，都没有合适的布尔类型，因此 可以与是否与true进行比较（例如2 == true得到0，因为布尔值表示false，而2本身可以表示为真。）

这也是Fortran中的一个问题，还是我总是可以a .eqv. .true.替换a？

（我发现在一些遗留代码中，我非常怀疑它只是作者没有真正想到的许多事情中的一个......但我很好奇是否有一些特殊情况隐藏在那里我应该提防。）

Answer 1

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

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

Answer 2

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

因为你问“永远一个原因”我可以想象在开发/调试过程中将它用作占位符：

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

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

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

Answer 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之前，请务必仔细检查。