Fortran templates
in [Fortran]
|
From: Damian on 16 Apr 2008 10:23 On Apr 16, 1:15 am, relaxmike <michael.bau...(a)gmail.com> wrote: > On 16 avr, 07:25, Damian <dam...(a)rouson.net> wrote: > > > At least one text describes an approach equivalent to your pre- > > processing approach: Object-Oriented Programming via Fortran 90/95 by > > Ed Akin, Cambridge University Press, 2003. I don't have my copy at > > hand but I'm pretty sure it's in Chapter 6. > > I have the book in my hands : "Object oriented programming > via fortran 90/95" by Ed Akin. > In fact, I was very enthousiast about the title, but the content > was very disappointing to me. > For me, the single article "Object-based programming in Fortran 90" > by Gray and Roberts is much more interesting, because it gives > the essence of OO :http://www.ccs.lanl.gov/CCS/CCS-4/pdf/obf90.pdf > > About the problem of generic code, here is the only part where the > subject is detailed, in chapter 3, p. 51 : > "None of the OOP languages have all the features one might desire. > For example, the useful concept of <<template>>, which is standard in C > ++, > is not in the F90 standard. Yet the author has found that a few > dozen lines of F90 code will define a preprocessor that allows > templates > to be defined in F90 and expanded in line at compile time. [...]" > > That is all : I did not find any paragraph showing how to practically > implement templates in fortran, a subject which could have been at > the core of the book with such a title. > The second edition of "Fortran 90/95 explained" does not deal > with that subject neither (but it may be done in the current edition, > I don't know). > > Comparing to the methods I allready know, Forpedo seems very > interesting. > The tool is easy to implement within a Makefile, as for m4 macros. > The generic source code really looks like fortran source code, > even with the macros like @T and <T>. > > I did the following table to compare the methods > - standard fortran : is the method in the fortran norm > - debug : is the template source code easy to debug > - features : does the method allow to manage complex templates > (this is only my point of view) > > Standard Debug Features > Fortran > ----------------------------------------------------------- > include * ** * > Pre-processing - * ** > m4 - * **** > forpedo - * *** > fortran 2003 * ? ? > > Michaël Keep looking. There is a short passage with more details later in the book. Again, I'm pretty sure it's chapter 6, but I'll send an exact page later when I have my copy with me. The reason I found it similar to what you wrote is your use of the leading underscore, which you explained was because Fortran variables names cannot start with an underscore. In his case, he uses a trailing dollar sign ($) for a similar reason. Look for the string "Template$". The reason I'm so certain it's there is because I use his technique in my own code. I learned it from his book and haven't seen it anywhere else. Damian
From: Damian on 16 Apr 2008 10:25 On Apr 15, 11:57 pm, Arjen Markus <arjen.mar...(a)wldelft.nl> wrote: > On 16 apr, 07:25, Damian <dam...(a)rouson.net> wrote: > > > > > On Apr 15, 7:16 am, relaxmike <michael.bau...(a)gmail.com> wrote: > > > > Hi all fortran gurus ! > > > > I would like to discuss the current methods to manage > > > templates in fortran, following the thread > > > >http://groups.google.com/group/comp.lang.fortran/browse_thread/thread.... > > > > which was very interesting, but showed no details on > > > how to pratically manage the source code. > > > This feature is very well-known by C++ developers as "templates". > > > > One example of the problems solved by C++ templates is to > > > have a sorting source code which is able to manage for any > > > data type, including integers, reals, or even abstract data > > > types. > > > > I currently know 3 ways of dealing with templates in fortran, > > > even if none of them is included in any fortran norm > > > (and none of them is detailed in a fortran book, to my knowledge) : > > > - pre-processing macros, > > > - clever use of the "include" statement, > > > - m4 macros. > > > > Let's begin with the pre-processing macros. > > > Suppose that the file "sorting_template.f90" contains a template > > > sorting module, parametrized by the _QSORT_TYPE macro. > > > The following is an example of parametrized argument declaration : > > > > subroutine qsort ( array, compare ) > > > _QSORT_TYPE, dimension(:) :: array > > > > Here "_QSORT_TYPE" may be an integer, a real or any fortran > > > derived type. > > > This name has been chosen because a fortran variable cannot > > > begin with an underscore so that no confusion can occur > > > between a preprocessing macro and a variable name. > > > Before using the template, one must instanciate it, > > > which is done with : > > > > #define _QSORT_TYPE type(SORT_DATA) > > > #include "sorting_template.f90" > > > > The "instanciation" is based, for example, on the following > > > SORT_DATA derived type, which may be defined in the > > > module "m_testsorting.f90" : > > > > type SORT_DATA > > > integer key > > > integer index > > > end type SORT_DATA > > > > Even if this derived type is quite simple, practical uses of this > > > method may include more complex data types. > > > The module "m_testsorting" has to be pre-processed before > > > being used. After pre-processing, the previous line has > > > been transformed to : > > > > subroutine qsort ( array, compare ) > > > type(SORT_DATA), dimension(:) :: array > > > > With this method, generic source code templates can be > > > configured at will and allow to generate specific > > > sorting algorithms for whatever type of data. > > > This method can lead to more complex templates, with > > > no limit in the number of macros, that is, no limit > > > in the number of abstract data types in the template. > > > > The main drawback is that the debugging process is not > > > possible interactively. This is because the source code > > > is generated at compile-time and the "template" does > > > not correspond to the post-processed one anymore. > > > One solution is to use manually the pre-processor to > > > generate the pre-processed template and to debug on that > > > later file. > > > > Two other methods exist to manage to do generic programming > > > in fortran : the "include" statement and m4 macros. > > > > The "include" fortran statement can be used so that the > > > target source code contains the definitions of an > > > abstract data type used in the template. > > > This method is used by Arjen Markus in the Flibs > > > library, for example in the linked list abstract > > > data structure : > > > >http://flibs.sourceforge.net/linked_list.html > > > > Here we suppose that the file "sorting_template.f90" > > > contains one sorting subroutine, which arguments > > > are defined like this : > > > > subroutine qsort_array( array, compare ) > > > type(SORT_DATA), dimension(:) :: array > > > > The trick is to use the include fortran statement > > > to put that template source code into a context in > > > which the abstract data type is defined. > > > The following source code defines a module, the derived > > > type SORT_DATA and then include the template source code. > > > > module m_testsorting > > > type SORT_DATA > > > integer key > > > integer index > > > end type SORT_DATA > > > contains > > > include "sorting_template.f90" > > > end module m_testsorting > > > > The module m_testsorting is now providing the derived type > > > SORT_DATA and the methods to manage it, which are included > > > in the template. With a little more work, it is even possible > > > to make so that the final derived type has a name which > > > corresponds more to the one implemented by the abstraction, > > > as shown by Arjen Markus on the linkedlist example. > > > > module MYDATA_MODULE > > > type MYDATA > > > character(len=20) :: string > > > end type MYDATA > > > end module > > > module MYDATA_LISTS > > > use MYDATA_MODULE, LIST_DATA => MYDATA > > > include "linkedlist.f90" > > > end module MYDATA_LISTS > > > > The main advantage of the "include" method is that > > > it uses only fortran statements so that the debugging > > > process is possible interactively. Moreover, it is very > > > elegant. > > > > Another method is to use m4 macros to generate source code > > > at compile-time. Gnu m4 is an implementation of the traditional > > > Unix macro processor. This method is used by Toby White the > > > in the Fox library : > > > >http://uszla.me.uk/space/software/FoX/ > > > > The template source code is defined in files which have the .m4. > > > extension and the corresponding source code is defined in the > > > .F90 file. The source code may be difficult to maintain, but the > > > method is extremely powerful, thanks to the m4 features. > > > For example, one can use a m4 "for" loop to generate > > > several subroutine based on one template subroutine. > > > But, as for the pre-processing method, the interactive > > > debugging of the .m4 templates is not possible : > > > instead, the processed .f90 generated files are debugged easily > > > and directly. > > > > Are there other well-known methods ? > > > Is there a definitive drawback for one of these methods so > > > that another way should be chosen? > > > > All comments will be appreciated. > > > > Best regards, > > > > Michaël Baudin > > > At least one text describes an approach equivalent to your pre- > > processing approach: Object-Oriented Programming via Fortran 90/95 by > > Ed Akin, Cambridge University Press, 2003. I don't have my copy at > > hand but I'm pretty sure it's in Chapter 6. > > > Also, FWIW, some would argue that Fortran 2003 supports at least some > > form of generic programming via parametrized derived types (definitely > > not the same capability as templates but generic programming > > nonetheless) and then there is the class(*) to which Arjen alludes. > > > Damian- Tekst uit oorspronkelijk bericht niet weergeven - > > > - Tekst uit oorspronkelijk bericht weergeven - > > I must have a look again at Akin's book - the details > have escaped me ;). > > Note that templates in C++ are completely different > beasts than what we are talking about here: > > If you define a template A with one parameter T in C++ and > then define in various pieces of your code the same instance, > say a type A< int> in ten different source files, > the compiler will have to create ten different copies of > the actual object code that implements that particular > type. > > It is up to the linker to make sure that in the final > executable program there is only one copy (or at least that > there is no conflict between them). > > So, in C++ the task is much more complicated than just > generating specific source code from generic source code. > > In Fortran we would have to generate the specific source > code for each specific type. And as Michael indicates > there are several methods for that. But in the end, > for the compiler and linker it is just a larger set > of ordinary code! > > Regards, > > Arjen Excellent points! Thanks for the clarification. Damian
From: relaxmike on 16 Apr 2008 11:14 You are right, I did not remember that part, but I read it. This is in chapter 6, p144, "Templates". My point of view is different from the one of the author about that problem and I hope that this chapter will be rewritten in the second edition, if ever. Michaël On 16 avr, 16:23, Damian <dam...(a)rouson.net> wrote: > Keep looking. There is a short passage with more details later in the > book. Again, I'm pretty sure it's chapter 6, but I'll send an exact > page later when I have my copy with me. The reason I found it similar > to what you wrote is your use of the leading underscore, which you > explained was because Fortran variables names cannot start with an > underscore. In his case, he uses a trailing dollar sign ($) for a > similar reason. Look for the string "Template$". The reason I'm so > certain it's there is because I use his technique in my own code. I > learned it from his book and haven't seen it anywhere else.
From: gunnar on 16 Apr 2008 13:36 On 15 Apr, 16:16, relaxmike <michael.bau...(a)gmail.com> wrote: > Hi all fortran gurus ! > > > I currently know 3 ways of dealing with templates in fortran, > even if none of them is included in any fortran norm > (and none of them is detailed in a fortran book, to my knowledge) : > - pre-processing macros, > - clever use of the "include" statement, > - m4 macros. > Hi, From what I have experienced, after starting to program in Fortran after 15 years, is that there is very boring to write the same control logic all over the program, especially when you have to make a minor change and need to do the same update in many places. Not to metion the probability to introduce errors by doing so. I also find it boring to write the logic needed to be able to select a certain algorithm during program execution. As I see it, parametrized derived types and CLASS(*) has the intention to let you do this, but I think that you have to include something more or extend the these constructs to really have something that helps. One idea that I have: Would it not be possible to also parametrize the procedures? Something like this subroutine bbbbb(E,F,H,D) type,type :: A=(INTEGER,REAL),B=(TypeX,typeY),C character(10), length :: D=("AlgorithmA") type(A),allocateable :: E(:) class(B) :: B type(C) :: H .. .. .. end The compiler could then use the type of E and F, and the value of D, to select the specific subroutine to use, and I could use D to select the algorithm to use during program execution. Regards Gunnar
From: GaryScott on 16 Apr 2008 16:39
On Apr 16, 12:36 pm, gunnar <bjorkm...(a)gmail.com> wrote: > On 15 Apr, 16:16, relaxmike <michael.bau...(a)gmail.com> wrote: > <snip> > From what I have experienced, after starting to program in Fortran > after 15 years, is that there is very boring to write the same control > logic all over the program, especially when you have to make a minor > change and need to do the same update in many places. Not to metion > the probability to introduce errors by doing so. I also find it boring > to write the logic needed to be able to select a certain algorithm > during program execution. While I have experienced this code duplication "problem" on rare occasion, I find that I fail to see that it is a great programming concern. I don't oppose adding such capabilities to the language, but please make it a formal part of the language and not some add-on that will be poorly supported like a pre-processor that largely, probably, poorly duplicates functionality of a pre-existing native JCL or macro language or a more popular preprocessor for another language. <snip> Regards Gunnar |