STLに頼ろうって時点で終わってるね。
「STL本体に慣れる事に全身全霊」
もっと違う事に全身全霊しなせい。

> で、大して性能差が無いんやったら、ディンカムウェア製に
> 乗り換えようかな～ って考えてるんです。

性能を気にするのであれば，出来上がったものに対してprofileして比較すべきです。

επιστημηさんの書かれた記事は，あくまで記事を書いた環境において，
STL-portのSTLの方がdinkumwareのSTLに比べて速かった，ということであって，
常にSTL-portのSTLの方がdinkumwareのSTLより速い，
と結論付けることのできる記事ではありません。

> 何故ビルドを渋っているのか言うと、今度１０人でやる開発に
> STLを使うためです。全員STL初体験なので、なるべく
> 手間とトラブルを避けたいからなんです。

それであれば，付属のSTLで十分でしょう。
ビルドを渋るくらいなら，最初から付属している物を使えばよいわけで。
＃hashなどの非標準機能を使う場合は別ですが。

YuOさん、ご意見ありがとうっす！

>性能を気にするのであれば，出来上がったものに対してprofileして比較すべきです。
それをいっちゃみもふたもない。そんな事は誰でもご存知よん。
が そんな事してる時間が無いケースは 実務で現実に起こるじゃーないっすか。
だから自分で調べつつ みなさんの博識さで補完させてもらおうってんでぃ！

>επιστημηさんの書かれた記事は，あくまで記事を書いた環境において．．．
これまたあたりきしゃりきですねぇ！理由は同上！
ちょっとだけ補足すると、この記事の内容って環境がパフォーマンスに対して支配的に
なるとは思えないよ。何故かって？それはね、うふふ。
それにエピさんの記事に依存したんは、彼の解説には誰よりも筋が通ってるからでっすー。
->裏を取った解説って事っすよ。
んでなきゃ、企業のホームページに堂々と技術解説なんてできないっしょ？ね？

>ビルドを渋るくらいなら，最初から付属している物を使えばよいわけで。
あっしはむしろSTLportやBoostをつかいたいんだぎゃ！
同僚のためを思って 手間をかけないようにしてるんですぎゃあ！

あとねー。他のレスでよく見るんだけど、注意するだけのレスってやめた方がいいと
思いますよん。だって無意味なのがはっきりしてるんだもん！
効果がない事に投資すんのは．．．やめとこ、僕がそうなってどうすんだよ！
ごめんなさいね、余計なお世話で。あと、僕の文章って！が多いね！ばかみたい。
（つーか、ばかなんだけど）

問題児のあっしですが、ずーずーしくも、まだ意見を伺いたく存知マッス。
みなさん、どうぞ宜しくお願い申し上げます。ぺこぺこ。

意見を聞きたいのかどうかよく分からない姿勢ですな。

>意見を聞きたいのかどうかよく分からない姿勢ですな。
聞きたい！聞きたい！聞きたいですー。

同僚に「おまえ、前頭葉やられてんじゃねえの？」と言われました。
そ、そうかな？ あっ、ひょっとしてレクターの野郎に．．．
って、そんな事どうでもよいわっ！

えー、気を取り直しまして、是非伺いとうございます。

