(j3.2006) Pre-Processed Programs Poorly Designed? (Was: Select Rank)

[Craig Dedo CAPM]

> -----Original Message-----

> From: j3-bounces at mailman.j3-fortran.org [mailto:j3-bounces at mailman.j3-fortran.org]

> On Behalf Of Bill Long

> Sent: Wednesday, February 18, 2015 13:56

> To: fortran standards email list for J3

> Subject: Re: (j3.2006) Select Rank

> 

> On Feb 18, 2015, at 10:10 AM, Keith Bierman < <mailto:khbkhb at gmail.com> khbkhb at gmail.com> wrote:

> >

> > On Wed, Feb 18, 2015 at 12:57 AM, Malcolm Cohen < <mailto:malcolm at nag-j.co.jp> malcolm at nag-j.co.jp> wrote:

> > ?...  fpp is better, but

> > even so it's not official and not 100% portable.  And doesn't solve

> > the tool problem.

> >

> > ?Well, the fpp source code is available, and reasonably portable.  If memory

> serves, it does put appropriate markings in the code that some tools (many

> debuggers) use to get the line numbering right.

> >

> > One hazard is on systems which don't properly supported mixed case file names,

> bork.F90 becomes bork.f90, and can clobber bork.F90 on line 1 of processing (got

> caught with this recently running Linux in a VM on a clients Windows system, where

> the source was in a shared folder, rather than inside the VM itself). An obvious

> approach would be to change the fpp processor to use .ftn and .f90 or some such?.

> >

> > ?But I take your point, it would be cleaner to have an all Fortran

> > solution. I'm not sure I buy "INCLUDE" as being much more pure than

> > #include, but the rest of the processing is where both the good and

> > bad lies ;>?

> 

> In general (my opinion) a Fortran program that requires preprocessing, or uses

> included files (either spelling), or has a build process that is anything beyond a

> simple make file is most likely poorly designed.

> 

> Cheers,

> Bill

> 

> Bill Long

>  <mailto:longb at cray.com> longb at cray.com

> Fortran Technical Suport  &                                  voice:  651-605-9024

> Bioinformatics Software Development                     fax:  651-605-9142

> Cray Inc./ Cray Plaza, Suite 210/ 380 Jackson St./ St. Paul, MN 55101

 

            I disagree.  There are several situations that require some kind of pre-processing, much as I dislike it.  One of the more important is that the Fortran standard does not require any specific kind of any data type.  This is explicitly left as processor-dependent.  Thus, programs that are written for more than one combination of compiler and OS require some kind of method of determining which kind types of each data type are supported.  Almost always, this is some kind of pre-processor directive.  Consider:

 

Real ? Almost all compilers support IEEE floating-point single and double, but support for any IEEE floating-point is NOT guaranteed.  Some compilers support Intel 10-byte reals, others don?t.  Some compilers support IEEE quad precision, others don?t.

 

Integer ? At least one compiler (GNU GFortran) supports 16-byte integers, others don?t.  

 

Character ? Almost all compilers support ASCII but this is NOT guaranteed.  Some compilers support ISO 10646 UCS-4, but others don?t.  One compiler supports both UCS-4 AND UCS-2, others don?t.

 

            Please feel free to contact me at any time with any questions or concerns that you may have.  I am looking forward to hearing from you soon.

 

Sincerely,

Craig T. Dedo, CAPM

17130 W. Burleigh Place

P. O. Box 423                         Mobile Phone:  (414) 412-5869

Brookfield, WI   53008-0423    E-mail:  < <mailto:craig at ctdedo.com> craig at ctdedo.com>

USA

Linked-In:   <http://www.linkedin.com/in/craigdedo> http://www.linkedin.com/in/craigdedo

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.j3-fortran.org/pipermail/j3/attachments/20150218/ea722ca6/attachment.html