問題タブ [boost-ptr-container]

私が働いている会社では、「RestrictedMap」というクラスを作成しました。これは、通常の std::map と同じインターフェースを提供しますが、[] 演算子を使用することはできません。クラスを快適に操作するために、他のいくつかの機能が提供されています。内部的に、クラスは std::map をラップします。

「RestrictedPointerMap」と呼ばれる、boost::ptr_map に対して同じことを行う同様のクラスを作成しようとしています。このために、テンプレート引数としてラップするマップのタイプを受け入れ、ほとんどの実装を含むRestrictedMapBaseを作成しました。2 つのクラスが派生し、ラップするマップのタイプを指定します。

• 以前と同じことを行い、std::map をラップするRestrictedMap
• 新しいもので、boost::ptr_map をラップするRestrictedPointerMapです。

これがコードです。完全を期すためにクラスを単純化していませんが、後で関連する関数に名前を付けます。

RestrictedMap.h

これは、RestrictedPointerMap でgetValueを呼び出したい場合を除いて、ほとんどの場合機能します。関数getDataは正しい値を返しますが、その後getValue関数で問題が発生します。間違ったポインターを返します (ポインターが間違っているように)。

問題を再現するコードを次に示します。

TestClass.h

TestClass.cpp

TestRestrictedPtrMap.cpp (メイン)

これの出力は次のとおりです。

なぜそれがうまくいかないのか、私にはわかりません。私の知る限り、戻り値は魔法によって悪くなります。

助けてくれてありがとう、

トム

要素を挿入および/または消去すると、既存の要素へのイテレータが無効になる可能性はありますか？

ありがとうございました。

TL;DR VS2013 のオプティマイザが混乱しているか、測定値が間違っているか、またはテストを有効にするために実際にグローバル ダミーを揮発性にする必要があるか、または ____ ですか?

免責事項：これは主に「学術的」な関心から外れています。私が見た違いが実際に製品コードに影響を与えるとは思いません。

はじめに: VS2013とVS2013の間で大きな違いが見られたため、私の最近の測定結果からこの質問にたどり着きました。（そこのコメントも参照してください）std::vector<std::unique_ptr<T> >boost::ptr_vector

私の特定のテスト ケースでは、boost::ptr_vector 内の要素へのアクセスは、unique_ptr のベクトルを使用するよりも 50% 高速になる可能性があります。

私のテストコードはここにあります: http://coliru.stacked-crooked.com/a/27dc2f1b91380cca (この質問には含めません。以下にスニペットを含めます)

• gcc 4.8 は違いを報告しないため、これは VS2013 のものです。

  /li>

• リンクされているテストコードの正確なタイミングは次のとおりです。

  /li>

テストループは次のようになります。また、私が見たものを説明する長いコメントをそこに残しておきます。

ループ内の唯一の行が要素にアクセスしている (ptr をグローバル ダミーに入れている) 場合、VS2013 オプティマイザーが奇妙なことをしているように見えます。が存在する場合if (pGlobalDummy)、どちらの場合も同じです。

誰でもこれについていくつかの光を共有できますか?

ハワードの回答のおかげでvolatile、グローバルダミーに追加すると違いが生じることがわかりました。つまり、グローバルダミーが次のように揮発性である場合：

ループの実行は少し遅くなりますが、まったく同じように実行されます。ここで揮発性が違いを生むべきですか？つまり、揮発性がなくてもテストは有効ですか?

クラス オブジェクトのリストを格納するために boost::ptr_vector を使用しています。

この方法でオブジェクトを ptr_vector に追加します。

オブジェクトを追加するのは、ptr_vector を含むクラスが初期化されるときに 1 回だけです。

ベクトルをコピーすることはありません。

ベクトルからオブジェクトを追加したり削除したりしませんが、次のように ptr_vector の要素に対して setCoords 関数を呼び出します。

私の問題は、ptr_vector を含むクラスが破棄されたときに断続的にセグメンテーション違反が発生するように見えることです。実行中に多くの異なる要素で setCoords を呼び出したときに、障害が発生する可能性が高くなるようです。

