- 신규로 표시
- 북마크
- 구독
- 소거
- RSS 피드 구독
- 강조
- 인쇄
- 부적절한 컨텐트 신고
I am not sure if this is a compiler bug or how Fortran is supposed to work, but if I allocate an allocatable array, then later deallocate it, then the SIZE function returns the size it was previously allocated with.
PROGRAM ALLOCATOR ! DOUBLE PRECISION, DIMENSION(:), ALLOCATABLE:: X ! ALLOCATE(X(10)) ! WRITE(*,*) SIZE(X),ALLOCATED(X) ! >> 10 T ! DEALLOCATE(X) ! WRITE(*,*) SIZE(X),ALLOCATED(X) ! >> 10 F ! END PROGRAM
Should it not return zero since the array no longer has any size?
Thanks
링크가 복사됨
- 신규로 표시
- 북마크
- 구독
- 소거
- RSS 피드 구독
- 강조
- 인쇄
- 부적절한 컨텐트 신고
Such things are only reliable if the array has been allocated. Not a bug as such. It is at the same level as local variables in subroutines and functions not retaining their values between calls, even if they appear to (unless they have the SAVE attribute). The same goes for pointer variables.
- 신규로 표시
- 북마크
- 구독
- 소거
- RSS 피드 구독
- 강조
- 인쇄
- 부적절한 컨텐트 신고
As Arjen says, your program violates the Fortran standard by asking for the SIZE of an unallocated array. Here are the standard's words about the argument to SIZE:
shall be an array of any type. It shall not be an unallocated allocatable variable or a pointer that is not associated.
- 신규로 표시
- 북마크
- 구독
- 소거
- RSS 피드 구독
- 강조
- 인쇄
- 부적절한 컨텐트 신고
It is always possible to override (not technically) and use an alternative routine if it is necessary to make decisions based on the size of an array.
PROGRAM ALLOCATOR DOUBLE PRECISION, DIMENSION(:), ALLOCATABLE:: X ! ALLOCATE(X(10)) ! WRITE(*,*) SIZEO(X),ALLOCATED(X) ! >> 10 T ! DEALLOCATE(X) ! WRITE(*,*) SIZEO(X),ALLOCATED(X) ! >> 0 F CONTAINS ! FUNCTION SIZEO(VAR) RESULT(ASIZE) DOUBLE PRECISION, ALLOCATABLE:: VAR(:) INTEGER :: ASIZE IF (.NOT.(ALLOCATED(VAR))) THEN ASIZE = 0 ELSE ASIZE = SIZE(VAR) END IF END FUNCTION SIZEO ! END PROGRAM
- 신규로 표시
- 북마크
- 구독
- 소거
- RSS 피드 구독
- 강조
- 인쇄
- 부적절한 컨텐트 신고
I came across this problem and forum post yesterday while teaching a post-doc some modern Fortran.
Please may I respectfully suggest a compiler flag which can raise a runtime error when we try to apply size to an unallocated array.
Or, for the standards committee...
size(a [,dim] [,stat] [,errmsg])
Thanks
Norman
- 신규로 표시
- 북마크
- 구독
- 소거
- RSS 피드 구독
- 강조
- 인쇄
- 부적절한 컨텐트 신고
I suppose the main frustration is that the standard does not define what should happen if an unallocated array or unassociated pointer is presented to size. My preference would be 0. What is not good is that Intel currently returns pseudo random answers, some of which may be plausible but wrong.
But thanks for the clarification.
- 신규로 표시
- 북마크
- 구독
- 소거
- RSS 피드 구독
- 강조
- 인쇄
- 부적절한 컨텐트 신고
The standard does indeed specify this:
ARRAY shall be assumed-rank or an array. It shall not be an unallocated allocatable variable or a pointer that is not associated.
Since you broke this rule, the result is undefined - which can be anything. The proper thing is for you to test that the argument is allocated or associated first.
- 신규로 표시
- 북마크
- 구독
- 소거
- RSS 피드 구독
- 강조
- 인쇄
- 부적절한 컨텐트 신고
- I came across this problem and forum post yesterday while teaching a post-doc some modern Fortran.
- ------------------------------------------------------------------------------------------------------
- Re note on your teaching a post-doc -- they should have learnt this language before they reached the end of a PhD.
- personal opinion.
- 신규로 표시
- 북마크
- 구독
- 소거
- RSS 피드 구독
- 강조
- 인쇄
- 부적절한 컨텐트 신고
In C/C++
char* futz; // undefined
int len = strlen(futz);
Just what do you expect the value of len to become?
In Fortran, you do have the opportunity to test for ALLOCATED or ASSOCIATED prior to obtaining the SIZE.
Quirk RE Fortran. You can allocate to size of 0. Therfore, if you insist on interpreting SIZE == 0 as not allocated, then allocate to size of 0 (and document copiously what you are doing).
Jim Dempsey
- 태그:
- c++
- 신규로 표시
- 북마크
- 구독
- 소거
- RSS 피드 구독
- 강조
- 인쇄
- 부적절한 컨텐트 신고
As others have said Fortran has the allocated function. Automatic run time checks would require additional code being executable pretty much every time you touch and allocatable. That sound like it would add inefficiency instead of leaving it fully under user control.
