Types fortran类型*N表示法

我已经读过很多次了，使用类型*N表示法real*8、complex*16等可能会导致可移植性问题。这里有没有人有过这样的问题，然后可以通过使用种类来解决

我不能说我对这个问题有什么意见。据我所知，目前所有活跃的Fortran编译器都理解这种定义种类的非标准方式

---

但是，这些年来，我遇到了很多非标准的可移植性问题。这些天来，我从来没有很好地，很少使用非标准特性，我当然不会这样声明种类。我通常只会使用非标准功能，如果它们有令人信服的优势，我看不到这样的优势。唯一令人信服的优势是提高执行速度，做一些在标准Fortran中很难或不可能做的事情，对语言功能的真正扩展。程序员的便利性并不是一个引人注目的优势。

我不能说我在这个问题上有什么问题。据我所知，目前所有活跃的Fortran编译器都理解这种定义种类的非标准方式

---

但是，这些年来，我遇到了很多非标准的可移植性问题。这些天来，我从来没有很好地，很少使用非标准特性，我当然不会这样声明种类。我通常只会使用非标准功能，如果它们有令人信服的优势，我看不到这样的优势。唯一令人信服的优势是提高执行速度，做一些在标准Fortran中很难或不可能做的事情，对语言功能的真正扩展。程序员的便利性并不是一个引人注目的优势。

我只是想说：我个人并不认为real*8只是方便而已。这是一个更明确的关于我想要什么-一个占用8字节而不是通常的4字节的浮点数。将real*8与realkind=selected\u real\u kind15进行比较。哪一个更有意义？由于代码的读取频率比编写频率高，因此更易于理解是明智的。你说土豆，我说土豆。这种语言的理念是指定所需的精度。对于十进制数的实数。然后编译器计算出要提供的类型。程序员已经习惯于使用普通类型，例如4字节单精度、8字节双精度，所以这种方法并不流行。Fortran 2008现在提供了程序员想要的命名种类值：INT8、INT16、INT32、INT64和REAL32、REAL64、REAL128。请参阅gfortran手册的“内部模块”一章。@mgilson：问题是标准没有说明real*N的含义，因为它是一个非标准扩展，尽管大多数编译器都支持它。N是字节数，在这种情况下，明显的后续问题是，一个字节中有多少位？还是八位字节？还是零碎？如今，8位字节或多或少是通用的，CPU体系结构支持IEEE 754，以及两个大小的整数类型的功耗等，在99.99%的情况下，这些都是不相关的。但是，由于使用标准的种类机制而不是这种机制很简单，为什么还要担心呢？@janneb-我只是说这是一种令人困惑的语法。当与不愿意学习新东西的人一起工作时，支持广泛支持的扩展有时是有意义的，如果只是为了不让同事感到困惑的话。此外，如果编译器将real*8实现为8字节real以外的其他东西，那么由于广泛使用它的遗留代码，将会出现相当大的变化……因此我也不认为这是一个太大的问题。我个人并不认为real*8只是方便而已。这是一个更明确的关于我想要什么-一个占用8字节而不是通常的4字节的浮点数。将real*8与realkind=selected\u real\u kind15进行比较。哪一个更有意义？由于代码的读取频率比编写频率高，因此更易于理解是明智的。你说土豆，我说土豆。这种语言的理念是指定所需的精度。对于十进制数的实数。然后编译器计算出要提供的类型。程序员已经习惯于使用普通类型，例如4字节单精度、8字节双精度，所以这种方法并不流行。Fortran 2008现在提供了程序员想要的命名种类值：INT8、INT16、INT32、INT64和REAL32、REAL64、REAL128。请参阅gfortran手册的“内部模块”一章。@mgilson：问题是标准没有说明real*N的含义，因为它是一个非标准扩展，尽管大多数编译器都支持它。N是字节数，在这种情况下，明显的后续问题是，一个字节中有多少位？还是八位字节？还是零碎？如今，8位字节或多或少是通用的，CPU体系结构支持IEEE 754，以及

---

两个大小的整数类型的幂，等等，在99.99%的情况下，这大部分是无关的。但是，由于使用标准的种类机制而不是这种机制很简单，为什么还要担心呢？@janneb-我只是说这是一种令人困惑的语法。当与不愿意学习新东西的人一起工作时，支持广泛支持的扩展有时是有意义的，如果只是为了不让同事感到困惑的话。此外，如果编译器将real*8实现为8字节real以外的其他东西，那么由于广泛使用它的遗留代码，将会出现相当大的问题……因此我也不认为这是一个很大的问题。