You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Tom Clune sent us the request below. I also was thinking about the same question when I introduced type(*) for a bunch of internal inter-language interfaces a while back, but did not have the time then to deal with the public InternalState API. We do use macro ESMF_NO_F2018ASSUMEDTYPE in order to guard for compilers that do not support this Fortran language feature.
On 11/1/22 09:11, 'Clune, Thomas L. (GSFC-6101)' via esmf_support wrote:
Since the dawn of time, the procedures ESMF_ESMF_UserCompGetInternalState() and the corresponding Set have had implicit interfaces. This was necessary in earlier revisions of Fortran because the “wrapper” argument would of necessity be of varying type. With the introduction of TYPE(*), it is now possible to give those procedures an explicit interface.
Without such a change, we have to disable some checking in the NAG compiler as it otherwise complains that different types are passed for that argument. You can cheat a bit by trying to put each such call into a different file, but TYPE(*) is the “right” answer here.
I realize some older Fortran compilers may not support this feature, so it could be that the explicit interface is conditional upon compiler support.
The text was updated successfully, but these errors were encountered:
theurich
changed the title
Use Fortran varying type(*) feature to clean up (an make public) the UserComp InternalState API
Use Fortran varying type(*) feature to clean up (and make public) the UserComp InternalState API
Nov 2, 2022
Tom Clune sent us the request below. I also was thinking about the same question when I introduced type(*) for a bunch of internal inter-language interfaces a while back, but did not have the time then to deal with the public InternalState API. We do use macro
ESMF_NO_F2018ASSUMEDTYPE
in order to guard for compilers that do not support this Fortran language feature.On 11/1/22 09:11, 'Clune, Thomas L. (GSFC-6101)' via esmf_support wrote:
The text was updated successfully, but these errors were encountered: