Richard Maine wrote:
> James Giles <jamesgiles@[EMAIL PROTECTED]
> 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.).
>> I can't find any place that prohibits scalar allocatables in
>> derived types. Do you have a page/line number pair for the
>> part of the standard that says so?
>
> I'm quite confident that they are *NOT* prohibitted in f2003.
> Allocatable scalars weren't in f95 at all, even with the TR. That has
> nothing to do with being a derived type component. The TR added places
> where you could put allocatable things, but it didn't change the fact
> that allocatable things were always arrays.
Ah, thus my confusion -- and thus my inability to get allocatable scalar
components to work on TR-compliant compilers.
>
> F2003 did change that. It allows allocatable scalars. And the change is
> quite im****tant for many things. I've mentioned here many times that I
> think that allocatable strings are a major improvement. While some
> people might think of a string as sort of like an array, the standard
> does not. Allocatable scalars are also useful for polymorphism, where
> the dynamic type gets assigned by the allocation.
>
> Now there are several f95 compilers that have not yet implemented
> allocatable scalars. Is that perhaps what you are talking about? That's
> rather majorly different from the f2003 standard not allowing them. The
> lack of allocatable scalars in the NAG compiler was one of the things
> that kept me from fiddling much with the object-oriented stuff with that
> compiler. It had a lot of the object-oriented features implemented quite
> early, but I found that pretty much everything I wanted to do with
> object orientation ended up with all the polymorphic objects "wanting"
> to be allocatable scalars. Thus the lack of allocatable scalars pretty
> much killed that. Yes, I could have made them pointers as a workaround,
> but that would have introduced extra "issues." But this was all about
> the state of implementation of that compiler - not about the standard.
>
> If you found anywhere in the standard that even implies such a
> restriction, I'd sure like to know. Perhaps you found a stray occurance
> of some mention of "allocatable array" that should have been changed to
> "allocatable variable." I recall making that change an awful lot in
> working on f2003. We tried to catch al of them, but I suppose one might
> have gotten overlooked somewhere. If you've found such a thing, please
> let us know.
Nope, I just re-read the TR, and saw that the 'allocatable components' bit
referred only to allocatable arrays, not scalars. Having erroneously
thought
that allocatable scalars were fine elsewhere, it seemed odd to me that
they
weren't permitted as derived-type components. So, my remarks are based on
a
misunderstanding of F95+TR, not something I read in the F2003 standard.
>
> But if it is just that the compiler griped that you can't have an
> allocatable scalar, that probably means that the compiler just hasn;t
> implemented them yet.
>
Yep, 'tis true...
|
