STLは'標準C++'の規格の一部です。標準C++に準拠した処理系であれば、
どのコンパイラであっても使えます。Visual C++'だけ'であるMFCとは大違いです。

Windows/VC++に限定されている場合、どちらを使っても構わないでしょうが、
シリアライズが絡まないかぎり、僕はMFCコレクションを使いません。

ＶＣで組んだプログラムを他のコンパイラでも共有するなんてことは一般の人はやらないですよ
ね。
ＭＦＣ、ＳＴＬのどちらが自分にとって使いやすいかということではないでしょうか。
ちなみに　私は処理に高速性を重視する場合、CArreyと同じＩ／Ｆをもつ自作の配列クラスを
愛用しています。

> ＶＣで組んだプログラムを他のコンパイラでも共有するなんてことは
> 一般の人はやらないですよね。

...そうでしょうか。汎用のライブラリを組むとなると、
処理系依存なコードは極力排除しておくが吉と考えます。

> ＭＦＣ、ＳＴＬのどちらが自分にとって使いやすいかということではないでしょうか。

同意します。要は'慣れ'あるいは'好み'の問題でしょうが。
とはいえMFC-collectionのメソッドの直交性のなさには閉口します。だから嫌い。

επιστημηさん、ご返事ありがとうございます。

なるほど、STLはC++の標準なのですね。

主な利点は、全くWindows/MFCに依存しないコードでSTLを使用していれば、C++環境の存在す
る他のプラットフォーム(UNIX等)にもそのまま移植できるという感じでしょうか。

自分の周りでは、Windows系の他に、UNIX系の仕事があるのですが、それらはいまだにＣ言語
のみでプログラミングするものばかりです。
(様々なスキルの人が作業可能であるようにするためみたい．．．)

そして、各種データのコレクションは、独自の関数を使用して行ってます。
(色々なテーブルのアドレスを void* にキャストして、その配列を管理)

上記みたいなことをしているとこで、C++ & STL が導入できれば、効率がかなり高まりそうで
すね。

みなさん、ありがとうございました。

もう解決にチェック入っていますが、個人的見解を述べさせて頂きます。

STLは、可搬性が高く、洗練されていると思います。
iteratorやalgorithm関連のものをうまく使うと、余計なコーディングをしなくて済み、
肝心の部分のコーディングに集中できます。
他にも洗練されていると思う部分はいろいろ・・・

ただし、VC++でSTLを使う場合、MSDNの解説が素晴らしく不親切なので
使えるようになるまでに色々苦労します。
それこそSTL標準講座(笑)等の分厚い本を一冊買って勉強するくらいの覚悟が
必要ではないかと思います。

MFC（のコレクションクラス）は、C言語のライブラリとの親和性が高いと思います。
例えば、
void GetHogeData(int[] buffer, int count);
というC言語の関数があったとします。
bufferにint型の配列の先頭へのポインタ、countにその配列の要素数を渡すと
何がしかのデータが配列に格納されて返ってくるものとします。

何かの都合でこのような関数を使わなくてはいけない場合（たぶんよくあることです）
STLはこういうのが（たぶん）苦手ですがMFCのコレクションクラスでは簡単にすみます。

で、最後に私がどうしているかですが、
私はWin32SDKとの付き合いが多いです。でもってWin32SDKのインターフェースは
基本的にはCです。
よって、
STLを使うとWin32SDKとのすり合わせに四苦八苦する
→MFCを使う
→MFCとSTLが混在するとややこしくなるので、Win32SDKに依存していない部分もSTLでは
なくMFCを使う
→結局全部MFC

というパターンが多いです。

> 例えば、
> void GetHogeData(int[] buffer, int count);
> というC言語の関数があったとします。
> bufferにint型の配列の先頭へのポインタ、countにその配列の要素数を渡すと
> 何がしかのデータが配列に格納されて返ってくるものとします。
> 何かの都合でこのような関数を使わなくてはいけない場合（たぶんよくあることです）
> STLはこういうのが（たぶん）苦手ですが...

