問題タブ [ref-qualifier]

これは、clang 3.3 で問題なくコンパイルされます。

しかし、gcc 4.8.1 では失敗します:

これをさまざまなコンテキストで使用すると、クラッシュや内部コンパイラ エラーなど、あらゆる種類の予期しないコンパイラの動作が発生します。

ref 修飾されたメンバー関数は、標準では「*this の右辺値参照」( N2439 ) と呼ばれ、gcc 4.8.1 でサポートされていることを理解しています。

ここでの問題は、gcc が ref 修飾されたメンバー関数型と通常のメンバー関数型を区別していないように見えるテンプレート引数としてそれらを使用することです。

clang の std ライブラリの実装は、この機能がサポートされているかどうかを検出するようです。

では、ref 修飾された関数のこの使用は標準ですか、それとも言語拡張ですか?

コードをG++ ( gcc 4.8.1 およびMinGW 4.8.2 with -std=gnu++1yflag) でコンパイルすると、奇妙な動作が見つかりました。SSCCE の精神で、次のスニペットを分離します。

エラーが発生します：

ただし、#if 1and #if 0、 or #if 0andの場合は#if 1正常にコンパイルされます。また、すべてを に置き換えるautoとvoid、すべてが正常にコンパイルされます。

それはバグですか、それとも私の誤解ですか？

次の変換演算子が与えられた場合

次の変換はすべて有効であると予想されますが、コンパイルエラーが発生するものもあります( live example ):

特に、1 は 3 と同じように見え、2 とほとんど同じように見えますが (7 から 9、8 についても同様)、動作が異なります。

説明または回避策はありますか？

私の動機は、さらに別の 'any'です。最終的には、 ,explicitのような型特性の問題を回避するためにすべての変換演算子を作成する必要がありましたが、新しい問題にぶつかりました。std::is_constructiblestd::is_convertible

EDIT申し訳ありませんが、私の間違いである 3 と 9 は無視してください (Kerrek SB に感謝します)。しかし、7 と 8 は問題として残ります。あとexplicit、やっぱり関係ないようです、すみません。

EDIT 2ちょうどそれに気づいた

変換演算子が でない場合は有効ですexplicit。そこで、explicit最初はサンプルでコピー初期化を使用していましたが、切り替えたときにexplicit直接初期化を使用する必要がありました。その後、この問題が発生しました (ケース 7 および 8)。

デフォルトでreturn s1 + s2 + s3 + s4 + s5;は、次のコードと同等である可能性があります。

割り当て時間を 1 に短縮するエレガントな方法はありますか? そのままにしておくということreturn s1 + s2 + s3 + s4 + s5;ですが、効率は自動的に改善されます。可能であれば、プログラマーによる の誤用を防ぐこともできますstd::string::operator +。

ref-qualifierメンバー関数は役に立ちますか?

左辺値参照修飾メンバー関数と修飾されていないメンバー関数に違いはありますか? もしそうなら、それは何ですか？

つまり、これら 2 つの宣言方法はfunc()異なるのでしょうか。

の両方のバージョンが存在する場合、明らかに上記のクラスはコンパイルされないため、「オーバーロードの解決を許可するのに十分なほど異なるか」という意味ではありませんfunc()。&つまり、 が含まれている場合と含まれていない場合でコンパイラの動作が異なるのはなぜですか?

少なくとも 1 つの違いがあります。それは、ref 修飾された関数 (左辺値型または右辺値型のいずれか) は、ref 修飾されていない関数でオーバーロードできないことです。現在の標準ドラフトから:

同じ名前と同じ parameter-type-list を持つメンバー関数宣言、および同じ名前、同じ parameter-type-list、同じテンプレート パラメーター リストを持つメンバー関数テンプレート宣言は、それらのいずれかがある場合はオーバーロードできませんが、すべてではありませんが、ref 修飾子があります。

...しかし、これが唯一の違いである場合、なぜ制限があるのでしょうか? foo()&&つまり、 (unqualified) の有効なオーバーライドとして扱われないのはなぜfoo()ですか?