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

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

■ このスレッドは過去ログ倉庫に格納されています
0001デフォルトの名無しさんNGNG
前スレ
【C++】STL（Standard Template Library）相談室
http://pc5.2ch.net/test/read.cgi/tech/1095583235/

関連スレなどは>>2以降で
0478デフォルトの名無しさん2005/04/27(水) 18:26:13
>>477
>ストリームってSTLじゃないんだっけ。
まったくもって違う。
つか、STL なんていう呼称に何か意味があるのか？
0479デフォルトの名無しさん2005/04/27(水) 18:39:15
ついついatoiやsprintfを多用してしまう俺
0480デフォルトの名無しさん2005/04/27(水) 22:04:51
STLスレ的って言うんだったらせめてこういう風にしようよ。
#include <iostream>
#include <string>
#include <algorithm>
#include <cctype>
#include <functional>
bool ToInt(char c, int *n)
{
    if (!std::isdigit(c))
        return true;
    *n *= 10;
    *n += c - '0';
    return false;
}
int main()
{
    int Num = 0;
    std::string str = "200";
    std::find_if(str.begin(), str.end(), std::bind2nd(std::ptr_fun(ToInt), &Num));
    std::cout << Num << std::endl;
    return 0;
}
BCCのSTLはToInt()の引数をint&にすると参照へのポインタは作れないと言いやがる。Boostなら平気だったが。
std::find_if(str.begin(), str.end(), boost::bind(ToInt, _1, boost::ref(Num)));
0481デフォルトの名無しさん2005/04/27(水) 22:29:05
boost::lambdaとboost::bindってどう違うの?
いつもはboost::lambdaの方を使ってるんだけど。

0482デフォルトの名無しさん2005/04/27(水) 22:43:04
>>481
boost::lambdaは無名関数作成。
boost::bindは>>480のように2引数関数オブジェクトから1引数関数オブジェクトを作ったりするのに使う。
0483デフォルトの名無しさん2005/04/27(水) 23:22:15
でもboost::lambda::bindってあるじゃない?
0484デフォルトの名無しさん2005/04/28(木) 01:30:10
>>483
boost 1.32 だと boost::lambda::bind よりも boost::bind の方が適用範囲が
広い。確か intrusive_ptr を使ってると lambda の方はうまく動かなかった
ような気がする。
0485デフォルトの名無しさん2005/04/28(木) 02:05:09
>>484
あんまり答えになってないんじゃないか? それはさておき、俺は
boost::lambda::bindとintrusive_ptrを使ってるけど別に困ってないけどな。

俺の経験ではboost::bindはlambdaと混用できなくて、
必然的にboost::lambda::bindを使う方が多い。
0486デフォルトの名無しさん2005/04/28(木) 21:53:38
boostのlambda使う奴がいるとは思わなかったw
0487デフォルトの名無しさん2005/04/28(木) 22:49:52
普通に使わないか？
便利だと思うんだけど。
0488デフォルトの名無しさん2005/04/29(金) 00:50:38
つーかbindって。ネーミングセンスなさ杉
0489デフォルトの名無しさん2005/04/29(金) 01:26:53
STLがbind1st、bind2ndなんて名前つけちゃったから。
0490デフォルトの名無しさん2005/04/29(金) 10:05:35
>>488 ハイセンスな名前きぼんぬ。
0491デフォルトの名無しさん2005/04/29(金) 10:57:12
ai-n
0492デフォルトの名無しさん2005/04/29(金) 11:03:47
boost::ボインど
0493デフォルトの名無しさん2005/04/29(金) 12:09:40
>>489
STL 以前に、コンピュータサイエンスで使われてた単語をそのまま
持ってきただけかと。そもそも boost::lambda のラムダも、λ計算
そのままだし。
0494デフォルトの名無しさん2005/04/29(金) 12:17:26
はじめbindっていうから、socketの話かとｵﾓﾀ
0495デフォルトの名無しさん2005/04/29(金) 12:38:55
boost::ランバダ
0496デフォルトの名無しさん2005/04/29(金) 12:41:31
boost::penis
0497デフォルトの名無しさん2005/04/29(金) 13:51:07
boost::uholtu!
0498デフォルトの名無しさん2005/04/29(金) 14:01:39
boost::yaranaika?
0499デフォルトの名無しさん2005/04/29(金) 14:43:26
boost::dagakotowaru
0500デフォルトの名無しさん2005/04/29(金) 14:57:02
馬鹿でも参加できる流れになると速いな。
0501デフォルトの名無しさん2005/04/29(金) 16:42:56
↓おっとここで天才登場
0502デフォルトの名無しさん2005/04/29(金) 16:58:32
やっぱLISP最高
0503デフォルトの名無しさん2005/04/29(金) 17:10:16
>>488
グッドセンスな名前はまだか？
0504デフォルトの名無しさん2005/04/29(金) 23:49:14
>>488
お前が馬鹿なだけ。
0505デフォルトの名無しさん2005/04/30(土) 00:11:35
vectorの要素がポインタのときresizeでサイズを拡張するのは危険と教えられたのですが
理由は何ですか？
0506デフォルトの名無しさん2005/04/30(土) 00:16:23
そうかねえ。488ではないが、bindではなくcurryとかにすべきだったんじゃないか?

