在FORTRAN

我試圖編譯解決了可用的球體這裏的納維 - 斯托克斯項目比較派生類型： https://fms.gfdl.noaa.gov/gf/在FORTRAN

使用默認的編譯器ifort，我想用gfortran，因爲我想使其最終可供任何想使用它的人使用。

在代碼中的某些點，有喜歡

if (x == y)

，其中x和y是含整數，實數和指針都派生類型（稱爲domain1d/2d）的語句。 gfortran抱怨說，比較是在非數字和退出之間。

然後我下載了ifort的試用版，它編譯時沒有問題。

因此，我想知道這是否是某種類型/結構的每個成員（即使用C術語更加舒適！）的實際比較，或者是否缺少一些基本的東西，對fortran來說是新的？

我明白，比較派生類型有時候沒什麼意義，但在這裏它似乎只是檢查兩者是否攜帶相同的信息。

感謝，喜悅

來源

2013-04-11 Joy Monteiro

在黑暗中拍攝：嘗試.EQ。而不是== – 2013-04-11 05:11:14

什麼是這些變量的TYPE // END TYPE定義？對我來說，你可以對派生類型進行邏輯測試，但是我真的不知道。 – 2013-04-11 05:12:35

英特爾Fortran編譯器實現了對Fortran標準的各種擴展，其中一些擴展從其祖先繼承（如DEC Fortran）。如果我知道它對派生類型實現了平等測試並不令人感到意外，但我不會感到驚訝，因爲它知道它編譯了這樣一個聲明，但沒有正確地實現我們可能認爲它應該做的事。如果你設置了嚴格遵守語言標準的編譯器選項，你可以用ifort來排除這個問題。 – 2013-04-11 06:30:57

理查德·W是正確的。我遇到了來自NOAA的大氣代碼的類似問題。這是GCC舊版本中的一個錯誤（它影響了我在4.47而不是在4.8）。由於某種原因，重載.EQ。不是過載==，反之亦然（如果你看看domain1D的實現，它肯定會重載.EQ，然後==顯示在代碼中的其他地方）。我通過確保.EQ。解決了這個問題。或始終使用==。

據我所知，.EQ。和==應該是等價的（我沒有看過那麼難），這就是爲什麼ifort（和我的情況，SGI Fortran編譯器）沒有遇到這個問題。

來源

2013-07-03 14:16:18

回答

相關問題