Allocatable derived type components?

To the good people at Silverfrost,

I tried the latest Personal Edition of FTN95, and it seems that allocatable derived type components are not yet supported. Any estimate as to when these will be added?

Thanks, Ludwig

Can you provide a short and simple example of code that does not work.

If it is in the Fortran 95 standard then the ommission needs to be classified as a bug.

Dear Paul,

Thanks so much for your reply. The following code... (the emoticon comes out when I put a colon between parentheses.)

module example type test1 real, dimension(10) :: a, b end type test1 type test2 real, dimension(:), allocatable :: a, b end type test2 end module example

produces the this error message upon compilation:

fatal 515 - ALLOCATABLE is invalid in the definition of a derived TYPE

The constant array dimension is fine, but the allocatable attribute within the type test2 is not. Perhaps I am missing something. (The above works with gfortran).

With best regards, Ludwig

The Fortran 95 standard does not say that you can use ALLOCATABLE in this context. It allows you to use POINTER and this serves the same purpose. I have not checked the Fortran 2003 standard.

It looks like you can ignore or downgrade this error (using for example /ignore 515). For the next release I will change the default to a warning unless /ISO is specified. If it causes no problems then we can remove the warning later.

You can change the compiler defaults by using /config. You may have edit the resulting configuration file by hand in order to implement /ignore 515.

Quoted from PaulLaidler The Fortran 95 standard does not say that you can use ALLOCATABLE in this context. It allows you to use POINTER and this serves the same purpose. I have not checked the Fortran 2003 standard.

This is a topic of real interest to me at the moment so I have been doing my homework, and I came to the same conclusion as Paul states above. However, when I try and implement it, I am falling at the first hurdle. I actually want to use derived types but I can't even make it work with intrinsic types. The following code:

    module pointless
    type mytype
      integer, pointer :: a (:)
    end mytype

! type (mytype) b end module pointless

(usual display problem with 'colon right bracket ⇒ smiley face') compiles OK, but as soon as I try and declare an actual variable of type mytype, by uncommenting line 5, FTN95 v5.10.0 barfs horribly, as below.

Am I myself horribly misunderstanding something? (even if so, compilers should not barf 😢 ). I've checked all the things fixed in subsequent releases and it doesn't mention anything like this.

Andy

Access violation: The instruction at address 0042e388 attempted to read from location 00000004 0042b86e make_new_variable(<ref>(<ptr>char),int,longÄlongÄint,int,<ptr>structÄtoken,enum [+2b1a]

00430dad add_variables(int,longÄlongÄint,int,<ptr>char,<ptr>structÄtoken,enumÄlogical) [+007a]

0040a953 parse_declaration_statement(<ptr>char,int,int,<ref>int) [+364e]

0041202b handle_token(<ptr>char,int,int,int,int,<ref>int) [+0df5]

0040514d ProcessEntireLine(void) [+0695]

0040619b compile(<ptr>char) [+00ce]

00401000 main [+049b]

00559736 SALFStart [+06ff]

eax=041f2700 ebx=040deab8 ecx=00000000 edx=00000000 esi=041f3440 edi=041f2700 ebp=0383f830 esp=0383d590 IOPL=0 ds=0023 es=0023 fs=003b gs=0000 cs=001b ss=0023 flgs=00210202 [NC OP NZ SN DN NV] 0360/6820 TSTK=5 [ ] 0042e388 push [ecx+0x4]

0042e38b push edi

Andy

The following code compiles OK for me.

module pointless 
type mytype 
integer, pointer :: a(:) 
end type 
type (mytype) b 
end module pointless 

<slaps forehead> Doh. I'd like to say 'that'll teach me to try and write sensible code at 01:30' but I don't suppose it will. It *will *reinforce the lesson about the perils of mixing keywords and variable names, though. Out of curiosity, I mutated the code some more and discovered, not sure whether to my delight or horror, that even this compiles OK:

    module pointless 
    type type 
    integer, pointer :: type(:) 
    end type 
    type (type) type
    end module pointless

However, I have now tried v5.21 and it catches the syntactical error (that v5.10 misses), which leads to the problem. And I also now see the reported bug fix (I think) in vv5.20:

Missing 'TYPE' in 'END TYPE' causes a module to terminate prematurely

I guess 'terminate prematurely' is the correct technical term for 'barf horribly'.

Andy