>>807 ＞普通のコーディングで起こり得ないと
普通に使うと頻発する。
というのは、配列の大きさを処理群の最大値で決定している。
まず、入力値(60-100個)を(5-10)群に群分けして、割り振る。
ここで、最大数20の群があると、配列が (10群 , 20個)の領域を確保する。
しかし、前後最低1個は、未使用の領域を確保しておく。Dim AA(10)として、未使用領域 AA(0), AA(10)を用意する。
これは、設計があいまいな日曜プログラマーな場合に、バグが頻発する　AA(0), AA(10)の使用を避けることで、バグ取りを回避する。
入れる文字を20文字として、32バイト(位置アドレス2つ、8バイト等を12バイトと想定, QBでは、配列全体に10バイト位、個々の配列構成変数に10バイト位使っていたので同じとした、16→32ビットの変化で2倍になっているかもしれない)。
10 * 20 * 32 = 6.4KB が1配列。
5配列もあれば、32KB使ってしまうので、(QBと同じく64KBスタックを使っていれば)簡単にパンクする。
Dim AA(10,20)
AA = Fun1(AA())
Fun1 内に
AA = Fun2(AA())
とあれば、配列が2個使っていることになる(QBと同じだとすると、引数をPush する)から。
FreeBasic だと、障害発生ちょっと前までしか出力ファイルに残っていないのだが、
QB だと、引数1個で、100だか300回位の再起呼び出しでハングした。
再起呼び出しの回数を2-3回に制限して、
巨大な配列は、共通領域なり、外部配列なりに保管して、引数によるスタックを圧迫を抑え
つかっていた。V.B.だと、このあたりを気にしないで済むので、気軽に巨大配列の引数を使っていた。
そのつもりで使ったらば、おかしなことになってしまった。

＞ここで、最大数20の群があると、配列が (10群 , 20個)の領域を確保する。
と書いたけど、V.b.時代だと、偏りも考えられるので、(100, 100)の配列を作って使う。
前に、スタック不足と思られる障害が出ていたので、数を数えてから、配列を作るという作業に直してはある。