>>489
STLのbind1st、bind2ndは引数に束縛という意味でbindをそのまま持ってきたわけだが、
boost::bindについてまで束縛を「そのまま持ってきた」と言えるかというと疑問だ。
0507デフォルトの名無しさん2005/04/30(土) 00:16:38
別に危険じゃないと思うが。
単に拡張にせよ縮小にせよ、ポインタが指している先の面倒を自分でみる必要があるだけで。
0508デフォルトの名無しさん2005/04/30(土) 01:20:32
ウホッ！いい男。
0509デフォルトの名無しさん2005/04/30(土) 03:27:20
>>505
そいつに聞け。
0510デフォルトの名無しさん2005/04/30(土) 07:26:01
STL関係のサイトを見てると、
vectorを使って、動的に確保したメモリ領域のアドレスを管理するのに、
どこもポインタからunsigned longとかunsigned intとかに変換してるのですが、
直接ポインタ型でvectorを使っても何もダメなことって無いですよね？
ポインタ型だって結局はunsigned longとかと同じ数値なんだし・・・
0511デフォルトの名無しさん2005/04/30(土) 07:53:51
>>506
そこで語源が固有名詞な専門用語持ってくるのも嫌な感じだな。
curry(apple, honey) とかも嫌だろ。

ついでに、調べてる最中にこんなんも拾った。
http://mail.python.org/pipermail/python-dev/2004-February/042660.html
曰く、
"Curry is a one argument function that accepts a function and returns a new function"
だそうだ。
0512デフォルトの名無しさん2005/04/30(土) 07:56:00
>どこもポインタからunsigned longとかunsigned intとかに変換してるのですが
どこでや。

>ポインタ型だって結局はunsigned longとかと同じ数値なんだし
sizeof(long*) == 8
sizeof(long) == 4

という環境もあるわけですが…
0513デフォルトの名無しさん2005/04/30(土) 07:57:28
>>510
数値に変換しているのは、ポインタ型それぞれに
テンプレートのインスタンス化が起こるのを嫌ってるんだろう。
ただ、そこで整数型で置き換えるのは間違いで void* ぐらいにしておくべき。
ポインタ型でvectorを使うのは全く問題ないが、
問題ない理由としてポインタが数値であるという認識は間違い。
0514デフォルトの名無しさん2005/04/30(土) 08:04:14
>>512
あぁいや、サイズが同じというんじゃなくて、結局は数値なんだしってことで

>>513
でも、データ上数値であることに変わりないと思うのですが
じゃあ、どういった理由で問題無いのでしょう？
0515デフォルトの名無しさん2005/04/30(土) 08:38:51
>>514
頭悪そうですね…
05165132005/04/30(土) 08:48:02
>>514
数値であっても、サイズが同じじゃないと問題が起こることぐらいわかるよな？

