Parameter MyVar = ## Vs Parameter ( MyVar = ## )

  • Follow


I'm converting a MS/Compaq Fortran program to my standard old
HP-UX Fortran 90. Does anyone know of a compiler switch or 
setting that allows the the "Parameter" statement to be used
without the parenthesis?

Parameter MyVar = ##   Vs  Parameter ( MyVar = ## )

My compiler also wants me to declare the "MyVar" variable where
the Compaq compiler does not. Anything I can do about that?

Any help much appreciated.

James Kimble
0
Reply jkimble (57) 4/13/2004 8:58:50 PM

jkimble@one.net (James Kimble) writes:

> I'm converting a MS/Compaq Fortran program to my standard old
> HP-UX Fortran 90. Does anyone know of a compiler switch or 
> setting that allows the the "Parameter" statement to be used
> without the parenthesis?
> 
> Parameter MyVar = ##   Vs  Parameter ( MyVar = ## )
> 
> My compiler also wants me to declare the "MyVar" variable where
> the Compaq compiler does not. Anything I can do about that?

I know nothing about special HP-UX switches, but I advise you to
fix the code instead of looking for switches to make it work.

The form with parens is standard Fortran.  It will work
with all f77 (and later) compilers and it will mean the
same thing for all of them.

The form without the parens is a nonstandard form.  It was
adopted by Dec, allegedly from some draft of the f77 standard.
Even Dec's documentation recommends against using it; they
support it only for compatibility with existing codes.
Some compilers support it as a nonstandard feature.

In my experience the majority of people who have used it don't
even understand what it really means.  They think that the
only difference is in the absense of the parens.  I've seen
"bug" reports from people explaining that their code would
have worked on a Vax, but I had a Vax handy and could verify
that they were wrong - they just never understood what that form
of parameter statement actually meant.

Your comment about the compilers "wanting" you to declare the
type is where the difference arises.  The standard parameter
statement implies nothing in particular about type.  The "usual"
rules apply - that names are implicitly typed based on their names
or can be explicitly typed.  If you used "implicit none",
then implicit typing is disabled and the compiler should "want"
you to declare the type.

In the nonstandard form, the type is inferred from the form of
the constant.  You are not allowed to declare it separately,
even as a conformation.

I realize that none of that is any help if, for some reason,
it is impractical for you to fix the code.  This is just all
explanatory about what the difference is.

Yes, when code uses nonstandard forms, it can have problems in porting
to different compilers.  That's sort of what the standard is for.  In
some cases there are sufficient reasons to justify this potential
problem - perhaps the task would be impossible or much more difficult
within the bounds of the standard.  But it is hard to buy that
argument for the nonstandard form of the parameter statement.  As far
as I can tell, that usage arises purely from not knowing the standard
or not caring (or both), rather than from an evaluation that the form
has any benefits worth the cost.

-- 
Richard Maine                       |  Good judgment comes from experience;
email: my first.last at org.domain  |  experience comes from bad judgment.
org: nasa, domain: gov              |        -- Mark Twain
0
Reply nospam47 (9742) 4/13/2004 9:50:54 PM


Richard Maine <nospam@see.signature> wrote in message news:<m1wu4jk0n5.fsf@macfortran.local>...
> 
> I realize that none of that is any help if, for some reason,
> it is impractical for you to fix the code.  This is just all
> explanatory about what the difference is.
> 


No, actually, your message is a great help. I want to standardize this
piece of code and you've told me what I need to know to do that. I can
easily write an awk/Perl script to make the needed changes (as I have
for others) and get this thing done right.

Thanks very much,

James Kimble
0
Reply jkimble (57) 4/14/2004 12:24:37 PM

2 Replies
32 Views

(page loaded in 0.577 seconds)

Similiar Articles:





7/18/2012 7:22:45 AM


Reply: