2016-11-11 6 views
1

コードベースでは、gccコンパイルオプションで "-fno-exceptions"を意味するC++例外は使用しません。(これは当社の方針であるため注意してください。しかし、そのような場合、例外をスローするコンストラクタの失敗を標準ライブラリからチェックする方法。私はいくつかのSOの投稿を読んだが、まだ明確なアイデアはない。たとえば、C++ 11では、std::regex("pattern") はregex_error例外をスローできます。私は次のコードをお持ちの場合:例外が発生したコンストラクタの失敗をチェックする方法

class Wrapper { 
public: 
    bool create(std::string pattern) { 
     try { 
     m_regex = std::regex(pattern); 
     m_state = true; 
     } catch (std::regex_error& e) { 
     //handle error case 
     m_state = false; 
     } 
    } 
private: 
    std::regex m_regex; 
    bool m_state; 
} 

を注: m_regex = std::regex(pattern);

例外をスローしていないで、今すぐオペレータ

basic_regex& operator=(basic_regex&& __rhs) noexcept 

を割り当てる移動することができます

explicit basic_regex(const CharT* s, flag_type f = std::regex_constants::ECMAScript) 

を呼び出します例外を使用するオプション、どのように我々は失敗を確認することができますか? f std :: regexのコンストラクタ?

class Wrapper { 
public: 
    create(std::string pattern) { 
     m_regex = std::regex(pattern); 
     // now, how to check? 
     // if (m_regex)? 
     m_state = true; 
    } 
private: 
    std::regex m_regex; 
} 

std :: regexには、障害を示す可能性のある状態が見つかりませんでした。

オプション1:正規表現のコンストラクタが失敗し、abort()が発生した場合、次の文m_state = trueは実行されません。私はチェックした、abort()例外が有効になって通常起こるが、キャッチが使用されないようだ。だからこれは間違っている。

オプション2:std::regex* ptr_regex = new std::regex("pattern")を使用して、ptr_regexのヌルネスを確認できますか?

+2

できません。例外を使用することが許可されていない場合(キャッチするだけであっても)、STLの使用を避ける必要があります。 – Gonmator

+0

@GonmatorはSTLだけでなく、特に正規表現を含むC++標準ライブラリのすべての部分を避けなければならないことを除いて、 –

+1

非常に低いリソースの組み込みプログラミングや、従来のコードベース(これはGoogleの仕組み)などの非常に良い理由がない限り、「当社は例外を許可しません」という良い解決策の1つは、可能であれば、他の場所で仕事を見つける。無能者の重要な政策の1つでは、残りの部分がまったく不調である可能性があります。例えば、チーフエグゼクティブは、働く倫理コンパスの欠如を明らかにする:それは組織のほぼすべてに影響を与えた可能性が高い。 –

答えて

2

これは幾分解決されていない問題であり、one of the big open problems discussed by SG14、委員会の「低レイテンシ」研究グループです。

標準に関する限り、これは単に定義されていません。例外はオプションではなく、スイッチをオフにすると何が起こるかは不明です。したがって、標準ライブラリは通常、エラーを処理する代替手段を提供しません。現在、将来の提案でこれをいくらか緩和する傾向があります。たとえば、現在のファイルシステムTSには、例外をスローする可能性のあるすべての関数のエラーコードを返す非投げ過負荷があります。同様の方法で、既存の標準ライブラリ施設に非投げの代替案を提供することは可能かもしれませんが、それはまさにSG14が把握しようとしていることです。

今のところ、重要な質問は:あなたコンパイラは、それが発生した場合に何をしないthrow(またはtry/catch)無効の例外を除いてコンパイルするとき?前にも述べたように、この規格ではこれはまったく指定されていないため、ここでの解決方法は必ずポータブルではありません。おそらく、ライブラリによって示されたエラーをthrowで検出または回復できない可能性があります。そのため、例外がスローされることを事前に除外できない場合は、関数をスローすることを避けてください(したがって、ほとんどの標準ライブラリ)。

この状況は今後改善されることを願っています。

+0

ええ、私たちは本当にこれに固執しています。しかし、私たちや顧客が委員会を待つことができないため、解決策や回避策を見つける必要があります。 – pepero

+0

@pepero私はあなたの痛みを感じます。代わりの実装を目にしておきたいと思うかもしれません。多くのベンダーは、このような理由で標準ライブラリ機能を実装しています。 「埋め込まれたSTL」は、インターネット検索の開始キーワードです。 Boostは、追加の保証を伴う実装を提供することがあります。残念ながら、あなたの質問から問題を解決する 'std :: regex'の実装についてはわかりません。 – ComicSansMS

0

例外を必要とするstdユーティリティをラップすることを目的としたライブラリを作成します。

このライブラリは、例外を有効にしてコンパイルされたです。

optional<std::regex>(たとえば)の同等値を格納します。おそらく失敗するコンストラクタを提供します(ライブラリ内の.cppのもの)がコンストラクタを呼び出し、try/catchを実行して失敗を空のregexにします。

スロー可能な他の操作がある場合、エラーリターンパスを持つメソッドにsimularlyラップします。多分彼らはstd::experimental::expected<T, error_information>を返すでしょう。

このライブラリと例外が無効にされたstdライブラリでコンパイルされたコード間のODRとリンクには、インライン関数が異なるため注意が必要です。私は今この問題を回避する方法の詳細はありません。

非常に速いgoogleからわかることから、膨らんだものと例外が有効になっている1つのライブラリは、ほとんどがそのライブラリのサイズに比例しているはずです。これをテストします。

関連する問題