 |
forums.silverfrost.com
Welcome to the Silverfrost forums
|
| View previous topic :: View next topic |
| Author |
Message |
sparge
Joined: 11 Apr 2005
Posts: 371
|
 Posted: Tue Feb 15, 2011 5:27 pm Post subject: How to redefine a PARAMETER in one easy lesson |
 |
|
Compare and contrast the two following snippets of code ...
FTN95 v6 issues several errors (as it should) if asked to compile this:
| Code: |
program parammed
use param
integer i, six (six)
six (:) = 6
write (*, '(i10)') (six (i), i = 1, 6)
end program parammed
module param
integer, parameter :: six = 6
end module param
|
On the other hand, it is happy to compile and run the following without error, even using /CHECKMATE:
| Code: |
program parammed
use param
call sixy
end program parammed
module param
integer, parameter :: six = 6
contains
subroutine sixy
integer i, six (six)
six (:) = 6
write (*, '(i10)') (six (i), i = 1, 6)
end subroutine sixy
end module param
|
It manages to use the PARAMETER declaration of six to redefine six as an integer array with six elements. I know that there are no reserved names in FORTRAN, but I think a compiler ought to recognise when a program attempts to redefine its own terminology (as it does in the first example). Ask not how I came by this perverse concept  but seems a pretty clear bug to me. What do others think? |
|
| Back to top |
|
 |
PaulLaidler
Site Admin
Joined: 21 Feb 2005
Posts: 8210
Location: Salford, UK
|
| Posted: Tue Feb 15, 2011 7:47 pm Post subject: |
|
|
I doubt if the Fortran standard has anything to say about this.
The reason this works OK is that, internally, module variable names are decorated according to which module they come from. So internally the two representations for "six" look quite different. They are also stored in a different way. |
|
| Back to top |
|
|
sparge
Joined: 11 Apr 2005
Posts: 371
|
| Posted: Wed Feb 16, 2011 11:36 am Post subject: Re: |
|
|
| PaulLaidler wrote: | | The reason this works OK is that, internally, module variable names are decorated according to which module they come from. So internally the two representations for "six" look quite different. They are also stored in a different way. |
Hmmm ... on that basis, I would expect the first code snippet to be OK and the second one not, but it's the other way around?
And it's not working OK - if you follow it in SDBG, the program does not know about a parameter called six. It's not in the variables window, even with the option checked to show parameters - and any attempt to use six rather than 6 (as it were) causes compile or run time errors. |
|
| Back to top |
|
|
PaulLaidler
Site Admin
Joined: 21 Feb 2005
Posts: 8210
Location: Salford, UK
|
| Posted: Wed Feb 16, 2011 11:52 am Post subject: |
|
|
Your code sample works OK for me provided, of course, that you change the order so that the module is defined first. This means that the declaration six(six) causes no problem.
The fact that parameters cannot be seen in SDBG is a known bug that still needs fixing. As far as I know parameters can never be seen as intended within SDBG.
If your code is changed by replacing 6 by six, at either point, the code does produce a compilation error but in these contexts the compiler thinks six is the array. |
|
| Back to top |
|
|
sparge
Joined: 11 Apr 2005
Posts: 371
|
| Posted: Wed Feb 16, 2011 12:32 pm Post subject: Re: |
|
|
| PaulLaidler wrote: | | Your code sample works OK for me provided, of course, that you change the order so that the module is defined first. This means that the declaration six(six) causes no problem. |
Hmm ... well, I have my module and my main program in separate files, so order of definition is not a factor for me. And based on what you say about internal decoration, order of definition ought not to matter - the internal decoration ought to resolve the apparent ambiguity.
The declaration does not cause a problem; that's what I don't understand. The compiler knows what six is for the purpose of declaring the array, but by the time it reaches executable statements it has "forgotten".
| PaulLaidler wrote: | | The fact that parameters cannot be seen in SDBG is a known bug that still needs fixing. As far as I know parameters can never be seen as intended within SDBG. |
It seems to be flakey - I have had problems with it sometimes. At the moment I have a project open and can see the parameters just fine. Which is why I knew something was amiss yesterday, once I realised I had inadvertently declared an array with the same name as a parameter - when I ran the code, I could still see other parameters but not the one that had been "redefined".
| PaulLaidler wrote: | | If your code is changed by replacing 6 by six, at either point, the code does produce a compilation error but in these contexts the compiler thinks six is the array. |
And yet from what you say, it ought to be able to distinguish the two incarnations of "six", because internally they do not have the same name?
I figured maybe the issue was being clouded because one "six" was a parameter and the other "six" was a variable. So I wrote this snippet, which fails to compile because "six" has already been declared in module param - as I would expect. But you say this ought not to trouble the compiler because the two declarations are made in separate modules?
| Code: |
module param
integer six
end module param
module parammed
use param
integer six
end module parammed
|
|
|
| Back to top |
|
|
PaulLaidler
Site Admin
Joined: 21 Feb 2005
Posts: 8210
Location: Salford, UK
|
| Posted: Wed Feb 16, 2011 12:56 pm Post subject: |
|
|
| Sorry but I cannot take this any further. It will all make sense in the detailed order of various passes through the code whilst parsing and compiling. |
|
| 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
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