ポインタ型でvectorを使うのが問題ない理由は、ポインタ型が
vectorのテンプレート引数として要求される条件を全て満たしているから。
0517デフォルトの名無しさん2005/04/30(土) 10:24:41
unko_curry はどうよ。
0518デフォルトの名無しさん2005/04/30(土) 10:54:13
それはどっちが味でどっちが本質なんだ
0519デフォルトの名無しさん2005/04/30(土) 18:36:36
おれが思うに、味がうんこだったら本質もうんこだと断定できる。
すなわち「うんこ味のカレー」はうんこそのものである。
また、「カレー味のうんこ」はたとえ見た目がうんこそっくりでも、
カレーそのものかもしれないという可能性がまだ残されている。
しかし、「うんこ」と断言されている以上、危険性は賭けである。
これ以上は1/2の確率と「運」に任せるしかない。
ゆえに、選ぶとしたら「カレー味のうんこ」だ！
0520デフォルトの名無しさん2005/04/30(土) 18:44:01
しかし、ここで今、重大な見落としをしていることに気付いた。
それは「カレー味」とは、どの程度の質レベルなのか、という問題である。
もしもうんこが1%でもブレンドされていたらおれの敗北である。
「カレー味」と表記されたからといって、原料が100%すべてカレー
である確率は残念ながらとても低いだろう。
最後に「うんこ」と断言されていることを忘れてはならない。
おれはまた、思考の渦に入り込んでしまった様だな。
0521デフォルトの名無しさん2005/04/30(土) 18:45:03
それはつまり、「カレー」「うんこ」の定義次第ということだね。
0522デフォルトの名無しさん2005/04/30(土) 18:53:14
難しいな・・
0523デフォルトの名無しさん2005/04/30(土) 20:50:03
この問題に比べたらSTLの習得なんて簡単。
0524デフォルトの名無しさん2005/04/30(土) 21:04:01
スカトロ大好きな俺にとっては簡単な問題
0525デフォルトの名無しさん2005/04/30(土) 21:52:06
疑問なんだけど、
スカトロって、誰が出したのかも判らない様なうんこでも食えるもんなの？
0526デフォルトの名無しさん2005/04/30(土) 22:10:42
そんな話はやめてくれ……。
0527デフォルトの名無しさん2005/05/01(日) 03:35:59
お前ら楽しそうだなｗ
0528デフォルトの名無しさん2005/05/01(日) 06:58:44
鴻上尚史のオールナイトニッポン
(「究極の選択」コーナー) って18年くらい前だっけ？
息の長いﾈﾀだ＜カレー味の運子
0529デフォルトの名無しさん2005/05/03(火) 03:17:29
curry化の語源は食い物のカレーじゃなくて人名(Haskell Curry)だよ
0530デフォルトの名無しさん2005/05/03(火) 03:31:20
>>529 知らずに喋ってる奴なんていねーよ。
0531デフォルトの名無しさん2005/05/03(火) 06:00:16
>>529で一気に萎えた件
0532デフォルトの名無しさん2005/05/03(火) 07:28:55
>>529は自分だけが物知りで特別だと勘違いしている痛い香具師
0533デフォルトの名無しさん2005/05/03(火) 07:32:47
>>529は初代うんち食う王
0534デフォルトの名無しさん2005/05/03(火) 08:11:01
>>529は↓
http://www.unsymmetry.org/up3d/files/1112701802518.jpg
0535デフォルトの名無しさん2005/05/04(水) 13:49:33
intあるいはdoubleをstringに変換する方法を教えてください
0536デフォルトの名無しさん2005/05/04(水) 13:55:47
sprintf
0537デフォルトの名無しさん2005/05/04(水) 14:21:52
>>536
もっとC++的なやり方はありませんか？
0538デフォルトの名無しさん2005/05/04(水) 14:27:45
std::string str = boost::lexical_cast<string>((int)10);
0539デフォルトの名無しさん2005/05/04(水) 14:30:56
strstream
0540デフォルトの名無しさん2005/05/04(水) 14:44:19
>>537
std::string str(number, ' ');

>>539
遅くない？
0541デフォルトの名無しさん2005/05/04(水) 14:47:10
lexical_castもなんか凄い遅いね
0542デフォルトの名無しさん2005/05/04(水) 14:51:10
iostream系が遅いと感じるって何の処理する時？
そういう時の代替案はなんだろう？printf?
0543デフォルトの名無しさん2005/05/04(水) 14:54:20
そんなんでプログラム全体の動作に致命的な影響を与えるほど遅くなるなら
C++使うのやめれ
0544デフォルトの名無しさん2005/05/04(水) 14:56:57
>535
wsprintf
0545デフォルトの名無しさん2005/05/04(水) 14:59:58
double x=1.0;
string str="aaa"+string(x)+"bbb";

みたいなことが出来るような文字列クラスはありませんか？
0546デフォルトの名無しさん2005/05/04(水) 15:15:20
std::ostringstream でも使いな
0547デフォルトの名無しさん2005/05/04(水) 15:26:20
トラックバック:http://pc8.2ch.net/test/read.cgi/tech/1108468718/
0548デフォルトの名無しさん2005/05/04(水) 15:56:01
>>537
reinterpret_cast<std::string>
0549デフォルトの名無しさん2005/05/04(水) 21:19:45
おまいらスレ鯛よく読め
0550デフォルトの名無しさん2005/05/04(水) 21:25:54
だが断る
0551デフォルトの名無しさん2005/05/04(水) 22:23:58
>>545
boost::lexical_cast()
0552デフォルトの名無しさん2005/05/04(水) 23:03:02
>>549
STL の意味を知らないからこそこのｽﾚに来るんじゃなかろうかと。
0553デフォルトの名無しさん2005/05/04(水) 23:18:27
>>535
"標準的"手法
#include <iostream>
#include <sstream>

