- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hello,
I'm really afraid of reporting this one...
Please tell me it is standard, and if it's not, that the standard is going to change:
module dummy_module
implicit none
type :: a_type
integer(4) :: val
end type a_type
type :: b_type
integer(4) :: val1
integer(4) :: val2
end type b_type
contains
function f(x)
! Variables
class(*), target :: x
class(*), pointer :: f
! Body of f
f => x
end function f
end module dummy_module
program polymorphism_test
use dummy_module
implicit none
type(a_type), pointer :: a
type(b_type), pointer :: b
allocate(b) b%val1 = 3.0 b%val2 = 4.0 a => f(b) end program polymorphism_test
Compiles with XE 2013 SP1 14.0.0100.12 and XE 2015 15.0.0107.2010 (and I think with Update 1 as well), which is perfect, but gfortran complains:
main.f90:38.8:
a => f(b)
1
Error: Data-pointer-object &L must be unlimited polymorphic, a sequence derived type or of a type with the BIND attribute assignment at (1) to be compatible with an unlimited polymorphic target
Edit:
I've just found this, it looks like it has not been resolved yet. I second antony on that, what a pity, 1000s of lines to rewrite, entire code broken... Is there any workaround to avoid using SELECT TYPE everywhere?
Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
NsK wrote:
..
Please tell me it is standard, and if it's not, that the standard is going to change:
...
Non-standard in my opinion; I think gfortran is correct. Plus I don't think the standard will change in this regard and nor should it. Fortran standard, at least philosophically (or perhaps more eagerly than that), wishes to "protect" its practitioners from shooting themselves in the foot or worse yet, hang themselves - such a "nice" sentiment can continue!
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Ok, tell me if I understand correctly: if I make a list of 100 objects, each potentially of a different class, and return a pointer to one object, I will have to write 100 lines of CLASS IS?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
NsK wrote:
Ok, tell me if I understand correctly: if I make a list of 100 objects, each potentially of a different class, and return a pointer to one object, I will have to write 100 lines of CLASS IS?
Not necessarily. You will have to determine the best design pattern based on your needs and you may have to create a "container" class that holds and works with the list of objects. You may have seen the list example in Modern Fortran Explained - Michael Metcalf, John Reid and Malcolm Cohen, Oxford University Press, 2011, ISBN 978-0199601417 which is one such option. See a related discussion on that example here: https://software.intel.com/en-us/forums/topic/518263
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Separately, you may want to think further about what all you're trying to do. For example, something like this cannot work:
program polymorphism_test use dummy_module implicit none type(a_type), pointer :: a type(b_type), pointer :: b allocate(b) b%val1 = 3.0 b%val2 = 4.0 a => b !.. this cannot work, a_type and b_type are "different" end program polymorphism_test
so how do you expect your f procedure to "magically" make it function?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thanks FortranFan,
I was not aware of John Reid's example, my list implementation looks quite similar actually, this "bug" just allows me to cast the content of the polymorphic container directly and remove the need for calls to type-bound procedures to access/modify the data after.
FortranFan wrote:
Separately, you may want to think further about what all you're trying to do. For example, something like this cannot work:
program polymorphism_test use dummy_module implicit none type(a_type), pointer :: a type(b_type), pointer :: b allocate(b) b%val1 = 3.0 b%val2 = 4.0 a => b !.. this cannot work, a_type and b_type are "different" end program polymorphism_testso how do you expect your f procedure to "magically" make it function?
I don't expect your last example to compile, but I hoped my version would compile and crash, at runtime.
Indeed, it shifts the responsibility from the compiler to the developer.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Missing error escalated as issue DPD200253728.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
This should be fixed in 16.0.
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page