Alias for the name of a type?

Help
1

Is it possible to define an alias for the name of a type? For example, is it possible to define my_real as an alias for real(kind(0.0D0))? Thank you.

2

The only way I know would be to use a preprocessor to expand the alias. What’s your goal? Depending on what you want to accomplish, there is likely a better solution.

1 Like
3

Thank you @nshaffer !

My motivation is to localize the usage of preprocessors and header files. More precisely, I am writing MEX gateways for interfacing a Fortran library with MATLAB. This necessitates the usage of fintrf.h defined by MathWorks. This header file defines many types (e.g., mwSize, mwIndex, mwPointer, …). I hope to compose a module (e.g., fintrf_mod) that includes fintrf.h and defines aliases for these types, so that I can use fintrf_mod instead of including fintrf.h and use the aliases instead of the MathWorks-defined types. In this way, I will only need to preprocess that code of fintrf_mod but nothing else.

Many thanks!

4

An alternative is to define a derived type and fill that with a single component of the right type and kind. That will hide the details. The price you pay is that you have to use something like:

type(mwSize) :: mysize

call something( mysize%data, ... )

Or something similar.

1 Like
5

Is something like the typedef specifier in C++ necessary in Fortran?

Some of C++'s fundamental types like unsigned long long are verbose, but Fortran doesn’t seem to have this issue. integer(8) looks fine.

I feel like the typedef specifier encourages people to give all kinds of weird names to C++'s fundamental types, which I don’t like.

1 Like
6

Not exactly what you are asking for, but you can name the integer KIND in a module

module kind_mod
integer, parameter :: double_prec = kind(1.0d0)
end module kind_mod

and then use that kind in the program

program main
use kind_mod, only: double_prec
real(double_prec) :: x
end program main
1 Like
7

Thank you all, @nshaffer, @Arjen, @fortran4r, and @Beliavsky, for your inputs and insights. According to the discussion, it seems that there does not exist a straightforward way of really defining an alias for the name of a particular type. So I will tolerate the inclusion of the MathWork’s header file wherever it is needed.

Many thanks again!

8

My use case would be: have a polished top level API.

Suppose that I have many modules, each one having a type that would be named basically the same, e.g. each module deals with a different kind of coordinates, all of them would have a “norm” procedure, all of them would have a “lattice” type holding the coordinates on some other metadata. What I would do is to name these procedures and types with a prefix (reminiscent of the module…). But of course for the end user API I want things to stay simple.

  • For procedures I can just define common names though interfaces (and get the plus of automatic dispatching on the different implementations if I want that)

  • For types I would like to export just one “lattice” type, corresponding to the only coordinate system I expect the most of the users would want to use (all the needed tools to conversion would be done internally when they call the top level routines; the more advanced users would use the needed modules instead of the top level for finer control), but I would avoid it to be named “obscure_prefix_lattice”, as it is in the corresponding module.

Probably the better solution to that is just to have namespaces, so that each type would be “lattice” and you can import it just as that in the top level but instead allow the prefixed qualification for advanced usage.

EDIT 1 : yes, I can probably just do use, only: lattice => prefixed_lattice, in the top level module and then export that as public. It’s just a little painful when I have a lot of stuff in the modules and only a bunch need this kind of treatment.

EDIT 2 : also, FORD would not recognize the alias name defined through only, so doing that would be too much confusing to end users (they see one type name in the docs, they are required to use another if they include the actual module intended for basic usage, big nope).

1 Like
9

Integer(8) may look fine but it means different things with different compilers. Try NAG. That’s why I use selected_int_kind. But even that has its problems. Gfortran allows selected_int_kind(20) but ifort does not.

1 Like