Struggling with dots and % (what should work and what not?)

Struggling with dots and % (what should work and what not?)

Bild des Benutzers markus

Hello,

while we all know % is the standard delimiter to denote members of derived types, usually the dot is used for that (albeit not standard, or is it now?)

The problem with dot delimiters is that they may lead to ambiguities with dot operators (like .eq.), though Intel compilers seem to cope well
with all of the usual (predefined) comparison operators. (I don't have to recall that blanks always have been "invisible" to Fortran from
the very beginning...)

But what, If I declare my own dot operator?

I have defined an interface operator .eqmm. (which means compared items are equal if nearer than 1 mm, see source example). This can be done
within Fortran 90 standards and compiles in most cases.

But now I have encountered some cases which don't compile.

1)   write(*,*) poly.vertex(1).xyz .eqmm. poly.vertex(2).xyz

2)   write(*,*) poly_arr(1)%vertex(1)%xyz .eqmm. poly_arr(1)%vertex(2)%xyz

3)   write(*,*) poly_arr(1).vertex(1).xyz .eqmm. poly_arr(1).vertex(2).xyz

I'm inclined to agree that case 1 is ambiguous (and indeed the same statement with % as delimiters compiles).

But why doesn't case 2 compile? The only dots involved are those from my .eqmm. definition. Seems the compiler stumbles over the array index poly_arr(1).

Case 3 is what I originally coded. Obviously I expected too much magic from the compiler. (It seems to be well defined and parsable,
as long you don't take the perspective of Fortran and ignore the blanks...)

Markus

AnhangGröße
Herunterladen t1.f901.85 KB
8 Beiträge / 0 neu
Letzter Beitrag
Nähere Informationen zur Compiler-Optimierung finden Sie in unserem Optimierungshinweis.
Bild des Benutzers Steve Lionel (Intel)

I will take a look at these tomorrow. No, the dot is not standard. Our compiler tries to resolve ambiguities in favor of standard-conforming code, but we haven't always gotten it right initially.

Steve
Bild des Benutzers TimP (Intel)

Blanks are "invisible" only with fixed format, which has not been the standard for the last 22 years. I don't see that you indicated whether you use fixed or free format.
It should be needless to repeat that the use of . where the standard specifies % was an extension which was in use before there were interface defined operators, and it posed some problems even without the newer defined operators. It seems that most source code which has been maintained in the last 2 decades or any code which was intended to be standard or portable would not be using that extension.

Bild des Benutzers Steve Lionel (Intel)

This is .f90 file, so it is free-form. I can reproduce the problems. It turns out this is one we have seen before where the expression is in an I/O list. If you assign the expression to a logical variable and then write that, it works. The issue ID is DPD200236931.

Steve
Bild des Benutzers jimdempseyatthecove

I think you can also use ()'s

write(*,*) (poly_arr(1)%vertex(1)%xyz .eqmm. poly_arr(1)%vertex(2)%xyz)

Jim Dempsey

Blog: The Parallel Void

www.quickthreadprogramming.com
Bild des Benutzers markus

Thank you for your responses.

But if blanks are significant with free form (what I have learned now), the source should compile. And indeed with encapsulating () it does. Seems to be a parser problem.

The reason for preferring nonstandard dots is rather obvious: For the purpose of delimiters they are visually better than %.

Bild des Benutzers Steve Lionel (Intel)

Yes, it is a known parser problem. I will update this thread when I have more information.

Steve
Bild des Benutzers dboggs

I also hate the dot delimiters. But I understand the issue and have been painfully forcing myself to use % from no on.

They are harder to type. They are harder to read. They are harder to say. They are harder to talk about. They are not like every other language. They are ugly. Enough said.

Melden Sie sich an, um einen Kommentar zu hinterlassen.