C配列が長さを追跡しないのはなぜですか？

配列で配列の長さを明示的に格納しない背後にある理由は何Cですか？

私の考えでは、そうするのには圧倒的な理由がありますが、標準（C89）を支持する多くの理由はありません。例えば：

1. バッファで利用可能な長さがあると、バッファのオーバーランを防ぐことができます。
2. Javaスタイルarr.lengthは明確であり、プログラマーintが複数の配列を扱う場合にスタックで多くのs を維持する必要がないようにします。
3. 関数パラメーターはより適切になります。

しかし、おそらく私の考えでは、最もやる気の理由は、通常、長さを維持しないとスペースが節約されないからです。配列のほとんどの使用には動的割り当てが含まれると言って思います。確かに、人々はスタックに割り当てられた配列を使用する場合がありますが、それはたった1つの関数呼び出し*です-スタックは4または8バイト余分に処理できます。

ヒープマネージャーは、動的に割り当てられた配列によって使用される空きブロックサイズを追跡する必要があるため、その情報を使用可能にします（そして、コンパイル時にチェックされる追加のルールを追加します。足で自分を撃つのが好きです）。

私が反対側で考えることができる唯一のことは、長さの追跡がコンパイラをより単純にしたわけではないかもしれないが、それほど単純ではないということです。

*技術的には、自動ストレージを備えた配列を使用して、ある種の再帰関数を作成できます。この（非常に精巧な）場合、長さを格納すると、実際にはより多くのスペースが使用されます。

配列の長さは静的プロパティであるため、C配列はその長さを追跡します。

int xs[42];  /* a 42-element array */

通常、この長さを照会することはできませんが、とにかく静的であるため必要はありませんXS_LENGTH。長さのマクロを宣言するだけで完了です。

より重要な問題は、C配列が暗黙的にポインターに分解されることです。たとえば、関数に渡される場合です。これはある程度意味があり、いくつかの素晴らしい低レベルのトリックを可能にしますが、配列の長さに関する情報を失います。したがって、Cがこの暗黙的なポインターの劣化を考慮して設計されたのは、より良い質問です。

もう1つの問題は、メモリアドレス自体を除き、ポインタにはストレージが必要ないことです。Cを使用すると、整数をポインターに、ポインターを他のポインターにキャストし、ポインターを配列のように扱うことができます。これを行っている間、Cは配列の長さを作成するほどの狂気ではありませんが、スパイダーマンのモットーを信頼しているようです。

これの多くは、当時利用可能なコンピュータに関係していました。コンパイルされたプログラムは限られたリソースのコンピューターで実行する必要があるだけでなく、おそらくもっと重要なことに、コンパイラー自体がこれらのマシンで実行する必要がありました。トンプソンがCを開発したとき、彼は8kのRAMを搭載したPDP-7を使用していました。実際のマシンコードに直接の類似性がなかった複雑な言語機能は、言語に含まれていませんでした。

Cの履歴を注意深く読むと、上記の内容をより深く理解できますが、マシンの制限によるものではありません。

さらに、言語（C）は、重要な概念、たとえば、実行時に長さが変化するベクトルなど、いくつかの基本的な規則と規則を使用して、重要な概念を記述するかなりの力を示します。... Cのアプローチを、ほぼ同時期の2つの言語、Algol 68とPascal [Jensen 74]のアプローチと比較するのは興味深いことです。Algol 68の配列は固定境界を持っているか、「柔軟」です。言語定義とコンパイラの両方で、柔軟な配列に対応するためにかなりのメカニズムが必要です（すべてのコンパイラが完全に実装するわけではありません）。配列と文字列、そしてこれは閉じ込めを証明しました[Kernighan 81]。

C配列は本質的に強力です。それらに境界を追加すると、プログラマーが境界を使用できる対象が制限されます。このような制限はプログラマーにとっては便利ですが、必然的に制限もあります。

Cが作成された当時に戻って、文字列ごとに 4バイトの余分なスペースがあったとしても、それはどんなに短くても無駄です！

別の問題があります-Cはオブジェクト指向ではないため、すべての文字列に長さプレフィックスを付ける場合、aではなくコンパイラ組み込み型として定義する必要がありますchar*。特殊なタイプの場合、文字列を定数文字列と比較することはできません。つまり、次のようになります。

String x = "hello";
if (strcmp(x, "hello") == 0) 
  exit;

