1

や などの長年の抽象化に基づいて構築された Qt ライブラリを作成しました。したがって、通常の共有ポインターが必要な場合は、一貫性を保つために使用するのが理にかなっています。QSharedDataPointerQSharedDataQSharedPointer

現在、これを C++11 プロジェクトで使用しています。shared_ptrコードをより標準的なものにするために、すべてのローカル サブシステムを に切り替えます。

ライブラリ自体の C++11 依存関係は必ずしも望ましいものではないため、使用する共有ポインターの種類を選択できるようにする必要があるように感じました。先に進むための最初のカットとして、C++0x でのテンプレート エイリアスの柔軟性で提案されているこの方法を試しました (確かに C++11 への依存自体ですが、非 C++11 ではコンパイラ フラグを介してプリプロセッサを使用できます)。ビルド)

#if THINKERQT_USE_STD_SHARED_PTR

#include <memory>
template<class T>
using shared_ptr_type = std::shared_ptr<T>;

#else

#include <QSharedPointer>
template<class T>
using shared_ptr_type = QSharedPtr<T>;

#endif

残念ながら、ポインタ クラスはメソッドに別の名前を付けました。特に、含まれているポインターへのアクセスは.get()、shared_ptr および.data()QSharedPointer によって行われます。

私はある種のエクストラクタを作成するつもりでしshared_ptr_type_get<>たが、同じことを効果的に達成できることに気付きました (含まれているポインタが null ではなく、ブール型強制によって null をテストできる場合)。

&(*ptr)

コードを読んでいると、ちょっとしたスピード バンプになります。しかし、WTF 要因を除けば、それは十分に害がないように思えます...そうですか?

4

1 に答える 1

3

私はこれを私のプロジェクトでも使用していますが、すでにお気づきのように読みやすさ以外に使用しても問題はありません。そして、Mike Seymourが指摘したように、最初にptrがnullポインタではないことを常に確認する必要があります。

ほとんどの場合、次のイディオムを使用します。

if( shared_ptr_type ptr = funcReturnsSharedPtr() )
{
    funcAcceptsRawPtr(&*ptr);
}

shared_ptr_type妥当な共有ポインタクラスはオーバーロードするため、使用する共有ポインタタイプの種類に関係なく、これが正しくコンパイルおよび機能することがほぼ保証されていますoperator*。

于 2012-06-22T13:38:03.403 に答える