問題タブ [intrusive-containers]

For questions regarding programming in ECMAScript (JavaScript/JS) and its various dialects/implementations (excluding ActionScript). Note JavaScript is NOT the same as Java! Please include all relevant tags on your question; e.g., [node.js], [jquery], [json], [reactjs], [angular], [ember.js], [vue.js], [typescript], [svelte], etc.

0 投票する
2 に答える
4029 参照

c++ - Boost.Intrusive と unordered_map

邪魔な unordered_map を使用しようとしています。何らかの理由で、ライブラリには unordered_set しかありません。侵入型のハッシュテーブルもありますが、同じ機能を持っているかどうかはわかりません。また、同じインターフェースもありません。
私は間違っていて、unordered_map リンクを見逃しましたか?
そうでない場合、実装に役立つチュートリアルはありますか?

0 投票する
3 に答える
1660 参照

c++ - Boost Intrusive List フック

Boost::Intrusive ライブラリのベース フックとメンバー フックの違いは何ですか?

ブーストのドキュメントを読みましたが、それほど説明的ではありません。

0 投票する
6 に答える
1788 参照

c# - C#で侵入型ツリークラスにジェネリックを使用させる方法は?

C#では、次のような侵入型のツリー構造があります。

ツリーに追加できるさまざまなオブジェクトは、子を持つことができるかどうかに応じて、Nodeまたは子を継承します。Container

内部クラスを作成することにより、コンテナの子のリストを管理するためにContainerのプライベートメンバーにアクセスできることを意味します。Node

これはすべてうまくいっています。しかし今、私はそれをジェネリックにして、型の安全性を維持しながら再利用できるようにしたいと思っています。基本的に、すべてのツリー機能をNodeの上のジェネリッククラスに移動し、NodeとContainerの間の別のクラスに移動します。これが私がやろうとしていることの大まかなデザインです:

GenericContainerもちろん、継承元を作成できないため、これは機能しませんNode(コンパイラエラーCS0689)。内部クラスの要件を削除しても(たとえば、internal自分のライブラリを使用して注意するだけで)、同じ問題(およびエラー)が発生しない設計を理解することはできません。

(私はそうしなければならないとは思いませんでしたが、それを詳しく説明します。コンパイルエラーを「修正」しようとはしていません。また、単純なツリー実装を探していません。これはコンテナ設計の質問です。)

そして今、私は少し困惑しています。誰かがこれをどのように設計するかについてもっと良いアイデアを持っていますか?

編集:クラスを継承階層に「注入」する問題を回避するために拡張メソッドを使用しようとする、設計のもう1つの方法であるこの回答を必ず確認してください(ただし、残念ながら完全には機能しません)。

0 投票する
1 に答える
789 参照

c++ - unique_ptrs の押し付けがましいリスト?

高度にマルチスレッド化されたプログラムがあり、侵入型のオブジェクトのリンク リストが含まれています。このリスト内のオブジェクトを複数のスレッドに渡す必要がありますが、一度にオブジェクトを所有するスレッドは 1 つだけです。つまり、このオブジェクトまたはそのポインターを共有する必要はありません。

ブーストを使用してunique_ptrを使用して侵入型リストを作成したかったのですが、読んだところ、unique_ptrは適切な所有権セマンティクスを持たないため、Boost侵入型ライブラリと互換性がありません。

これにより、侵入型ライブラリでは、その要素 (ポインター) が生のポインターと同じ所有権セマンティクスを持つ必要があります。したがって、unique_ptr や shared_ptr でさえ資格がありません。

邪魔なリストを最適に実装する方法について、誰かがアドバイスをくれないかと思ったので、その要素を複数のスレッドに安全に渡し、それらがそのスレッドに移動され、スレッド間で共有されていないことを知ることができますか?

0 投票する
3 に答える
1825 参照

c++ - C++ CRTP およびベースからの派生のネストされた typedef へのアクセス

編集:興味のある人のためにデザインの変更が完了したら、ここに github リンクを配置します。

バックグラウンド

