Strange error trying to use typed allocation inside a type guard

[Richard_Weed]

Hello,

I'm getting the following error with the attached code and for the life of me I can't figure out what I'm doing wrong. The error occurs with both Intel 14.1 and 18.1. Gfortran's 5-7 give a similar error as does Oracle Developer 12.6 compiler. PGI 18.4 compiles with no error however. I've looked through all my F2003 references and cant find anything that says I'm doing something illegal but I think I am. Can somebody explain whats going on here. The this variable is explictly declared allocatable and the parent type that's extended is not abstract so I'm confused as to what the error message is telling me. error message is:

gentest.F90(36): error #8306: Associate name defined in ASSOCIATE or SELECT TYPE statements doesn't have ALLOCATABLE or POINTER attribute   [THIS]
          ALLOCATE(INT8Data_t :: this)

Also, sorry if this appears twice but this is my first time posting so I think I did something wrong the first time.

Thanks

Rick

[Juergen_R_R]

Is there some code attached to this? I don't see any.

[FortranFan]

Code attachment is missing, but chances are OP has a construct such as

select type ( this => .. )
   ..
   type is ( .. )
     ...
     allocate ( .. :: this )

in which case the associate-name this does NOT have the allocatable attribute.  OP should be able to find details on this (pun intended!) in section 16.4.1.5 Construct association in 04-007 document toward Fortran 2003.

[Richard_Weed]

Sorry FortranFan, I thought I uploaded the source code as an attachment. I found a workaround after I posted this but I still have some questions about the correct behavior. Here is what I was trying to do first.

  Subroutine initGenericData(this, val)

    Implicit NONE

    Class(genericData_t), Intent(OUT), ALLOCATABLE :: this
    Class(*),                          Intent(IN)  :: val

    Select Type(val)

      Type is (Integer(INT8))
        Select Type(this)
          Type is (INT8Data_t)
          ALLOCATE(INT8Data_t :: this)
          this%value = val
        End Select

    End Select

 INT8data_t is just an extension of the genericData_t that contains an INT8 value.

I' found if I moved the ALLOCATE(INT8Data_t::this) ahead of the Select Type(this) statement it worked as expected. My question now is why I need the extra Select Type(this) guard after I do the ALLOCATE(INT8Data_t :: this). ie.

    Type is (INT8))

    ALLOCATE(INT8Data_t :: this)

     this%value = val

gives an error on the this%value assignment (I had it this way first). I would think that the compiler should know the type of the this argument after the ALLOCATE and you could do an intrinsic assignment. I'm trying to refactor some code I wrote to implement standard containers (list, queues etc. using unlimited polymorphic variables). My old code works but its just too top heavy with the type guards etc.required to handle all the data cases I want to cover. I'm leaning toward using a mix of parameterized types and macros to simplify things. To me this is an example of why I believe the current implementation of unlimited polymorphism and the whole select type nonsense is an example of a bad idea implemented poorly. Unfortunately, I can't think of any better way to do it within the constraints of the standard. I hope the standards committee continues to reach out to the user community about how they would like to see generics implemented and how we would use generics in real world codes. I personally just want something like the STL library (say an ISO_FORTRAN_ADT intrinsic module) that gives me all the containers, iterators etc. that the C++ folks get for free. I don't want to see a full macro-like template facility like in C++. Maybe parameterized modules and some changes to the current parameterized types are enough to cover what would be user defined templates in C++. just my 2 cents.

Thanks for your response 

[Juergen_R_R]

I think the reason is that the processor needs to resolve the polymorphic type of `this` at compile time, irrespective of the context of that assignment statement. That is the reason why you need to put it in a `select type` environment. 

[FortranFan]

Weed, Richard wrote:

.. My question now is why I need the extra Select Type(this) guard after I do the ALLOCATE(INT8Data_t :: this). ie.

    Type is (INT8))

    ALLOCATE(INT8Data_t :: this)

     this%value = val

gives an error on the this%value assignment (I had it this way first). I would think that the compiler should know the type of the this argument after the ALLOCATE and you could do an intrinsic assignment. ..

Outside of the SELECT TYPE construct, all that a compiler can acknowledge knowing per the Fortran standard is the declared type of an object which in the above code snippet is genericData_t, irrespective of the CLASS qualification or the ALLOCATE statement.  So if 'value' is a component is component of genericData_t derived type, then the assignment instruction can be accepted by the compiler without a need to place it in a SELECT TYPE construct.

