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

逻辑上，并且在* ahem * 正确设计的编程语言中，将布尔值与真值进行比较总是多余的，即a == True应该简单地用a来代替。（并且类似地，a == False由not a）。有没有理由写.eqv。。真正。？

许多语言，包括C，没有一个正确的布尔类型，因此它可以有所作为你是否具有真正的（如2 == true产量0，这是一个布尔值代表假比较，而2本身可以代表真正的）。

这也是Fortran中的问题，还是我总是可以用a替换a .eqv. .true.？（我发现在一些遗留代码中，我非常怀疑这只是作者没有真正想到的许多事情之一......但我很好奇是否实际上隐藏了一些特殊情况应该留意。）

来源

2015-03-13 leftaroundabout

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

关于在遗留代码中发现的东西，不要忘记，即使不是大多数，Fortran用户也不是专业程序员，也从未接受过适当编程技巧的全面培训。通常，他们只是被教授语言规则。

来源

2015-03-13 12:19:53

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

既然你问“曾经的理由：”我能想象使用它作为一个占位符开发/调试期间：

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

同样地，我可以看到，如果有人修改代码，原本a为整数，转换为逻辑，你可能最终会切换a.eq.1到a.eqv..true.我可以想象如果你有很多复杂的逻辑表达式，这可能是一个安全/简单的方法。

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

来源

2015-03-13 14:13:50 agentp

这对一些人来说是个问题。上次我在Coursera上学习课程时，他们正在减去这些表面比较的分数。但是使用不同的语言，而不是Fortran。 – 2015-03-13 15:02:24

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

来源

2015-03-13 14:32:17 francescalus

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

回答

相关问题

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