Fortran - Does F2003 has the similar fuction like "template" in C++??

Author

Does F2003 has the similar fuction like "template" in C++??

li.simula@gmail.com

2007-06-24, 10:06 pm

I want to kown the 2003 standard that: does it has the similar fuction
like "template" in C++??

James Van Buskirk

2007-06-25, 8:06 am

<li.simula@gmail.com> wrote in message
news:1182735788.707133.13890@m37g2000prh.googlegroups.com...

>I want to kown the 2003 standard that: does it has the similar fuction
> like "template" in C++??

Since f03 contains f95, you can do templates the same way in the
new version as the old. I've got several examples written in
template style on my web page, http://home.comcast.net/~kmbtib/ .
f03 didn't help with the storage association problem that can
be seen in http://home.comcast.net/~kmbtib/For...ENERIC_BLAS.ZIP
and I haven't gotten around to redoing
http://home.comcast.net/~kmbtib/For.../order_stat.i90 ,
http://home.comcast.net/~kmbtib/For...r_stat_test.f90 with
IMPLICIT declaration of templated entities yet; been too busy with
other stuff, sorry. Maybe if anyone got interested enough I could
be talked into devoting some time to it...

--
write(*,*) transfer((/17.392111325966148d0,6.5794487871554595D-85, &
6.0134700243160014d-154/),(/'x'/)); end

highegg

2007-06-25, 8:06 am

On Jun 25, 3:43 am, li.sim...@gmail.com wrote:
> I want to kown the 2003 standard that: does it has the similar fuction
> like "template" in C++??

A short answer is no. There are parameterized types in F2003, but you
can't parameterize them by other types, just by "kind" and "length"
parameters.
I do not believe that there is a general agreement amongst Fortran
users that something like C++ templates even should be in Fortran.
A macro processor is a roughly equivalent tool; less convenient but
probably more powerful and more transparent.
C++ templates are being abused in a horrible way to build up a
convenient syntax for various metaprogramming techniques (most notably
in Boost project), starting with the Barton-Nackman trick and working
up from there. For instance, using the ublas library,
typically a whole hierarchy of classes is created to compile a
simple vector arithmetic (the templates are reused, so things not so
bad asymptotically) statement like a = b*exp(-t)/c. (a,b,c,t vectors).
A macro processor is much more easy to understand for a moderately
skilled programmer. I have good experience with metaprogramming in
Fortran via m4, others have mentioned even using Ruby or similar
scripting tools.

Bil Kleb

2007-06-25, 8:06 am

highegg wrote:
> On Jun 25, 3:43 am, li.sim...@gmail.com wrote:
>
> [..] others have mentioned even using Ruby or similar scripting tools.

We use Ruby for Fortran templating, unfortunately we haven't
waded through our bureaucracy to release it.

Forpedo is available: http://www.macanics.net/forpedo/
It is Python-powered.

Regards,
--
Bil Kleb
http://fun3d.larc.nasa.gov

Craig Powers

2007-06-25, 10:07 pm

highegg wrote:
> On Jun 25, 3:43 am, li.sim...@gmail.com wrote:
>
> A short answer is no. There are parameterized types in F2003, but you
> can't parameterize them by other types, just by "kind" and "length"
> parameters.
> I do not believe that there is a general agreement amongst Fortran
> users that something like C++ templates even should be in Fortran.
> A macro processor is a roughly equivalent tool; less convenient but
> probably more powerful and more transparent.
> C++ templates are being abused in a horrible way to build up a
> convenient syntax for various metaprogramming techniques (most notably
> in Boost project), starting with the Barton-Nackman trick and working
> up from there. For instance, using the ublas library,
> typically a whole hierarchy of classes is created to compile a
> simple vector arithmetic (the templates are reused, so things not so
> bad asymptotically) statement like a = b*exp(-t)/c. (a,b,c,t vectors).
> A macro processor is much more easy to understand for a moderately
> skilled programmer. I have good experience with metaprogramming in
> Fortran via m4, others have mentioned even using Ruby or similar
> scripting tools.

I'd question whether kludges around the things that C++ doesn't have and
Fortran does should be taken as indictments of the template mechanism
generally.

With respect to a macro processor, I assume you mean something "better"
(for a suitable definition of "better") than the C preprocessor --
templates were created because the C preprocessor was judged to be
insufficient, and I doubt the vast quantity of metaprogramming in
existence now was contemplated when they were created.

highegg

2007-06-26, 4:17 am

> With respect to a macro processor, I assume you mean something "better"
> (for a suitable definition of "better") than the C preprocessor --
> templates were created because the C preprocessor was judged to be
> insufficient, and I doubt the vast quantity of metaprogramming in
> existence now was contemplated when they were created.

Well, originally, templates were created for implementing type-generic
classes without diving into polymorphism and thus sacrificing
performance (which is a huge concern of C++). I do not question the
original purpose.
However, constructing a hierarchy of classes for evaluation of an
arithmetic expression or unrolling a short loop really feels somewhat
wicked. The template mechanism is apparently used for things it wasn't
intended to.
F2008 "smart macros" would probably be better, but I'm still not sure
it is worth to do. I think that the need for metaprogramming only
arises in large projects, and a large project can afford incorporating
external metaprogramming tool.

C preprocessor is ill-suited for Fortran metaprogramming, m4 is
certainly better.

Tobias Burnus

2007-06-26, 8:06 am

Hello all,

On Jun 25, 9:15 am, highegg <high...@gmail.com> wrote:
> On Jun 25, 3:43 am, li.sim...@gmail.com wrote:
>
> A macro processor is much more easy to understand for a moderately
> skilled programmer. I have good experience with metaprogramming in
> Fortran via m4, others have mentioned even using Ruby or similar
> scripting tools.

Well, the Fortran 2008 draft proposes:
DEFINE MARCRO
(See "3.5 Macro processing" in ftp://ftp.nag.co.uk/sc22wg5/N1651-N1700/N1678.pdf)

Tobias,
who is not sure whether he likes all the difficult to implement
additions of Fortran 2003 and 2008, though many are useful (ISO C
bindings).

Colin Paul Gloster

2007-07-18, 7:12 pm

In news:4680429c$0$63179$a726171b@news.hal-pc.org timestamped Mon, 25
Jun 2007 18:32:33 -0400, Craig Powers <enigma@hal-pc.org> posted:
|-------------------------------------------------------------------------|
|"[..] |
| |
|I'd question whether kludges around the things that C++ doesn't have and |
|Fortran does should be taken as indictments of the template mechanism |
|generally." |
| |
|-------------------------------------------------------------------------|

What is trying to be achieved by them should not be derided, but the
technique used in C++ (and Java and Ada and so on) instead of currying
functions as in languages such as ML is a sign of a limitation. From
16.4 Higher-order functions
of
Mordechai (Moti) Ben-Ari, "Understanding Programming Languages",
hyperlinked to from
HTTP://STWWW.Weizmann.ac.Il/g-cs/be.../index.html#upl
:"[..]

Note that unlike imperative languages, this generalization is achieved
naturally without any additional syntax or semantics like generic or template.

[..]"

|-------------------------------------------------------------------------|
|"[..] and I doubt the vast quantity of metaprogramming in |
|existence now was contemplated when they were created." |
|-------------------------------------------------------------------------|

The creator of C++ stated that he would not want to prevent people
using features in unexpected ways.

Regards,
Colin Paul Gloster

Sponsored Links