[J3] Clarification on F18/017

[Malcolm Cohen]

Hi Ondrej,

 

> In your analysis you explained that due to automatic deallocation predating finalizers, it is natural for some compilers to allow CBPA. 
>
>Is there any other motivation to allow the CBPA order?



In principle, there should not be any ordering required by the standard between non-overlapping finalizable objects. Having the standard mandate ordering (or anything else) unnecessarily, places restrictions on the technology used by Fortran processors. Such restrictions should be kept to a minimum.

 

The lack of unnecessary restrictions is one of the reasons Fortran processors can more easily achieve higher performance than other languages. Ordering restrictions are well known for limiting potential optimizations.

 

> From the user perspective, the CBPA order is unexpected and surprising. In our opinion based on the discussion so far, it should not be allowed by the Standard.

I too use Fortran as a user, and when I do, I frequently make substantial use of the object-oriented features. I do not find that order to be surprising.

 

It has been noted by other users that type extension, except for inheritance of type-bound procedures, works very similarly to embedding the “parent type” as the first component. I have also heard it expressed that some of those users would prefer it to work more like embedding than it does already.

 

However, I note that embedding does not provide any ordering of the newly-embedded (and no longer “parent”) component, and so there is not even any ordering between B and P in that case, you end up with C followed by A B and P in any order whatsoever.

 

Now, I’m not a great fan of the “type extension is like embedding plus type-bound-procedure cleverness” model of thinking about it, but it is undeniably not uncommon.

 

Cheers,

-- 

..............Malcolm Cohen, NAG Oxford/Tokyo.

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.j3-fortran.org/pipermail/j3/attachments/20200609/b59b64a0/attachment.htm>