ログインしてさらにmixiを楽しもう

コメントを投稿して情報交換!
更新通知を受け取って、最新情報をゲット!

C言語とC++言語コミュのSTL(c++)

  • mixiチェック
  • このエントリーをはてなブックマークに追加
c++ 使いの皆さん STL(Standard Template Library) をどの程度使っていますか?

コメント(38)

・set
・map
・vector
・string
以外はじぇんじぇん使ったことないのです。

setとmapを愛用中。
僕の使ってた環境ではSTLがありませんでした。くそー○wind○iverぁぁぁー
STLなくては生きていけません。
将来を誓い合った仲です。

でも、いろいろと気に入らない部分も見えてきたので、
boost に浮気しています。
boost ってのがあるんですね。知りませんでした。
STL の standard 性に疑問があったのですが、boost ならポータビリティの問題もないですね。
コンテナ関係は無いとつらいです。
boostはregexくらいです。
STL、Boost どころか FC++ も欲しいというところですが、最近は他の言語のために C を書いているので恩恵を受けられなかったり……

SWIG みたいに C++ を FFI とできるものが一般的になってくれると嬉しいのですが。


麦角さん>

STL には STLport (http://www.stlport.org/) という実装があります。
また、Boost の中には次期標準ライブラリに入れる候補に上がっているライブラリもあります。
 キューやスタックの実装がアホみたいに楽になるコンテナも素敵ですが、algorithmを合わせ技で使うともっと素敵ですね。

 eMbededVisualC++環境での仕事が多いのでeVC4からのSTLサポートはとてもありがたいです。
STL は実は使ったことがありません。やはり便利でしょうか?
便利どころか STL や Boost なしの C++ プログラミングなんて考えられない(し考えたくもない)くらいです。

C++よりCの方が好き (http://mixi.jp/view_bbs.pl?id=53098) というトピックでおぎのさんが答えて言っているように、STL ありとなしでは全然別の言語になります。

C++ 好きという人達は大体 STL や Boost、その先にある template programming のテクニックを使って遥かに便利になったプログラミングをおこなっていますし、STL および標準ライブラリを最初に学ばせるという構成を取っている本もあります。

Accelerated C++
http://www.pearsoned.co.jp/washo/prog/wa_pro51-j.html

Boost の初手としては regex のようなあるべきなのになぜか標準にはないライブラリや algorithm の使い勝手をます lambda や bind、function などを使っていけばいいと思います。
まったく同感です。> shelarcy さん

コンテナクラスなど、便利なツールを使うために
STLを使うというだけではもったいない。
(そういう意味では、regex も同じかな?)

単に型に依存しないという意味だけではない
ジェネリックなプログラミングを体現すれば、
もう抜けられません。

とにかく何はともあれ、bind は必須ですね。
なんで、hash_map は標準で入ってないんでしょうねぇ。
J2ME ですら、Hashtable は標準で入ってるのに...
ベーシックな質問で申し訳ありませんが、STL というのはプラットフォームに依存しないのですか? つまり Visual C++ だろうが GCC だろうが問題なく使用できるのでしょうか?
> なんで、hash_map は標準で入ってないんでしょうねぇ。
どんなオブジェクトでもそこそこ速度の出るハッシュ関数をかけなかったからとか? (^^;;
> だいはど さん

STL って C++ の標準テンプレートライブラリなので、
基本的に、プラットフォームに依存する事はない(ハズ)です。

ただ、もしかしたら細かい所で、処理系依存の部分があるかも
しれないですね...。


閑話休題:
フレームワークをテンプレートライブラリとして
自前で作ったりしてましたが、なんか、こう
違う感じがして、最近はあまりテンプレートから
遠ざかってしまってます。

ジェネリックプログラミングというパラダイムは
素晴らしいと思うのですが、C++ のテンプレート機能が
ベストな解ではないな、と。

ジェネラティブプログラミングとしての
テンプレートは...、もう、C++ のテンプレートに
無理させないで下さい、って感じかなぁ。
# ありゃ、アートというか、技巧というか、ってっ感じ。
# 僕には、無理、かなぁ (^^;;;

C# にもジェネリックプログラミングが入るという話なので、
ちょっと楽しみ :-)
> saito さん

なるほど,ありがとうございます.もうちょっと自分でも勉強してみます.
> ジェネラティブプログラミングとしての
> テンプレートは...、もう、C++ のテンプレートに
> 無理させないで下さい、って感じかなぁ。
めちゃ同感です。
コンパイラの限界に挑戦してどうする? という感じはあります。
(^^;;
> あつし さん
ですよね〜。

ジェネラティブという考え方は、
なかなか面白いと思うので、
もうちょっとスマートに実現できる方法が
あれば良いのですけどね〜。
ええと、無茶な話ですけど Haskell や Scheme 処理系の拡張なんかを見ていると、100% 処理系を使いこなすだけでなく処理系を改造し始めてからが真価のような気がしますが、そう考えるのはよってたかって研究成果をかき集めている GHC のユーザーだからでしょうね。

関数型言語
http://mixi.jp/view_community.pl?id=10453

GHC Language Features
http://www.haskell.org/ghc/docs/latest/html/users_guide/ghc-language-features.html


それはさておき、generative programming の大部分の技術は頭のいい人達に任せておいて、expression template 等のコアになる技術や Boost での研究成果を利用させてもらえばいいと思います。
generic programming というのはもともとは OOP の 1 feature でオーバーローディングを定義するものなので、C++ とかではああいう形になってしまうにはある種の必然性があります。

G'Caml
http://web.yl.is.s.u-tokyo.ac.jp/~ganat/index200310.html

ですから、改善するとすればもっと根本的なところですね。list や lazy list をライブラリではなくプリミティブなものにしてしまえば、文法は数段階変わります。

あとは、そんなに使われていませんが Haskell や Clean で実験的におこなわれている、さらに上を行く試みがありますね。型から型を足し算や掛け算などで算出できるようになれば、多くの似たような定義を省略できるようになります。
(流石にずれてきたと思うので、これ以上は generic & generative programming と処理系の拡張、とかそういうトピックで……)

Generic classes
http://www.haskell.org/ghc/docs/latest/html/users_guide/generic-classes.html

総称プログラミング
http://sky.zero.ad.jp/~zaa54437/programming/clean/LanguageReport21/Chap7.html
valarray と slice の組合せが便利で、手放せなくなってしまいました。ublas あたりも頼っていますが、もうちょい簡単でいいという場合が多いので。Blitz++ の評判がよさそうなのですが、VC++ で動かないらしいので、触ったことがなかったりします (というのは STL と関係ないか)。
VC 7.1 では動くはずでは?
STL 使いなら VC と言えば 7 (.NET) 以降です。さらに進んで Boost などのテンプレート系のライブラリが使いたければ 7.1 (.NET 2003) 以降です。例外は認めません(と言いたい)。
あ、2003だとboostにも対応してたんですか?
正直気付かなかった…。

っていうか、VC++6.0でテンプレート使うと“識別子が長い”
云々の警告が出てウザいです。 (^^;
#pragmaで消せますが…。
仕事の事情で、VC++7.0 (VS2002) なのです。そいつに fix して開発が進んでしまったのと、ライセンスの更新が進んでいないので。7.1 だと、lambda とか使えていい感じなんですけどね。(慣れていないうちはコンパイルエラーにひっかかるとひきつりますが)。
むかーしむかしのトピックですが。。。
> 10: shelarcy さん
の意見に同感です。

個人的には、STL 使うとバグが減ると思っていて、それが最大の利点のような気がしています。(自分で書くコードが減らせるわけですから。STL にバグがあった場合は除きますが(笑))

最近は、あまり触る機会がないんでちょっと古い話ですが、前は関数アダプタとか作ろうと思うと、互換性(mem_fun_refあたり)に泣かされた記憶があります。。。業を煮やして自分で再定義したりとか。。。もうそんなことはないかな?
昔は純粋なC++だけでしたが最近勉強する機会があり
使い始めました。やはり便利ですね。やりすぎると
フットプリントが増大するとかいう問題を
聞くのですが、個人的にはまだそこまで到達してないので
問題は無いですね。ただ、バグが出たときのデバッグに
非常に多くの時間がかかるので嫌です。
まだSTLの場合はコンパイルを通すことすらたまにできないのですが、
STLでコンパイルエラーが出たときはどこをどう直していいのか
正直わからないようなエラーが出力されるので(笑)、
嫌ですな。まだまだSTL初心者でした。
( ´∀`)つSTLFilt
http://www.bdsoft.com/tools/stlfilt.html
STLFilt!
すごい便利なものがあるんですね.
知りませんでした.
しかし,ここまでしないといけないとは・・・(^^;
C++BuilderにSTLFiltを使う時はリソースファイルか何かを
いじって英語版にしてからでないとうまく動かなかったよう
な記憶があります。

gccはバージョン3以降はtemplate周りのエラーメッセージが
かなり抑制・簡素化され、STLFiltはほとんどプリティ・
プリンタとしてしか働かないケースが多いです。

でもわざと難解なエラーメッセージを出させる事は可能で
あり、そういう時はSTLFiltは劇的に効きます^^;

インストールはperlを入れるだけ。もう既にperlのインス
トールをしてある人は、すぐにでも動かせます。
http://www.tietew.jp/cppll/archive/10763
ここら辺に、涼しげになる様子が書かれていますね。
C++Builderももしかしたら日本語のままで動くかもしれません。
ちょっと試してみますわ。
http://www.tietew.jp/cppll/archive/10762
と同じく、Effective STLのヤバげなプログラムをBCC32
(5.6.4)に食わせて見ました。

エラー E2034 const_iter.cpp 14: '_STL::_Rb_tree_iterator<_STL::pair<const _STL::string,_STL::string>,_STL::_Const_traits<_STL::pair<const _STL::string,_STL::string> > >' 型は '_STL::_Rb_tree_iterator<_STL::pair<const _STL::string,_STL::string>,_STL::_Nonconst_traits<_STL::pair<const _STL::string,_STL::string> > >' 型に変換できない(関数 NiftyEmailProgram::showEmailAddress(const _STL::string &) const )
警告 W8057 const_iter.cpp 19: パラメータ 'nickname' は一度も使用されない(関数 NiftyEmailProgram::showEmailAddress(const _STL::string &) const )
*** 1 errors in Compile ***

↑これが↓のように。

エラー E2034 const_iter.cpp 14: 'const_iter' 型は 'iter' 型に変換できない(関数
NiftyEmailProgram::showEmailAddress(const string &) const )
BD Software STL Message Decryptor (Release 2.01 for Borland C++/C++Builder)
警告 W8057 const_iter.cpp 19: パラメータ 'nickname' は一度も使用されない(関数
NiftyEmailProgram::showEmailAddress(const string &) const )
*** 1 errors in Compile ***

これなら誰でも理解できそうですね。日本語版でも動くようです。
3行目にタイトルメッセージが混ざり込んでいるのは、無理矢理
日本語版のエラーメッセージを食わせた副作用?^^;
STL 以外の話題は、できれば C++言語の方で。
http://mixi.jp/view_bbs.pl?id=6984

Windows port の方に既に書き換えたソースが入っているようですね。
Visual Studio .NET 2003 (VC 7.1) (99% or 98.11%? http://www.itmedia.co.jp/enterprise/0308/07/epn04.html) レベルと聞いて想像がつかなければ、どれだけ変な書き換えかそっちを見て判断してください。
2chでstd::setのイテレータはconstにするべきかそうでないか
の議論が少しされていました。

標準ではstd::mapとstd::multimapのキーはconstだけど、
std::setとstd::multisetのキーはconst/非constのどちらで
もいいと言うような事が書かれていました。

で、非constでキーを変更した場合の動作は自分で責任を持つ
ようにと。要するにやっちゃだめなわけです。移植性を重視
するには、constとしてプログラムを書く事がEffective STL
にも書かれています。

ログインすると、残り6件のコメントが見れるよ

mixiユーザー
ログインしてコメントしよう!

C言語とC++言語 更新情報

C言語とC++言語のメンバーはこんなコミュニティにも参加しています

星印の数は、共通して参加しているメンバーが多いほど増えます。

人気コミュニティランキング