Fortran templates
in [Fortran]
|
From: Gerry Ford on 16 Apr 2008 02:10 "Arjen Markus" <arjen.markus(a)wldelft.nl> wrote in message news:0a01dacb-fcd7-4279-8d60-833a9ce60c14(a)b5g2000pri.googlegroups.com... In Fortran 2003 you can use the class facilities and unlimited polymorphic variables to solve these problems, but material showing how to do that is limited so far. --->Would you consider these class facilities and unlimited polymorphic variables as "object-oriented?" -- "Shopping for toilets isn't the most fascinating way to spend a Saturday afternoon. But it beats watching cable news." ~~ Booman
From: Arjen Markus on 16 Apr 2008 02:50 On 16 apr, 08:10, "Gerry Ford" <ge...(a)nowhere.ford> wrote: > "Arjen Markus" <arjen.mar...(a)wldelft.nl> wrote in message > > news:0a01dacb-fcd7-4279-8d60-833a9ce60c14(a)b5g2000pri.googlegroups.com... > > In Fortran 2003 you can use the class facilities and unlimited > polymorphic variables to solve these problems, but material > showing how to do that is limited so far. > > --->Would you consider these class facilities and unlimited polymorphic > variables as "object-oriented?" > They can certainly be used in that way - for a suitable definition of "object-oriented". But the main point is that they give you the possibility to define interfaces that allow a wide range of actual types. Regards, Arjen
From: Arjen Markus on 16 Apr 2008 02:57 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
From: Arjen Markus on 16 Apr 2008 02:59 On 15 apr, 18:33, Bil Kleb <Bil.K...(a)NASA.gov> wrote: > relaxmike wrote: > > Hi all fortran gurus ! > > Hi. > > > Are there other well-known methods ? > > Apparently not well-known, but there is: > > http://www.macanics.net/forpedo/ > > Regards, > -- > Bil Klebhttp://fun3d.larc.nasa.gov I often use Tcl scripts or Fortran programs to generate the specific code, if other methods fail - fairly ad hoc, but it works splendidly. Regards, Arjen
From: relaxmike on 16 Apr 2008 04:15
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 |