トップページ⇒tech
1001コメント253KB

【C++】STL（Standard Template Library）相談室

■ このスレッドは過去ログ倉庫に格納されています
0001デフォルトの名無しさんNGNG
関連スレなどは>>2以降で
0232デフォルトの名無しさんNGNG
>>231
その話がSTLとどういう関係があるのか？
0233デフォルトの名無しさんNGNG
>>231
キーワードわかってんだからググれば？
0234デフォルトの名無しさんNGNG
1引数ファンクタを0引数ファンクタに落とすクラスは標準にないでしょうか？
2引数を1引数にするにはbind1stとかを使えばいいのですが。
別に自作してもたいした手間ではないのですがなんか・・・
0235デフォルトの名無しさんNGNG
>>234
ない。
0236デフォルトの名無しさんNGNG
自作してもたいした手間ではないものほど標準であって欲しい
0237235NGNG
>>234
ごめん。
クラスね。unary_functionがある。でも、生成関数はない。
0238デフォルトの名無しさんNGNG
非標準ならboost::bind，boost::lambda::bindとかが使えるかな．
あ，でもここSTLスレだった・・・．
0239デフォルトの名無しさんNGNG
unary_functionとbiary_functionの型パラメータは
なんで最後が戻り値の型なんでしょう

最初にあった方が直感的だと思うけど・・・
0240デフォルトの名無しさんNGNG
仕様決めた人間に聞け
0241デフォルトの名無しさんNGNG
>>239
俺もそう思た
確かLokiでは最初に戻値型があったような
0242デフォルトの名無しさんNGNG
センスがなかったんだな。きっと。
0243今度はな、名前が…NGNG
そこでキーワード引数ですよ。
0244デフォルトの名無しさんNGNG
そこで、じゃないだろ
もともと順序性あるのにわざわざキーワードにマップする意味なし
0245デフォルトの名無しさんNGNG
順序性あるか？
たまたまC++の構文がそうなっているだけのような気がするが。
0246デフォルトの名無しさんNGNG
見た目の順序のことを言っているだけだが？
0247デフォルトの名無しさんNGNG
だけだが？
0248デフォルトの名無しさんNGNG
けだが？
0249デフォルトの名無しさんNGNG
だが？
0250デフォルトの名無しさんNGNG
ｶﾞｯ!
0251デフォルトの名無しさんNGNG
const char dakedaga[] = "だけだが？";
for (int i = 0; i < 3; ++i)
  std::cout << dakedaga + 247 + 2 * i << std::endl;
0252デフォルトの名無しさんNGNG
std::vector<int> vecint;
のすべての要素と和はかっこよくかけませんかね？
forで回すのは無しねｗ
0253デフォルトの名無しさんNGNG
int total = std::accumulate(vecint.begin(), vecint.end(), 0);
0254デフォルトの名無しさんNGNG
struct sum
{
　　int m_sum;
　　sum() : m_sum(0) {}
　　void operator()(int n)
　　{
　　　　m_sum += n;
　　}
};
として

{
　　sum s;
　　std::for_each(vecint.begin(), vecint.end(), s);
　　std::cout << "合計:" << s.m_sum;
}

これでどうや？
0255デフォルトの名無しさんNGNG
>>253
>>254
ありがとうございます。
どちらもC++らしいかっこいいとおもいます。
ですが、>>254さんのはちょっと内容が僕にはヘビーなんで>>253さんので以降と思います。