boost::intrusive, , を独自の実装に置き換えます。これはintrusive_set、64 ビットでコンパイルされた侵入セットがコンテナー ノードに 3 x 8 バイトのポインターを詰め込むためです。私のコンテナーには 2^16 ノードの制限があるため、2x 16 ビットのオフセット序数 (サイズの 6 倍の縮小) を使用して、ノードあたり 4 バイトまで下げることができます。

以下の例baseは、侵入セット コンテナーです。derivedクラスにはstd::vector<container_entry_type<entry_type> >. 明らかに、このレベルの間接化では、ネストされた typedef を派生に含める必要があります。これをベースで参照したいと思います。

ps、コンテナーはデータ記述言語の AST 用です。したがって、含まれる要素は小さなデータ型であり、3 x 8 バイトは非常に重要です。コンテナーはタイトなループでデータセットを検証するために使用されるため、特にそうです。

分離された問題

次のセマンティクスを実現したい:

しかし、ネストされた typedef にベースからアクセスできません。この問題について、clang は次のように述べています。

代わりに、私はしなければなりません:

これが私のユースケースを達成する唯一の方法ですか? 物事がずっと冗長になるだけです。派生は、いくつかのキーストロークを節約するために特性から派生することもできると思います。

もう 1 つの選択肢は、派生を使用せず、現在派生されているものにロジックを直接接続することです。ただし、個別にテストベースを単体テストしたいと思います。

0 投票する
2 に答える
7676 参照

c++ - C ++ STLコンテナは例外なく使用できませんが、これについて何ができますか?

C ++の想定される精神は、「使用するもの、支払うもの」です。ただし、これは、STLでの例外とその普及により、非常に衰弱させる可能性があります。

誰かが「例外をオンにするだけ」と言う前に、私たちが住まなければならないプログラミング環境では人生はそれほど寛大ではありません。私のものは、実行環境がスタックをほどくのに十分なC++ランタイムを提供しないカーネルプログラミングです。

STLコンテナは、基盤となるバッキングストアにストレージを再割り当てできない場合、割り当て失敗の例外をスローします。環境で例外が有効になっていない場合、プログラムはかなり不思議なことにクラッシュします。実装がまっすぐに中止されるのを見たことがあるか、割り当てが機能しなかったとしても機能すると想定しています。

私が遭遇した多くのCADTライブラリは、エラーコードを返すか、出力パラメータとしてエラーを使用することで、この問題に事前に対処しています。

この問題に対処するための「最良の」C++の方法は何ですか?

明確にするために

標準ライブラリは使いたくない、使えない。私は「できないことをどうやってやるのか」とは問いません。私は尋ねています:「きれいな状態で、コンテナライブラリをどのように構築する必要がありますか?」

0 投票する
1 に答える
742 参照

c++ - C++11モードのGCCで1.48で壊れた押し付けがましいunordered_setをブースト

GCC4.7とBoost1.48に付属するFedora17のバニラインストールを実行し、C ++ 11モードを使用すると、BoostIntrusiveのunordered_setが壊れます。GCC4.6.2とBoost1.47が付属しているFedora16では、動作します。これは実際のコードを壊し、公式ドキュメントの例さえも壊します:

エラーメッセージ:

/usr/include/boost/intrusive/hashtable.hpp:227:65:エラー:削除された関数の使用'constexpr boost :: intrusive :: detail ::bucket_traits_impl> :: type> ::bucket_traits_impl(const boost :: intrusive: :detail ::bucket_traits_impl> :: type>&)'</ p>

/usr/include/boost/intrusive/hashtable.hpp:30:0、/usr/include/boost/intrusive/unordered_set.hpp:18、t.cpp:23からインクルードされたファイル:

/usr/include/boost/intrusive/detail/hashtable_node.hpp:80:8:注:'constexpr boost :: intrusive :: detail ::bucket_traits_impl> :: type> ::bucket_traits_impl(const boost :: intrusive :: detail ::bucket_traits_impl> :: type>&)'は、' boost :: intrusive :: detail ::bucket_traits_impl> :: type>'がムーブコンストラクターまたはムーブ代入演算子を宣言しているため、暗黙的に削除済みとして宣言されます

