問題タブ [c++03]

多かれ少なかれ、タイトルが示唆するもの。私はまだ C++0xを使用していませんが、それが起こったときに備えたいと思います。また、その機能の一部を使用するために書き直さなければならないコードの量を減らしたいと考えています。そうすれば、後方互換性と前方互換性を一度に取得できます。

私が見つけた最も興味深いものの 1 つは で、nullptr最近頻繁に使用しています。

「公式の回避策」とMeyer の提案を確認した後、これを自分の C++ プログラムと将来の C++0x プログラムの両方で使用することにしました。2 番目の部分は単純です。キーワードであるため、nullptr単純にサポートされます。しかし、最初の部分は私に不快感を与えています。

Meyers の提案は次のように機能します。

std::nullptr_tその提案の問題点は、C++0x で必要とされる型を宣言することです。つまり、回避策を「ネイティブに感じる」には、std::名前空間を再度開いて型を追加する必要があります。私は、C ++プログラムで行うのは違法であることを理解しています（明らかに警告を発して眉をひそめているように見える特殊化を追加するのとは異なります）。

C++ プログラムでnullptr快適かつ合法的な方法で使用したい。私が考えていたオプションの 1 つは、別の名前空間で型を宣言し、それを次のように使用することでしたusing。

これはそれを機能させる正しい方法でしょうか？ディレクティブを強制usingし、特定の順序の#includeディレクティブも強制します。nullptr_tC++0x より前のコードでは、名前空間を持つ型を (たとえば、関数の引数の型として)要求しないと期待するのは正しいでしょうか? このようにすると、実際に「ネイティブ感」が得られるでしょうか？

補足として、互換性とコーディングを改善するために、いくつかの気の利いた C++0x のものを C++ にバックポートしようとすることは、歓迎されることですか、それとも嫌われることですか? それまでの間、私はこのソリューションと、私が取り組んでいる他のソリューションを、リリースされるソフトウェアに統合しました。

このサンプルコードについて疑問に思っています。

このコードは実際にC++03で整形式ですか？

私の主張は、の副作用=は次のシーケンスポイントの後でのみ完了するということですp=arr。また、コードの結果にアクセスしているため、整形式ではない可能性があるため、=と[]操作の間に順序はありません。

私は正しいですか？

この動作は、CおよびC++11で明確に定義されています。このコードは実際にはMySQLから派生しています。

注: この質問は、もともと 2012 年にさかのぼって尋ねられました。decltype指定子が主要なコンパイラによって完全に実装される前です。C++03 にしかアクセスできない場合を除き、このコードを見ないでください。すべての主要な C++11 準拠のコンパイラが をサポートするようになりdecltypeました。

メンバーのタイプを取得する簡単な方法はありますか?
C++03 の場合

私は実際にこれを行っています（つまり、少し怠惰です）：

しかし、ユーザーにメンバーの型を強制的に指定させるのではなく、コンパイラーに実用的に生成させたいのです。

タイプの参照を簡単にするために、using句を使用して個々のタイプを現在のスコープに取り込むことができます。

問題は、クラスがテンプレートクラス（または関数）であるかどうかです。それらを完全にインスタンス化せずに現在のスコープに持ち込むことは可能ですか？

任意のクラス (読み取り: 特定のクラスではない) のメンバー関数を指すことができる関数ポインター (非 C++ 11) を宣言することは可能ですか?

たとえば、クラス A、B、および C があるとします。C には関数ポインターが宣言されており、そのポインターを B のメンバー関数の 1 つと A のメンバー関数の 1 つを指すように切り替えたいとします。C++ はこれを許可しますか?

C++03 では、Boost の Foreach は、こ​​の興味深い手法を使用して、式が左辺値か右辺値かを実行時に検出できます。(私はこの StackOverflow question: Rvalues in C++03を介してそれを見つけました)

これが実行時に動作するデモです

(これは、私の最近の別の質問について考えているときに発生した、より基本的な質問です。これに対する回答は、他の質問の回答に役立つ可能性があります。)

コンパイル時に C++03 で rvalue-ness をテストするという質問を詳しく説明したので、これまで試してきたことについて少しお話しします。

