問題タブ [stl]

おおよそ次のコードがあります。これをより良く、またはより効率的にすることはできますか? おそらく使用していstd::remove_ifますか？移動中にマップからアイテムを削除できますか? 一時的な地図の使用を避けることはできますか?

どうやら ;-) 標準コンテナは、何らかの保証を提供します。

どのような種類の保証があり、さまざまな種類のコンテナーの違いは正確には何ですか?

SGIページ（STLについて）から作業して、私はこれを思いつきました：

STL検索アルゴリズム（およびmin_elementアルゴリズム）を使用して、ベクトル内の最小値の位置を見つけようとしていますが、位置を返す代わりに、値を与えるだけです。たとえば、最小値がそれである場合、位置は 8 などとして返されます。ここで何が間違っていますか?

Google C++ スタイル ガイドの演算子のオーバーロードに関するセクションでは、演算子をオーバーロードしないことを推奨しています (「まれな特殊な状況を除く」)。具体的には、次のことを推奨しています。

特に、 クラスを STL コンテナーのキーとして使用できるようにするためだけにオーバーロードしoperator==ないでください。operator<代わりに、コンテナーを宣言するときに等値ファンクターと比較ファンクターの型を作成する必要があります。

そのようなファンクターがどのように見えるかについては少し曖昧ですが、私の主な質問は、なぜこれのために独自のファンクターを書きたいのですか? を定義operator<して標準std::less<T>関数を使用する方が簡単ではないでしょうか? 一方を他方よりも使用する利点はありますか？

別のコードで 2 番目のものを見たことがありますが、この長さの比較はコードの生産性を高めるために行われたと思います。特定の辞書を持つスクリプト言語のパーサーで使用されました。単語は 4 ～ 24 文字で平均 7 ～ 8 文字で、アルファベットには 26 文字のラテン文字と "@"、"$"、"_" が含まれます。

長さの比較は、STL 文字列を操作する == 演算子をエスケープするために使用されました。これには、単純な整数比較よりも明らかに時間がかかります。しかし同時に、与えられた辞書の最初の文字の分布は単語サイズの分布より単純に広いため、文字列を比較する際の最初の 2 文字は、通常、その文字列のサイズよりも異なることがよくあります。これにより、長さの比較が不要になります。

私はいくつかのテストを実行しましたが、それが私が見つけたものです.2つのランダムな文字列の比較を何百万回もテストしていますが、2番目の方法ははるかに高速であるため、長さの比較が役立つようです. しかし、実際のプロジェクトでは、デバッグ モードではさらに遅くなり、リリース モードでは不十分なほど速くなります。

だから、私の質問は、なぜ長さの比較が比較を速くすることができ、なぜそれを遅くすることができるのですか?

UPD: 私はその 2 番目の方法も好きではありませんが、それには理由があると思います。

UPD2: 真剣に、問題は最善を尽くす方法ではありません。この場合、STL 文字列はもう使用していません。長さの比較が不必要で間違っていることなども不思議ではありません。これはどのように可能ですか？

私は 1 つの std::list<> コンテナーとこれらのスレッドを持っています:

• 要素を無期限に追加する 1 つのライター スレッド。

• 使用可能なときに要素を読み取って削除する 1 つのリーダー/ライター スレッド。

• コンテナーの SIZE にアクセスする複数のリーダー スレッド (size() メソッドを使用)

最初の 2 つのスレッドからリストへのアクセスを保護する通常のミューテックスがあります。私の質問は、サイズ リーダー スレッドもこのミューテックスを取得する必要があるかどうかです。読み取り/書き込みミューテックスを使用する必要がありますか?

Visual C++ 6 を使用する Windows 環境にいます。

更新：答えはまだはっきりしていないようです。主な疑問を要約すると: 正確な値を必要としない (つまり、 +/- 1 変動)? 競合状態により、size() 呼び出しが無効な値 (つまり、適切な値とはまったく関係のない値) を返すようになるのはなぜですか?

回答: 一般に、競合状態を回避するためにリーダー スレッドを保護する必要があります。それにもかかわらず、私の意見では、アップデートで上記の質問のいくつかはまだ答えられていません.

前もって感謝します！

回答ありがとうございます。

Windows と Mac の間でクロスプラットフォームのコードを書いています。

list::end() が「リストの最後の要素に続く位置をアドレス指定する反復子を返し」、リストを順方向にトラバースするときにチェックできる場合、逆方向にトラバースする最良の方法は何ですか?

このコードは Mac では機能しますが、Windows では機能しません (最初の要素を超えて減少することはできません)。

これは Windows で動作します:

forループで実装できる逆方向にトラバースする別の方法はありますか?

通常、次のような STL コードが見つかります。

しかし、実際には次のように記述することをお勧めします。

スコープが心配な場合は、中かっこを追加します。

.end() 関数はループの各反復で呼び出されないため、特にコンソールをプログラミングしている場合は、これにより速度と効率が向上するはずです。私はパフォーマンスの向上を当然のことと考えています。合理的に聞こえますが、どの程度かはわかりません。また、使用しているコンテナーの種類と実際の STL 実装によって異なります。しかし、このスタイルを数か月間使用した今、私はとにかく最初のスタイルよりも実際に気に入っています.

その理由は読みやすさです: for 行はきちんと整頓されています。最初の例のスタイルを使用すると、実際のプロダクション コードで修飾子とメンバー変数を使用すると、非常に長い行を簡単に作成できます。そのため、この例では意図的に水平スクロール バーを表示するようにしました。;)

一方、for ループの外側のスコープに Iter 変数を突然導入します。しかし、少なくとも私が働いている環境では、最初の例でも外側のスコープで Iter にアクセスできたはずです。

これについてどう思いますか？Iter の範囲を制限する可能性以外に、最初のスタイルの長所はありますか?

実稼働システムの構築に Visual Studio 6 をまだ使用しているクライアントがいます。彼らは、STL を使用し、マルチプロセッサ マシン上で実行されるマルチスレッド システムを作成します。

サーバーマシンの仕様を変更したり、負荷を増やしたりすると、エラーを再現するのが「奇妙な」困難になることがあります...

Visual Studio 6 の開発にはいくつかの問題があることを知っています。Visual Studio 2005 または 2008 に移行するよう説得したいと思います (彼らは Visual Studio 2005 を持っていて、いくつかのプロジェクトで使用しています)。

この質問の目的は、既知の問題またはアップグレードする理由のリストと、これらの問題が議論または報告されている場所へのリンクをまとめることです。また、これらの問題がどのようにあなたを悩ませたかについての実際の「ホラーストーリー」があると便利です.

最近、Scott Meyers の『 Effective C++ 』という素晴らしい本を読んでいます。最後のヒントの 1 つで、彼は TR1 の機能のいくつかを取り上げました。私はそれらの多くを Boost で知っていました。

ただし、私がまったく認識していないものがありました: tr1::reference_wrapper.

tr1::reference_wrapper をいつ、どのように使用しますか?