This is the mail archive of the fortran@gcc.gnu.org mailing list for the GNU Fortran project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [Patch,Fortran] Add polymorphic type support (OOP, RTTI) - merge from Fortran-dev branch


Dear Paul,
>> I'm not sure about what we would expect in that case, but from a C++ point
>> of view, one should be allowed to declare a derived-type in a module and use
>> it there with CLASS, but the compiled code should also work when passed a
>> CLASS object whose actual type is some subtype that was unknown at
>> compile-time of the original module. ?Would this work?
>
>I am not entirely sure that this would be standard compliant in
>fortran.  We have discussed the matter but have not really concluded.
>My tilt is that all subtypes should be known at compile time because
>they should all be use associated.  In fact, I am reminded that we
>need to warn that attempts to define classes in interfaces will not
>work at present.

If I understand what you are saying, you are wrong here; having a code
compiled once, and work with type extensions as they are added without
recompilation, is arguably the main  point (if not quite the whole
point) of polymorphism. 
Besides the fact that my code uses this concept and the NAG compiler
does not complain, a more authoritative source is M&R&C: the whole
purpose of section 16.9, procedure encapsulation, is to show an instance
of this "work with unknown derived types" concecpt, and how it can be
useful. 

If I have misunderstood what you are saying, then consider the previous
reference as an added reference for further discussion.

Regards
Salvatore 



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]