Home > Archive > Fortran > June 2005 > creating directories on the fly
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
creating directories on the fly
|
|
| Bart Vandewoestyne 2005-06-01, 4:00 pm |
| Hello,
I'm having an application where I want to write out some data. Each
dataset is specific to some testfunction with some specific
testparameters and is for a specific dimension, e.g.
testfunction 'f1' has parameter 'a=0.5' and is 100-dimensional.
Therefore, i would like the data for that test to arrive in a directory
like
../f1/a0p5/dim100/
Now because the user can choose the function, parameter a and dimension himself
when running the program, i do not know these parameters in advance so i can't
create these directories in advance using a script or something. I have to
create them on the fly after the user has typed his parameters.
Now I am looking for the solution that is most standard-conforming and
which should still run on different OS'es like Linux, Windows, ...
After building up the string with the directory name in it, i have found
that i can do something like (using the F-compiler):
call system("mkdir -p testdir")
But I see different problems with this method:
1) I used the -p flag to get no errors if testdir already exists. This
seems less portable than not using the -p flag... because i cannot be
sure that every mkdir command has this -p flag... But if i don't use
the -p flag, i get errors if the directory already exists... can i
use certain standard fortran subroutines/functions to check if a directory
already exists?
2) On
http://groups.google.be/group/comp....6d36bf98a61c655
I have found that the SYSTEM subroutine is not part of the standard, but
is an extension. However, if I compile a simple test-program that uses
the SYSTEM subroutine with the F-compiler, i do not get warning messages
and the compiler also doesn't report to me that it is an extension... I
cannot find any documentation on the SYSTEM subroutine in my book 'The F
programming language' by Metcalf and Reid. I'm a bit  now... is
the use of SYSTEM really non-standard? Then why does the F-compiler
allow it? Walt?
3) Is there another way rather than using the SYSTEM subroutine to
create a directory on the fly in a Fortran 95 program? And hopefully in an
operating system independent way? Because I would like to keep my code
working on as much platforms as possible without having to use too many
tricks...
Thanks for the help and suggestions,
Bart
--
"Share what you know. Learn what you don't."
| |
| Walt Brainerd 2005-06-01, 4:00 pm |
| Bart Vandewoestyne wrote:
> Hello,
>
> I'm having an application where I want to write out some data. Each
> dataset is specific to some testfunction with some specific
> testparameters and is for a specific dimension, e.g.
>
> testfunction 'f1' has parameter 'a=0.5' and is 100-dimensional.
> Therefore, i would like the data for that test to arrive in a directory
> like
>
> ./f1/a0p5/dim100/
>
> Now because the user can choose the function, parameter a and dimension himself
> when running the program, i do not know these parameters in advance so i can't
> create these directories in advance using a script or something. I have to
> create them on the fly after the user has typed his parameters.
>
> Now I am looking for the solution that is most standard-conforming and
> which should still run on different OS'es like Linux, Windows, ...
>
> After building up the string with the directory name in it, i have found
> that i can do something like (using the F-compiler):
>
> call system("mkdir -p testdir")
>
> But I see different problems with this method:
>
> 1) I used the -p flag to get no errors if testdir already exists. This
> seems less portable than not using the -p flag... because i cannot be
> sure that every mkdir command has this -p flag... But if i don't use
> the -p flag, i get errors if the directory already exists... can i
> use certain standard fortran subroutines/functions to check if a directory
> already exists?
>
> 2) On
> http://groups.google.be/group/comp....6d36bf98a61c655
> I have found that the SYSTEM subroutine is not part of the standard, but
> is an extension. However, if I compile a simple test-program that uses
> the SYSTEM subroutine with the F-compiler, i do not get warning messages
> and the compiler also doesn't report to me that it is an extension... I
> cannot find any documentation on the SYSTEM subroutine in my book 'The F
> programming language' by Metcalf and Reid. I'm a bit now... is
> the use of SYSTEM really non-standard? Then why does the F-compiler
> allow it? Walt?
This answer is going to be a bit of a cop-out. Of course, the syntax
call anything (...) is standard. On the other hand, system is not a
standard intrinsic subroutine. So it is not described in "Programmers
Guide to F", either, but is described in the manual "F Compiler and
Tools" that comes with the compiler.
There are lots of other tools that come with F also, such as routines
to solve equations. These have been integrated into F in the sense
that all you have to do is put the appropriate USE statement in your
program and call them. Thus, they look like built-in modules. These
also are described in the "Tools" manual.
So the answer is: call anything is legal F syntax; if the "anything"
is not an intrinsic subroutine, somebody must provide it; many
procedures that are not standard intrinsics are provided with the
F compiler.
Since call system (...) executes an operating system command, it is
sort-of-by-definition dependent on the OS. If the command is Unix-like
and you have Cygwin installed on Windows, that should cover a lot of
the common cases.
> 3) Is there another way rather than using the SYSTEM subroutine to
> create a directory on the fly in a Fortran 95 program? And hopefully in an
> operating system independent way? Because I would like to keep my code
> working on as much platforms as possible without having to use too many
> tricks...
>
> Thanks for the help and suggestions,
> Bart
>
| |
| Walter Spector 2005-06-01, 4:00 pm |
| Bart Vandewoestyne wrote:
> ...
> After building up the string with the directory name in it, i have found
> that i can do something like (using the F-compiler):
>
> call system("mkdir -p testdir")
As you've discovered, the F95 Standard does not have a 'system' call to allow
you to do this. Any such library routine will therefore be less than portable.
IMHO the closest one can get to a Standard-conforming solution is to use the POSIX 1003.9
PXF calls - PXFMKDIR in particular. But they are not universally implemented either.
If the compilers you use do support PXFMKDIR, then here is how to call it:
call PXFMKDIR (path, ipathlen, imode, ierror)
where:
path = CHARACTER string with requested directory name (input)
ipathname = # of significant characters in 'path'.
(Note: A value of 0 means trim blanks, but due to a certain buggy
implementation of PXF, I'd recommend len_trim (path))
imode = protection mode - (e.g., o"755")
ierror = returns 0 if successful. Otherwise returns errno.
Note that someday the 'mkdir' system call should be easy to call directly, via
F2003 C Interop.
> But I see different problems with this method:
>
> 1) ... can i
> use certain standard fortran subroutines/functions to check if a directory
> already exists?
The most accurate way, again using PXF, is to do a PXFSTAT system call to read the
file systems information about a given file. Extract the st_mode field with PXFINTGET.
Last use the PXFISDIR function to see if the file is a directory or not.
Something like:
logical, external :: PXFISDIR
character(512) :: pathname
integer :: jstat ! "handle" for a stat structure
integer :: mode
integer :: pxferr
:
call PXFSTRUCTCREATE ('stat', jstat, pxferr) ! create a stat structure
call PXFSTAT (pathname, len_trim (pathname), jstat, pxferr) ! do the stat call
call PXFINTGET (jstat, 'st_mode', mode, pxferr) ! look at st_mode
if (PXFISDIR (mode)) then...
which roughly correlates to the following C code:
#include <sys/stat.h>
char *path; // pointer to some file name
struct stat *s;
mode_t mode;
:
s = malloc (sizeof (struct stat));
if (stat (path, s) == -1) { /* handle errors */ }
if (S_ISDIR (s->st_mode)) ...
Unfortunately I've no idea how to portably write the above using F2003 C Interop.
So, IMO, PXF will remain the most standardized way to do it.
> 2) ... if I compile a simple test-program that uses
> the SYSTEM subroutine with the F-compiler, i do not get warning messages
> and the compiler also doesn't report to me that it is an extension...
> ... why does the F-compiler
> allow it? Walt?
Walt Brainerd will have to answer that one. :)
Walt Spector
(w6ws at earthlink dot net)
| |
| Madhusudan Singh 2005-06-01, 4:00 pm |
| Bart Vandewoestyne wrote:
> Hello,
>
> I'm having an application where I want to write out some data. Each
> dataset is specific to some testfunction with some specific
> testparameters and is for a specific dimension, e.g.
>
> testfunction 'f1' has parameter 'a=0.5' and is 100-dimensional.
> Therefore, i would like the data for that test to arrive in a directory
> like
>
> ./f1/a0p5/dim100/
>
> Now because the user can choose the function, parameter a and dimension
> himself when running the program, i do not know these parameters in
> advance so i can't
> create these directories in advance using a script or something. I have
> to create them on the fly after the user has typed his parameters.
>
> Now I am looking for the solution that is most standard-conforming and
> which should still run on different OS'es like Linux, Windows, ...
>
> After building up the string with the directory name in it, i have found
> that i can do something like (using the F-compiler):
>
> call system("mkdir -p testdir")
>
> But I see different problems with this method:
>
> 1) I used the -p flag to get no errors if testdir already exists. This
> seems less portable than not using the -p flag... because i cannot be
> sure that every mkdir command has this -p flag... But if i don't use
> the -p flag, i get errors if the directory already exists... can i
> use certain standard fortran subroutines/functions to check if a directory
> already exists?
>
> 2) On
>
http://groups.google.be/group/comp....6d36bf98a61c655
> I have found that the SYSTEM subroutine is not part of the standard, but
> is an extension. However, if I compile a simple test-program that uses
> the SYSTEM subroutine with the F-compiler, i do not get warning messages
> and the compiler also doesn't report to me that it is an extension... I
> cannot find any documentation on the SYSTEM subroutine in my book 'The F
> programming language' by Metcalf and Reid. I'm a bit now... is
> the use of SYSTEM really non-standard? Then why does the F-compiler
> allow it? Walt?
>
> 3) Is there another way rather than using the SYSTEM subroutine to
> create a directory on the fly in a Fortran 95 program? And hopefully in
> an
> operating system independent way? Because I would like to keep my code
> working on as much platforms as possible without having to use too many
> tricks...
>
> Thanks for the help and suggestions,
> Bart
>
You may want to look at fortranposix :
http://www.sourceforge.net/projects/fortranposix.
The library is not complete yet, but I think your issue can be addressed
using the functions already implemented. If not, I will be happy to add the
required functions to it.
Portability might be an issue (on Windows) in using any POSIX based solution
because Windows does not include these functions unless you install Windows
services for Unix.
| |
| Bart Vandewoestyne 2005-06-01, 8:58 pm |
| In article <429DC347.9050802@fortran.com>, Walt Brainerd wrote:
>
> This answer is going to be a bit of a cop-out. Of course, the syntax
> call anything (...) is standard.
OK, i can agree with that :-)
> On the other hand, system is not a standard intrinsic subroutine.
OK. That's basically what I wanted to know...
> So it is not described in "Programmers
> Guide to F", either, but is described in the manual "F Compiler and
> Tools" that comes with the compiler.
OK. Thanks for this reference... i did not know of that manual... I
have made myself a printed copy now :-)
> There are lots of other tools that come with F also, such as routines
> to solve equations. These have been integrated into F in the sense
> that all you have to do is put the appropriate USE statement in your
> program and call them. Thus, they look like built-in modules. These
> also are described in the "Tools" manual.
>
> So the answer is: call anything is legal F syntax; if the "anything"
> is not an intrinsic subroutine, somebody must provide it; many
> procedures that are not standard intrinsics are provided with the
> F compiler.
OK. After reading this, I have the following facts and questions:
Fact 1: Apparently I don't need a USE statement to be able to call the
SYSTEM subroutine...
Fact 2: When I try to use allocatable dummy arguments, i get a clear
indication *at compile time* that I'm using an 'Extension', for
example:
Extension: example_expand_allocatable.f95, line 27: ALLOCATABLE
dummy argument P detected at ::@P
Fact 3: Although the SYSTEM subroutine does not belong to the Fortran
standard, i don't get an indication that I'm using an extension...
So here are my two questions:
Question 1: shouldn't the use of the SYSTEM subroutine be only possible
when doing an explicit USE statement, so the user knows he is USE'ing
some library routine which is vendor-specific?
Question 2: shouldn't the use of the SYSTEM subroutine give a warning at
compile time when compiling it with the F-compiler, so a user *knows* he
is using an extension?
> Since call system (...) executes an operating system command, it is
> sort-of-by-definition dependent on the OS. If the command is Unix-like
> and you have Cygwin installed on Windows, that should cover a lot of
> the common cases.
OK... thanks for the clarifications... I guess after reading through all
the answers, there is actually no real, clean and proper way to create
directories in a system/vendor-independent way :-(
Regards,
Bart
--
"Share what you know. Learn what you don't."
| |
| Richard E Maine 2005-06-01, 8:58 pm |
| In article <1117652997.236380@seven.kulnet.kuleuven.ac.be>,
Bart Vandewoestyne <MyFirstName.MyLastName@telenet.be> wrote:
> Fact 3: Although the SYSTEM subroutine does not belong to the Fortran
> standard, i don't get an indication that I'm using an extension...
I don't think you understood Walt's reply. Doing "call system(...)" is
*NOT* an extension. Go look it up in the standard if you want; perfectly
standard syntax. Calling subroutines is not an extension. Period.
It is completely standard-conforming for me to name my own subroutine
SYSTEM and to then call it. I'd be darned annoyed if any compiler
decided to warn me about calling my own subroutine, particularly if I
gave it the EXTERNAL attribute. THat would just plain be a broken
compiler.
Now if you gave the INTRINSIC attribute to system, then things would be
different. The compiler would have at least half a chance. But then, it
would also be incompatible with most other implementations, which
consider it an external rather than an intrinsic.
> Question 1: shouldn't the use of the SYSTEM subroutine be only possible
> when doing an explicit USE statement, so the user knows he is USE'ing
> some library routine which is vendor-specific?
I'd agree with that as a general design philosophy. I think that many
things should be in modules. In fact, I've argued for some of the
existing standard intrinsics to be transitioned into modules, but that
proposal didn't meet with much acceptance.
But, in the case of widespread things like SYSTEM, you'd lose much
pretext of portability. Most of the other implementations of it are not
in modules (NAG's being an exception), so if F required it to be in a
module, then code wouldn't port well.
I don't know whether that's a good reason, but its a reason.
> Question 2: shouldn't the use of the SYSTEM subroutine give a warning at
> compile time when compiling it with the F-compiler, so a user *knows* he
> is using an extension?
See above. It is not an extension. The compiler presumably doesn't even
know about it at compile time; it doesn't need to. It is just a plain
old ordinary subroutine called like any other. Presumably, if you
arranged (at link time) to link in a version that you wrote instead of
the version provided in the compiler's run-time library, your version
would get used instead.
> there is actually no real, clean and proper way to create
> directories in a system/vendor-independent way :-(
Alas, you are correct. You may be able to come reasonably close, but you
aren't going to get it completely portable. I don't think anyone in this
thread has mentioned one of the "usual" pieces of advice for
system-dependent things like this. It may seem so obvious as to be
trite, but a lot of people fail to do it anyway. Namely...
Isolate and document it. Isolate the system-dependent part to a small
separate procedure. Ideally, put the procedure in a completely separate
file, possibly grouped with other similar system-dependent procedures,
but separate from the main bulk of your application code. I often find
it wise to have an intermediate procedure of my own. All the calls to my
procedure are then ok; that one procedure is then the only thing likely
to need porting work. It adds an extra level of overhead, but that is
really not going to be measurable for something like this. Then document
that procedure as a system dependency, so that people porting the code
know where to look first.
The other suggestions are then specific candidates for implementations
of that procedure.
--
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
| |
| Bart Vandewoestyne 2005-06-02, 8:58 pm |
| In article <nospam-8057F7.13120901062005@news.supernews.com>, Richard E Maine wrote:
>
>
> I don't think you understood Walt's reply. Doing "call system(...)" is
> *NOT* an extension. Go look it up in the standard if you want; perfectly
> standard syntax. Calling subroutines is not an extension. Period.
>
> It is completely standard-conforming for me to name my own subroutine
> SYSTEM and to then call it. I'd be darned annoyed if any compiler
> decided to warn me about calling my own subroutine, particularly if I
> gave it the EXTERNAL attribute. THat would just plain be a broken
> compiler.
>
> Now if you gave the INTRINSIC attribute to system, then things would be
> different. The compiler would have at least half a chance. But then, it
> would also be incompatible with most other implementations, which
> consider it an external rather than an intrinsic.
OK. I think I understand Walt's reply now a bit more :-)
>
> I'd agree with that as a general design philosophy. I think that many
> things should be in modules. In fact, I've argued for some of the
> existing standard intrinsics to be transitioned into modules, but that
> proposal didn't meet with much acceptance.
>
> But, in the case of widespread things like SYSTEM, you'd lose much
> pretext of portability. Most of the other implementations of it are not
> in modules (NAG's being an exception), so if F required it to be in a
> module, then code wouldn't port well.
>
> I don't know whether that's a good reason, but its a reason.
Hmm... I'm beginning to see the problem here... just like SYSTEM, there
are other intrinsics like SUM etc for which you don't have to use a
USE-statement. The question is then: which ones should require a USE
statement and which ones don't...
Regarding the fact that SYSTEM isn't one of the intrinsics from the
standard, i have the feeling it would be better if a USE statement was
required to be able to use it. In general, i would say that intrinsics
that are defined by the standard should not need a USE, and any
procedures/subroutines/functions that are vendor-specific *do* need a
USE. From this point of view, SYSTEM should need a USE statement... Is
this clear reasoning, or am I overlooking certain details which make
things more complicated?
>
> See above. It is not an extension. The compiler presumably doesn't even
> know about it at compile time; it doesn't need to. It is just a plain
> old ordinary subroutine called like any other. Presumably, if you
> arranged (at link time) to link in a version that you wrote instead of
> the version provided in the compiler's run-time library, your version
> would get used instead.
See above: in my opinion, it would be more natural if the SYSTEM call
required a USE statement, just like for example the routines from the
SLATEC module that comes with the F-compiler also need a USE. Again my
question: could it really be that simple or am i overlooking details
which make things more complicated than as what I am presenting here...
>
> Alas, you are correct. You may be able to come reasonably close, but you
> aren't going to get it completely portable. I don't think anyone in this
> thread has mentioned one of the "usual" pieces of advice for
> system-dependent things like this. It may seem so obvious as to be
> trite, but a lot of people fail to do it anyway. Namely...
>
> Isolate and document it. Isolate the system-dependent part to a small
> separate procedure. Ideally, put the procedure in a completely separate
> file, possibly grouped with other similar system-dependent procedures,
> but separate from the main bulk of your application code. I often find
> it wise to have an intermediate procedure of my own. All the calls to my
> procedure are then ok; that one procedure is then the only thing likely
> to need porting work. It adds an extra level of overhead, but that is
> really not going to be measurable for something like this. Then document
> that procedure as a system dependency, so that people porting the code
> know where to look first.
>
> The other suggestions are then specific candidates for implementations
> of that procedure.
I totally agree and this is now also what I am doing. I have a kind of
'wrapper' routines that contain platform-dependent stuff... should i
change platform, then all i have to do is change these wrapper routines.
Regards,
Bart
--
"Share what you know. Learn what you don't."
| |
| Steven G. Kargl 2005-06-02, 8:58 pm |
| In article <1117748235.986001@seven.kulnet.kuleuven.ac.be>,
Bart Vandewoestyne <MyFirstName.MyLastName@telenet.be> writes:
> In article <nospam-8057F7.13120901062005@news.supernews.com>, Richard E Maine wrote:
>
> Hmm... I'm beginning to see the problem here... just like SYSTEM, there
> are other intrinsics like SUM etc for which you don't have to use a
> USE-statement. The question is then: which ones should require a USE
> statement and which ones don't...
>
> Regarding the fact that SYSTEM isn't one of the intrinsics from the
> standard, i have the feeling it would be better if a USE statement was
> required to be able to use it. In general, i would say that intrinsics
> that are defined by the standard should not need a USE, and any
> procedures/subroutines/functions that are vendor-specific *do* need a
> USE. From this point of view, SYSTEM should need a USE statement... Is
> this clear reasoning, or am I overlooking certain details which make
> things more complicated?
You're overlooking history. Many compilers provided a SYSTEM (or ETIME
or FUBAR or FOO or etc.) procedure long before MODULES were part of the
standard. To suddenly require, all procedures that are not contained
within the current standard to be within a MODULE would break a significant
amount of legacy code.
As a personal programming style, you may want to adopt the explicit
use of the INTRINSIC and EXTERNAL statements.
--
Steve
http://troutmask.apl.washington.edu/~kargl/
| |
| Bart Vandewoestyne 2005-06-03, 9:07 am |
| In article <d7nv5d$4fs$1@gnus01.u.washington.edu>, Steven G. Kargl wrote:
>
> You're overlooking history. Many compilers provided a SYSTEM (or ETIME
> or FUBAR or FOO or etc.) procedure long before MODULES were part of the
> standard. To suddenly require, all procedures that are not contained
> within the current standard to be within a MODULE would break a significant
> amount of legacy code.
OK. This indeed seems like an acceptable argument...
> As a personal programming style, you may want to adopt the explicit
> use of the INTRINSIC and EXTERNAL statements.
Actually, i have never been using INTRINSIC or EXTERNAL statements
because first of all i did not quite 100% understand what they are meant for
and after looking it up in my books it still was not quite clear to me, and
secondly, apparently i could live without them up until now...
Suppose the following program (which compiles with F, but not with g95
because of that SYSTEM), how would i increase my programming style by
using this INTRINSIC or EXTERNAL statement?
program test_create_directory
implicit none
call system("mkdir -p testdir")
open(unit=20, file="testdir/testfile.dat", &
status="replace", access="sequential", action="write")
write(unit=20, FMT="(F32.30)") 1.0
close(unit=20)
end program test_create_directory
I've tried adding
intrinsic system
or
external system
right before the 'implicit none' statement, but apparently this does not work.
Could you explain a bit more what you mean by "As a personal programming style, you may want to adopt the explicit use of the INTRINSIC and EXTERNAL
statements.", maybe by applying this philosophy to the above program?
Thanks,
Bart
--
"Share what you know. Learn what you don't."
| |
| David Flower 2005-06-03, 9:07 am |
| Have you checked out Winteracter (see www.polyhedron.co.uk).
This provides, inter alia, a routine to create a directory, and is
available for a variety of compilers.
Incindently, not only is SYSTEM not standard, but its arguments are
operating-system dependent. To take an extreme case, under g95 windows,
it responds to a few Unix commands only.
| |
| Walt Brainerd 2005-06-03, 4:00 pm |
| Bart Vandewoestyne wrote:
<snip>
>
> Suppose the following program (which compiles with F, but not with g95
> because of that SYSTEM), how would i increase my programming style by
> using this INTRINSIC or EXTERNAL statement?
>
> program test_create_directory
>
> implicit none
>
> call system("mkdir -p testdir")
> open(unit=20, file="testdir/testfile.dat", &
> status="replace", access="sequential", action="write")
> write(unit=20, FMT="(F32.30)") 1.0
> close(unit=20)
>
> end program test_create_directory
>
This compiles and runs fine on my Windows XP version
of g95. What error do you get?
--
Walt Brainerd +1-877-355-6640 (voice & fax)
The Fortran Company +1-520-760-1397 (outside USA)
6025 N. Wilmot Road walt@fortran.com
Tucson, AZ 85750 USA http://www.fortran.com
| |
| Jan Vorbrüggen 2005-06-03, 4:00 pm |
| > Suppose the following program (which compiles with F, but not with g95
> because of that SYSTEM), how would i increase my programming style by
> using this INTRINSIC or EXTERNAL statement?
Both serve only one purpose: namespace management. The standard defines
some intrinsic functions and one intrinsic subroutine. Their names are
not qualified by anything, e.g., a prefix such as FORTRAN_, like the new
IEEE ones are for F03 (and which also require you to USE a module). So
it might happen that some function or subroutine of yours uses the same
name as an intrinsic. If you specify it as EXTERNAL, you are telling the
compiler to _not_ use that intrinsic, but to find the right code else-
where.
Typically, the compiler does not actually look for that code - that is
left to the linker. That is why EXTERNAL is only rarely needed: anything
that is not defined in a compilation unit and is not in the intrinsic
namespace is automatically EXTERNAL.
For your particular problem, however, the consequence is that EXTERNAL
won't help: the compiler doesn't care what SYSTEM does and where it is,
but the linker would like to find it, and you need to supply it with
the correct information in this regard. It will depend on your compiler
where SYSTEM is to be found, and what you have to tell the linker to
find it. Perhaps the documentation says so?
I suppose INTRINSIC is only needed to revoke an in-scope EXTERNAL. That
implies it was only added for F90, because before there were no nested
scopes in Fortran. Or is this incorrect?
Jan
| |
| Richard E Maine 2005-06-03, 4:00 pm |
| In article <3gb8aeFbjrqiU1@individual.net>,
Jan Vorbrüggen <jvorbrueggen-not@mediasec.de> wrote:
> I suppose INTRINSIC is only needed to revoke an in-scope EXTERNAL. That
> implies it was only added for F90, because before there were no nested
> scopes in Fortran. Or is this incorrect?
No, it was not added on f90 and no, that's not its only purpose.
However, the needs for it are rare and obscure. The only reason I've
ever used INTRINSIC was basically for documentation, but it does have
obscure uses.
The only other use I recall off-hand, without spending more time to look
it up or deduce other ones, is that you need INTRINSIC in order to pass
an intrinsic procedure as an actual argument.... except that there are
only a few of them that you can do that with (and it is basically and
old list not getting added to), and you might well have a whole career
of programming in Fortran without ever having even wanted to do one of
those few.
--
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
| |
| Bart Vandewoestyne 2005-06-03, 4:00 pm |
| In article <42A06461.2040202@fortran.com>, Walt Brainerd wrote:
>
> This compiles and runs fine on my Windows XP version
> of g95. What error do you get?
Sorry, I forgot to mention that you need to add the -std=F option to g95
to get it not to compile. Without the -std=F option, it does indeed
compile with g95.
Regards,
Bart
--
"Share what you know. Learn what you don't."
|
|
|
|
|