Paul van Delst wrote:
> Rich Townsend wrote:
>> Just out of curiosity, could anyone enlighten me why allocatable
>> scalars aren't allowed in derived types (in F2003 or F95 + TR15581)?
>> It strikes me as this could be a useful way of having a component that
>> either has a well-defined value (ALLOCATED(foo%bar) == .TRUE.) or has
>> no value (ALLOCATED(foo%bar) == .FALSE.).
>
> Probably because what you want to use them for is a bad idea? :o)
>
> What wrong with using an actual component that you explicitly set? E.g.
>
> type mytype
> logical :: bar = .false.
> ...other stuff
> end type mytype
>
> ?
>
> Why would you want to use an ALLOCATABLE component for simply checking
> true/false? If there is a good reason (which I doubt) what about,
>
> type mytype
> integer,allocatable :: bar(:)
> ...other stuff
> end type mytype
> ....
> type(mytype) :: foo
>
> You can still use that for your test:
>
> if( allocated(foo%bar) ) then
> ....
> end if
>
> ?
Well, suppose I wanted a scalar integer that had the standard range of
values
[-HUGE(0) -> +HUGE(0), plus the non-model numbers], but could also be
'unset'.
Having the scalar be unallocated is a nice way to implement the 'unset'
feature.
Plain old Fortran 'undefined' won't cut the mustard in this respect, since
to
reference an undefined variable in any manner is WWIII-causer.
>
>
> cheers,
>
> paulv
>
> p.s. Welcome back.
Thanks!
|
