Storing/Retrieving TYPEs with ALLOCATABLE components (TR) (long)
From: Jugoslav Dujic (jdujic_at_yahoo.com)
Date: 03/03/04
- Next message: James Van Buskirk: "Re: Derived type individual elements (F90)"
- Previous message: Rich Townsend: "Re: Derived type individual elements (F90)"
- Next in thread: Richard Maine: "Re: Storing/Retrieving TYPEs with ALLOCATABLE components (TR) (long)"
- Reply: Richard Maine: "Re: Storing/Retrieving TYPEs with ALLOCATABLE components (TR) (long)"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Wed, 3 Mar 2004 17:46:34 +0100
I'm passing this on from IVF/CVF Forum to c.l.f, where Steve and
I had a brief discussion. For sake of completeness, here are
declarations of relevant structures:
TYPE T_ENTRY
INTEGER(1):: iPair(2) = 0
...
END TYPE T_ENTRY
TYPE T_BOARD
INTEGER:: nEntries = 0
INTEGER:: iFlags = 0
TYPE(T_ENTRY), ALLOCATABLE:: tEn(:)
END TYPE T_BOARD
TYPE(T_BOARD), ALLOCATABLE:: tBrd(:)
The original question was about non-standard BINARY files, but
for sake of standard-conformance, I'd guess UNFORMATTED could
apply as well. Here's the discussion:
<quote>
<Jugoslav>
I'm revising some old software of mine (CVF 6.6C), which used Form='BINARY'
files for storage. I converted most of the data structure into TYPEs with nested
ALLOCATABLE components.
Currently, the saving code looks like:
OPEN (11, FILE=szNtrFile, FORM='BINARY')
WRITE(11) CURR_VERSION, tNT, tSec, tBrd
DO iB=1,tNT%nBoards
WRITE(11) tBrd(iB)%tEn
END DO
where tBrd is an array of type T_BOARD containing allocatable component tEn(:)
of type T_ENTRY.
My understanding is that WRITE in this case just dumps whatever happens to be in
tBrd, including array descriptor of tEn (i.e. TRANSFER(tBrd, (/0_1/))).
However, retrieval of such file doesn't go without problem (in a subsequent
invocation of program):
READ(11, IOSTAT=iErr) NT
READ(11, IOSTAT=iErr) Sec
READ(11, IOSTAT=iErr) tBrd
ALLOCATE(tBrd(NT%nBoards))
DO i=1,NT%nBoards
DEALLOCATE(tBrd(i)%tEn, STAT=iSt)
ALLOCATE(tBrd(i)%tEn( tBrd(i)%nEntries))
READ(11) tBrd(i)%tEn
END DO
Without previous DEALLOCATE, the allocate line fails at run time with message
"the array is already allocated". With the deallocate, I got "user breakpoint
called from xxxx" somewhere in NTDLL.dll followed by "Heap: Invalid Address
specified to RtlFreeHeap." in the debugger. The program appears to work after
that, but I don't feel comfortable about it. OK, this is easily explainable by
the fact that I'm loading an invalid descriptor tBrd%tEn from the file... but
how can I avoid it?
Basically, I seem to have managed that tEn component has "undefined" allocation
status (which is not possible according to Standard, but then BINARY files
aren't standard either).
I'm open to suggestions how to workaround the problem; binary file is a must,
but some suitable method for avoiding either WRITEing or READing a structure
with wrong descriptor is welcome.
</Jugoslav>
Reply
Re: Storing/Retrieving TYPEs with ALLOCATABLE components Options
sblionel
Moderator
Posts: 3355
Member Since: 03-12-2002
Posted: 03-03-2004 08:16 AM (Viewed 8 times)
Quoting from the TR: "As with ultimate pointer components, variables containing
ultimate allocatable array components are forbidden from appearing directly in
input/output lists - the user shall list any allocatable array or pointer
component for i/o"
[The last phrase seems a bit garbled to me, but I think it's saying that you
have to list the component directly in the I/O list so that its value is read or
written, rather than trying to read or write the descriptor.]
It would not astonish me if the compiler did not detect this as a standards
violation.
Now, this does not seem to be what you are doing, if I understand it correctly.
When you write tBrd(iB)%tEn, if I have it right that tEn is an allocatable array
component, what should be written is the values in the array, if any (a
dereference, if you will), NOT the descriptor. If the array is unallocated,
then the program is invalid as you're not allowed to reference an unallocated
array.
Similarly on a read, the array component would already have to be allocated.
It could be that you have found an aspect of this feature that is not properly
implemented in the compiler....
Steve
Reply
Re: Storing/Retrieving TYPEs with ALLOCATABLE components
jugoslavdujic
Registered User
Posts: 1380
Member Since: 04-22-2002
Posted: 03-03-2004 08:37 AM (Viewed 1 time)
It's a bit garbled to me too... but I parse it as if I do violate the standard,
as I store tBrd array -- which is a "variable containing ultimate allocatable
array components" -- prior to the values of its tEn components. If I parse it
well, then there's no way to save/retrieve tBrd at all (which is really painful,
as it contains other non-allocatable stuff).
I'll pass this on to comp.lang.fortran to see if language gurus have to say
something about it.
</quote>
-- Jugoslav ___________ www.geocities.com/jdujic Please reply to the newsgroup. You can find my real e-mail on my home page above.
- Next message: James Van Buskirk: "Re: Derived type individual elements (F90)"
- Previous message: Rich Townsend: "Re: Derived type individual elements (F90)"
- Next in thread: Richard Maine: "Re: Storing/Retrieving TYPEs with ALLOCATABLE components (TR) (long)"
- Reply: Richard Maine: "Re: Storing/Retrieving TYPEs with ALLOCATABLE components (TR) (long)"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
