Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Highlighted

Assignment error OOP and polymorphism

Hi all. Trying OOP and polymorphism I manage to code an example which runs properly in Windows with the ifort14 compiler. When trying to run this in a Linux system with ifort18 I receive the following run-time error message:

"forrtl: severe (189): LHS and RHS of an assignment statement have incompatible types", in line "stringer = CompositeHatSection()"

Any clue? Many thanks in advance  

Gustavo

------------------

 

program zz_demo_polymorphism
    
    type :: CompositeStringerSection
        real :: A   ! area
    end type
    
    type, extends(CompositeStringerSection) :: CompositeHatSection
        real :: H   ! height
    end type
    interface CompositeHatSection
        procedure composite_hat_section_constructor
    end interface
    
    type(CompositeStringerSection) :: stringer
    
    stringer = CompositeHatSection()
    
    print *, 'A = ', stringer%A
    print '(A)', 'Execution finished. Press Enter to continue...'
    read (*,*)
   
contains
    
    function composite_hat_section_constructor() result(this)
    
        ! polymorphic return value (derived class constructor)
        class(CompositeStringerSection), allocatable :: this    
        ! Warning : return value is a general composite stringer
                      
        ! Aux polymorphic variable to adjust derived class constructor
        class(CompositeHatSection), allocatable :: self         
       
        allocate(self)  
        self%A = 100.
        self%H = 25.

        call move_alloc(self, this)
                
    end function

end program

 

0 Kudos
12 Replies
Highlighted
Beginner

From what I see line 14 needs

From what I see line 14 needs to be declared as “class” and not “type”, because you are using it as polymorphic 

0 Kudos
Highlighted
Valued Contributor III

Yes, line 14 does not conform

Original comment (dated Tue, 06/11/2019 - 17:46) deleted due to possible inaccuracy in interpretation of the Fortran standard.

0 Kudos
Highlighted

Thanks AT90 and FortranFan.

Thanks AT90 and FortranFan.

I am used to code and debug in Windows with VS and ifort14 . The code I showed works fine there. As the return value of the constructor function is of the class corresponding to the assignment type, and it is allocated before escaping the function... for me it resulted quite natural to code like that.... It was like doing assignments of deferred length strings (allocatable) to variables defined as character strings with a fixed size, for example, for text reporting. I guess I didn't read the right reference documentations about OOP.

Your correction works with our ifort18 in Linux. But in Windows, with my ifort14 compiler, it gives an error: "In an intrinsic assignment statement, variable shall not be polymorphic.". Probably I should get familiarized with a good IDE in Linux and/or push my organization to update the ifort compiler we have available in Windows.

Thanks again.

Gustavo

0 Kudos
Highlighted
Beginner

Ifort 14 is very old and many

Ifort 14 is very old and many things have been implemented since then. 

Intrinsic assignment to polymorphic is a f2008 feature. I can only assume that ifort 14 does have that implemented.

 

 

0 Kudos
Highlighted
Valued Contributor III

Quote:Baños, Gustavo wrote:

Baños, Gustavo wrote:

.. I am used to code and debug in Windows with VS and ifort14 . The code I showed works fine there. ..

@Gustavo,

I suggest you request support with Intel Online Support Center on this: https://supporttickets.intel.com/servicecenter?lang=en-US

I had to read the Fortran standard section on intrinsic assignment just now in connection with something else and I have second thoughts on my comments in Quote #2, hence I've removed them.  Besides, latest Intel compiler 19.0 Update 4 on Windows does not raise the error you notice on Linux with Intel Fortran 18.  So there is something amiss here and Intel support can best guide you..

0 Kudos
Highlighted

Thanks again for the feed

Thanks again for the feed back...

