1

Is there a way to define generic procedures to dynamically handle each kind of int, character and real without having to specify a procedure for each one? I guess this is also asking whether kind polymorphism exists in Fortran.

I'm thinking of something that would be interfaced something like this:

module generics_test

interface read_generic
    module procedure read_int, &
                     read_real, &
                     read_char
end interface read_generic

contains

subroutine read_int(value)
    implicit none
! Arguments
    <what sort of type spec could go here?> :: value
! Implementation
    <would there need to be some kind handling here?>
end subroutine read_int

<other read subroutines here>

end module generics_test

It seems that polymorphism in Fortran 2003 focuses on derived types, such as the examples from the Portland Group. I'm only interested in generic handling of intrinsic types.

This is mainly for curiosity, since we work almost exclusively with defaults for integer and character, and real(8). (N.B. I know we should use iso_fortran_env, but not all of the compilers we use have support for it.)

Kyle_S-C
  • 1,107
  • 1
  • 14
  • 31
  • Right, the question referenced in my answer is not a direct duplicate, but this one probably is. Although, the people searching for these techniques do not have to know about C++ and templates. I will wait for other votes before insta-closing. – Vladimir F Героям слава Mar 30 '15 at 11:01
  • N.B. You do not have to use `iso_fortran_env`. What you *really should* use is kind constants instead putting just (8) there. Where you get the constant value is totally up to you, `iso_fortran_env`. is just one of many possibilities. – Vladimir F Героям слава Mar 30 '15 at 11:03
  • So I use my own precision module with variables defined like `dp = selected_real_kind(x, y)`, but it's a bit of a struggle to refactor the whole code to use this kind of thing. I do for my new bits that are nicely compartmentalised, but not everything. – Kyle_S-C Mar 30 '15 at 11:06
  • I do mean *kind*, I think. I'm specifically thinking of different kinds of `real`, since the defaults can vary from compiler to compiler (and with compiler flags) and large swathes of our code just have the default `kind`. My question was more about whether I need to implement things like `read_real4`, `read_real8`, `read_real16` etc. – Kyle_S-C Mar 30 '15 at 11:09
  • I edited the code to perhaps make it a bit clearer too. – Kyle_S-C Mar 30 '15 at 11:15
  • Yes, that does clarify, thanks. The answer is the same but with extra stressing for "even just differing kind parameters". – francescalus Mar 30 '15 at 11:23

1 Answers1

1

No, it is not possible. Not even with parametrized derived types.

You must manually create each specific procedure. There are many tricks with preprocessors which can assist you to do some poor-man's C++-like tempting. Examples can be found even on StackOverflow. See, among others, STL analogue in Fortran .

Community
  • 1
  • 1
Vladimir F Героям слава
  • 57,977
  • 4
  • 76
  • 119
  • Not really appropriate for a question of its own, but do you know if there is a good reason for this? Has it been considered at any of the Fortran specification meetings? – Kyle_S-C Mar 30 '15 at 11:13
  • It is quite difficult thing to design right. C++ also does not instantiate templates for every type out there. Creating an instance for every kind could easily lead to code bloat. There are certainly thoughts about meta-programming for Fortran, but as far as I know there were always other priorities. The upcoming standard concentrates on Coarrays and C interoperability plus small additions and fixes. Maybe there will be some activity in the next round. You could try to ask at comp.lang.fortran where you can find many committee members. The official latest news: http://www.nag.co.uk/sc22wg5/ – Vladimir F Героям слава Mar 30 '15 at 12:23
  • 2
    Found this in N2015.txt : "Earlier attempts at providing a template-like facility in Fortran by way of parameterized modules or intelligent macros failed to gain consensus. On the other hand, programmer feedback indicates that not having this feature is considered the most serious gap in the language. It is clear that, due to the significant size and amount of work for specification, this cannot be considered for inclusion in the next edition. Therefore it is suggested to defer this to a Technical Specification to be published after the next standard has been released." – Vladimir F Героям слава Mar 30 '15 at 12:31