私が受け取るメッセージは次のとおりです。

助けてくれてありがとう、私は以下のgdbバックトレースを貼り付けました：

何千もの小さなオブジェクト (500,000 以上) を作成するアプリケーションがあります。これらのオブジェクトをヒープに割り当てるオブジェクト ファクトリがあります。

私が直面している問題は、これらの小さなオブジェクトを保持するオブジェクトが範囲外 (ドライバー) になると、処理時間の 65% がこれらの小さなオブジェクトの破棄に費やされることです。

map、entries、およびfieldsは抽象基本クラスへのポインターを保持し、各基本クラスには多くの子クラスがあります。

アプリケーション アーキテクチャは次の形式に従います。

アプリケーションのパフォーマンスを向上させるために、いくつかの方法を試しました。

最初に通常のポインタを持つデータ構造を使用し、次にクラスのデストラクタでオブジェクトを明示的に削除しました。

次に、データ構造を使用してみましboost::shared_ptr<>たが、参照カウントがかなりのオーバーヘッドを引き起こし、大きなメリットはないと判断しました。

私が今たどり着いた解決策boost::ptr_containerは、ヒープオブジェクトの所有権を取得し、コンテナが範囲外になると自動的にそれらを破棄することです。このソリューションでは、オブジェクトの破棄にかなりの時間が費やされます。

この間ずっとオブジェクトを破壊するのを防ぐためにできることはありますか?

ブースト ライブラリを以前の 1.54 (svn ソース) から 1.57 (git ソース) に更新しました。同じ ./b2 パラメータを使用しましたが、宛先ディレクトリにはptr_containerライブラリが含まれていません。

複製されたリポジトリのあるディレクトリには、次のパスにある ptr_container ライブラリが正しく含まれています:

次のコマンドでビルドしています。

しかし、成功しませんでした。

編集：

gitからビルドした場合のみ問題が発生するようです。ブースト サイトから zip パッケージをダウンロードすると、宛先ディレクトリに ptr_container が正しく含まれています。

これは、ソース コードを取得するために使用している git コマンドです。

最新のブーストバージョンも入手しようとしましたが、このバージョンはまったく使用できません。./b2 を実行した直後に、次のような奇妙なエラーが表示されます: Buidling boost error: Name clash for '<pstage\lib>boost_system-vc120-mt-1_58.dll'

git リポジトリからブーストを正しく取得してインストールする方法のヒントに感謝します。

Boost Pointer Containerの最初の例では、生のポインターを構造体に追加します。

しかし、push_back再割り当てをトリガーする可能性のある 、またはその他のメンバー関数がプロセス中に例外をスローした場合はどうなるでしょうか? 私の理解では、その場合、特定のオブジェクトのメモリを管理するのは呼び出し元次第ですが、呼び出し元はメモリを管理することを目的とするクラスに生のポインターを渡すため、呼び出し元がそうしない可能性が最も高いです。 t。

では、上記のコード例である種の固有のスマート ポインターを使用してポインターをコンテナーに提供する前にラップし、メモリー リークが発生しないことを確実にする必要はないでしょうか? コンテナーは、このようなスマート ポインターのオーバーロードを提供しますが、それらの使用を強制しません。

それとも、追加操作中にコンテナーが例外をスローすることはなく、常に成功するという議論ですか?

上記の例では、コメント アウトされた行は、コピーできない の要素をコピーしようとするため、コンパイルされませんptr_deque。ただし、push_backフォームは機能します。

私はそれoperator [] (K const &)が単にreturn emplace(k, mapped_type()).first->secondorであると考えていましたがreturn insert(value_type(k, mapped_type())).first->second、これは本質的にコメントアウトされたステートメントです

どうやらそうではないようです。内部で魔法operator []を実行しますか？placement new

それとも何か特別なことがありptr_dequeますか？

私はgcc-6.1とブースト1.59を使用しています