 |
forums.silverfrost.com Welcome to the Silverfrost forums
|
| View previous topic :: View next topic |
| Author |
Message |
LitusSaxonicum
Joined: 23 Aug 2005 Posts: 2428 Location: Yateley, Hants, UK
|
Posted: Sun Sep 30, 2012 6:04 pm Post subject: |
|
|
Aha! I see it now. If only I hadn't been too lazy to retype the routine name, and hadn't just cut'n'pasted it from FTN95.CHM ...
Eddie |
|
| Back to top |
|
 |
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 8283 Location: Salford, UK
|
Posted: Sun Sep 30, 2012 7:53 pm Post subject: |
|
|
/DCLVAR requires that you declare all subprograms when they are called.
I have corrected FTN95.chm. |
|
| Back to top |
|
 |
DanRRight
Joined: 10 Mar 2008 Posts: 2945 Location: South Pole, Antarctica
|
Posted: Mon Oct 01, 2012 12:33 am Post subject: |
|
|
| Is declaring subroutines as external legal portable standard Fortran? |
|
| Back to top |
|
 |
JohnCampbell
Joined: 16 Feb 2006 Posts: 2625 Location: Sydney
|
Posted: Mon Oct 01, 2012 3:01 am Post subject: |
|
|
/dclvar is like an extension to /implicit_none.
I have tried to adopt this as a coding convention to document all variables and called routines, but without using /dclvar, I have not consistently updated my EXTERNAL declarations.
Adopting /dclvar could enforce this convention.
There is a question as to how using EXTERNAL as a documention of routines used conforms to the standard, but it can assist as a documentation of the code when returning to update.
Are warnings provided for both undeclared routines and declared routines that are not used ?
The use of EXTERNAL for documenting routines being used may conflict with the use of clearwin.ins, where the external declaration is in the include file. (not sure of this)
John |
|
| Back to top |
|
 |
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 8283 Location: Salford, UK
|
Posted: Mon Oct 01, 2012 10:21 am Post subject: |
|
|
EXTERNAL is included in the Fortran standard.
Warnings are only provided (with /DCLVAR) for undeclared routines otherwise there would be a problem with INCLUDE statements for standard libraries. |
|
| Back to top |
|
 |
LitusSaxonicum
Joined: 23 Aug 2005 Posts: 2428 Location: Yateley, Hants, UK
|
Posted: Mon Oct 01, 2012 11:16 am Post subject: |
|
|
Strictly speaking, EXTERNAL is required for FUNCTION names passed as a parameter to a subprogram, as otherwise a compiler could flag the name as a variable name.
For example
| Code: |
EXTERNAL LIAM, MICK
CALL INIO (JOHN, KEITH, LIAM)
CALL INIO (JOHN, KEITH, MICK)
|
would be correctly interpreted as variable, variable, function, but without the EXTERNAL if would be variable, variable, variable.
Until I used Clearwin, I couldn't see the point of this, as if in INIO, LIAM is always used as a function, there is no point in passing its name, and if INIO is sometimes called with LIAM, and sometimes with MICK, one could pass a single value of 1 or 2 (say) and within the routine, call LIAM for 1, and MICK for 2 (or .TRUE. and .FALSE., 0 or 1 etc).
I can't imagine that any compiler/linker throws a sulk if a symbolic name declared EXTERNAL hasn't been used in a subprogram call anywhere in the code, and so the habit arose of declaring many or all subprogram names as EXTERNAL, just to show in the source code that they are not simple variables and that they should be searched for a link time. I saw this a lot when I read programs that had (multiple) named BLOCK DATA sections, as these are not otherwise referred to in the source code, and if missing would not be noticed.
It all gets a bit complicated with Fortran 90 et seq.
Eddie
PS I noticed when reading CLEARWIN.INS (v 6.10) that there is this:
| Code: |
C_EXTERNAL CREATE_INTERPROCESS_SHAERMEM@ &
&'__create_interprocess_shared_memory' (STRING,VAL) |
Is it a typo, and if so, has it been fixed?
E |
|
| Back to top |
|
 |
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 8283 Location: Salford, UK
|
Posted: Mon Oct 01, 2012 2:06 pm Post subject: |
|
|
| Yes I fixed this just a few days ago. |
|
| Back to top |
|
 |
DanRRight
Joined: 10 Mar 2008 Posts: 2945 Location: South Pole, Antarctica
|
Posted: Tue Oct 02, 2012 6:11 pm Post subject: |
|
|
| By some reason i do not like declarations of subroutines as external, or just lazy to add somewhere between 1000 and 10000 more lines, but may be i'm still not getting something. I understand that compiler might be confused with the functions (taking them as variables, so i declared that properly despite of it probably was done same 10000 times) but it seems to me that compiler can easily find if this is a subroutine or not because it is always CALLed. |
|
| Back to top |
|
 |
JohnCampbell
Joined: 16 Feb 2006 Posts: 2625 Location: Sydney
|
Posted: Wed Oct 03, 2012 5:41 am Post subject: |
|
|
Dan,
There are times, such as a function as an argument, where EXTERNAL must be used.
I also try to extend the implicit_none approach to use EXTERNAL to document, at the start of a routine, all routines that are being used.
When I do it properly, I find this to be useful to document what can be assumed of this routine for using other functions. It is useful when you come back to maintain or change the code.
This is not really related to the original post, as it has evpolved somewhat.
John |
|
| Back to top |
|
 |
LitusSaxonicum
Joined: 23 Aug 2005 Posts: 2428 Location: Yateley, Hants, UK
|
Posted: Wed Oct 03, 2012 11:46 am Post subject: |
|
|
John and Dan,
What does (ab)using EXTERNAL give you that a comment line does not? Indeed, in comments, one can list:
Subroutines CALLed by this subprogram
Functions used by this subprogram
This subprogram called from ...
(Ab)using EXTERNAL can at best provide the first two, and even then, gives no pointer to which source code file (and line!) to find it in.
You don't need EXTERNAL at all if you go the extra distance and use MODULEs.
Eddie |
|
| Back to top |
|
 |
DanRRight
Joined: 10 Mar 2008 Posts: 2945 Location: South Pole, Antarctica
|
Posted: Thu Oct 04, 2012 5:34 am Post subject: |
|
|
Modules do not need external -- good. But I still do not see strong reason that subroutines MUST be declared as external for using /DCLVAR for all the rest cases. Compiler can exclude them from that itself.
Also, returning to original restriction on control length - isn't it just possible to increase the limit from current 1280x1280 to say 2560x2560 ? |
|
| Back to top |
|
 |
|
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|