iPhoneで再帰を避けるべきですか？

Question

iPhoneで実行されるコードで再帰を避けるべきですか？

また、誰かがiphoneの最大スタックサイズを知っていますか？

Answer 1

はい、再帰を避けることは、すべての組み込みプラットフォームで良いことです。

スタックオーバーフローの可能性を下げるだけでなく、スタックオーバーフローの可能性も排除するだけでなく、より高速なコードも提供することがよくあります。

反復アルゴリズムを常に反復的に書き換えることができます。それは必ずしも実用的ではありません（クイックソートを考えてください）。これを回避する方法は、再帰の深さが制限されるようにアルゴリズムを書き換えることです。

イントロレーションは、どのように実際に行われたかの完全な例です。クイックソートの再帰深度をlog2（要素数）に制限します。だから、32ビットマシン上で、私は（車のエンターテイメントシステム、携帯電話、ゲーム・コンソールや、過去に組み込みプラットフォーム用のソフトウェアのかなりを書いた32

http://en.wikipedia.org/wiki/Introsort

より深いを再帰的にすることはありません私はいつも再帰の深さに上限を置くか、最初のところで再帰を避けるようにしました。

私のプログラムのどれもスタックオーバーフローで死んだことはなく、ほとんどのプログラムは32kbのスタックに満足しています。これは、各スレッドがそれ自身のスタックを取得すると、複数のスレッドが必要になると大きな時間を費やします。メガバイトのメモリをこのように節約することができます。

Answer 2

iphoneの最大スタックサイズは？

iPhoneは、ほとんどのオペレーティングシステムと同様に、すべてのプロセスに有効なメモリ空間が与えられている修正されたOSXを実行します。

これは完全なプロセッサーなので、スタックが成長し、ヒープが成長します（逆もまた同様です）。これは、プログラムに割り当てられたメモリが足りなくなるまでスタックをオーバーフローさせないことを意味します。

スタックとパフォーマンス上の理由から（単純なループと比較して関数呼び出しが高価な）再帰を避けるのが最善ですが、どのような場合でも再帰関数に適用できる制限を決定し、長すぎる

Answer 3

「再帰を使用しないでください」という沸騰の回答が2つあります。私は同意しない - それはiPhoneが厳しく制限された組込みシステムではない。問題が本質的に再帰的である場合は、そのように表現してください。

数百または数千のフレームのスタック深度に再帰しない限り、問題は発生しません。