IDE for ifort on Linux
in [Fortran]
|
From: David W Noon on 11 Jul 2010 09:00 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Sat, 10 Jul 2010 14:40:22 -0700 (PDT), mariano mendez wrote about Re: IDE for ifort on Linux: [snip] > - Change Fixed-format to Free-Format refactoring: Allowing >programmers to change old fixed format files to free format . I'm sure that is a nice aesthetic feature. > - Standarizing Iinput / Output : remove all format statement and >replacing it with character(len),parameter FmtString replacing all >format labels with format string. That is counter-productive. Quite often a format is used in many places, so referring to a label is very convenient, because any change to the format can be applied in a single place and all references pick it up automatically. If you put character string formats all over the place, any changes need to be applied all over the place too. - -- Regards, Dave [RLU #314465] ======================================================================= dwnoon(a)spamtrap.ntlworld.com (David W Noon) Remove spam trap to reply by e-mail. ======================================================================= -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.15 (GNU/Linux) iEYEARECAAYFAkw5wHkACgkQ9MqaUJQw2MmIDgCfT44ylsuDLVX41HyQ2nv+MReo RHsAn1anbOsJ9bL9OgaR+/uwxcKsKpXv =ozQg -----END PGP SIGNATURE-----
From: dpb on 11 Jul 2010 09:40 David W Noon wrote: .... > On Sat, 10 Jul 2010 14:40:22 -0700 (PDT), mariano mendez wrote about > Re: IDE for ifort on Linux: > .... >> - Standarizing Iinput / Output : remove all format statement and >> replacing it with character(len),parameter FmtString replacing all >> format labels with format string. > > That is counter-productive. > > Quite often a format is used in many places, so referring to a label is > very convenient, because any change to the format can be applied in a > single place and all references pick it up automatically. If you put > character string formats all over the place, any changes need to be > applied all over the place too. .... In addition to which it's not likely that the compiler would find duplicate strings this way and will thus store every copy in the executable instead of referring to one. Agree this doesn't seem like _a_good_thing_ (tm) in general practice. --
From: Gordon Sande on 11 Jul 2010 09:55 On 2010-07-11 10:40:45 -0300, dpb <none(a)non.net> said: > David W Noon wrote: > ... >> On Sat, 10 Jul 2010 14:40:22 -0700 (PDT), mariano mendez wrote about >> Re: IDE for ifort on Linux: >> > ... > >>> - Standarizing Iinput / Output : remove all format statement and >>> replacing it with character(len),parameter FmtString replacing all >>> format labels with format string. >> >> That is counter-productive. >> >> Quite often a format is used in many places, so referring to a label is >> very convenient, because any change to the format can be applied in a >> single place and all references pick it up automatically. If you put >> character string formats all over the place, any changes need to be >> applied all over the place too. > ... If there are formats for both a heading and the contents of a table the formats can be placed together to make it easy to change both it the details of how the table is to be presented ever change. If one wants to use character strings they must be literals with the stated disadvantages, variables with the problem that they will need to be defined or parameters with the disadvantage that they will need to be in the declarations. There are other examples of where grouping the formats makes good sense even when the references are scattereed. > In addition to which it's not likely that the compiler would find > duplicate strings this way and will thus store every copy in the > executable instead of referring to one. > > Agree this doesn't seem like _a_good_thing_ (tm) in general practice.
From: Dan Nagle on 11 Jul 2010 12:09 On 2010-07-11 09:40:45 -0400, dpb <none(a)non.net> said: > David W Noon wrote: > ... >> On Sat, 10 Jul 2010 14:40:22 -0700 (PDT), mariano mendez wrote about >> Re: IDE for ifort on Linux: >> > ... > >>> - Standarizing Iinput / Output : remove all format statement and >>> replacing it with character(len),parameter FmtString replacing all >>> format labels with format string. >> >> That is counter-productive. >> >> Quite often a format is used in many places, so referring to a label is >> very convenient, because any change to the format can be applied in a >> single place and all references pick it up automatically. If you put >> character string formats all over the place, any changes need to be >> applied all over the place too. > ... > > In addition to which it's not likely that the compiler would find > duplicate strings this way and will thus store every copy in the > executable instead of referring to one. > > Agree this doesn't seem like _a_good_thing_ (tm) in general practice. I don't see how this follows. There may be some confusion between named constants and literal constants. Note that the OP wrote "character(len),parameter FmtString" I put formats in named character constants, and put the named character constants in a module, and I can make a change in one place (the module) and have it used everywhere. It is also helpful to do so when the format is logically part of a type definition. A format statement is referenced by its label (the statement "number"), so it can only be used by transfer statements within the same scoping unit (C931). This gives repetitions of the format string that must be hunted and found before being updated. And the labels of format statements are a logically distinct space from labels used for branching. Therefore, the programmer has a slight but unnecessary burden of forming two numerical sequences for the two uses of labels, at the risk of trying to transfer to a format, or vice versa. (So that format labels start at, say, 90000 while branch target labels start at, say, 10000.) Note further that format statements cannot appear within the specification part of a module (C1103). The named character constants can be used anywhere the name is visible, and, if defined within a module, can be made visible anywhere by a use statement, giving global access to a single definition. -- Cheers! Dan Nagle
From: steve on 11 Jul 2010 12:25 On Jul 11, 6:00 am, David W Noon <dwn...(a)spamtrap.ntlworld.com> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On Sat, 10 Jul 2010 14:40:22 -0700 (PDT), mariano mendez wrote about > Re: IDE for ifort on Linux: > > [snip] > > > - Change Fixed-format to Free-Format refactoring: Allowing > >programmers to change old fixed format files to free format . > > I'm sure that is a nice aesthetic feature. > > > - Standarizing Iinput / Output : remove all format statement and > >replacing it with character(len),parameter FmtString replacing all > >format labels with format string. > > That is counter-productive. > > Quite often a format is used in many places, so referring to a label is > very convenient, because any change to the format can be applied in a > single place and all references pick it up automatically. If you put > character string formats all over the place, any changes need to be > applied all over the place too. I believe that you may have misread what Mariano wrote. I don't see much difference in the following code: program a call b call c end program a subroutine b real :: x = 42, y = 1066 write(*, 10) x write(*, 10) y 10 format (ES12.4) end subroutine b subroutine c character(len=10), parameter :: fmt = '(ES12.4)' real :: x = 42, y = 1066 write(*, fmt) x write(*, fmt) y end subroutine c It seems that you are interpreting Mariano's statement to mean subroutine c real :: x = 42, y = 1066 write(*, '(ES12.4)') x write(*, '(ES12.4)') y end subroutine c which is not what he wrote. -- steve
First
|
Prev
|
Next
|
Last
Pages: 1 2 3 4 Prev: where can i type this line? Next: Reason to deallocate out array |