コンパイル時にこのチェックを実行できるようにしたい。C++11なら簡単だけど、C++03が気になる。

私は彼らのアイデアに基づいて構築しようとしていますが、さまざまなアプローチにもオープンです。彼らの手法の基本的な考え方は、このコードをマクロに入れることです。

の左側が「true」である?ため、EXPRESSION が評価されることはないと確信できます。しかし興味深いのは?:、パラメーターが左辺値か右辺値かによって、演算子の動作が異なることです (詳細については、上記のリンクをクリックしてください)。rvalue_probe特に、 EXPRESSION が左辺値であるかどうかに応じて、次の 2 つの方法のいずれかでオブジェクトを変換します。

スローされたテキストをキャッチして、EXPRESSION が左辺値か右辺値かを分析するために使用できるため、これは実行時に機能します。しかし、コンパイル時にどの変換が使用されているかを特定する方法が必要です。

これは潜在的に有用です。

EXPRESSION は右辺値ですか?

私たちは尋ねることができます：

コンパイラがtrueをコンパイルしているとき rvalue_probe() : EXPRESSION、オーバーロードされた 2 つの演算子operator Xまたはoperator X&のどちらが選択されていますか?

（通常、戻り値の型を変更してそれを取得するsizeofことで、どのメソッドが呼び出されたかを検出できます。しかし、これらの変換演算子では、特にそれらが?:.

私は次のようなものを使用できるかもしれないと思った

EXPRESSION が左辺値の場合、operator&が選択され、式全体が型になることを期待しました&。しかし、うまくいかないようです。ref 型と非 ref 型を区別するのは非常に困難 (不可能?) です。特に、?:どの変換が選択されたかを確認するために式の内部を掘り下げようとしている今はそうです。

ここに貼り付けたデモコードは次のとおりです。

(最後に別のコードがいくつかありましたが、それは単に混乱を招くだけです。失敗した回答の試行を実際に見たくはありません! 上記のコードは、実行時に lvalue-vsus-rvalue をテストする方法を示しています。)

それが可能かどうか、また C++ クロスプラットフォーム (C99、C++0x に依存しない) で実装する方法はsnprintf? ブーストにそのようなものはありますか？(C++ のイディオムは何に置き換えるのsnprintf(4)だろうか?)

規格は、

これfooは、外部リンケージを持つインライン関数です（デフォルトでは、すべての関数宣言に外部リンケージがあるため）。これは奇妙なことに私を襲います。1つの定義ルールセクション3.2（C++03とC++11の両方）は次のように述べているためです。

3 ...インライン関数は、それが使用されるすべての変換単位で定義されるものとします。

5 a[n]の定義は複数存在する可能性があります...外部リンケージを使用したインライン関数（7.1.2）...複数の変換単位で定義されたDという名前のエンティティが与えられた場合...Dの各定義はトークンの同じシーケンスで構成されます

これは、インライン関数にも内部リンケージがある可能性があることを意味します。これは、外部リンケージを介して（つまり、変換ユニット間で）関数を使用すると、未定義の動作（段落3による）が呼び出され、その内容がすべての変換ユニットのインライン関数は同じである必要があります。

このルールには、下位互換性または特定のツールチェーンの理由がありますか？

次のコードがコンパイルされ、コンパイルされないのはなぜC++11ですかC++03？（gccとの両方cl）

ストリームがコンストラクターパラメーターとしてC++03受け入れられないのはなぜですか？この決定は何かに基づいたものですか、それとも偶然に起こったのですか？std::string

私はいつも次のコードだと思っていました

マップ内で単位化された値が作成されるため、ランダムな値が出力されます。ただし、作成された int は実際には常にゼロに初期化され、標準の組み込み型も特定の状況でゼロに初期化されることが判明しました。

問題は、標準型 (int/char/float/double/size_t) のゼロ初期化がいつ実行されるかです。int i;どこかで宣言すると、ランダムなデータが含まれることは間違いありません。

PS 質問は C++03 標準に関するものです。質問の理由は、int/float/size_t などの組み込み型の初期化をいつ提供する必要があるか、またはいつ安全に省略できるかがわからなくなったためです。