その静的文字列を文字列に変換するか、長さの接頭辞を考慮するために異なる文字列関数を使用するには、特別なコンパイラの詳細が必要です。

しかし、最終的には、Pascalとは異なり、長さプレフィックスの方法を選択しなかったと思います。

Cでは、配列の連続するサブセットも配列であり、そのように操作できます。これは、読み取り操作と書き込み操作の両方に適用されます。サイズが明示的に保存されている場合、このプロパティは保持されません。

長さでタグ付けされた配列を持つことの最大の問題は、その長さを保存するのに必要なスペースではなく、それをどのように保存するかという問題ではありません長い配列には余分なバイトがありますが、短い配列にも4バイトを使用することは可能です）。より大きな問題は、次のようなコードが与えられることです。

void ClearTwoElements(int *ptr)
{
  ptr[-2] = 0;
  ptr[2] = 0;
}
void blah(void)
{
  static int foo[10] = {1,2,3,4,5,6,7,8,9,10};
  ClearTwoElements(foo+2);
  ClearTwoElements(foo+7);
  ClearTwoElements(foo+1);
  ClearTwoElements(foo+8);
}

コードが最初の呼び出しを受け入れ、ClearTwoElements2番目の呼び出しを拒否できる唯一の方法は、ClearTwoElementsメソッドが、どの場合でも、fooどの部分を認識するかだけでなく、配列の一部への参照を受け取ることを知るのに十分な情報を受け取ることです。これは通常、ポインターパラメーターを渡すコストを2倍にします。さらに、各配列の前にアドレスのポインタが置かれている場合（検証の最も効率的な形式）、最適化されたコードはClearTwoElements次のようになります。

void ClearTwoElements(int *ptr)
{
  int* array_end = ARRAY_END(ptr);
  if ((array_end - ARRAY_BASE(ptr)) < 10 ||
      (ARRAY_BASE(ptr)+4) <= ADDRESS(ptr) ||          
      (array_end - 4) < ADDRESS(ptr)))
    trap();
  *(ADDRESS(ptr) - 4) = 0;
  *(ADDRESS(ptr) + 4) = 0;
}

メソッド呼び出し元は、一般に、配列の先頭へのポインタまたはメソッドへの最後の要素を完全に合法的に渡すことができることに注意してください。メソッドが、渡された配列の外側にある要素にアクセスしようとした場合にのみ、そのようなポインターは問題を引き起こします。したがって、呼び出されたメソッドは、まず、引数を検証するためのポインター演算が範囲外にならないように配列が十分に大きいことを確認してから、引数を検証するためのポインター計算を行う必要があります。そのような検証に費やされる時間は、実際の作業に費やされるコストを超える可能性があります。さらに、メソッドが記述されて呼び出された場合、メソッドはより効率的である可能性があります。

void ClearTwoElements(int arr[], int index)
{
  arr[index-2] = 0;
  arr[index+2] = 0;
}
void blah(void)
{
  static int foo[10] = {1,2,3,4,5,6,7,8,9,10};
  ClearTwoElements(foo,2);
  ClearTwoElements(foo,7);
  ClearTwoElements(foo,1);
  ClearTwoElements(foo,8);
}

オブジェクトを識別するための何かと、その一部を識別するための何かを組み合わせるタイプの概念は、良いものです。ただし、検証を実行する必要がない場合は、Cスタイルのポインターの方が高速です。

Cと他のほとんどの第3世代言語、および私が知っているすべての最近の言語との根本的な違いの1つは、Cがプログラマーの生活をより簡単または安全にするように設計されていないことです。プログラマーが自分が何をしているかを知っていて、それだけを正確にやりたいという期待を持って設計されました。「舞台裏」では何もしませんので、驚きはありません。コンパイラレベルの最適化もオプションです（Microsoftコンパイラを使用する場合を除く）。

プログラマーがコードに境界チェックを記述したい場合、Cはそれを行うのに十分簡単に​​しますが、プログラマーはスペース、複雑さ、およびパフォーマンスの観点から対応する価格を支払うことを選択する必要があります。私は長年怒りで使っていませんでしたが、制約に基づいた意思決定の概念を理解するためにプログラミングを教えるときにそれを使っています。基本的に、それはあなたがやりたいことを何でも選択できることを意味しますが、あなたが下すすべての決定には、あなたが知っておく必要がある価格があります。これは、他の人に自分のプログラムに何をしてほしいかを伝え始めるときにさらに重要になります。

簡潔な答え：

