問題タブ [boost-range]

これは、フィルター処理された反復子で私が抱えている問題の単純化されたバージョンです (したがって、フィルターを回避するために別の方法で書き直すように依頼しても意味がありません)。奇妙なことに、実際のコードでis_sortedは問題があるように見えますが、他の用途では問題なく動作するようです。

これは、Clang++ 3.5 と G++ 4.9 の両方でコンパイルに失敗します (Mac OS X では最新):

ラムダを修正に保存することは知っていstd::functionますが、その代償を払いたくありません。カスタム ラッパーを使用してstd::is_sortedも問題は解決しません。この問題は他の問題 (ブースト変換イテレータや c++11 lambdaなど) に関連しているように見えますが、そうではありません。少なくとも、それらの解決策はここには当てはまりません。

ありがとう！

I've written a convenient functor wrapper for tuple std::get. When using it with boost transformed and operator[], I get warning that I'm returning reference to local temporary object. My system: ubuntu 14.04, compilers: clang-3.5 and g++-4.8.2, boost version: 1.56.

Warning details:

Adding flag -Wreturn-stack-address is not a solution since it's dangerous in bigger projects.

I noticed that deleting const keyword gets rid of warning but I don't know why and don't want to assume that functor gets only non-const ranges.

Questions: how to fix code to get rid of warning? Why deleting const gets rid of warning?

関数によって返された範囲を 1 つの大きな範囲に連結したいと考えています。次のコードを検討してください。

私が達成しようとしていること:
aaa ベクトルは巨大で、 foo は非常に大きな範囲を返す可能性があります。もちろん、範囲内のすべての要素のコピーを新しい整数のベクトルに作成して返すこともできます。非効率的で、メモリと時間を浪費します。したがって、boost::joined_range を 1 つ返したいと思います。最悪の場合、範囲のベクトルを使用できますが、単純すぎてエレガントではありません:) Joined_range がデフォルトで構築可能ではないことに加えて (この実装例では問題になります)、戻り値の型は何でしょうか? 一時変数 (ccc) 型と、上記を達成するための正しくエレガントな方法は何でしょうか?

equal_range によって照会され、range::join および boost::any_range を使用して関数から結果が返されるブースト multi_index_container を使用してい
ます、参照についてはよくわかりません。例：

今私が必要としているのは、boost::sort、unique などの範囲変更アルゴリズムを使用することです。これは、範囲内の要素の constness のために明らかに範囲で実行できません。
要素を新しいコンテナにコピーする以外の回避策はありますか?

編集 1:
構造体と MIC の例:

これは、この MICの質問に対するフォローアップの質問です。参照ラッパーのベクトルにアイテムを追加するとき、選択した反復アプローチに関係なく、約 80% の時間を ++ 演算子内で費やします。
クエリは次のように機能します

参照ラッパーを埋めるために次の方法を試しました

何をするにしても、演算子 ++ またはイテレータをインクリメントするだけの size メソッドの料金を支払います。つまり、まだ ++ で立ち往生しています。したがって、問題は、結果の範囲をより速く反復する方法があるかどうかです。そのような方法がない場合は、範囲を作成する代わりに結果で満たされる reference_wrapper のコンテナへの参照を保持する新しい引数を追加する equal_range の実​​装を試す価値がありますか?

編集 1: サンプル コード http://coliru.stacked-crooked.com/a/8b82857d302e4a06/
このバグのため、Coliru ではコンパイルされません
編集 2: コール ツリー、演算子 ++ で費やされた時間
編集 3: いくつかの具体的なもの。まず第一に、operator++ が全体の実行時間に時間がかかりすぎるという理由だけでこのスレッドを開始しませんでした。単に「という理由で」好きではありませんが、現時点ではパフォーマンス テストの主要なボトルネックになっています。通常、各リクエストは数百マイクロ秒で処理されますが、これと同様のリクエスト (やや複雑です) は 1000 ～ 1500 マイクロ秒で処理され、それでも許容されます。元々の問題は、データ構造の項目数が数十万に達すると、パフォーマンスが 20 ミリ秒程度に低下することでした。MIC に切り替えた後 (コードの可読性、保守性、および全体的なエレガンスが大幅に改善されました)、リクエストごとに 13 ミリ秒程度に達することができ、そのうち 80% ～ 90% が operator++ に費やされました。これをどうにかして改善できるかどうか、それともタールと羽毛を探すべきかという質問です。:)

以下は、Visual Studio 2010 でコンパイルされません。

コンパイラは不平を言います（エラーメッセージはもともとドイツ語で、私の翻訳です）：

Boost 1.57 を使用しています。

明らかに間違ったテンプレート パラメータ値でoperator |を構築しようとしていますか?strided_rangeCategory

これはバグですか、それとも何か間違っていますか?

Streams ライブラリmapには、メンバー関数によって範囲を表示するためのきちんとした関数があります。Range-V3に同等のビューはありますか?

view::transform唯一のオプションでしょうか？