- 新着としてマーク
- ブックマーク
- 購読
- ミュート
- RSS フィードを購読する
- ハイライト
- 印刷
- 不適切なコンテンツを報告
Hello,
I wonder why the following two methods of filling the strings fmt(i), generate different results.
In the debugger the strings appear to be exactly the same, but writing the strings using the format statement generates different results.
The first method gives: 'F9.0 '
The second method gives: 'F9.0 F6.0 '
It seems to be a hidden length problem, because when I fool the compiler by defining the function frmt as character(4) in the interface section. the result is again as it should be.
Thanks,
Walter Kramer
I wonder why the following two methods of filling the strings fmt(i), generate different results.
In the debugger the strings appear to be exactly the same, but writing the strings using the format statement generates different results.
The first method gives: 'F9.0 '
The second method gives: 'F9.0 F6.0 '
implicit none
character(6) :: fmt(4)
character(12) :: bufstr(2)
interface
character(6) function frmt(cs)
character(6), intent(in) :: cs
end function
end interface
fmt(1)=frmt('F9.0')
fmt(2)=frmt('F6.0')
write(bufstr(1),100) fmt(1),fmt(2)
fmt(3)='F9.0'
fmt(4)='F6.0'
write(bufstr(2),100) fmt(3),fmt(4)
100 format(A,A)
end
character(6) function frmt(cs)
character(6), intent(in) :: cs
frmt=cs
end function
It seems to be a hidden length problem, because when I fool the compiler by defining the function frmt as character(4) in the interface section. the result is again as it should be.
Thanks,
Walter Kramer
コピーされたリンク
6 返答(返信)
- 新着としてマーク
- ブックマーク
- 購読
- ミュート
- RSS フィードを購読する
- ハイライト
- 印刷
- 不適切なコンテンツを報告
Sorry, wrong tags:
Hello,
I wonder why the following two methods of filling the strings fmt(i), generate different results.
In the debugger the strings appear to be exactly the same, but writing the strings using the format statement generates different results.
The first method gives: 'F9.0 '
The second method gives: 'F9.0 F6.0 '
It seems to be a hidden length problem, because when I fool the compiler by defining the function frmt as character(4) in the interface section. the result is again as it should be.
Thanks,
Walter Kramer
Hello,
I wonder why the following two methods of filling the strings fmt(i), generate different results.
In the debugger the strings appear to be exactly the same, but writing the strings using the format statement generates different results.
The first method gives: 'F9.0 '
The second method gives: 'F9.0 F6.0 '
implicit none
character(6) :: fmt(4)
character(12) :: bufstr(2)
interface
character(6) function frmt(cs)
character(6), intent(in) :: cs
end function
end interface
fmt(1)=frmt('F9.0')
fmt(2)=frmt('F6.0')
write(bufstr(1),100) fmt(1),fmt(2)
fmt(3)='F9.0'
fmt(4)='F6.0'
write(bufstr(2),100) fmt(3),fmt(4)
100 format(A,A)
end
character(6) function frmt(cs)
character(6), intent(in) :: cs
frmt=cs
end function
It seems to be a hidden length problem, because when I fool the compiler by defining the function frmt as character(4) in the interface section. the result is again as it should be.
Thanks,
Walter Kramer
- 新着としてマーク
- ブックマーク
- 購読
- ミュート
- RSS フィードを購読する
- ハイライト
- 印刷
- 不適切なコンテンツを報告
Walter,
A recent thread introduced me to the Memory Debug Window. Set a breakpoint on your "end" statement and run to that point. Open the Memory window and type fmt as the Address. You'll see that the last two characters of fmt(1) and fmt(2) are NULs (x00), while the last two characters of fmt(3) and fmt(4) are spaces (x20). Looks like the actual arguments have to be padded to six characters.
Dick
A recent thread introduced me to the Memory Debug Window. Set a breakpoint on your "end" statement and run to that point. Open the Memory window and type fmt as the Address. You'll see that the last two characters of fmt(1) and fmt(2) are NULs (x00), while the last two characters of fmt(3) and fmt(4) are spaces (x20). Looks like the actual arguments have to be padded to six characters.
Dick
- 新着としてマーク
- ブックマーク
- 購読
- ミュート
- RSS フィードを購読する
- ハイライト
- 印刷
- 不適切なコンテンツを報告
Dick, thank you.
Luckily I didn't have to pad the actual argument with spaces. I now use character(*) as type definition for the argument. This solves the problem.
Walter
Luckily I didn't have to pad the actual argument with spaces. I now use character(*) as type definition for the argument. This solves the problem.
Walter
- 新着としてマーク
- ブックマーク
- 購読
- ミュート
- RSS フィードを購読する
- ハイライト
- 印刷
- 不適切なコンテンツを報告
I am still curious.
If actual character argument A is passed to dummy argument B, and A has less characters than B, then B will be padded with NUL characters. In an ordinary assignment B=A, B will be padded with blanks.
I this a consequence of passing by reference?
Walter
If actual character argument A is passed to dummy argument B, and A has less characters than B, then B will be padded with NUL characters. In an ordinary assignment B=A, B will be padded with blanks.
I this a consequence of passing by reference?
Walter
- 新着としてマーク
- ブックマーク
- 購読
- ミュート
- RSS フィードを購読する
- ハイライト
- 印刷
- 不適切なコンテンツを報告
Well, when a constant, such as string literal 'F6.0' has to be passed
into routine by reference, compiler has to "make up" a real address of
it somehow. Now, Compaq's experts could tell you better, but it
can be done either by:
a) passing the address where the constant is actually stored in the
image of .exe file itself or
b) creating a space somewhere on the stack, filling it with the
value of the constant and passing address of that space.
In your case, what you get as value of the actual argument, is your
constant plus whatever happened to be immediately behind the space in memory where it is stored. I guess you're just lucky that you get CHAR(0)
there, but I may be wrong. Point is, that the declaration of dummy argument (LEN=6) just overrides the actual length of the constant (passed
as hidden argument), which is 4 in the example.
With simple assignment (B=A) compiler "knows" what's the right thing to
do, since it has all information present; with your sample, it perhaps could deduce that it should pad the rest with blanks, but it apparently doesn't,
and I wouldn't blame Compaq for that.
Btw, I deem declaring character arguments other than (LEN=*) bad practice and I don't see why otherwise would it allowed at all -- perhaps someone can tell a good reason, but I don't see it right now.
Jugoslav
into routine by reference, compiler has to "make up" a real address of
it somehow. Now, Compaq's experts could tell you better, but it
can be done either by:
a) passing the address where the constant is actually stored in the
image of .exe file itself or
b) creating a space somewhere on the stack, filling it with the
value of the constant and passing address of that space.
In your case, what you get as value of the actual argument, is your
constant plus whatever happened to be immediately behind the space in memory where it is stored. I guess you're just lucky that you get CHAR(0)
there, but I may be wrong. Point is, that the declaration of dummy argument (LEN=6) just overrides the actual length of the constant (passed
as hidden argument), which is 4 in the example.
With simple assignment (B=A) compiler "knows" what's the right thing to
do, since it has all information present; with your sample, it perhaps could deduce that it should pad the rest with blanks, but it apparently doesn't,
and I wouldn't blame Compaq for that.
Btw, I deem declaring character arguments other than (LEN=*) bad practice and I don't see why otherwise would it allowed at all -- perhaps someone can tell a good reason, but I don't see it right now.
Jugoslav
- 新着としてマーク
- ブックマーク
- 購読
- ミュート
- RSS フィードを購読する
- ハイライト
- 印刷
- 不適切なコンテンツを報告
Jugoslav, thanks for your explanation. In the future I will follow your advise and declare all character dummy arguments with (LEN=*).
Walter Kramer
Walter Kramer