- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
1. Did all the belt points go away with the new forum? I now have "none". (Which might be a good time to change my email address from the forum to the Premier support)
2. Is this legal Fortran:
TYPE ConstructionData
<snip == many variables>
!Complex Fenestration
TYPE(BSDFWindowInputStruct), ALLOCATABLE :: BSDFInput ! nest structure with user input
END TYPE ConstructionData
And later:
ALLOCATE(Construct(ConstrNum)%BSDFInput) -- note -- no dimension.
IVF doesn't seem to complain. gfortran (V4.8) didn't complain either until it tried to use it in an unallocated way.
(Removed ALLOCATABLE and ALLOCATE statement and gfortran was happier).
But -- is this legal Fortran?
Link Copied
6 Replies
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
1) Check the Dashboard button at the top of the forum page to see if your status is reported. If not, I'd be happy to file a forum bug ticket asking how people should ask for such corrections.
2) If you want checking for standard compliance, you must set the /stand option on the compile line. I'll leave it to those more expert on this to weigh in on whether your example is outside the standard; if so, /stand ought to flag it. Not flagging extensions under /stand would be a reportable bug (needing an actual example which compiles).
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
As long as the array Construct has been allocated or defined and ConstrNum is a valid index into this array.
Steve may have to answer to if an ALLOCATABLE attribute can be applied to a non-array user defined type.
Note you can have a pointer to a non-array user defined type and allocate to that pointer.
As you have your code written, you may have entered an ambiguous situation that is not covered by the documentation (but may be addressed by the F2003/8 specifications).
Jim Dempsey
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Yes, for some reason, the points showed back up when I posted.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Allocatable scalars are standard F2003. Can be any type, intrinsic or user-defined. The really fun variant is deferred-length character:
[fortran]
CHARACTER(:), ALLOCATABLE :: vstr
ALLOCATE (vstr(47)) ! Creates a CHARACTER(47)
vstr = 'abc123' ! Reallocates to length 6
[/fortran]
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Yea, okay. But this is an "allocatable" type that is not allocated to any length, to repeat:
TYPE ConstructionData
---snip == many variables
!Complex Fenestration
TYPE(BSDFWindowInputStruct), ALLOCATABLE :: BSDFInput ! nest structure with user input
END TYPE ConstructionData
And later:
ALLOCATE(Construct(ConstrNum)%BSDFInput) -- note -- no dimension.
Above is allocating TYPE BSDFInput that is part of TYPE ConstructionData which is allocated a dimension. Is the Dimension somehow implied?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
BSDFInput is a scalar component (that happens to be allocatable). It has no dimension - to supply one (after BSDFInput in the allocate statement) would be an error. The allocate statement is allocating just that component of one single element in the "parent" variable Construct (element number ConstrNum).
Having allocatable scalar components that are just integers or reals is probably not all that exciting, but in addition to Steve's example of a deferred length character components, allocatable scalars are useful for polymorphic components and cases where the component may itself be of derived type and that type may be large.
(While you've shown the definition of the type, you've not shown the declaration of that Construct variable. Presumably it is an array, or the allocate statement would cop a syntax error.)
More rambling just for extra clarity: If ConstrNum had the value 2 and there were no other statements, then Construct(1)%BSDFInput would remain unallocated. If Construct was itself an allocatable (as opposed to the component), and had not been allocated when the allocate statement you show was executed, then your program would explode - that allocate statement is not trying to allocate Construct - it is allocating one of its components.
(My belt got changed to a red one lately, which no longer matches my shoes. I presume that red colour reflects the build status in tinderbox of all the projects I am working on.)

Reply
Topic Options
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page