問題タブ [stl]

Boost 内で tr1::result_of がよく使われていると聞きます... tr1::result_of の自宅で使用できる良い (単純な) ユースケースがあれば知りたいです。

c_str()とdata()(STL およびその他の実装における)の違いは、c_str()常に null で終了し、そうdata()ではないといういくつかの場所を読みました。私が実際の実装で見た限り、それらは同じことをするか、またはdata()呼び出しますc_str()。

ここで何が欠けていますか？どのシナリオでどちらを使用するのがより正しいですか?

Visual Studio 2003 を使用してビルドされた古いプロジェクトがあり、最近 vs2005 で再コンパイルしました。ただし、実行時に次のエラーが発生します。

リスト反復子はインクリメントできません

プログラムをこの関数までたどりました：

私は C++ の専門家ではありませんが、これは VS デバッガーが得た限りです。誰かが私に何が問題なのか説明してもらえますか?

ありがとう

私は現在、VS2005 の STL のデフォルト実装を使用していますが、あまり満足していません。おそらくもっと良いものがありますか？

次のことがうまくいかない理由を頭に入れようとしています。std :: vectorがあり、それに含まれているvalue_typeの静的メンバー関数を次のように呼び出したいと思います。

ここで、Vectorは実際にはテンプレート化された型のtypedefです。

静的メンバー関数Dim（）は、実際にはVectorの次元Uをインライン化します。

これで、コンパイラは次のようなエラーメッセージを返します。

それは私を困惑させます。明らかに問題のある行を次のように置き換えることができます

それは機能しますが、vのvalue_typeに関する仮定をハードコードしているため、明らかに醜いです...ありがとう！

for eachVisual C++ 2008 (およびおそらく以前のバージョンも?) が反復を容易にするために stl リストなどの構文をサポートしていることを最近発見したばかりです。例えば：

私はそれを発見してとてもうれしく思いましたが、私のコードを gcc やその他のコンパイラでコンパイルできるようにする必要があると誰かが判断した恐ろしい日の移植性について心配しています。この構文は広くサポートされていますか? また、移植性の問題を気にせずに使用できますか?

好奇心が強いという理由だけで、C++ の STL の機能に類似した C 言語はありますか? glib と呼ばれるGTK+ライブラリについての言及を見たことがありますが、これは法案を満たすと考える人もいますが、C で STL 機能を提供する他のライブラリはありますか?

2 つの s を連結するにはどうすればよいstd::vectorですか?

std::pair を使用して、関連する 2 つの数量の論理グループを関数の引数/戻り値として定義することがよくあります。いくつかの例: 行/列、タグ/値など。

多くの場合、std::pair を使用するだけでなく、実際に独自のクラスを展開する必要があります。物事が崩壊し始める時期を確認するのは非常に簡単です。コードが make_pair で散らばり、最初と 2 番目に何が何であるかを思い出すのが非常に難しくなりstd::pair<int, int>ますPosition。

std::pair の機能を真の意味を伝える型にラップする最良の方法は何ですか?

ここに私が考えたいくつかのことがあります：

これにより、少なくとも型を渡すときに意味のある名前が付けられますが、型は強制されず、実際には単なるペアであり、同じ問題のほとんどが依然として存在します。ただし、これは非常に簡単に記述できます。

合理的に説明的な名前を介して変数にアクセスできるため、これは優れています。ここでの問題は、まだ first と second にアクセスできるため、抽象化が簡単に漏れることです。また、関数を介して単純な変数にアクセスすると、構文が面倒になります。

明らかな次のステップは、継承を非公開にすることです。

これで、少なくとも first と second へのアクセスはなくなりましたが、新しい問題が発生します。型を std::set に格納する場合、first と second にアクセスできないため、operator< オーバーロードにアクセスできなくなりました。これは、必要な演算子のオーバーロードごとに転送関数を定義する必要があることを意味します。私にとって、これは通常 ==、!=、および < ですが、他にも必要な場合があります。はい、連想コンテナーに貼り付けるためだけに operator< をオーバーロードするべきではないことはわかっていますが、すべてが非常に単純になります...そして、新しい型ごとにこれらの演算子を定義するのは面倒であり、関数を介してアクセスする必要があります. 我々はそれを修正することができます：

これで変数へのアクセスは簡単になりましたが、オーバーロードされた演算子を定義するのはさらに面倒です。なぜなら、それらをペアの実装に転送するだけでなく、実際に毎回再実装する必要があるからです...

欠点なしでこれを簡単にする、私が見落とした解決策はありますか? そうでない場合、どちらを好む傾向がありますか?

重複の可能性:
現在の C または C++ 標準ドキュメントはどこにありますか?

私が取り組んでいる現在のプログラムで STL を使用したいのですが、ベンダーは私が合理的な STL であると感じているものをサポートしていません。私の解釈が正しいかどうか、またはベンダーの解釈が正しいかどうか疑問に思うだけの API ではない C++ 標準または STL 標準を見つけることができませんでした。私はすでにSGI のサイトで多くの時間を費やしてきました。推奨事項はありますか？また、標準と見なされる API 以外のドキュメントはありますか?