ありがとうございました
0256デフォルトの名無しさんNGNG
一冊でもまともな本を持ってたら
そのまんまの記述が見つかるレベルだぞこれ。
ちゃんと本買ったほうがいいんじゃねえか？
0257デフォルトの名無しさんNGNG
>>255
boostでは無名関数が定義されていますので、こういうこともできますよ
int sum = 0;
std::for_each(data.begin(), data.end(), (sum += boost::lambda::_1) );
0258デフォルトの名無しさんNGNG
>>257 スレ違い。
0259デフォルトの名無しさんNGNG
>>258
確かにスレ違いだけど、STLを使っている人の中にはBOOSTを使う用意の
ある人も多いのではないかと思っている。
そういった人が、STLではこうしているがもっとスマートにはならないだろうか、
と考えた時、BOOSTの中にある選択肢を"たまたま"知らなかったとしたらBOOSTスレ
にそれを聞きに行くだろうか。
知らないものは、聞きにはいかない。
ここでキーワードを教えるくらいは良いと思うけれどね。
0260デフォルトの名無しさんNGNG
てかC++スレ分割しすぎ
0261デフォルトの名無しさんNGNG
>>260
C++は分割して作業しやすいように出来ているからね。
0262デフォルトの名無しさんNGNG
>>257
無名関数ですか、perlっぽいすがまた、激しくｶｺｲｲですね
未だにCﾗｲｸにﾙｰﾌﾟで回す癖が抜けませんｗ
0263デフォルトの名無しさんNGNG
>>262
もともとはLispのlambda式なんだけどね。
BOOSTのlambdaはちょっと違和感があるけれど。。。
0264デフォルトの名無しさんNGNG
>>259
すれ違いで悪いんですが、Delphiでの解決方法教えてください
0265デフォルトの名無しさんNGNG
>>264
257はありだろうけど
さすがにそれはDelphiスレで聞くべきだよ
(本当に知りたければね)
0266デフォルトの名無しさんNGNG
>>259
アホは放置しろ。
0267デフォルトの名無しさんNGNG
そういえば結局、次期標準でBoostから採用されるものって何なんだ？
0268デフォルトの名無しさんNGNG
>>267
ttp://jbbs.livedoor.jp/bbs/read.cgi/computer/5651/1048584601/88
0269デフォルトの名無しさんNGNG
日本語読めないの
0270268NGNG
>>269
ｽﾏﾝ寝てないの
0271デフォルトの名無しさんNGNG
>>267
function, tuple, type_traits, regex, mem_fn, shared_ptr, ref, bind
0272デフォルトの名無しさんNGNG
とりあえずofficial wishlist置いときますね
http://lafstern.org/matt/wishlist.html
0273デフォルトの名無しさんNGNG
STLportにバグが見つかったそうな。
0274デフォルトの名無しさんNGNG
>>273
('A`)　ﾏｼﾞﾃﾞ？
0275デフォルトの名無しさんNGNG
いっぱいあるだろそんなもん。
0276デフォルトの名無しさんNGNG
STLPortなんてどうして使うの？
0277デフォルトの名無しさんNGNG
>>276
付属stlがくそだからじゃないか？
0278デフォルトの名無しさんNGNG
STLSoftもつかおーぜ
0279デフォルトの名無しさんNGNG
>>278
そんな怪しい名前のソフトは使いたくねーなｗ
0280デフォルトの名無しさんNGNG
>274
多分これ。
ttp://www.freeml.com/message/[email protected]/0011266
0281デフォルトの名無しさんNGNG
std::map<std::string,int> Map;

Map.insert(std::pair<std::string,int>(std::string(""),1));
　　　　　　　　　　　　~~~~~~~~~~~~~~~
の部分をハードコーディングではなく書けませんか？
0282デフォルトの名無しさんNGNG
typedef std::map<std::string,int> OrenoMap;
typedef std::pair<std::string,int> OrenoPair;

OrenoMap Map;

Map.insert(OrenoPair(std::string(""),1));
0283デフォルトの名無しさんNGNG
>>281
typedef std::pair<std::string,int> hoge;
0284デフォルトの名無しさんNGNG
う゛ぁぅえ＿ｔｙぺ
0285デフォルトの名無しさんNGNG
>>281
std::pair<>(std::string(""), 1)
ってこと？
0286デフォルトの名無しさんNGNG
>>285
それOKなんですか？
0287デフォルトの名無しさんNGNG
Map[""] = 1;
0288デフォルトの名無しさんNGNG
>>286
ダメだからmake_pairってのが用意されてたりする
0289デフォルトの名無しさんNGNG
>>281
Map.insert(std::make_pair(std::string(""), 1));

古いコンパイラだと受け付けないのもあるかもしれませんが・・・．
0290デフォルトの名無しさんNGNG
typedef std::map<std::string,int> MapT;

MapT m;
m.insert(MapT::value_type(std::string(""),1));
0291デフォルトの名無しさんNGNG
m.insert(MapT::value_type("",1));
でもOK
0292デフォルトの名無しさんNGNG
そんな面倒なことせんでも>>287でOKだろ。
0293デフォルトの名無しさんNGNG
こうｒ
0294デフォルトの名無しさんNGNG
>>292
意味が違うし
0295デフォルトの名無しさんNGNG
>>294
詳しく
0296デフォルトの名無しさんNGNG
map::insertはkeyが既存の場合，値が変更されません．
287さんのはkeyが既存のものも変更されます．
あと，細かいところだと293さんが書かれているの（効率）もあります．
0297rubykitchNGNG
全部EffectiveSTLの受け売りですねぷぷううううううううううううううううううううううううううううう
Ｒｕｂｙ ＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞Ｃ++
0298デフォルトの名無しさんNGNG
SuperRubyistはEffectiveSTLまで読んだのか
0299デフォルトの名無しさんNGNG
SuperRubyisは勉強熱心だね。
0300デフォルトの名無しさんNGNG
vector <string> temp;

ってやっちゃっていいのでしょうか？
なんかVC6だと警告でるのですが・・・。
0301デフォルトの名無しさんNGNG
>>300
警告の内容も晒さずに人様の貴重な時間を浪費して良くそんなことが聞けるな。
0302Ruby!!!!!!!!!!!!!!!NGNG
vc6は窓から投げ捨てろ
0303デフォルトの名無しさんNGNG
>>300
それは無害です。

E:\Project\Test755\Test755.cpp(16) : warning C4786: 'std::reverse_iterator<......'
: 識別子が '255' 文字に切り捨てられました (debug 情報内)。
0304デフォルトの名無しさんNGNG
>>301
もうしわけありませんでした。
って、調べてみたら解決しました。

どうやらＶＣのコンパイラが対応していないだけってことだったらしいです。

#pragma warning(disable:4786)

っというように追加して、みんなやってるようです。
0305デフォルトの名無しさんNGNG
>>303
レスありがとうございました。
0306デフォルトの名無しさんNGNG
今更だけど、std::mapより素直に力技のstd::vectorの検索を実装しといた方が柔軟な仕様変更に強いね。
メモリ消費量も断片化しないからstd::vetorは捨てたものじゃない。
当初の予想以上に作り込む必要が出てきたときstd::mapは厳しいね、いろんな意味で。
0307デフォルトの名無しさんNGNG
おいおい…
お前の設計段階での抽象化が甘いだけだよ。
0308デフォルトの名無しさんNGNG
>>306
力技の実装が素直なわけないだろ。
「仕様変更に強い」ではなくて、
たまたま実装に都合のいい仕様変更がはいっただけじゃないのか？

特殊なケースを一般的であるかのように言うのは感心できない。
0309デフォルトの名無しさんNGNG
そもそもvectorを代わりに使うならmapじゃなくてmultisetになりそうなもんだが
0310デフォルトの名無しさんNGNG
>>309 どっちでもいけるだろ。
0311デフォルトの名無しさんNGNG
map<T1, T2>をvector<pair<T1, T2> >にしたのかもしれん
0312デフォルトの名無しさんNGNG
>>311
その通りですが、なにか？
0313306NGNG
コンテナ要素が複雑であった場合は結局、諸々の検索方法を実装しなければならず、
std::mapのキー検索の存在感が、かすむ、かすむ。
みんなはどうしてるわけ？mapにおけるキー以外の検索。
0314デフォルトの名無しさんNGNG
>>313
boost::multi_index

ってのはもうちょっと先の話だが、
キー以外の検索があるのなら map に不満が出るのはあたりまえ。
最初っからそう言えよ。
0315デフォルトの名無しさんNGNG
普通に考えて、set<自分で作ったクラス>、だろ。
他に選択肢がありえる理由がわからん。
0316デフォルトの名無しさんNGNG
>>315
less でソートされてる必要は無いから set で保持するのは無駄だろ。
0317デフォルトの名無しさんNGNG
std::vectorで済むものはそうしているし、
駄目なものは他のものを使っている。例えば赤黒木。
いずれにせよ、検索のための"algorithm"をstd::vector専用に書いたりはしない。
0318デフォルトの名無しさんNGNG
>>316
いつも無駄なわけじゃないだろ?
0319306NGNG
>>315
std::setはメモリ消費量が大きいです。無駄多し。vector<list<setです。VC6,VC7で確認済み。
メモリを一括確保できるstd::vector::reserve()がある限り、std::vector最強だと思います。
ちなみに要素をswapしたい場合などは配列を直接移動させることは避けて
これまたポインタ配列やポインタリストを用意して順序付けするようにしてますが。
std::setは論外です。std::setは柔軟性の点で劣るかと。重み付けがかえって邪魔になる事多し。
0320デフォルトの名無しさんNGNG
ねぇ、おまいらSTLとかなんかよりまずは
C++を勉強してこい、話はそれからだな
0321デフォルトの名無しさんNGNG
>>319
ひょっとして、検索が主な用途じゃないのか？
0322デフォルトの名無しさんNGNG
>>319
なんで初めにmapを使ったのか、理由を教えて。
0323デフォルトの名無しさんNGNG
>>319
メモリ消費量の大きさが「無駄」になるかどうかは使う場面ごとに違うだろ。
reserve するためには要素数に対する前提が必要だろ。

繰り返すが、
特殊なケースを一般的であるかのように言うのは感心できない。
0324306NGNG
>>322
実は、自分のＰＣに数十万のファイルがあってファイルを探すのが面倒なので
ファイル名だけでフルパス名を取得できる仕組みを作ってたのですが、
ファイル名をキーにして、ファイルのフルパス名・その他情報を値としてstd::mapを構成していたのですが、
色気を出してワイルドカード検索できるようにしようとした時点でstd::mapによる設計が形骸化しました。
現在そのプログラムはバックグラウンドで動かすサーバ形式をとっているのですが、
ファイルが数十万なので常駐メモリが100ＭＢを超えています。（※意図的なものです。）
ギガクラスのメモリを乗せる時代に見合ったファイルインデックスシステムがあってもいいかな、と。
ゲームやVMでしかメモリをフル稼働しないのは勿体ない気がしたこともありまして。
0325デフォルトの名無しさんNGNG
setでinsertしまくると遅い事に気づいたんだけどうまい方法無い？
挿入するまとまりを、
vectorに一旦入れてからset.insert(vec.begin(), vec.end())みたいな感じで
まるごとinsertしてみたけど意味無かった。
0326デフォルトの名無しさんNGNG
[cppll:5647] ソート済みベクタは遅い？
これ見てからはもっぱらソース済みvectorは使わなくなったな。
0327デフォルトの名無しさんNGNG
>>324
おもいっきり>>307-308じゃんかｗ
0328デフォルトの名無しさんNGNG
>>323
自分の経験則からいくと、vector::reserveの冗長性を織り込んだメモリ消費量より、
std::listやstd::set,std::mapのメモリ断片化によるメモリ消費量の肥大化の方が厄介でした。
多くの場合、要素数のおおよその数が分かっているので、したがってvectorが最適である可能性が高い。
しかも、そのサイズに関する最適化の効果を確実に得られるのもvectorの特徴。
他のコンテナではＰＧによる最適化の手段が限られている。
0329デフォルトの名無しさんNGNG
>要素数のおおよその数
予想も付かない場合が多い。
0330デフォルトの名無しさんNGNG
vectorはPGが要素数を教えて上げないと極端に遅くなるか
極端にメモリが無駄になるかのどちらかになるから。

vector以外のコンテナはそんな事は無い。
0331デフォルトの名無しさんNGNG
つかそこまでいったらUNIX DBとかsqliteぐらい使えよ。
■ このスレッドは過去ログ倉庫に格納されています