問題タブ [safe-bool-idiom]

誰かがこのコードの理由を説明してもらえますか？

次のコンパイラエラーが発生しますか？

どちらのsafe_boolテンプレートもから派生してsafe_bool_baseいるため、基本クラスの保護されたメンバーにアクセスできない理由がわかりません。

私は何かが足りないのですか？

やあみんな、私はこのページのC++セーフブールイディオムクラスから私のクラスを派生させました：Bjorn Karlssonによるセーフブールイディオム

以下のようなif式で使ってみたところ

エラー C2451: conditional expression of type 'Element' is illegal が発生しました。以下のように bool にキャストしようとすると、このエラーが発生しました

エラー C2440: '型キャスト': 'Element' から 'bool' に変換できません

安全な bool イディオムを使用するのはこれが初めてです。これが許可されていないのか、Visual C++ 10 のバグなのかわかりません。何かコメントはありますか? 前もって感謝します！

@Rのこの答え。Martinho Fernandesは、単純な

回答の標準的な引用によると§4 [conv] p3：

式 e は、何らかの発明された一時変数(§8.5)に対してT、宣言が適切な形式である場合にのみ、暗黙的に型に変換できます。特定の言語構造では、式をブール値に変換する必要があります。そのようなコンテキストに現れる式は、何らかの発明された一時変数 t (§8.5) に対して、宣言が整形式である場合に限り、に文脈的に変換され、整形式であると言われます (§8.5)。T t=e;teboolbool t(e);

強調表示された部分は、@R として "暗黙の明示的なキャスト" (標準では "コンテキスト変換" と呼ばれます) を明確に示しています。マルティニョはそう言った。

「暗黙の明示的なキャスト」を必要とする「特定の言語構造」は次のようです。

• if, while, for( §6.4 [stmt.select] p4)
• 二項論理演算子&&and ||(§5.14 [expr.log.and/or] p1両方の場合)
• 論理否定演算子!( §5.3.1 [expr.unary.op] p9)
• 条件演算子?:( §5.14 [expr.cond] p1)
• static_assert( §7 [dcl.dcl] p4)
• noexcept( §15.4 [except.spec] p2)

タイトルの仮定は正しいですか？潜在的な欠点を見逃さなかったことを願っています。

プログラマーの作業時間の 25% は、必要なコードが既に存在するかどうかのチェックに費やされています。

安全な bool イディオムを実装するための基本クラスを探しています。

次のセーフ bool イディオムからの抜粋を考えてみましょう。

typedefなしで変換関数を宣言することは可能ですか? 以下はコンパイルされません。

安全な bool イディオムに関連する別の質問があります。

bool_type(typedef) とthis_type_does_not_support_comparisonsはどうしてconstですか? とにかく、誰も実際に戻りポインターを介してメンバー関数を呼び出すことは想定されていませんよね? ここはconst必要ですか？operator bool_typeそうでなければ、(メンバー関数は) const-correctness に違反しますか?

@Xeo の優れたc++-faq質問から: C++11 では safe-bool イディオムは廃止されましたか? explicitC++03 でセーフ bool が必要なコンテキストでは、ユーザー定義の変換boolが自動的に呼び出されるため、セーフ bool イディオムが不要になったことを知りました。

&&ただし、 、 、などの演算子をオーバーロードする機能は、これを回避しているようです||。!

operator!への変換の提供を超えて が必要なケースは、やboolのようにまれですが、C++ 式ツリーの実装 (遅延実行および記号演算手法に使用される) では、これらをオーバーライドする必要があります。operator&&operator||

ユーザー定義の演算子が呼び出されているときに「コンテキスト変換」が行われますか? operator&&またはの定義がoperator||「セーフブール」を実装する型と「コンテキスト変換」用に設計された型の両方で正しく機能することを確認するには、どのような SFINAE 呪文が必要ですか?

明確にするために、与えられた：

operator||次の式がすべて有効になるために必要な署名は次のとおりです。

これらは異なるオーバーロードを使用します:

以下はコンパイル時に拒否されます。

私は「セーフブールイディオム」を指摘され、何が起こっているのかを解読しようとした後（サイトで提供された説明は、それが機能する理由を理解するのに十分ではありませんでした）、次のコードを試してみることにしましたできるだけ単純化しようとします。サイトは以下のコードを提供しました：

「bool_type」の主な根拠を分析することにしました。これが中心になっているようです。次の行があるとします。

bool_type が表す 'void Testable::*' の型の typedef であると推測することはできます (ブラケットのため、それほど簡単ではありません)。これは、次の変更と関数呼び出しを行うことでさらに実証できます。

これにより、bool_type の型を確認できます。

エラー: 初期化で 'void (Testable::*)()const' を 'int' に変換できません

これは、実際に「void (Testable::*)」のタイプであることを示しています。

ここで問題が発生します。

次の関数を変更すると:

そしてそれを次のように変えます：

次の苦情が生成されます。

エラー: '*' トークンの前に識別子が必要です
エラー: '< 無効な演算子 >' が関数を返す関数として宣言されました

したがって、私の質問は次のとおりです。

'void (Testable::*) が実際に bool_type の typedef である場合、これらの苦情が生成されるのはなぜですか?

と

ここで何が起こっているのですか？

安全な bool イディオムのすべてのインスタンスを、explicit operator bool既に C++11 機能を使用しているコードで置き換えることを考えています (そのため、古いコンパイラが明示的な変換演算子を認識しないという事実は問題になりません)。微妙な問題を引き起こす可能性がある場合。

したがって、古くて鈍い安全な bool イディオムから新しい光沢のあるイディオムに切り替えることによって引き起こされる可能性のあるすべてexplicit operator boolの非互換性 (最も細かいものであっても) は何ですか?

EDIT: I know that switching is a good idea anyway, for the latter is a language feature, well-understood by the compiler, so it'll work no worse than what's in fact just a hack. I simply want to know the possible differences.

クラスの安全な bool イディオムを実装するために (Boost.Operators から)を活用しようとしてboost::bool_testable<>いますが、ライブラリの最新バージョン (この記事の時点で 1.49) にはもうないようです。

それはどこに行きましたか？現在利用可能なより良い代替手段はありますか?

私は C++11 を使用できないため、安全な bool を不要にする言語拡張機能を使用できません。