Pointers: MOLDing instead of CASTing

[joseph-krahn]

I have not seen the term 'molding' used, but I think it should be the standard term for converting pointers, as well as non-pointer data, in Fortran.

Fortran does not support pointer casting, but generally does support pointer molding, using derived-type pointer containers and TRANSFER():

type int_ptr_type
  integer, pointer :: value
end type int_ptr_type
type real_ptr_type
  real, pointer :: value
end type real_ptr_type
type(int_ptr_type) :: p_int
type(real_ptr_type) :: p_real
...
p_int = transfer(p_real, mold=p_int)

I refer to this as 'molding' because the format argument for TRANSFER is MOLD, and it makes sense compared to the term 'casting'. Casting involves re-interpreting a pointer variable in-place, and a cast is something that confers shape by being placed around an object. A mold, on the other hand, confers shape by an object being placed into it, which is like the TRANSFER function: the data has to be moved into a new object. (Actually, 'cast' has many meanings, including the act of molding something, so one has to consider the meaning as for cast used with broken bones.)

This approach is nicer in some ways, because it avoids mis-representing a variable's type. The major disadvantage is that the Fortran Standards do not guarantee this sort of conversion to work. In my experience, this method works as long as the both pointer targets a scalars, which are normally represented as a single pointer value. The standards avoid binary specifications, but it would be nice if scalar pointers were required to be conformable, so that this method of pointer conversion could be more than just a hack.

[jimdempseyatthecove]

Why not use a derived type containing a union

TYPE pIntORpReal
union
map
type(int_ptr_type) :: p_int
end map
map
type(real_ptr_type) :: p_real
end map
end union
end type pIntORpReal
...
type(pIntORpReal) :: something
...
value = something.p_real

Jim Dempsey

[joseph-krahn]

Yes, a UNION is a good way to do a "reinterpret cast" in Fortran, but it is non-standard Fortran. My description of MOLDing versus CASTing is partly to explain the ideology of Standard Fortran, as far as I understand it.

The Fortran Standards have not included unions specifically for the reason that a union is a form of type casting and, in the committee's opinion, CASTing is more dangerous than MOLDing. Their intent is to avoid having data interpretable in more than one way without moving the data to an appropiately typed container. They dislike unions so much that it is not even included in the newly defined ISO C-Binding standard.

I think that the strong dislike of unions comes from many years of ugly Fortran hacks with excessive use of EQUIVALENCEs.

[jimdempseyatthecove]

You always can fall back on a formatted internal write followed by a formatted internal read.

TRANSFER can be used, but why perform an unnecessary copy operation.

I think the Fortran Standards committee is going overboard to protectall programmers from some programmers bad programming experiences.

Many of the operating system function calls pass data structures that are content dependent. i.e. depending on certain flags in the data structure the structure is identified and a given interpretation is used. This interpretation is currently done by way of UNIONs. By removing UNION from Fortran will pressure the programmers to re-invent their old hacks and some new hacks(think of the mess that will make).

In a different forum thread there was a problem concerning an array temporary being created when a slice of a larger array is being passed on subroutine call. The compiler sometimes goofs and creates a temporary array (and copies data) on call then copies back and deletes the temporary array on return when all it needs to do is create the appropriate array descriptor. If the committee is going to be a stickler about UNION then they will have to insist that array temporaries are always created. Think of the performance consequences.

Additionally think about the disastrous effect this will have regarding multi-threaded programming (i.e. multiple instances of same data).

For the same multi-threaded programming reasons a UNION may be required to implement a given algorithm. e.g. DCAS (used in Lock-Free programming techniques).

IMHO the Fortran Standards committee is going too far on this one.

Jim Dempsey

[joseph-krahn]

I agree that the committee is going too far here. This is particularly obvious with ISO C BINDING. I was sure it would include UNIONS, which are essential for full C interoperability. But, the UNION-phobes prevailed over such sanity.

Unions are like many 'bad' programming practices; they are only bad if mis-used or over-used.

[jimdempseyatthecove]

If they really want to fix things (that aren't broke) they should look into eliminating "=".

I would venture to guess that all programming errors resulted some way or the other from the misuse of an "=". If you wrote A=B+C and didn't really intend to modify A then the problem must be the "=". Get rid of "=" and the problem is solved!

(Acidic) Humor aside,

I am sure someone can prove:

For this particular case, the use ofUNION is clearly a bad choice.

It is far reaching for someone to declare then, the extension of this to:

For all circumstances the use ofUNION is clearly a bad choice.

Consider for the moment you are in the physical world. Assume you are servicing people, say a doctor's office. With UNION you could union Male and Female to your set of medical records and clearly distinguish the difference. Without UNION she might be asked to bend over and cough, or worse yet, he to receive the speculum.

Jim