Records passed in subroutine calls

[WSinc]

I thought you could pass a record in a calling sequence, but here I get an error #6633,
even when the types are identical in structure.

Is there a subtlety here? Seems obvious.......

[Steven_L_Intel1 · Accepted solution]

Identical in structure, yes. Same type, no. Put the type in a module and USE the module both places - then it will be the same type.

Let me make an analogy - if you had a twin brother, would he be you?

[WSinc]

Is there an article I can refer to?

I need to research this a little further for my own edification.

My twin brother doesn't speak to me anymore

(just kidding) :<)


Thanks -

[Steven_L_Intel1]

The Fortran standard, linked to at the top of the main forum page, is the reference, though as is typical for the standard, the words about this are not all in one place.

Referencing Fortran 2008, we can start with paragraph 2 of section 12.5.2.4 ("Ordinary dummy variables") which says, "The dummy argument shall be type compatible with the actual argument."

Ok, so now we need to know what "type compatible" means. The canonical definition is in the "Terms and Definitions" chapter, section 1.3.147.11, which says, "compatibility of the type of one entity with respect to another for purposes such as argument association, pointer association and allocation (4.3.1)". Big help that is, but it does reference 4.3.1.

Section 4.3.1 is "Type specifiers and type compatibility". This describes how you give an object a type, whether it be intrinsic, derived or polymorphic. Buried in the subsection on CLASS, 4.3.1.3, is this: "A nonpolymorphic entity is type compatible only with entities of the same declared type."

There is no exception here for two types that have the same layout - those are different types.

[Steven_L_Intel1]

Bill, I have led you astray... - partly.

I missed an important part of the standard, 4.5.2.4, "Determination of derived types". I will quote it here:

3 4.5.2.4 Determination of derived types
4 1 Derived-type definitions with the same type name may appear in different scoping units, in which case they might
5 be independent and describe different derived types or they might describe the same type.
6 2 Two data entities have the same type if they are declared with reference to the same derived-type definition.
7 Data entities also have the same type if they are declared with reference to different derived-type definitions
8 that specify the same type name, all have the SEQUENCE attribute or all have the BIND attribute, have no
9 components with PRIVATE accessibility, and have type parameters and components that agree in order, name,
10 and attributes. Otherwise, they are of different derived types. A data entity declared using a type with the
11 SEQUENCE attribute or with the BIND attribute is not of the same type as an entity of a type that has any
12 components that are PRIVATE

So in your example, if you gave derived type CB the SEQUENCE attribute in both caller and callee, then you would avoid the error.

[John_B__Walter]

Thanks for these details Steve. This explains the disconnect I had this past week. In the calling routine I had defined an array with a base index of 0 instead of 1. In the subroutine I defined the dummy argument as
X(:) and was surprised when it came through as an undefined pointer.

Thanks again.

[John_D_B_]

Steve, I've embarrassed my self again. I sent a module that does compile (with typos corrected). Just ignore the previous message. With apologizes. John Bauer

[Steven_L_Intel1]

Glad to hear it.