プロジェクト

全般

プロフィール

C言語で2次元配列を渡せなくて困った話 » 履歴 » バージョン 5

健二 酒井, 2019/03/15 21:12

1 1 健二 酒井
# C言語の2次元配列を渡せなくて困った話
2 1 健二 酒井
3 1 健二 酒井
タイトルの通りです。正確に言うと、C言語で文字列の配列を引数に取る関数でドハマりしたっていう話です。
4 1 健二 酒井
ポインタをちゃんと勉強したら「よくできてるな」って納得した感じ。
5 1 健二 酒井
6 1 健二 酒井
## 前提
7 1 健二 酒井
8 1 健二 酒井
* intは4バイトとします。
9 1 健二 酒井
10 1 健二 酒井
## 詰まったところ
11 1 健二 酒井
12 1 健二 酒井
二次元配列を受け取れるような関数を定義したかった。
13 1 健二 酒井
とりあえず話をするために名前を付ける。
14 3 健二 酒井
15 1 健二 酒井
```
16 1 健二 酒井
int caller_matrix[3][5]
17 1 健二 酒井
```
18 2 健二 酒井
19 2 健二 酒井
caller_matrixを実引数にして渡そうとしています。
20 1 健二 酒井
で受け取る側ですが以下の、1番のシグネチャじゃダメってコンパイラから怒られた(警告だったかもしれない)っていうのでわけわかんなくなって詰まったんですね。
21 1 健二 酒井
1番:
22 1 健二 酒井
23 1 健二 酒井
```
24 1 健二 酒井
void some_function(int *matrix[5])
25 1 健二 酒井
```
26 1 健二 酒井
27 1 健二 酒井
※ちなみに正しい渡し方。
28 1 健二 酒井
2番:
29 1 健二 酒井
30 1 健二 酒井
```
31 1 健二 酒井
void some_function(int arr[][5])
32 1 健二 酒井
```
33 1 健二 酒井
34 1 健二 酒井
or
35 1 健二 酒井
3番:
36 1 健二 酒井
37 1 健二 酒井
```
38 1 健二 酒井
void some_function(int (*arr)[5]) 
39 1 健二 酒井
```
40 1 健二 酒井
41 1 健二 酒井
2番は理解するけど、3番と1番の違いって何よ?何でダメ?っていうお話。
42 1 健二 酒井
「2番、3番はバッファオーバーランの原因になるだろ。その書き方は認めない」っていう突っ込みはとりあえずやめてください。
43 1 健二 酒井
44 1 健二 酒井
### 配列の名前
45 1 健二 酒井
46 1 健二 酒井
以下のような宣言があったとする。
47 3 健二 酒井
48 1 健二 酒井
```
49 1 健二 酒井
int arr[5];
50 1 健二 酒井
int* p_arr;
51 1 健二 酒井
52 1 健二 酒井
p_arr = arr;
53 1 健二 酒井
```
54 3 健二 酒井
55 1 健二 酒井
これは正しいですね。なぜなら「arr」は評価(?)されたときに、intへのポインタ型であるアドレスを返します。これがまず第一の面白ポイント。
56 1 健二 酒井
で、配列を引数に取る関数は
57 1 健二 酒井
58 1 健二 酒井
```
59 4 健二 酒井
void some_function(int* argument) 
60 1 健二 酒井
```
61 1 健二 酒井
62 1 健二 酒井
って書いても
63 1 健二 酒井
64 1 健二 酒井
```
65 4 健二 酒井
void some_function(int argument[])
66 1 健二 酒井
```
67 1 健二 酒井
68 1 健二 酒井
って書いても大丈夫。これを踏まえて
69 1 健二 酒井
70 1 健二 酒井
```
71 1 健二 酒井
void some_function(int *matrix[5])
72 1 健二 酒井
```
73 1 健二 酒井
74 1 健二 酒井
って書いた。結果は上で言った通りむっちゃ怒られた。~~C言語マジ意味わかんねぇとか呟いた~~
75 1 健二 酒井
76 1 健二 酒井
### 整理
77 1 健二 酒井
78 1 健二 酒井
さて、疑問を整理してみると一番は
79 1 健二 酒井
80 1 健二 酒井
```
81 1 健二 酒井
int *matrix[5]
82 1 健二 酒井
```
83 1 健二 酒井
84 1 健二 酒井
の型ってなんだ?っていう話になります。
85 1 健二 酒井
86 1 健二 酒井
### 型の計算
87 1 健二 酒井
88 1 健二 酒井
ちょっとJavaやC#の総称型っぽく書きます。
89 1 健二 酒井
型Tに対してArr[T]で「Tの配列」型、Ptr[T]で「Tへのポインタ」型を意味するとします。
90 1 健二 酒井
さて、問題の型を見てみましょう。これは以下のように二通りの解釈ができます。C言語の初心者にとっては。
91 1 健二 酒井
これがよく分からない原因です。
92 1 健二 酒井
93 1 健二 酒井
1. Arr[Ptr[int]]
94 1 健二 酒井
1. Ptr[Arr[int]]
95 1 健二 酒井
96 1 健二 酒井
前者は分かります。実際のデータを考えるとアドレス(intへのポインタ型)がメモリにびっしり詰まっているイメージです。
97 1 健二 酒井
さて後者は何でしょう?配列へのポインタ?なんだそれ?
98 1 健二 酒井
そこで「配列へのポインタとはそういえば聞いたことがない気がする」と気づきます。でも、「配列が確保したメモリの先頭アドレスだろ。常識的に考えて…」とか思ったりしました。
99 1 健二 酒井
100 1 健二 酒井
後者は何だと頭を悩ませていたときに「そもそもPtr<int>ってなんだ?」とか思い始めて来ます。これは理解できます。
101 1 健二 酒井
メモリをイメージすればいいのです。以下の図はメモリのイメージです。
102 1 健二 酒井
図形一個で1バイトです。四角がint型変数が確保した領域を指します。(ちゃんとintは4バイトと仮定しましたよ)
103 1 健二 酒井
○○○ ■□□□ ○○○○
104 1 健二 酒井
105 1 健二 酒井
Ptr<int>は■を指します。確保したメモリ領域の先頭を指します。
106 1 健二 酒井
107 1 健二 酒井
数学っぽく考えましょう。以下のように一般化します。
108 1 健二 酒井
「Ptr<T>はT型変数が確保した連続したメモリ領域の先頭を指す」
109 1 健二 酒井
と考えます。こう考えると全ての表記と辻褄があってきそうです。
110 1 健二 酒井
111 1 健二 酒井
さて、次に以下のコードに戻りましょう。さっき面白ポイントといったところです。
112 1 健二 酒井
113 1 健二 酒井
```
114 1 健二 酒井
int arr[5];
115 1 健二 酒井
int *p_arr;
116 1 健二 酒井
117 1 健二 酒井
p_arr = arr;
118 1 健二 酒井
```
119 1 健二 酒井
120 1 健二 酒井
p_arrの型はPtr[int]です。arrの型はArr[int]です。ですが、ある意味で区別しなくてよい表記ができています。
121 1 健二 酒井
※厳密にはポインタと配列は区別しなければならないものです。arrにint型へのポインタを代入することはできないですしね。
122 1 健二 酒井
123 1 健二 酒井
### ポインタ記法と配列記法
124 1 健二 酒井
125 1 健二 酒井
この解釈をつきつめていくとポインタ記法と配列記法の整合性もちゃんと取れているのが面白ポイントその2です。
126 1 健二 酒井
127 1 健二 酒井
```
128 1 健二 酒井
#include <stdio.h>
129 1 健二 酒井
130 1 健二 酒井
int main() {
131 1 健二 酒井
    int arr[5] = {1,2,3,4,5};
132 1 健二 酒井
    int *p_arr;
133 1 健二 酒井
134 1 健二 酒井
    p_arr = arr;
135 1 健二 酒井
136 1 健二 酒井
    printf("arr[2]:     %d\n", arr[2]);
137 1 健二 酒井
    printf("*(arr + 2): %d\n", *(arr+2));
138 1 健二 酒井
    printf("p_arr[2]:   %d\n", p_arr[2]);
139 1 健二 酒井
    printf("*(p_arr+2): %d\n", *(p_arr+2));
140 1 健二 酒井
}
141 1 健二 酒井
```
142 1 健二 酒井
143 1 健二 酒井
実行結果:
144 1 健二 酒井
145 1 健二 酒井
```
146 1 健二 酒井
arr[2]:     3
147 1 健二 酒井
*(arr + 2): 3
148 1 健二 酒井
p_arr[2]:   3
149 1 健二 酒井
*(p_arr+2): 3
150 1 健二 酒井
```
151 1 健二 酒井
152 1 健二 酒井
どれも同じ値として評価されますね。メモリの状態を頭の中で描くとこんな感じになります。
153 1 健二 酒井
○○○ ■□□□ ■□□□ ■□□□ ■□□□ ■□□□ ○○○○○
154 1 健二 酒井
四角系はarrが占めている領域です。色塗りが各要素の先頭アドレスの指す領域です。
155 1 健二 酒井
arrの評価結果は最初の■を表し、
156 1 健二 酒井
arr[1]は2番目の4ブロックを表します。2ブロック(1ブロック=sizeof(int))の分だけ進んだ値の実態です
157 1 健二 酒井
ポインタ演算p_arr+2の演算結果は2ブロック分進んだ三つ目の■のアドレスを指します。
158 1 健二 酒井
素晴らしいですね。
159 1 健二 酒井
ややこしいですね。
160 1 健二 酒井
161 1 健二 酒井
ということでPtr<T>と解釈を広げてあげることでPtr[Atr[T]]が意味づけられ、今までのものとちゃんと一貫してるかのような表記方法が得られるわけですね。
162 1 健二 酒井
ただ素直に考えた配列のアドレス「&arr」というのは通用しなくなってしまいます。ここが惜しい感じがします。
163 1 健二 酒井
164 1 健二 酒井
### 再び二次元
165 1 健二 酒井
166 1 健二 酒井
さて、新しい記法を手に入れたので戻ってみます。
167 1 健二 酒井
int型の二次元配列(int matrix[3][5]、厳密には『「int型の配列」の配列』、はArr[Arr[T]]ですね。メモリのイメージは
168 1 健二 酒井
169 1 健二 酒井
○○○ ■□□□ ■□□□ ■□□□ ■□□□ ■□□□
170 1 健二 酒井
    ■□□□ ■□□□ ■□□□ ■□□□ ■□□□
171 1 健二 酒井
    ■□□□ ■□□□ ■□□□ ■□□□ ■□□□ ○○○○○
172 1 健二 酒井
173 1 健二 酒井
といった具合です。
174 1 健二 酒井
この確保の仕方は二次元配列の初期化子{{1,2,3,4,5},{6,7,8,9,10},{11,12,13,14,15}}とも一貫しています。
175 1 健二 酒井
また、matrix[1]で2列目の先頭の黒のアドレスを指すことも整合性が取れています。matrix[1]はPtr[Arr[int]ではないはずですがね…。
176 1 健二 酒井
これらはPtr[T]がArr[T]と同じように考えたられることになるかと思います
177 1 健二 酒井
TをArr[int]で置き換えてみましょう(int型の配列も立派な型です)。
178 1 健二 酒井
それぞれ、Ptr[Arr[int]]、Arr[Arr[int]]となります。
179 1 健二 酒井
180 1 健二 酒井
そして今、戻りに戻って当初の問題となった「2次元配列を受け取る関数」シグネチャを見てみましょう。
181 1 健二 酒井
182 1 健二 酒井
```
183 1 健二 酒井
void some_function(int arr[][5])
184 1 健二 酒井
```
185 1 健二 酒井
186 1 健二 酒井
この書き方はArr[Arr[int]]を想起させます。
187 1 健二 酒井
188 1 健二 酒井
とすると
189 1 健二 酒井
190 1 健二 酒井
```
191 1 健二 酒井
void some_function(int (*arr)[5]) 
192 1 健二 酒井
```
193 1 健二 酒井
194 1 健二 酒井
はPtr[Arr[int]]に相当するのでしょう。\*を括弧内に入れることで「仮引数arrはPtr型」を優先的に示していると。
195 1 健二 酒井
196 1 健二 酒井
そして、ダメなシグネチャ
197 1 健二 酒井
198 1 健二 酒井
```
199 1 健二 酒井
void some_function(int *matrix[5])
200 1 健二 酒井
```
201 1 健二 酒井
202 1 健二 酒井
この引数の宣言はArr[Ptr[int]]と解釈されます。C言語的には。
203 1 健二 酒井
これはよろしくないですね。
204 1 健二 酒井
205 1 健二 酒井
### 結論
206 1 健二 酒井
207 1 健二 酒井
「ハゲの山田氏のカツラ」という名詞句は「ハゲの山田氏」なのか「ハゲのカツラ」なのかという2通りの解釈ができますね。「ハゲの」を受けるのが山田氏なのかカツラなのかどちらかが優先されるかで意味合いが変わってきます。
208 1 健二 酒井
本質的にはこれと同じく、int \*arr[5]と書いたときの\*と[5]のどちらの解釈が優先されるのかということが問題だったんですね。
209 1 健二 酒井
左から修飾するもの(今回の\*)と右から修飾するもの(今回の[5])を括弧なしに並べて書いたときは同様に解釈の優先順位の問題がでてくるんじゃないかと思います。
210 1 健二 酒井
211 1 健二 酒井
212 1 健二 酒井
### 余談
213 1 健二 酒井
214 1 健二 酒井
* Arr[int]とPtr[int]が同じように解釈できるならダメなのもできなきゃおかしくねっていう気も若干してきましたが、
215 1 健二 酒井
Arr[Ptr[int]]は、Ptr[int]が確保するサイズを1ブロックとしてメモリを連続して確保するの意味合いが変わってきてしまいますね。やっぱダメですね。
216 5 健二 酒井
一番外側のArrだけPtrと交換可能なんですかね。
217 5 健二 酒井
    * メモリ確保で考えると交換できないけど、そこだけ気を付ければなんかうまくいく気もするぞ…
218 1 健二 酒井
219 1 健二 酒井
* 例えば、JavaScriptの式typeof 'string' === 'bool'ということを考えるとtypeof ('string' === 'bool')と解釈すれば'bool'ですし、(typeof 'string' ) === 'bool'ならtrue(だよな?)という評価になるかと思います。前者の表記はとても不自然ですが、一つの読み方としてはあり得ない話ではないかと思います。
220 1 健二 酒井
ちゃんと括弧つけてあげると安心。
221 1 健二 酒井
222 1 健二 酒井
* 今度は3次元を引数に取ろうとして迷う気がする。
223 1 健二 酒井
224 1 健二 酒井
* C言語の二次元配列のメモリの確保の仕方はCOBOLの配列の宣言と同じです。なんてこったい、つながったぞ。まぁ一次元を以下に二次元にするかだから自然な発想ですよね。
225 1 健二 酒井
226 1 健二 酒井
## 参考
227 1 健二 酒井
228 1 健二 酒井
オライリーさんの詳説Cポインタ:https://www.oreilly.co.jp/books/9784873116563/
229 1 健二 酒井
230 1 健二 酒井
こんなことを考えて配列とポインタとなんとなく分かったような気がしたのです。長い長い言い訳でした。
231 1 健二 酒井
というか段々何言ってるか分からなくなってきた。