int main()
{
    double d = 1.2345;
    std::stringstream ss;
    std::string str;
    ss << d;
    ss >> str;
    std::cout << str;
}
0554デフォルトの名無しさん2005/05/05(木) 00:14:19
>>552
orzとSTL
0555デフォルトの名無しさん2005/05/05(木) 00:15:12
>>552
そうなんだけど。
だからこのスレいらないんだよ。
0556デフォルトの名無しさん2005/05/05(木) 00:19:15
無かったらまたどっかのアフォが立てるだけ
例えば俺とか
05575522005/05/05(木) 00:39:38
>>553
ほらね。
0558デフォルトの名無しさん2005/05/05(木) 00:44:21
”標準的”って書いてあるやん
0559デフォルトの名無しさん2005/05/05(木) 02:38:55
>>558
STLちゃうやん
0560553じゃないけど2005/05/05(木) 02:43:09
>>559
だから”標準的”なんでしょ。
stringもstreamもSTLではないが標準ライブラリに含まれる。
0561デフォルトの名無しさん2005/05/05(木) 02:53:46
じゃあSTLとSLの違いを教えてください
0562デフォルトの名無しさん2005/05/05(木) 02:58:39
"STL"なんて呼称の範囲は、C++の標準ライブラリに
取り込まれてしまった今となっては明確に区切れる物では無い。
HP STL や SGI STL のことを指して言ってるのかもしれないが、
今使われてるのはそれらをベースにしたC++標準ライブラリだ。
範囲が明確に決まってるかのように、含まれるだの含まれないだの言うのは時代遅れだぞ。

このスレが不要である事に疑いの余地は無い。
0563デフォルトの名無しさん2005/05/05(木) 03:08:02
それが結論でいいんだけど、書籍や入門サイトでSTLの呼称が
根強く残っているから混乱しちゃうんだな。
呼称は「標準ライブラリ」で統一されるといいんだけど。
0564デフォルトの名無しさん2005/05/05(木) 03:17:35
563
標準ライブラリじゃなくてテンプレートライブラリ
0565デフォルトの名無しさん2005/05/05(木) 03:29:05
テンプレートが邪魔だって言ってるんでは
0566デフォルトの名無しさん2005/05/05(木) 06:39:30
orzとSTLの違いを教えてください
0567デフォルトの名無しさん2005/05/05(木) 07:05:53
vectorは配列に比べて動作が遅くなりますか？
0568デフォルトの名無しさん2005/05/05(木) 07:19:56
ﾃﾒｰで計ればすむことだろ
0569デフォルトの名無しさん2005/05/05(木) 07:30:48
>>568
はかってみたら5倍程度遅くなったんです。これってふつうですか？
0570デフォルトの名無しさん2005/05/05(木) 07:53:23
その値が普通かどうかは知らないが、サイズやキャパシティを自分で覚えてくれて
アクセス毎に境界チェックが入るということ等から見当がつきそうなものだが。

見当がつかなかったらコンパイラにアセンブラソースを吐かせて自分で比較すれ。
0571デフォルトの名無しさん2005/05/05(木) 08:39:12
だが断る
0572デフォルトの名無しさん2005/05/05(木) 09:00:21
>>567>>569
速度が気になるのならboost::arrayをどうぞ。
0573デフォルトの名無しさん2005/05/05(木) 09:02:38
>>569
普通に全件表示を書いたら配列とvectorでは速度が変わらなかったんです。
普通にstd::find()を使ってもstd::accumurate()を使っても同じ速度だし。
どうやったらvectorを遅く動かせるんでしょうか。
0574デフォルトの名無しさん2005/05/05(木) 09:07:12
>>573
vectorは動的にメモリを確保するから、普通の配列に比べコンストラクタ・デストラクタに時間が掛かる。
0575デフォルトの名無しさん2005/05/05(木) 10:45:10
なので、はじめにあらかじめ確保する関数があったはず。
0576デフォルトの名無しさん2005/05/05(木) 10:48:22
>>575
それでも普通の配列より時間がかかる
0577デフォルトの名無しさん2005/05/05(木) 11:23:36
>>570
operator[]()は境界チェックをしないわけだが。
■ このスレッドは過去ログ倉庫に格納されています