From the snippet it seems the comparison would never work, anyway. Note that the arguments A and B on input are 4 characters with a trailing blank, while the comparison is against 3 characters. In theory it might work with IF (A(1:3) .EQ. 'XDO'..etc.. Reminds me of packing 4-byte HOLLERITH into INTEGER*4 (or even REAL*4) in FORTRAN IV. (*Shudders*)
I suggest to handle character strings as characters:-)
It might be better in this case to use:
IF (TRIM(A) .EQ. 'XDO') THENso we're not getting everything messy with string indices.
]]>I suggest to handle character strings as characters:-)
]]>I think changing the declaration line to:
CHARACTER * 4 A,Bshould be sufficient.
Just to clarify, the .EQ. operator and its other dot-friends are still valid Fortran under the up-to-date standards. I often see brand new Fortran written using them because, in a way, .EQ. is more obvious than the == alternative. Additionally, developers still need to use .AND. and .OR., for example, so it could be seen as being consistent.
]]>I often struggle with the IF construction (it used to be so simple). One thing I've done is replace all the .EQ. with ==
Because you are also using that period for ".AND." and ".OR.", it is so easy to get lost in the syntax (if .EQ. is even valid in your compiled version).
Most of my time isn't spent on "how to do it" algorithmically, it's how to do it in the current syntax.
]]>Is there a way to have the compiler allow this comparison? See below.
Error: Operands of comparison operator '.eq.' at (1) are INTEGER(4)/CHARACTER(3)
Below are some code snippets from the original FORTRAN 77 code.
CALL INPUT( 1,'XDO ','XDI ',XDO,XDI)
SUBROUTINE INPUT(K,A,B,C,D)
INTEGER * 4 A,B
51 IF(A.EQ.'XDO'.AND.B.EQ.'XDI')I=1
This results in: Error: Operands of comparison operator '.eq.' at (1) are INTEGER(4)/CHARACTER(3)
I am trying to preserve the original code in its entirety. If changes need to made to allow for the proper comparison, what would the change be?
Any help would be greatly appreciated. Thanks.
]]>