[RFC] polymorphic arrays

[Janne Blomqvist]

On Thu, Aug 5, 2010 at 20:49, Daniel Kraft <d@domob.eu> wrote:
> Janus Weil wrote:
>>
>> Hi Daniel,
>>
>> thanks for your comments!
>>
>>>> Now the question is what to do for polymorphic arrays, i.e. CLASS
>>>> variables with the DIMENSION attribute. Basically I see two
>>>> possibilities:
>>>> 1) Use the class container also for polymorphic arrays, and have the
>>>> "$data" field point to an array descriptor.
>>>> 2) Extend the array descriptor to include some "$vptr" field, which
>>>> would determine the dynamic type of the array, and use this instead of
>>>> a class container.
>
>>> To me it seems that #1 is the "natural" approach given what we currently
>>> do.
>>>  While going with #2 seems to be more light-weight and "better" to me for
>>> arrays, it will both introduce a somewhat distinct implementation for
>>> polymorphic scalars and arrays and will also not work with the approach
>>> of
>>> doing everything (or mostly everyting?) at the front-end level -- at
>>> least
>>> it seems thus to me.
>>>
>>> I do not know what to recommend, but if you go for #2, I would think
>>> about a
>>> way to nicely use a "similar" technique also for polymorphic scalars if
>>> possible.
>>
>> Of course it would be nice to treat all the cases in one consistent
>> framework. If one decides for #2 as the superior approach, then one
>> could in principle unify the treatment of polymorphic scalars + arrays
>> by using an array descriptor also for scalar classes (basically array
>> descriptors and class containers are similar concepts anyway). This
>> would introduce a bit of memory overhead, since the array descriptor
>> includes fields which are not needed for scalars. However, one would
>> gain in consistency.
>
> Yes, that's a possibility.  And it sounds nice to me in that it actually
> contributes more to a unification of concepts, namely between array
> descriptors and class containers.  I don't think that the memory overhead
> will be a real problem, as using OOP stuff will by itself always introduce
> some overhead (think of more indirection because of virtual functions, the
> vtab itself and other such stuff) -- and the argument that seems to come up
> with respect to that is that this overhead does not matter compared to the
> benefit OOP brings in certain situations.  And I think especially memory
> consumption is not the most pressing issue in this respect -- but that's
> only my impression, and of course we should try to keep things as efficient
> as reasonably possible.
>
>> Btw, another asymptotic aim for our OOP implementation could be to
>> have consistency/interoperability with C++ classes. However, I
>> presently have too little knowledge of the implementation of
>> poylmorphism in g++ to say anything more concrete about this topic at
>> this point (any pointers in this direction are welcome, though).
>
> That sounds like a very interesting goal; however, I'm not really sure it is
> a very achievable one -- thinking of multiple inheritance, virtual
> inheritance and probably also a lot of small differences between OOP in C++
> and Fortran.  Do you think this would really be useful at a greater scale?
>  BTW, I think that Java does something like it...  Although I never really
> used gcc's Java (or Java at all for already some years).

I guess it would be possible to do something that "works" for some
common simple cases, but the different features of C++ and Fortran OOP
would make it hard to do something bulletproof that one could actually
advertise to users.

However, C++/g++ does provide a widely used and "battle hardened" way
of implementing OOP, so I don't think looking at how g++ does it is
without merit. IIRC I have posted this link before, but here goes
again, this describes the C++ ABI that g++ follows:

http://www.codesourcery.com/public/cxx-abi/

specifically

http://www.codesourcery.com/public/cxx-abi/cxx-vtable-ex.html

for a quick look at some examples of how classes with virtual
functions are laid out in memory, and also the layout of vtables.

Assuming that gfortran OOP is implemented similarly as the C++ OOP
described above,

class(some_type), dimension(...) :: ...

would be implemented as a normal array descriptor, with each element
being a derived type, where the derived type contains, in addition to
the data members, a pointer to the vtable. Or, if some_type is a
subclass, then each instance contains a vtable pointer for the
concrete type and a vtable pointer for the superclass. So, no need to
change the array descriptor nor use some kind of "class container".

-- 
Janne Blomqvist