多かれ少なかれ、タイトルが示唆するもの。私はまだ C++0xを使用していませんが、それが起こったときに備えたいと思います。また、その機能の一部を使用するために書き直さなければならないコードの量を減らしたいと考えています。そうすれば、後方互換性と前方互換性を一度に取得できます。
私が見つけた最も興味深いものの 1 つは で、nullptr
最近頻繁に使用しています。
「公式の回避策」とMeyer の提案を確認した後、これを自分の C++ プログラムと将来の C++0x プログラムの両方で使用することにしました。2 番目の部分は単純です。キーワードであるため、nullptr
単純にサポートされます。しかし、最初の部分は私に不快感を与えています。
Meyers の提案は次のように機能します。
class nullptr_t { // ← this is my issue
// definition of nullptr_t
} nullptr = { };
std::nullptr_t
その提案の問題点は、C++0x で必要とされる型を宣言することです。つまり、回避策を「ネイティブに感じる」には、std::
名前空間を再度開いて型を追加する必要があります。私は、C ++プログラムで行うのは違法であることを理解しています(明らかに警告を発して眉をひそめているように見える特殊化を追加するのとは異なります)。
C++ プログラムでnullptr
快適かつ合法的な方法で使用したい。私が考えていたオプションの 1 つは、別の名前空間で型を宣言し、それを次のように使用することでしたusing
。
namespace mylibrary {
class nullptr_t {
....
} nullptr = { };
// end namespace
}
// These would have to go in the header file.
using mylibrary::nullptr;
using mylibrary::nullptr_t; // apparently this is necessary as well?
これはそれを機能させる正しい方法でしょうか?ディレクティブを強制using
し、特定の順序の#include
ディレクティブも強制します。nullptr_t
C++0x より前のコードでは、名前空間を持つ型を (たとえば、関数の引数の型として)要求しないと期待するのは正しいでしょうか? このようにすると、実際に「ネイティブ感」が得られるでしょうか?
補足として、互換性とコーディングを改善するために、いくつかの気の利いた C++0x のものを C++ にバックポートしようとすることは、歓迎されることですか、それとも嫌われることですか? それまでの間、私はこのソリューションと、私が取り組んでいる他のソリューションを、リリースされるソフトウェアに統合しました。