これが参照するコード、hashtable.hpp:227です。

Boost 1.47では、これは次のとおりです。

BOOST_FWD_REF(TYPE)私のシステムではTYPE &&デフォルトで定義されていますが、定義されている場合BOOST_NO_RVALUE_REFERENCESはになりconst TYPE &ます。そして、私がそれをそのように定義すると、コードはコンパイルされます!

これがなぜであるかについて何か考えはありますか?それはGCCのせいですか、Boostのせいですか、Fedoraのせいですか、それとも私のせいですか?

0 投票する
2 に答える
1205 参照

c++ - 常に侵入的なリストでBOOST_FOREACHを使用する

BOOST_FOREACHマクロを使用して侵入リストを反復処理するには、次のコードを検討してください。

Boostバージョン1.48を指定すると、コードはclang 3.2(SVN)およびgcc 4.6.3で失敗しますが、gcc4.5.3では機能します。コードxsへの非const修飾パラメーターを使用すると機能します。iterateC ++ 11を有効にすると、すべてのコンパイラがコードを受け入れます。boost-1.46を使用する場合、両方のgccバージョンがコードを受け入れますが、clangはまだ受け入れません。

手元のコードはマクロの誤用BOOST_FOREACHですか、それともブースト側のエラーですか?通常のforループでの反復よりも優れた回避策はありますか?

編集: GCCclangのエラーメッセージをpastebin(どちらも非常に冗長です)に貼り付けました。

0 投票する
1 に答える
253 参照

c++ - Boost::Intrusive での splay_multiset のメンバー フックの実装

ビジュアル C++ 2008 で自分のプロジェクトの 1 つに boost::intrusive を実装していたところ、問題が発生しました。splay_multiset コンテナーに splay フックを使用しています。MyClass の下でスプレイ フックをパブリックに定義しました (以下のコード)。

問題は、splay_multiset を使用することです。どのオプションを選択しても (オプション 1 または 2 のいずれか、コードで言及)、どちらの場合もコンパイル エラーが表示されます。

オプション 1 が有効になっている場合 (オプション 2 がコメント化されている場合)、以下のエラーが表示されます。

一方、オプション 2 が有効になっている (オプション 1 がコメント化されている) 場合、これらのエラーはオプション 1 で発生するため、宣言されていない識別子エラー メッセージは表示されません。しかし、以下のようなエラーが表示されます (明らかです)。

私の質問は、なぜ最初のケースでエラーが発生するのですか? この問題を解決するにはどうすればよいですか?

0 投票する
3 に答える
937 参照

c++ - 侵入型リンクリストを使用したC++循環依存

私はこの邪魔なリンクリストを実装しました:

次のように使用できます。

相互のリストを含む2つのオブジェクトが必要になるまで、問題なく機能します。

各MyEntry1はMyEntry2のリストを保持し、各MyEntry2は1つのMyEntry1のリストにのみ表示できます。とその逆。ただし、MyEntry2が定義される前にメンバーポインタ&MyEntry2 :: nodeが取得されるため、これはコンパイルされません。

この問題のあるレイアウトには実際には実用的なセマンティクスはありません。一般的なリンクリストの使いやすさを制限する可能性があるのは、私が見つけた理論上の問題にすぎません。

リストをかなり非現実的にしない方法はありますか?

編集:ここでのすべてのデータ構造のレイアウトは完全に定義されています。これは、LinkedListのデータメンバーが問題のあるNodeMemberテンプレートパラメーターに依存していないためです。関数だけが行います。問題は、その時点で実際に認識されている必要はないにもかかわらず、言語が&MyEntry2::nodeを認識していることを要求していることのようです。

編集:この汎用リストを使用して、構造を2つ以上のリストに追加できる必要があります。これがNodeMemberテンプレートパラメータの目的です。エントリ内のどのLinkedListNodeを使用するかを指定します。