“Scientific Software Design: The Object-Oriented Way” by @rouson, Xia, and Xu.
2 Likes
Thanks @FortranFan
I will study your example. I was not aware of parameterized derived type. And I have not yet touched to generic programming.
Concerning enums, it’s too bad to be obliged to use all these int() conversions. Although I guess there is no risk with small values?
Finally, I am a little confused with that syntax:
integer, kind :: nsides
Could you elaborate?
Re: parameterized derived type (PDT), you can refer to The Fortran 2003 Handbook and/or Modern Fortran Explained for background.
Here is a nice summary article by PGI group for a quick review.
So you will know PDT is a facility introduced starting Fortran 2003 and, unfortunately and I truly believe to be wrongly, much maligned. But I do think its design in the standard is half-baked. Nonetheless for this case you have highlighted in the original post, a PDT design appears better suited, it’s what I would adopt.
As to the syntax,
..
integer, kind :: nsides
..
it informs the processor, the type in question, say tile_t, has a kind-type parameter called nsides. The standard has semantic stipulations around type parameters which you can look up in a MN-007r1 document for the standard starting Fortran 2003 e.g., 23-007r1.pdf for the forthcoming Fortran 2023 revision.
But quickly, you can see nsides as coming into play similarly to your DP named constant. Practical consideration with this is a compile-time constant. However the useful aspect in your situation is poor person’s Generics with having a module defined with the two kinds of polygons you do intend to support, one with 13 vertices and the other with 14.
1 Like