回答編集履歴
1
コメントなどをもとに推測を追加
answer
CHANGED
|
@@ -21,10 +21,40 @@
|
|
|
21
21
|
> ポインタあるいは算術型のオブジェクトの初期知識は**（大カッコで囲まれていることもある）**単一の式である。(以下略)
|
|
22
22
|
> -- 「プログラミング言語C」p.273 太字は引用者による。
|
|
23
23
|
|
|
24
|
-
つまり、`int`などについては普通に囲むことはANSI規格の時点で認められており、カーニハンとリッチーとしては想定通りだったようです。ただし、この後の文字列リテラルによる文字配列に関する部分ではこの注意書きのような記述はありません。
|
|
24
|
+
つまり、`int`などについては普通に囲むことはANSI規格の時点で認められており、カーニハンとリッチーとしては想定通りだったようです。ただし、**この後の文字列リテラルによる文字配列に関する部分ではこの注意書きのような記述はありません**。
|
|
25
25
|
|
|
26
|
+
※ Harahinaさんの情報によると初版でも上の文言はそのままあるようです。
|
|
27
|
+
|
|
26
28
|
---
|
|
27
29
|
|
|
28
|
-
ということでANSI(C89)の時点では文字列リテラルを用いた初期化においては波括弧でも囲んでもよいと
|
|
30
|
+
ということですが、yuki23さんの情報によると、ANSI(C89)の時点では文字列リテラルを用いた初期化においては波括弧でも囲んでもよいとなっていたとのことです。ですが、K&Rにはそのような記述が無い事から、カーニハンとリッチーはそれが許されるとは想定してなかった可能性が高いです。
|
|
29
31
|
|
|
32
|
+
そもそもK&R(第二版 4.9 初期化 p.105)では
|
|
33
|
+
|
|
34
|
+
```C
|
|
35
|
+
char pattern[] = "ould";
|
|
36
|
+
```
|
|
37
|
+
|
|
38
|
+
を
|
|
39
|
+
|
|
40
|
+
```C
|
|
41
|
+
char pattern[] = {'o', 'u', 'l', 'd', '\0'};
|
|
42
|
+
```
|
|
43
|
+
|
|
44
|
+
と同値な簡略形としています。では、
|
|
45
|
+
|
|
46
|
+
```C
|
|
47
|
+
char pattern[] = {"ould"};
|
|
48
|
+
```
|
|
49
|
+
|
|
50
|
+
は
|
|
51
|
+
|
|
52
|
+
```C
|
|
53
|
+
char pattern[] = {{'o', 'u', 'l', 'd', '\0'}};
|
|
54
|
+
```
|
|
55
|
+
|
|
56
|
+
となるのかというと、後者はコンパイルエラーになります。普通の配列に対して余計な波括弧を足すことはできません。
|
|
57
|
+
|
|
58
|
+
**ここからは私の単なる推測です。**K&Rでは配列に対して、波括弧で囲んでリストを作るとしています。そして、文字配列については文字列リテラルでも初期化できるとしています。これを読んだCコンパイラの開発者が、何を思ったのか、「文字配列は配列だから、初期化子を波括弧で囲む必要があるけど、文字列リテラルも使えると言うことだから、波括弧の中で文字列リテラルを書けば良いんだ」と解釈したのでは無いでしょうか？つまり、`char pattern[] = {"ould"};`が正当であると。標準規格が定まる前の言語というのは、複数の実装が存在すると、それぞれが自分たちもそれができるという競争状態になります(JavaScriptが良い例です)。C言語もそのような状態であったため、うちのコンパイルでもできるとして広まっていったのかも知れません。ANSI制定にあたり、既存のコンパイラの実装状況の調査を行った時、既に普及している解析手法であったため、これは外せないとなったのが真相では無いかと思います。
|
|
59
|
+
|
|
30
60
|
なお、JIS規格はISO規格の翻訳に過ぎませんので、正確な情報を得たい場合にはISO規格を確認してください。
|