vectorなら何の問題もありませんです。

> vectorなら何の問題もありませんです。

どういう風にすればいんでしょうか？

# GetHogeData(v.begin(), v.size()); とかやっていいんかな？

GetHogeData(&v[0], v.size());

とか，

GetHogeData(&*v.begin(), v.size());

とかになります。

vectorの反復子がポインタとは限らないので。

＃VC++.NETがそう。

YuO さんありがとうございます。

> vectorの反復子がポインタとは限らないので。

御意。さすがにあれはまずいだろうとは思ってました。

> GetHogeData(&v[0], v.size());
> GetHogeData(&*v.begin(), v.size());

なるほど。でも、どーも気色悪くて。
調べてみたら vector の場合は合法みたいですね。

http://www.ascii.co.jp/books/detail/4-7561/4-7561-3715-6.html
http://www.pearsoned.co.jp/washo/software/wa_soft07-j.html
この辺の本にそういう方法が載ってるようで。(とある方の日記からの情報)

# 一冊本を買わないと駄目ですね。勉強不足だわ。

おお、なるほど、&v[0] 又は &*v.begin() で配列の先頭へのポインタが取れるんですねー。
これって公式な方法なんですよね。この方法は思いつきませんでした。
どうもありがとうございます。

ということは、
GetHogeString(char* buffer, int size)
というような文字列取得関数も、
-----
string str;
GetHogeString(&str[0], str.size());
-----
という形で使えるんですねー。

でもこのコードはSTLにある程度以上精通している人でないと理解できそうにないですね。
そこがちょっとネックになりそうです。

STLとMFCのコレクションクラスの違いは上級者向けと初級者向けかもしれませんね。
使いこなせば開発効率がかなり上がるSTLと、
簡単に使いこなせるけれど開発効率の上がり方に限界があるMFCコレクションクラス。

でもこれでSTLの最大の課題（だと思っていたもの）がクリアできました。
これでコンテナ周りはMFCではなくSTLという選択肢も選べるようになりました。
（私はこのトピックの質問者ではありませんが）教えていただきどうもありがとうございまし
た。

以下、トピックのタイトルから離れて来ていますが雑感です。

以下、VC++でSTLを使う上でネックになっていると思っている点です。
・MSDNのSTLの解説がタコ
・MFCとSTLが混在すると保守が面倒（両方を知っている人でないと保守できない）
→なんとかならないもんですかね。
・MFCのGUI周りのクラスのインターフェースにCStringを使ったものが
多数あるので、std::stringを使うのは難しい。
CWnd::GetWindowText(std::string& str); なんて関数があればなぁ・・・。
・同じようにiostream周りもGUI周りのクラスのインターフェースに使われているので
iostream周りはC++標準ライブラリで！というのは難しい。

なんとかならないものですかねー。
「MicroSoftさん頑張って下さい」というようなものがほとんどですが。(^^;

# 部分に反応

> MSDNのSTLの解説がタコ
これは和訳がヘタなのね。英文の方がまだマシです。

> MFCのGUI周りのクラスのインターフェースにCStringを使ったものが
> 多数あるので、std::stringを使うのは難しい。
>...

MFCは昔々からあって、歴史的経緯からコンパチビリティを
重視しているので、MFCより後発のSTL(標準C++ライブラリ)
に歩み寄るのはちと困難なのかも。

みなさん、こんにちは。
知らぬ間に、たくさんの方が書き込みされていて、おどろきました。

> MSDNのSTLの解説がタコ

STLに限らずMFC関連の解説は、かなり分かりずらかったり、あいまいだったりで、何とかして
もらいたいです。
SDKの方は、かなり分かりやすいですけど．．．

VCがインストールされてるフォルダ以下を、vectorでファイル検索すると、STLのソースコ
ードが見つかるので、MSDNを見ても解決できないときは、そこを解析すれば何とかなるとは思
います。

STLの件、それでもわかんなかったら cppll へいらっさいまし。
# 手前味噌御免 ^^;