May I please have a little clarification by my favourite rocket scientist on: that fortran is 'not pass by reference'.
The default in fortran is (surely?!) that the argument suffers 'pass by reference' behaviour, whereas the default in vanilla C is that the argument suffers 'pass by copy' behaviour (to coin a phrase). That is in fortran (without any other specification) a change to the argument (alias) in the subroutine will result in a change to the pass (original) in the main.
I postulate perhaps that Richard means: one cannot assume that the means to the end is actually pass by reference. Perhaps he will be kind enough to put me out of my misery at reading these potentially misleading comments.
Specifically, I would like to confirm that the default standard in fortran is an effective 'pass by reference'.
Regards
Gaz
-----Original Message-----
From: Richard Maine [mailto:[log in to unmask]]
Sent: Friday, 8 August 2003 1:03 AM
To: [log in to unmask]
Subject: obscure fortran features
Drew McCormack writes:
> What I need are the following features:
>
> 1) A means of storing pointers to procedures in a data structure. I
> know this is not directly supported, but is there some back door to
> achieving this (other than C)?
They are supported in f2k, which you said you can't wait for. Other
than that, there is no reasonably standard or portable way, no. There
are always vendor-specific hacks, bt they aren't even close to portable.
> 2) Procedures that effectively take generic pointers (ie like C's
> void*) to memory as arguments. Since Fortran is pass by reference, I
> should be able to achieve this as long as I avoid using an explicit
> interface, which will enforce strong typing. I will need to be able to
> get the memory address of the passed arguments though. Is there an
> official fortran function to get the memory address of a variable?
Again, not until f2k. And again, there are vendor-specific hacks, but
nothing portable. Some vendors have such functions.
P.S. No, Fortran is not pass-by-reference. Assume that too much and
you will get in trouble because it isn't true. Most implementations
do something at least much like pass-by-reference in most situations.
But there are some cases where you basically *CAN'T* do
pass-by-reference. And optimizers have a long history of causing
failures in codes that assume pass-by-reference.
In simple cases like calling a C hack to get the address of a
named variable, and if you steer clear of array sections, pointers,
and other complications, it will probably work.
However, even if it works for your application, I see so many cases
of bugs caused my mistaked assumtions of pass-by-reference that I
cannot let this common myth be restated without challenge. Every
time that it is restated increases the number of times that someone
else will believe it and write a buggy program because of it. Even
if it holds for your application, I hate to see other programmers
mislead into writing buggy code....which does happen on this subject.
> 3) Procedures that can have a variable number of arguments (like "..."
> in C). I know you can do this with the 'optional' keyword from f90, but
> it requires an explicit interface (right?), and that conflicts with (2)
> above.
Right. Also, there is a specific finite list of optional arguments;
this really isn't much like the ... in C.
> Can anyone give me pointers or suggested solutions to one or more of
> these requirements?
For the first 2, I really think that your best near-term options are
either to use a C wrapper back door or to find vendors that have early
implementations of the relevant f2k features. I don't think you'll do
much better. I can't think of anything good for the last one...
heck, I'm leary of the C "..." feature even in C. I have some
inherited C code that I can't port from one of my linux boxes to
another because the C "..." feature has multiple incompatable
implementations, and the one used in the code isn't supported by the
version of the compiler on the new system. (Suppose if I spent enough
hours I could port it, but it takes me a *LOT* of time to do much of
anything in C and the trivial attempts here didn't work.)
--
Richard Maine | Good judgment comes from experience;
[log in to unmask] | experience comes from bad judgment.
| -- Mark Twain
************************************************************************
The information in this e-mail together with any attachments is
intended only for the person or entity to which it is addressed
and may contain confidential and/or privileged material.
Any form of review, disclosure, modification, distribution
and/or publication of this e-mail message is prohibited.
If you have received this message in error, you are asked to
inform the sender as quickly as possible and delete this message
and any copies of this message from your computer and/or your
computer system network.
************************************************************************
|