導入：なぜ「想定サイズ配列」を知っておく必要があるのか
数値計算の現場で古いFortranコード（Fortran 77以前）を保守していると、引数に A() と記述された配列定義を見かけることがあります。これは「想定サイズ配列」と呼ばれる機能です。一見便利そうに見えますが、現代のプログラミングにおいては「バグの温床」となり得る危険な仕様です。この仕組みを理解し、なぜ現代的な記述へ移行すべきかを知ることは、コードの信頼性を向上させるために非常に重要です。
基礎知識：想定サイズ配列とは何か
想定サイズ配列とは、サブルーチンや関数の引数として配列を受け取る際、最後の次元のサイズを指定せずに () と記述する手法です。
通常の配列ではサイズが固定されているのに対し、この形式では「呼び出し側から渡されたメモリ領域の先頭アドレス」だけがサブルーチン側に伝わります。そのため、サブルーチン側は配列の「最後がどこにあるのか」という情報を一切持てません。
実装と解決策：なぜ使用を避けるべきか
この形式には、致命的な欠点が3つあります。
1. SIZE関数の無効化： 配列全体のサイズを知る術がないため、SIZE(A)を呼び出しても期待した結果が得られません。
2. 境界チェックの欠如： コンパイラが配列の範囲外アクセスを検知できないため、メモリ破壊や不正な計算結果を生む原因となります。
3. 全体演算の不可： A = 0.0 のような配列全体を操作する構文が利用できません。
現代的な解決策としては、Fortran 90以降で導入された 「想定形状配列（Assumed-shape Array）」 を使用してください。引数に A(:) と記述することで、コンパイラが自動的に形状情報を保持し、安全なコードが書けるようになります。
サンプルプログラム：安全な実装への書き換え
以下に、レガシーな想定サイズ配列と、推奨される想定形状配列の比較例を示します。
[CODE]
SUBROUTINE Process_Legacy(A)
! レガシーな想定サイズ配列：サイズ情報がないため危険
REAL A()
! ここでSIZE(A)を呼び出しても正しい値は返らない
! 境界チェックも効かず、誤ったインデックスアクセスで暴走する可能性がある
PRINT , “レガシー関数：サイズ不明”
END SUBROUTINE
SUBROUTINE Process_Modern(A)
! 推奨される想定形状配列：(:)と記述することでサイズ情報を保持する
REAL, INTENT(IN) :: A(:)
! コンパイラが形状情報を把握しているため、SIZE関数が正しく動作する
INTEGER :: n
n = SIZE(A)
PRINT , “モダン関数：配列サイズは “, n
! 配列全体の演算も安全かつ簡潔に記述可能
! A = 0.0 ! 全要素をゼロクリアするような操作も安全に実行可能
END SUBROUTINE
[/CODE]
応用・注意点：現場での移行戦略
既存の巨大なレガシーコードをすべて一度に書き換えるのは困難です。その場合は、以下のステップで進めるのが現実的です。
1. インターフェースブロックの活用： 呼び出し側に「インターフェース」を明示的に記述することで、コンパイラに配列の形状を認識させ、コンパイル時のチェックを強化する。
2. モジュール化の推進： 可能な限り引数に ALLOCATABLE な配列や、モジュール内で定義された型を使用するように設計を刷新する。
3. コンパイラオプション： 古いコードをコンパイルする際は、境界チェックオプション（gfortranであれば -fcheck=all など）を付与し、実行時に不正なアクセスがないかを監視してください。
レガシーな仕様を理解することは、トラブルシュートの第一歩です。しかし、安定した数値計算システムを構築するためには、可能な限り「想定形状配列」への移行を検討してください。
コメント