Weed, Richard wrote:

.. .. I'm trying to refactor some code I wrote to implement standard containers (list, queues etc. using unlimited polymorphic variables). My old code works but its just too top heavy with the type guards etc.required to handle all the data cases I want to cover. I'm leaning toward using a mix of parameterized types and macros to simplify things. ..I personally just want something like the STL library (say an ISO_FORTRAN_ADT intrinsic module) that gives me all the containers, iterators etc. that the C++ folks get for free. ..

There is recognition among users as well as many of the Fortran standard committee of the need to provide facilities for generics/templates - chances look good for some capability being added to the language in the next revision Fortran 202X.  So those of us who may be still interested in Fortran a couple of decades from now can look toward to submitting compiler bug reports in year 2038 or later!  However 'standard containers' appear highly unlikely to be part of the IEC ISO Fortran standard or even an extended part of it ( like the -1 or -2 sections) which is a shame.  Advancement of Fortran may be yet prove to be a classic tale of too little, far too late regarding the time line and extent of additional parameterization and other facilities such as iterators getting added to the language, but future Fortranners, however small they may be as a fraction of overall coders in scientific and technical computing, may have some ability to develop their own containers.

In the meantime, all one is left with are the existing limitations so if one continues to use Fortran, one can either stick to the most basic of containers i.e., arrays of each known type or containers with unlimited polymorphic component for the content and/or use macro based approach(es).  Now, as to the issue of requiring extensive use of SELECT TYPE constructs, better design can possibly help reduce the need for such constructs.  If you can show a small working prototype of what you have toward a container e.g., a simple list to hold data of a few types, say INTEGER and REAL, readers here may be able to show other design options.

[Richard_Weed]

FortranFan, thanks again for your comments. I have a working version of lists, queues, etc. using unlimited polymorphism. I was trying to implement a hashmap (aka unordered map) using the same procedure for hashmaps I used for the list etc. but ran into a lot of issues so I was going back and looking if I could simplify things a lot. Re. the decision to not include containers, I think that is very bad news. I hope one day someone will explain the dynamics of the standard committee and why some members appear so adamant about not implementing things that a lot of users are screaming for and have become an accepted part of all of Fortran's competitors. For all of the years of expertise that obviously exists on the committee, I sometimes get the impression that few of them have never written anything in Fortran more complex than the equivalent of Hello World. I just wish they would take the time to look at (like I have) current C++ open source codes in areas such as Computational Fluid Dynamics and Finite Elements. What they will find is the use of the STL in most cases outways the use of hand rolled templates. Even then the user developed templates are almost always some extension of an existing STL container. If Steve Lionel is listening I would propose you follow up your previous user survey with another that 1. lists the topics currently under consideration (like generics) and the proposed implementations for F20xx, 2. publish how the committee voted and why things like containers were rejected, 3. let users then vote on the set of items selected by the committee and let them critique the committtee's decisions. Unfortunately, I'm afraid Fortran will die from what I see as pig-headedness on the part of some committee members and a lack of any real understanding of how modern scientific and engineering applications are really developed. Sad because as I like to point out to my students, Fortran took us to the moon and back. What has C++ really given us but a bunch of video games and other such nonsense.

[FortranFan]

Weed, Richard wrote:

.. I was trying to implement a hashmap (aka unordered map) using the same procedure for hashmaps I used for the list etc. but ran into a lot of issues so I was going back and looking if I could simplify things a lot. ..

Putting aside any discussion on Fortran 202X which is only a needless distraction relative to your original post and getting back to the issue about SELECT TYPE constructs, again there is a case to be made for code design improvements if the code involves, say, more than one such construct (which will be usually be in a getter type of a method) for every type that is supported by the container which will generally needed to be considered explicitly due to the lack of generics in current language standard.

So again if you care to post a minimal working example of your code design, perhaps that can then result in a fruitful discussion of options here.

But otherwise anything about Fortran 202X - and I need to constantly remind myself about this - is best directed to other forums e.g., comp.lang.fortran https://groups.google.com/d/msg/comp.lang.fortran/dHe4aF_Loc0/faVRpFBkAgAJ