- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
From what I see line 14 needs to be declared as “class” and not “type”, because you are using it as polymorphic
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Original comment (dated Tue, 06/11/2019 - 17:46) deleted due to possible inaccuracy in interpretation of the Fortran standard.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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..
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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...
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
@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".
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
@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".
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
@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.
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page