Why it is forbidden?
in [Fortran]
|
Prev: Caveat: Can One Dim Local Arrays Using Argument List Integers ??
Next: Spam removal - volunteer?
From: Craig Powers on 22 Dec 2009 01:18 Den7 wrote: > > Aren't my examples which write NOT IN THE SAME UNIT but into two > different I/O using have to be allowed? Well, no, they certainly don't HAVE to be allowed, considering that at the present time, they are NOT allowed. If you would like to see that changed, the most productive way to accomplish that is probably to write a proposal to change the standard to allow it. A good proposal would take into account all of the various ways such an allowance would affect the language, including interaction with other features that you may not have considered. If you have a good proposal, then you would also need to find someone who goes to the standards meetings to champion the proposal, but I think it would be more difficult to write a good proposal than, having written one, to find someone willing to try to shepherd it.
From: robin on 22 Dec 2009 05:53 Den7 wrote in message <826b410e-7a06-452e-9660-0b385897cd0b(a)o9g2000prg.googlegroups.com>... >On Dec 21, 3:46 pm, "robin" <robi...(a)bigpond.com> wrote: >> Den7 wrote in message ... >> It requires recursion, not multithreading. > >> Why not change FOO to a subroutine? >> Then you don't have that problem. >in mulththreading we have special lock mechanism which >allows I/O even on the same unit, if you lock >it until it finishes its work, then unlock. Requires multiple copies of the code. Or requires recursive code. Then there's the question of I/O buffers. > Another >I/O will then safely come so two overlapping in time >I/Os will not conflict. That is one more option i >reluctantly pursue now... Why not change FOO to a subroutine? Then you don't have that problem.
From: robin on 22 Dec 2009 05:53 Den7 wrote in message <78740b88-2b8d-42f9-a33a-546b9e7fda20(a)u25g2000prh.googlegroups.com>... >Aren't my examples which write NOT IN THE SAME UNIT but into two >different I/O using have to be allowed? Requires recursive I/O, as many have already said.
From: robin on 22 Dec 2009 05:53 Den7 wrote in message <29ec2a48-e7e0-4eb6-8255-00a03cb2bce6(a)u1g2000pre.googlegroups.com>... >May be there exist a way to implement something resembling ENCODE >- which transforms real or integer value into character >not via internal file write ? Of course there is, and it's easy enough to do it yourself. Converting to integer has been published quite some time ago.
From: robin on 22 Dec 2009 05:53
Den7 wrote in message <7af7ef60-ae7a-4287-95fc-9e19c71ef671(a)a39g2000pre.googlegroups.com>... >Thanks to all for discussions. I plan to request from my Fortran 95 >compiler developers to address this issue at least as an extension, so >what specifically i have to ask as program-minimum and program- >maximum? My minimum requirement is at least to make the code not >crash, this is totally disgusting and DOS-ish. To make my request >completely focused and more solid please check these two snippets >work. The fact it works in some other compilers usually stimulates >developers most. > >Actually where i use it is a bit more complex and not exactly what you >see here, and is related to Windows GUI builder where utilizing >Windows mouse realtime handling may cause out-of-normal-order flow of >the fortran code in callback functions and its crash due to multiple >internal writes could be not completed and overlap in time. Result is >a crash. Yuck. > >So because I have to ask exactly what i need, the program-maximum is >(can i mask more?) > > integer foo > external foo > > open(11,file='11.out') > open(11,file='12.out') > write(11,*) foo(12) > end > > integer function foo(i) > character*9 char_I > write(char_i,'(i9)') i > write(12,*,err=1000) char_i >1000 foo=i > end > > >Or at least the code does not crash on internal write or internal read >(the program-minimum) > > integer foo > external foo > > open(11,file='11.out') > write(11,*) foo(12) > end > > integer function foo(i) > character*9 char_I > write(char_i,'(i9)',err=1000) i >1000 foo=i > end > >Or may be ask for implementing ENCODE/DECODE not via internal write? >Almost all compilers support it based on Polyhedron review. No-one's going to implement non-standard ENCODE/DECODE which became redundant with F77 -- that's 30 years ago. |