Yesterday at home I tried both ways (assignment to type() variable, and assignment to class(), once allocated, but compiling with gfortran, and none of them worked. I have the impression, since a long time, that modernization of the Fortran compilers is coming too slowly. Even in disciplines like mine, structural analysis, where Fortran has been the eternal champion, is difficult to resist the temptation and the pressures to move...

0 Kudos
Highlighted
Valued Contributor I

Quote:Baños, Gustavo wrote:

Baños, Gustavo wrote:

Thanks again for the feed back...

Yesterday at home I tried both ways (assignment to type() variable, and assignment to class(), once allocated, but compiling with gfortran, and none of them worked. I have the impression, since a long time, that modernization of the Fortran compilers is coming too slowly. Even in disciplines like mine, structural analysis, where Fortran has been the eternal champion, is difficult to resist the temptation and the pressures to move...

This is of course always a developer's decision: we were discussing the same thing (in high energy physics), at the end we estimated that rewriting all of our code in e.g. C++ or Python would either take too much time or would not be flexible enough.

0 Kudos
Highlighted

A round about for this

A round about for this specific task working in both environments, ifort14 and ifort18, without the class and allocatable stuff would be:

program zz_demo_not_polymorphism
    
    type :: CompositeStringerSection
        real :: A   ! area
    end type
    
    type, extends(CompositeStringerSection) :: CompositeHatSection
        real :: H   ! height
    end type
    interface CompositeHatSection
        procedure composite_hat_section_constructor
    end interface
    
    type(CompositeStringerSection) :: stringer
    
    stringer = CompositeHatSection()
    
    print *, 'A = ', stringer%A
    print '(A)', 'Execution finished. Press Enter to continue...'
    read (*,*)
   
contains
    
    function composite_hat_section_constructor() result(this)
    
        ! return value (of parent class)
        type(CompositeStringerSection) :: this    
                      
        ! Aux variable of the child class which will be condensed into "this" 
        type(CompositeHatSection) :: self         
       
        self%A = 100.
        self%H = 25.

        this = self%CompositeStringerSection
                
    end function

end program

 

0 Kudos
Highlighted
Valued Contributor III

@Gustavo,

@Gustavo,

Did you file a support request with Intel?  As indicated to you earlier, your code in the original post does not encounter the "forrtl: severe (189): LHS and RHS of an assignment statement have incompatible types" with several Intel Fortran versions including the latest 19.0 Update 4 on Windows.  So if you are noticing the error on Linux, you may be facing some other issue with Intel compiler rather than a Fortran language problem.

As to Fortran, your original code as a demo for polymorphism looks alright now though I admit I managed to confuse myself - my bad - upon seeing your issue with "ifort 18 on Linux" on "forrtl: severe (189): LHS and RHS of an assignment statement have incompatible types".

0 Kudos
Highlighted
Valued Contributor III

Quote:Baños, Gustavo wrote:

Baños, Gustavo wrote:

A round about for this specific task working in both environments, ifort14 and ifort18, ..

Yes, the code you show here should work.  As you would know well, the issue here will be the confusion for users to find a type named 'CompositeHatSection' and (effectively) a constructor for it to return something that is of 'CompositeStringerSection' i.e., the 'parent' type.

0 Kudos
Highlighted

@FortranFan

@FortranFan

Hi. I didn't request anything formal to Intel... I may be assuming that someone from Intel is aware of the discussions this blog... And I am expecting that the answer will be to upgrade the intel compilers here to the latest version, which would not be for free, and which would not be under my authority even I could push... So I have doubts that "the effort" worths. Maybe I am not fair with Intel and the quality of its technical support.

FortranFan wrote:

@Gustavo,

Did you file a support request with Intel?  As indicated to you earlier, your code in the original post does not encounter the "forrtl: severe (189): LHS and RHS of an assignment statement have incompatible types" with several Intel Fortran versions including the latest 19.0 Update 4 on Windows.  So if you are noticing the error on Linux, you may be facing some other issue with Intel compiler rather than a Fortran language problem.

As to Fortran, your original code as a demo for polymorphism looks alright now though I admit I managed to confuse myself - my bad - upon seeing your issue with "ifort 18 on Linux" on "forrtl: severe (189): LHS and RHS of an assignment statement have incompatible types".

0 Kudos
Highlighted

@FortranFan

@FortranFan

Sure, using a "constructor" is not the best, not even a good, choice, and misleading. A function or method of the class with a more appropriate name would be much better. Probably I landed there after some tries and errors with the OOP and returning that was not the original intention. Normally I will refactor that code before deploying the software.

FortranFan wrote:

Quote:

Baños, Gustavo wrote:

 

A round about for this specific task working in both environments, ifort14 and ifort18, ..

 

 

Yes, the code you show here should work.  As you would know well, the issue here will be the confusion for users to find a type named 'CompositeHatSection' and (effectively) a constructor for it to return something that is of 'CompositeStringerSection' i.e., the 'parent' type.

0 Kudos