Linux カーネルの非常に長い関数に関する学術プロジェクトを書いています。
その目的のために、非常に長く (数百行のコード)、悪いプログラミングとは見なされない (つまり、分解やディスパッチの使用の恩恵を受けない) 実際の関数の例を探しています。テーブル）。
そのようなコードを書いたり見たりしたことがありますか? 投稿またはリンクして、なぜそんなに長いのか説明してもらえますか?
私はここのコミュニティから素晴らしい助けを得ています - プロジェクトに取り入れられるどんなアイデアも適切にクレジットされます.
ありがとう、
ウディ
私がこれまでに書いた中で最も長い関数にはすべて、1 つの共通点があります。それは、非常に大きな switch ステートメントです。項目の長いリストをオンにする必要があり、いくつかのオプションを別の関数にリファクタリングしようとすると、理解が難しくなるだけの場合があります。大きな switch ステートメントを使用すると、サイクロマティックな複雑さが屋根を通り抜けますが、多くの場合、代替の実装よりも優れています。
私が解雇される前の最後のものでした。
前職: 非常に長い case ステートメント、IIRC 1000 行以上。これはオブジェクトよりずっと前のことです。各オプションの長さはわずか数行でした。分割すると、わかりにくくなります。実際には、同じ基礎となるデータ型のセットに対して異なることを行う、そのようなルーチンのペアがありました。
申し訳ありませんが、コードはもうありません。投稿するのは私のものではありません。
私が恐ろしいとは思わなかった最も長い機能は、カスタム CPU VM の主要な方法です。@epotter と同様に、これには大きな switch ステートメントが含まれていました。実際、きれいに分解したり、読みやすさを向上させたりするのに抵抗があると思う多くの方法には、switch ステートメントが含まれています。
残念ながら、ある種のコードジェネレーターを使用してビルドステップ中に自動生成された場合、このタイプのサブルーチンがチェックインされたり、どこかに投稿されたりすることはあまりありません。
したがって、Cが別の言語から生成されたプロジェクトを探してください。
パフォーマンスの他に、カーネル空間でのコールスタックのサイズは8Kだと思います（サイズを確認してください）。また、私が知る限り、カーネルのコードはかなり具体的です。将来、一部のコードが再利用される可能性が低い場合は、関数呼び出しのオーバーヘッドを考慮して、わざわざコードを関数にする必要があります。
速度が重要な場合 (カーネルである種のロックを保持している場合など) は、関数呼び出しを行うことによるオーバーヘッドのために関数を分割したくないと想像できます。コンパイル時に、パラメーターをスタックにプッシュする必要があり、データを返す前にポップする必要があります。そのため、効率上の理由から大きな関数が必要になる場合があります。