What are the benefits of User-defined derived-type Input/Output?

1

A derived type (DT) is ultimately composed of basic types, and I write derived types by using appropriate format strings for the components, often defining a subroutine called display for a DT. I have heard of but not studied or used UDDTIO, and I believe that it’s a feature of modern Fortran that compilers have been slow to add.

What are the benefits of UDDTIO compared to doing it manually as described above?

2

You can try out the Fortran example in this thread, particularly with

   ..
   real :: vector(4)
   type(mat_t(n=2,m=2)) :: A
   type(mat_t(n=2,m=2)) :: V(4)

   a_scalar = 1.0
   vector = [ a_scalar, a_scalar, a_scalar, a_scalar ]
   print *, exp( vector )

   A = ones( A%n, A%m )
   print *, exp( A )

   V = [ A, A, A, A ]
   print *, exp( V )
   ..

and ponder whether you like the idea of data transfers with derived types aka “classes” in list-directed, namelist, and DT formatted IO statements in the same manner as intrinsic types. If yes, defined IO will be useful; otherwise, continue as usual.

1 Like
3

I played with it some at one point, but found it limiting in a few ways.

What if my derived type has a derived type as a component? Should both have UDDTIO and the one “calls” the other?

UDDTIO is supposed to do non-advancing IO, but what if I need multiple lines to represent my type well as a string?

Basically, I found it doesn’t compose well.

BUT, it does mean if you’re trying to do some debugging you can just do print *, my_object and it works.

4

Thanks to @FortranFan and @everythingfunctional for their replies. The code cited in the other thread compiles and runs with Intel Fortran but not with gfortran GNU Fortran (GCC) 12.0.0 20210718 from equation.com for Windows. Gfortran does not like the private statements in that code, and even when they are commented out, it gives the messages below. I won’t give up gfortran compataiility without a strong reason and will stick with my current approach to derived type I/O.

xdtio.f90:13:4:

   13 |    generic :: exp => exp_mat_t   !<-- overload the intrinsic
      |    1
Error: Unclassifiable statement at (1)
xdtio.f90:10:15:

   10 |       procedure, pass(dtv) :: write_mat_t
      |               1
Error: Argument 'dtv' of 'write_mat_t' with PASS(dtv) at (1) must be of the derived-type 'mat_t'
xdtio.f90:61:8:

   61 |    use mat_m
      |        1
Fatal Error: Cannot open module file 'mat_m.mod' for reading at (1): No such file or directory
compilation terminated.
1 Like
5

The code example I provided conforms to current standard Fortran whereas gfortran has certain gaps in support toward the standard and there is an outstanding list of support requests at GCC Bugzilla.

If you seek “gfortran compataiility,” the comment in this thread applies. gfortran needs a growing team of dedicated FOSS volunteers to contribute to its development and resolve bugs. So the users who rely on gfortran should seriously consider joining GCC as FOSS volunteers and/or encourage others to do the same. Otherwise, gfortran faces the risk and fate of g77 and g95.

6

Fortran will rate rather poorly if one allows perfection be the enemy of good. Take it just a bit further and apply it broadly to anything introduced starting FORTRAN I and one can easily reach a point where there is no raison d'être whatsoever, seriously, for using anything in the language. Few, if anything, “compose well”, especially with defined operations introduced starting Fortran 90. Defined IO, the subject of this thread, is just one part of it. There is little support for reflection, on and on the gaps go. The whole scaffolding around the language can then be argued is half-baked, that it can only hold because of perspective, that for scientific and technical computing needs and considering the all-round resource constraints with people to advance the language, processors, cost and what-not, one has to move forward with limited or barely good enough facilities. What is called UDDTIO, not a term in the standard, then requires the same perspective.

Separately the standard does not state defined IO shall be non-advancing, only that the specifier is ignored. Re: multiline output, again the standard does not prohibit it, only that it asks the child transfer to pass the record handling, termination etc. to the parent.

One can indeed use defined IO for more than simple print statements during naïve debug attempts, but sure it requires a supporting processor and there aren’t too many of those unfortunately. Nonetheless, a well-designed defined IO with derived types can also be a convenient tool for serialization and deserialization of one’s “classes”.

7

Complex subordinates clauses full of sarcasm won’t help much, even with French interjections. Neither will do deprecating gfortran on every occasion. Nor spiteful citing of typos (“gfortran compataiility”)
Did Intel’s ifort support full current standard right from the day after it was announced? I doubt. Also, it was a paid software then, is free now but, being closed source, may well be paid again tomorrow. It is by no means easy to install. The Intel base kit requires 15 GB of stuff to be installed (checked on Ubuntu) - twice the size of the whole Operating System. If this discourse group has an aim to promote Fortran to new programmers, it cannot disregard open source compilers as simply ‘non-conforming’.
Just my 2p.

1 Like