Cは低レベルのプログラミング言語であるため、これらの問題を自分で処理することが期待されますが、これにより、Cの実装方法の柔軟性が大幅に向上します。

Cには、長さで初期化される配列のコンパイル時の概念がありますが、実行時には、データの先頭への単一のポインターとして全体が単純に格納されます。配列とともに配列の長さを関数に渡したい場合は、自分で行います。

retval = my_func(my_array, my_array_length);

または、ポインタと長さを持つ構造体、またはその他のソリューションを使用できます。

より高いレベルの言語は、配列型の一部としてこれを行います。Cでは、これを自分で行う責任が与えられますが、その方法を選択する柔軟性も与えられます。 そして、あなたが書いているすべてのコードがすでに配列の長さを知っているなら、変数として長さを渡す必要はまったくありません。

明白な欠点は、ポインターとして渡される配列の固有の境界チェックがないため、危険なコードを作成できることですが、それは低レベル/システム言語の性質とそれらが与えるトレードオフです。

追加のストレージの問題は問題ですが、私の意見では小さな問題です。結局のところ、ほとんどの場合、とにかく長さを追跡する必要がありますが、amonは静的に追跡できる場合が多いことを指摘しています。

より大きな問題は、長さをどこに保存し、どのくらいの長さにするかです。すべての状況で機能する場所は1つではありません。データの直前にメモリに長さを格納するだけだと言うかもしれません。配列がメモリではなく、UARTバッファのようなものを指している場合はどうなりますか？

長さを残しておくと、プログラマーは適切な状況に合わせて独自の抽象化を作成できます。また、汎用のケースで利用できる既製のライブラリがたくさんあります。本当の問題は、なぜこれらの抽象化がセキュリティに敏感なアプリケーションで使用されないのかということです。

C言語の開発から：

構造は、マシンのメモリに直感的な方法でマップする必要があるように見えましたが、配列を含む構造では、配列のベースを含むポインタを隠しておく適切な場所も、それを配置する便利な方法もありませんでした初期化されました。たとえば、初期のUnixシステムのディレクトリエントリは、Cでは次のように記述されます。

struct {
    int inumber;
    char    name[14];
};

抽象オブジェクトを特徴付けるだけでなく、ディレクトリから読み取られる可能性のあるビットのコレクションを記述する構造も必要でした。コンパイラnameは、セマンティクスが要求するポインタをどこに隠すことができますか？構造がより抽象的に考えられていて、ポインターのスペースが何らかの形で隠されていたとしても、複雑なオブジェクト、おそらく構造を含む配列を任意の深さで指定したものを割り当てるときに、これらのポインターを適切に初期化する技術的な問題をどのように処理できますか？

このソリューションは、タイプレスBCPLと型付きCの間の進化連鎖における重要なジャンプを構成しました。ストレージ内のポインターの実体化を排除し、代わりに式で配列名が言及されたときにポインターを作成しました。今日のCで生き残っているルールは、配列型の値が式に現れると、配列を構成する最初のオブジェクトへのポインターに変換されるということです。

その一節は、ほとんどの状況で配列式がポインターに崩壊する理由を扱っていますが、配列の長さが配列自体と一緒に保存されない理由にも同じ理由が当てはまります。型定義とメモリ内のその表現との間で1対1のマッピングが必要な場合（リッチーが行ったように）、そのメタデータを保存するのに適した場所はありません。

また、多次元配列についても考えてください。各次元の長さメタデータはどこに保存しますか

T *p = &a[0][0];

for ( size_t i = 0; i < rows; i++ )
  for ( size_t j = 0; j < cols; j++ )
    do_something_with( *p++ );

質問は、Cに配列があると仮定しています。ありません。配列と呼ばれるものは、データとポインター演算の連続シーケンスに対する操作のための単なる構文上の砂糖です。

以下のコードは、実際には文字列であることを知らないintサイズのチャンクで、srcからdstにデータをコピーします。

char src[] = "Hello, world";
char dst[1024];
int *my_array = src; /* What? Compiler warning, but the code is valid. */
int *other_array = dst;
int i;
for (i = 0; i <= sizeof(src)/sizeof(int); i++)
    other_array[i] = my_array[i]; /* Oh well, we've copied some extra bytes */
printf("%s\n", dst);

なぜCは単純化されて適切な配列を持たないのですか？この新しい質問に対する正しい答えがわかりません。しかし、一部の人は、Cが（多少）より読みやすく、移植性の高いアセンブラーであるとよく言います。