9

私は組み込みプラットフォームで作業していますが、バイナリに 60k を追加することに不安があります。とにかく、組み込みシステムで例外を回避するための議論がありますが、それらのほとんどは偽物だと思います。例外は理にかなっていますが、現状のコストを正当化することはできません。私は gcc 4.6.3 を使用しています。オプションが不足している可能性があります。または、これは単に例外のオーバーヘッドである可能性があります。-Os を試し、例外を longjmp に変更しましたが、役に立ちませんでした。私は何かを逃したかもしれません。

洞察をありがとう。

4

2 に答える 2

2

を使用して、GCC で例外を無効にすることができます-fno-exceptions。

ただし、ケーキを持って食べることはできません。例外をオフにすると、例外をキャッチできなくなります。また、例外をオンにしてコンパイルされたコードに対してリンクすると、例外が壊れます。ただし、意図したとおりにバイナリ サイズが縮小されます。

例外のないコード (ただし、エラー チェックのレベルは同じ) は罪のように醜いですが、それはあなたが支払わなければならない代償です。

C での素敵な例外のない堅牢なコード例 :)

error_t foo(void) {
    if (!do_foo()) {
        error_code = E_FOO;
        goto bail;
    }
    if (!do_bar()) {
        error_code = E_BAR;
        goto bail;
    }
    /* repeat 100 times */
bail:
    cleanup();
    return error_code;
}
于 2013-02-07T22:58:13.590 に答える
2

最初は、いいえ！

例外処理には、主に RTTI サポートを主に要求することによって、いくらかのコストがかかります (これまでのところ実験的に証明されていません)。RTTI サポートは、特に多数のテンプレート インスタンス化がある場合 (たとえば、STL テンプレート クラス/コンテナ クラスを多数のさまざまな型で広範囲に使用する場合)、コードのテキスト セグメントの使用に費用がかかります。

一方、newlib が必要な実装などを削減する他の可能性と比較すると、60k のオーバーヘッドのコストはそれほど大きくありません。

例外のサポートを手放すことについて、よく考えるべきです!

面白いことに、今日同僚とこのトピックについて話し合ったところ、明らかにメモリ不足の状況によって引き起こされたエラーに直面していました。問題のファームウェア (および FreeRTOS への OS バインディング) は例外をサポートしていませんが、new(). try/catchこれは、STL によって誘導されたアルゴリズムを使用して発生する可能性があり、失敗時にブロックを使用してこれを傍受する機会はありません(単純な の使用などstd::vector)。

したがって、例外を使用するかどうかに関係なく、エラー状況をどのように処理するかを決定し、たとえば一般的な STL パターンの使用などで一貫した動作を提供することを確認し、.textセクション サイズに対して支払うコストからこれを検討する必要があります。

于 2013-02-07T22:40:17.693 に答える