2016-09-02 4 views
0

関数またはサブルーチンに渡される配列のランクおよび/またはサイズがわかっている場合、想定形状または想定サイズの配列を使用する理由はありますか?例えば、私は配列ランク/サイズが利用可能である場合、想定サイズの配列を使用する理由はありますか?

function f(a,m,n) 
    real,dimension(m,n),intent(inout) :: a 
    ! ... 
end function 

function f(a,m,n) 
    real,dimension(*),intent(inout) :: a 
    ! ... 
end function 

を置き換えることができればそうしないように(のFortran 90以降で)何らかの理由があるのでしょうか?

+0

を参照し、OPの質問に答えるためにあなたのコード例では、大きさ引き継ぎ配列の引数を持っています。タイトルとテキストは、想定された形状にも言及しています。仮定された形状と仮定されたサイズは、意味的に意味が異なる。明示的な形状と仮定した形状との比較に本当に関心がありますか? – francescalus

+0

それを指摘してくれてありがとう。私は実際に仮定サイズを明示的な形状と比較することに興味があります(上記の2番目の例が意味するところであれば)。タイトルを更新します。 –

答えて

5

コメントではなく、答えの多くには長すぎる...

この

function f(a,m,n) 
    real,dimension(m,n),intent(inout) :: a 
    ! ... 
end function 

a形状引き継ぎ配列をしない、それが明示的な形状(m,n)を持っています。最近、私は書いています

function f(a) 
    real,dimension(:,:),intent(inout) :: a 
    ! ... 
end function 

このバージョンでは、aは間違いなく想定形状です。まれに、私は手続きの中で配列のサイズや形状が必要ですが、shape(a)などと書くことで得られます。

最後に、Assumed size arrays: Colon vs. asterisk - DIMENSION(:) arr vs. arr(*)

+0

関数f2、f3、f4を作るのはかなり始まり、MとNのサイズだけが異なるので、@ High Performance Mark Example#2に向いています。 SHAPEとUBOUNDとLBOUNDのマークは便利になりました。 – Holmz

+0

混乱して申し訳ありません - 私は想定サイズを意味するとき、私は仮定の形を書いた。 –

関連する問題