[J3] [EXTERNAL] Re: C_PTR not allowed in SEQUENCE types?

Fri Mar 12 13:29:56 UTC 2021

Minor correction.  The implicit interface inside the framework is entirely written in C.   And that uses macros that are platform/compiler specific to enable the necessary portability.    The macros appear to just perform name mangling for the trailing underscore(s), so I think one could have written the implicit interface in Fortran instead.

From: J3 <j3-bounces at mailman.j3-fortran.org> on behalf of j3 <j3 at mailman.j3-fortran.org>
Reply-To: j3 <j3 at mailman.j3-fortran.org>
Date: Friday, March 12, 2021 at 7:38 AM
To: j3 <j3 at mailman.j3-fortran.org>
Cc: "Clune, Thomas L. (GSFC-6101)" <thomas.l.clune at nasa.gov>, Malcolm Cohen <malcolm at nag-j.co.jp>
Subject: Re: [J3] [EXTERNAL] Re: C_PTR not allowed in SEQUENCE types?

Hi Malcolm,

I think in the end I’ll go with a rather different kludge that is already in use in the framework to which I’m attempting to add a feature.   I don’t “own” the code and even if I had the time to convert everything to BIND( C), I’d still have to get the community to accept the new implementation – the framework is intended to be shared infrastructure for Earth system model components across organizations.   (US Centric, but I believe there are some Eurpean and Asian components built on this framework.)

What the framework developers have done in a few other “user customizable” portions is have the user wrap their custom type ala

TYPE  WRAP
      TYPE(user_t), pointer :: ptr
END TYPE WRAP

The framework than provides an _implicit_ interface to pass in object of type WRAP.       Inside the framework they then declare the corresponding dummy as their own derived type that also contains a single pointer component.    This is done in a rather different part of the framework than I’ve been looking at, so I’ve not yet actually tracked down how they then get this into one of the SEQUENCE containers.  At any rate this is surprisingly portable across all major Fortran processors for the last 15-20 years.      It’s really no better than TRANSFER at the end of the day, but it is existing practice and thus familiar to the users I’m supporting.

Cheers,

-          Tom

From: J3 <j3-bounces at mailman.j3-fortran.org> on behalf of j3 <j3 at mailman.j3-fortran.org>
Reply-To: j3 <j3 at mailman.j3-fortran.org>
Date: Thursday, March 11, 2021 at 8:15 PM
To: j3 <j3 at mailman.j3-fortran.org>
Cc: Malcolm Cohen <malcolm at nag-j.co.jp>
Subject: [EXTERNAL] Re: [J3] C_PTR not allowed in SEQUENCE types?

Hi Tom,

If you’re happy or at least willing to do terrible kludges, INTEGER(c_intrptr_t) and the TRANSFER intrinsic are your friends.

Frankly, I think we’ve lost enough toes to SEQUENCE types. They were obsolete when introduced in 1991, and obsolete now. I don’t want to extend them.

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

From: J3 <j3-bounces at mailman.j3-fortran.org> On Behalf Of Clune, Thomas L. (GSFC-6101) via J3
Sent: Thursday, March 11, 2021 11:10 PM
To: Van Snyder via J3 <j3 at mailman.j3-fortran.org>
Cc: Clune, Thomas L. (GSFC-6101) <thomas.l.clune at nasa.gov>
Subject: [J3] C_PTR not allowed in SEQUENCE types?

Is there a fundamental reason that C_PTR cannot be a SEQUENCE type?

I won’t admit to the terrible kludge that I’m attempting that led me to face this issue.   But he kludge aside, this seems to me at first glance to be a very reasonable and minor extension.

Disclaimer

The Numerical Algorithms Group Ltd is a company registered in England and Wales with company number 1249803. The registered office is: Wilkinson House, Jordan Hill Road, Oxford OX2 8DR, United Kingdom. Please see our Privacy Notice<https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.nag.co.uk%2Fcontent%2Fprivacy-notice&data=04%7C01%7Cthomas.l.clune%40nasa.gov%7C4816f1469bd44258a60208d8e553cc04%7C7005d45845be48ae8140d43da96dd17b%7C0%7C0%7C637511495371312491%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=w2IxhKdYoGxszIIq%2FZYIoZ2wPlg6fD%2BfUlGIOzCAe5Y%3D&reserved=0> for information on how we process personal data and for details of how to stop or limit communications from us.

This e-mail has been scanned for all viruses and malware, and may have been automatically archived by Mimecast Ltd, an innovator in Software as a Service (SaaS) for business.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.j3-fortran.org/pipermail/j3/attachments/20210312/e71776b6/attachment-0001.htm>