Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Highlighted
New Contributor I
1 View

redefine intrinsic operator

I am a little confused of the default operation of intrinsic operator(==), here's the example:

program main
    implicit none

    if('a' == 96) print*, 1
    if('a' == 97) print*, 2
    if('a' == 98) print*, 3

end

there's no output when program executes. And what's more, when extending the operator(==) to deal with character-integer comparison, As:

module test
    implicit none
    
    interface operator(==)
        module procedure :: equals
    end interface operator(==)

    contains

    function equals(c, value)

    logical               :: equals
    character, intent(in) :: c
    integer,   intent(in) :: value

    equals = (c == char(value))
    
    end function equals
    
end module test

The compiler generates an error message:

error #6748: The type/rank for the arguments of this specific function for a defined OPERATOR redefines intrinsic expression operations.   [EQUALS]

So how does the operator(==) work when dealing with operands other than character-character ? And is it extensible? Appriciate any help.

PS: The user-defined extension of other intrinsic comparison operators such as (>, <, >=, <=) are all fine when dealing with character-integer operands.

0 Kudos
12 Replies
Highlighted
Black Belt
1 View

If you had compiled your

If you had compiled your first program with standards checking enabled, you would have seen a clue:

t.f90(4): warning #7840: A character string or Hollerith string is non-standard in this context.   ['a']
    if('a' == 96) print*, 1
-------^
t.f90(5): warning #7840: A character string or Hollerith string is non-standard in this context.   ['a']
    if('a' == 97) print*, 2
-------^
t.f90(6): warning #7840: A character string or Hollerith string is non-standard in this context.   ['a']
    if('a' == 98) print*, 3
-------^

It is not standard Fortran to use the equality operator with a character and numeric type. So what is happening here?

Note the "Hollerith string". This is a variant of a feature that was in FORTRAN IV (F66) but dropped in F77. F66 didn't have character type at all, but did have Hollerith constants of the form 4HABCD. These were actually numeric values. Many compilers then added an extension allowing you to use quoted strings instead of the nH syntax.

So what does 'a' mean? Since character values are "big-endian", you get a default integer value with the high byte set to 97. This is not the same as 97.

I strongly advise against using this extension. If you had used IACHAR('a') instead, you'd get what you want.

Steve (aka "Doctor Fortran") - https://stevelionel.com/drfortran
0 Kudos
Highlighted
Black Belt
1 View

As for your extension

As for your extension procedure, that's a compiler bug. It should allow this. One of the Intel folks will escalate it.

Steve (aka "Doctor Fortran") - https://stevelionel.com/drfortran
0 Kudos
Highlighted
Valued Contributor III
1 View

The compilation error though

The compilation error though shown by OP with the defined operator looks like a bug in the compiler, may be someone will take a closer look.

0 Kudos
Highlighted
Employee
1 View

I reported to defect with the

I reported to defect with the extension procedure to Development.

(Internal tracking id: DPD200419309)

0 Kudos
Highlighted
Valued Contributor III
1 View

Quote:Kevin D (Intel) wrote:

Kevin D (Intel) wrote:

I reported to defect with the extension procedure to Development.

(Internal tracking id: DPD200419309)

Thanks, most surprising though.  And it looks like this one goes back all the way to the days of Digital Fortran as a Fortran 90 compiler, the same exact text appears in the compiler message!

0 Kudos
Highlighted
Black Belt
1 View

I suspect the problem relates

I suspect the problem relates to the compiler supporting comparison of Hollerith literals as an extension. It needs to first check to see if there is a user-supplied generic extension before applying the nonstandard behavior.

Steve (aka "Doctor Fortran") - https://stevelionel.com/drfortran
0 Kudos
Highlighted
New Contributor I
1 View

Thanks for all the help and

Thanks for all the help and demonstration.

0 Kudos
Highlighted
New Contributor I
1 View

Quote:Kevin D (Intel) wrote:

Kevin D (Intel) wrote:

I reported to defect with the extension procedure to Development.

(Internal tracking id: DPD200419309)

Hi, Is anyone know if this problem has been fixed in the latest release ?

0 Kudos
Highlighted
Black Belt
1 View

The 2018 compiler took in the

The 2018 compiler took in the file with no complaints.

You may wish to complete your testing by writing a main program that uses the module and exercises the operator for proper functioning.

0 Kudos
Highlighted
New Contributor I
1 View

Quote:mecej4 wrote:

mecej4 wrote:

The 2018 compiler took in the file with no complaints.

You may wish to complete your testing by writing a main program that uses the module and exercises the operator for proper functioning.

Thanks, mecej4. I'll try out later.

0 Kudos
Highlighted
Moderator
1 View

Quote:Blane J. wrote:

Blane J. wrote:

Quote:

Kevin D (Intel) wrote:

 

I reported to defect with the extension procedure to Development.

(Internal tracking id: DPD200419309)

 

 

Hi, Is anyone know if this problem has been fixed in the latest release ?

I confirmed with development that this was fixed in 18.0 compiler.

Devorah - Intel® Developer Support
0 Kudos
Highlighted
New Contributor I
1 View

All right, Devorah, Thank you

All right, Devorah, Thank you.

0 Kudos