速度が気になるのならSTLを使うなといってみたり。
>それにエピさんの記事に依存したんは、彼の解説には誰よりも筋が通ってるからでっすー。
>->裏を取った解説って事っすよ。
>んでなきゃ、企業のホームページに堂々と技術解説なんてできないっしょ？ね？
どうどうとやる方もいたりして(ｗ
STLの話には過剰に反応する方ですから。

> VC++に標準搭載されているSTL(ディンカムウェア製)って、
> 使えますか？

使えますとも。

> 僕はSTLportを使い続けています。下のURLの中身を読んで、
> 実行速度が最も速いだろう、と思ったんです。

hash_xxx については概ね STLport が良好な成績でした。
が、使用頻度の大きい vector/string/stream については
調査していません。 hash_xxx はどちらかと言うとrare-case
ではないかと考えます。標準ではありませんし。

> あと、ディンカム版は、DEBUG_NEWマクロに関する事などの
> 細かい事を相手してやらんとならんかった事も敬遠した理由ですね。

え? それは MFC の問題では?

> がBoostにしろSTLportにしろ、自分でライブラリをビルドする
> 必要がありますよね。
> ...
> 何故ビルドを渋っているのか言うと、今度１０人でやる開発に
> STLを使うためです。全員STL初体験なので、なるべく
> 手間とトラブルを避けたいからなんです。

誰かひとりがライブラリこさえてみんなにバラ撒けば、大きな
トラブルはないと思うのですが…

> どうどうとやる方もいたりして(ｗ
> STLの話には過剰に反応する方ですから。

あー、つまり僕の事なのかな? 別に構わんが。

> 速度が気になるのならSTLを使うなといってみたり。

速度が気になるからSTLを使うのだと思うが・・・
そんな話をしても仕方がないな、まあよい。

で、私個人的の話をすると、個人的なものはSTLportを使って、
仕事ではVC付属のをそのまま使ってます。

個人的にSTLportを使ってる理由は、『ただなんとなく』です。
特に大きな理由はありません。

仕事でVC付属のを使ってる理由は、
引継ぎとかどうしてもあるんで、そのときの環境まわりの
問題を少しでも少なくしたいからです。

なんか、所々気になるところはありますが、慣れの問題だと思いますし、問題なく使えます。
やっぱりソースだけポンと渡して、違う環境ですぐコンパイルできるのは強いです。

補足。

>> VC++に標準搭載されているSTL(ディンカムウェア製)って、
>> 使えますか？
> 使えますとも。

VC6の場合、Dinkumware-OEM には少なからず問題あり。
http://www.dinkumware.com/vc_fixes.html
ここにあるパッチを当てておくが吉。

>速度が気になるのならSTLを使うなといってみたり。
確かに自前実装の方が速い事もありました。でも捨てました。
「まあ、今回はたまたま自前コードが速かっただけさ。」って感じで。
”総合得点”で選ぶならＳＴＬがお買い得っしょ。

>使えますとも。
やっぱり。よーし使ってみよ。つーか使ってます。

>え? それは MFC の問題では?
そうでーす。ＶＣ＋＋６でＤｅｂｕｇビルドをする時は、ＳＴＬヘッダを＃ｉｎｃｌｕｄｅ
する前に ＃ｕｎｄｅｆ ｎｅｗ をしてやる。で、直後にDEBUG_NEWを再定義してやる。
でないと文法エラー。ＶＣ＋＋７以降では解決されたよー。うれぴー。

>誰かひとりがライブラリこさえてみんなにバラ撒けば、大きな
>トラブルはないと思うのですが…
確かにそうなんですけど、それをやる必要があるのかな？という疑問があったんです。
やらずとも同効果が出るのであればそれでいいと。
で、みなさんの意見と自身の実験結果から結論を出そうと思ったんでーす。

>個人的にSTLportを使ってる理由は、『ただなんとなく』です。
僕が使う理由は、ＶＣ＋＋６時代のディンカムＳＴＬでは コーディングで余計な気を
使わないとすんなりソースを食ってくれなかったからです。その経緯で今でも使ってる
って感じっす。
でも中身を見るとＳＴＬｐｏｒｔに比べ 凄く厳密に実装されています。そこは好感が
もてますね。

>引継ぎとかどうしてもあるんで、そのときの環境まわりの
>問題を少しでも少なくしたいからです。
そーなんですよねー。つまらない問題でも会社にとっては嫌ですもんね。

>なんか、所々気になるところはありますが、慣れの問題だと思いますし、
そーなんですよねー。仕様の厳密さは大歓迎だけど、すぐに文法エラーが出ますからねぇ。
ま、しゃーないかな？

>やっぱりソースだけポンと渡して、違う環境ですぐコンパイルできるのは強いです。
そのとおし！

>補足。
情報ありがとうございまーす。僕はVC++7.1なのですが、プロージャー氏のサポートに対する
考え方を 垣間見る事ができました。こういう人が作った物なら大丈夫かな、と。

ってーことで閉めにさせて貰いマンモス。みなさん、どうもありがとう！

いけてない説もありました。↓
http://www.nantekotta.com/stl.html

↑その方が問い合わせたためかどうか知らんが、VC7 では NULL を返すか例外を投げる
かが選択できるようになってますな。

> でも中身を見るとＳＴＬｐｏｒｔに比べ 凄く厳密に実装されています。
> そこは好感がもてますね。

どこらへんが、ですか?