05/10/30 23:12:16
【注意】STLの落とし穴【危険】
ｽﾚﾘﾝｸ(tech板)
3:デフォルトの名無しさん
05/10/30 23:14:20
>>1
乙
4:デフォルトの名無しさん
05/10/30 23:21:13
C++関連スレ
【C++】template 統合スレ -- Part6
ｽﾚﾘﾝｸ(tech板)l50
C++相談室 part44
ｽﾚﾘﾝｸ(tech板)l50
【初心者歓迎】C/C++室 Ver.22【環境依存OK】
ｽﾚﾘﾝｸ(tech板)l50
5:デフォルトの名無しさん
05/10/30 23:22:27
ここらへんもいれておくかな。
BOOSTを語れゴラァ
ｽﾚﾘﾝｸ(tech板)l50
内藤ﾎﾗｲｿﾞﾝがC/C++の宿題を片付けます 49
ｽﾚﾘﾝｸ(tech板)l50
6:デフォルトの名無しさん
05/10/30 23:38:00
Apache C++ Standard Library
URLﾘﾝｸ(incubator.apache.org)
STLpotrがあるならこれも
7:デフォルトの名無しさん
05/10/31 00:05:07
じゃあこれも
URLﾘﾝｸ(gcc.gnu.org)
8:デフォルトの名無しさん
05/10/31 01:03:34
STL分けるのもう良そうよ
C++相談室が閑散としすぎ
9:デフォルトの名無しさん
05/10/31 01:08:59
>>8
ところがC++相談室には、STLの質問が滅多に来ないんだなこれが。
C++を使いながらも、STLを忌避している香具師が多いという証拠だろう。
10:デフォルトの名無しさん
05/10/31 01:21:49
>>9
単にここがあるからでは?
11:デフォルトの名無しさん
05/10/31 05:32:30
言語とライブラリは分けたほうがいい。
12:デフォルトの名無しさん
05/10/31 05:35:51
>>11
標準ライブラリ
13:デフォルトの名無しさん
05/10/31 06:39:07
標準ライブラリーもライブラリーなのでは？
14:デフォルトの名無しさん
05/10/31 07:43:06
ｽﾚﾘﾝｸ(tech板:562番)
562 名前：デフォルトの名無しさん[sage] 投稿日：2005/05/05(木) 02:58:39
"STL"なんて呼称の範囲は、C++の標準ライブラリに
取り込まれてしまった今となっては明確に区切れる物では無い。
HP STL や SGI STL のことを指して言ってるのかもしれないが、
今使われてるのはそれらをベースにしたC++標準ライブラリだ。
範囲が明確に決まってるかのように、含まれるだの含まれないだの言うのは時代遅れだぞ。
このスレが不要である事に疑いの余地は無い。
15:デフォルトの名無しさん
05/10/31 08:42:05
個人的には別に他のスレに統合されてもいいかなとも思うけど、
過去ログを参照するときは適度にカテゴライズされてたほうが都合がいいかな。
そういう意味ではC++に関する話題を分類するとき、
STLを一つのカテゴリーにするのは結構無難な選択かも。
16:デフォルトの名無しさん
05/10/31 14:17:29
>>9
バカばっか、という事でしょう。
17:デフォルトの名無しさん
05/10/31 15:37:05
厨ほどスレを分化させたがるよな
18:デフォルトの名無しさん
05/10/31 16:31:12
＿ -―- ＿
, ', -､ヽ'´ ｀'´, -､ヽ
! { / ﾞ } i
ヽ｀ｰ,' ● ● ﾞｰ'ノ
｀ ! ┬ l" < 厨ー
｀ヽ. ┴ ﾉ
/｀＝=ｧ'⌒ヽ=＝'ヽ
19:デフォルトの名無しさん
05/10/31 16:41:03
厨w
20:デフォルトの名無しさん
05/10/31 17:02:46
コンテナとアルゴリズムは分けるべきじゃねw?
21:デフォルトの名無しさん
05/10/31 17:15:23
細かすぎる分類はごめんだが、悪くないと思うけどなぁ。STLスレ。
言語の規格が巨大なC++の分類の仕方としてはごく普通な発想って気が・・・
STLに焦点をしぼった書籍もたくさんあることだしさ。
22:デフォルトの名無しさん
05/10/31 19:37:16
>>18
巣に帰れ
23:デフォルトの名無しさん
05/10/31 22:03:55
>>9
C++相談室にSTLの質問が来ないのは、忌避も何もその前に
テンプレートを使うようなレベルに達していないようなやつばかりが質問してくるからだと思うが。
>>11
ならSTLと言わず標準ライブラリ全てを扱うスレが存在すべき。
24:デフォルトの名無しさん
05/10/31 23:08:12
serializationで抽象クラスのポインタシリアライズがうまくいきません。
どこかにサンプルコードとかありませんかね？
25:デフォルトの名無しさん
05/10/31 23:14:38
前スレのもそうだがboostスレで質問したほうが良いのではないだろうか？
26:デフォルトの名無しさん
05/10/31 23:55:14
template<T>のTがあるインターフェイスを実装しているとか
引数なしPublicコンストラクタがあるとかの制限
ってどうやったらできますか
27:デフォルトの名無しさん
05/11/01 00:00:52
>>26 concept_check
28:デフォルトの名無しさん
05/11/01 00:02:43
実際に呼べば判るとおもうが
29:デフォルトの名無しさん
05/11/02 22:23:57
こんにちは。
とあるトランプゲームを作ろうと思って、以下のコードを書きました。
void InitCard(std::list<BYTE>& card){
card.clear();
for(int i=0;i<2;i++){
for(int j=0;j<13;j++){
card.push_back(j);
}
}
card.push_back(13);//ジョーカを一枚追加。数値は１３
SetRandom();//srandなど
std::random_shuffle(card.begin(),card.end());//vc7.1ではライブラリ内でエラー。なぜ？？
}
このコードではrandom_shuffleでコンパイルエラーが発生してしまいます。
・C2784: 'std::reverse_iterator<_RanIt> std::operator +(_Diff,const std::reverse_iterator<_RanIt> &)' : 'const std::reverse_iterator<_RanIt> &
用のテンプレート引数を 'std::iterator_traits<_Iter>::difference_type' から減少できませんでした。
with
[
_Iter=std::list<BYTE>::iterator
]
・C3767: '+' 一致した関数はアクセス不可能です。
・C2676: 二項演算子 '+' : 'std::list<_Ty>::iterator' は、この演算子または定義済の演算子に適切な型への変換の定義を行いません。 (新しい動作; ヘルプを参照)
with
[
_Ty=BYTE
]
どなたか原因がわかりませんか？？
30:デフォルトの名無しさん
05/11/02 23:01:52
listをdequeにしたら?
31:デフォルトの名無しさん
05/11/02 23:04:19
>>30
レスありがとう。
ちょっとやってみます。
32:デフォルトの名無しさん
05/11/02 23:04:33
>>29
random_shuffleはrandom access iteratorが必要。
しかしstd::listのイテレータはbidirectional iteratorなのでエラーになった。
random access iteratorはbidirectional iteratorに加え+, -, +=, -=, []の演算子が使える。
これはもうどうでもいいことだが今回はエラーメッセージを見ると+がないというエラーのようだ。
33:デフォルトの名無しさん
05/11/02 23:20:53
dequeにするくらいならvectorにするべきじゃないか？
要素がBYTE型なのだから、コピーのコストなんてたかが知れてる。
34:デフォルトの名無しさん
05/11/02 23:24:11
>>32
レスありがとう。
リストは付け替えるだけで順番も変わるのと時間かかるけど場所の特定が簡単なので、ランダムアクセスできると思い込んでました。（自分で作るときはそうすると思う・・・。
うーん。思い込みはいけませんね。勉強になりました。
そうそう。dequeにしたらちゃんと通りました。
ありがとうございます。
35:デフォルトの名無しさん
05/11/02 23:36:14
>>33
レスありがとう。
今回の場合ランダムシャッフルさえできれば、一列に並んでる構造ならばなんでもいいのですが、
今回は試す意味でdeque使ってみようと思います。
提案ありがとう。
36:デフォルトの名無しさん
05/11/03 00:09:45
vectorは、要素削除後の管理が自己責任で面倒である点を除けば、
list,set,dequeのいずれよりも、メモリ消費量や速度・柔軟性で上。
引数に配列形式でアドレスを渡す各種API関数でコンテナを流用できるのは、vectorだけ。
色々試した結果、最後にはvectorに回帰する。
これは誰もが辿る道だ。
37:36
05/11/03 00:21:00
補足。
自己責任と書いてしまったが、insert()を遠慮なく使えるなら気にしなくていいことだった。
38:デフォルトの名無しさん
05/11/03 00:26:10
>>36
今のところセッパつまってないので、いいのですが。
最後はベクタというのはちょっと面白いです。
そこまで行くにはまだ時間がかかりそうですが、それまで色々やってみたいです。
39:デフォルトの名無しさん
05/11/03 01:00:26
>36
>最後にはvectorに回帰する。
トランプゲームの内容次第ですな。
山から引いたカードを二度と使わないようなゲームならvectorをスタックとして
使用すればいいけど、山の下に戻すようなゲームだとvectorよりはdequeの
方がいいですな。
まあ、たかが53枚だからC互換のvectorの方が良いという意見もあるかもしれんが……
40:デフォルトの名無しさん
05/11/03 02:24:51
vector<CHoge *> list1; // list1.size() == 0
vector<CHoge *> list2; // list2.size() == 3
list1にlist2の全データをコピーしたくて
list1.insert(list1.end(), list2.begin(), list2.end());
とやったのですが、実行後 list1.size() == 87となってしまいます。
リストにリスト全体を追加するにはどうすればいいのですか?
iteratorで１件ずつ回してコピーするしかないのでしょうか?
41:デフォルトの名無しさん
05/11/03 02:47:45
>>40
list1.insert(list1begin(), list2.begin(), list2.end());
42:デフォルトの名無しさん
05/11/03 02:56:51
>>40
ソースはそのままでいい。
むしろ、list1とlist2のiteratorをちゃんと区別してコンテナ操作できてるかチェック。
43:デフォルトの名無しさん
05/11/03 03:38:09
>>41
×でした。>>40と同じく追加後の件数が実データ数を大きく越えていました。
>>42
for (vector<CHoge *>::iterator it = list2.begin(); it != list2.end(); it++)
list1.push_back(*it);
これで正しくコピーできるので、自分の中でiteratorの区別はできていると思っています。
44:40
05/11/03 04:00:16
原因わかりました！
実際は下記のような実装になっていたのですが
CMyClass* p;
list1.insert(list1.end(), p->getList().begin(), p->getList().end());
vector<CHoge *> CMyClass::getList();
getList()が参照を返していなかったのが原因でした。
vector<CHoge *>& CMyClass::getList();
上記のように修正したらうまくいきました。皆さんお騒がせしてすみませんでした。
45:29
05/11/03 04:46:26
このすれのおかげで完成しました。例のトランプゲームです。
内容はスピードってゲームなんですけど、適当に実装したCPUが超速でカード出してくるので勝てません。（@@;
うひー。orz
46:デフォルトの名無しさん
05/11/03 07:29:52
>>36
>色々試した結果、最後にはvectorに回帰する。
だって、ププッwwwwwwwwwww
47:デフォルトの名無しさん
05/11/03 13:43:21
正論すぎて反論できないのが可哀相
48:デフォルトの名無しさん
05/11/03 15:12:47
>>36
>vectorは、要素削除後の管理が自己責任で面倒である点を除けば、
>list,set,dequeのいずれよりも、メモリ消費量や速度・柔軟性で上。
中略
>色々試した結果、最後にはvectorに回帰する。
>これは誰もが辿る道だ。
それぞれのコンテナは、用途と状況に応じてパフォーマンスが違う。
例えば、シーケンスの途中に要素の挿入・削除が頻繁にある場合はlistを使うべき。
それを、一列に比べても意味が無い。
もしかしてvectorが全てだとでも思っているのか。
49:デフォルトの名無しさん
05/11/03 15:28:09
おまいら既存のコンテナに頼りすぎてないか？
例えばvectorのインデックスで木を表現しても良いはずだ。
50:デフォルトの名無しさん
05/11/03 15:31:39
ならvector使わなくてもいいはずだ
51:デフォルトの名無しさん
05/11/03 16:19:13
>>49
読みにくいだろ。
ほかのコンテナをvectorで代用していったら、
何やってるか、わかんなくなってくよ。
52:sage
05/11/03 17:09:42
>これは誰もが辿る道だ。
え、オレ、そんな道辿ってないんだけど。
vectorに回帰と言うよりも、
どちらかというとboostにたどり着いたかな
53:デフォルトの名無しさん
05/11/03 17:37:53
on
54:デフォルトの名無しさん
05/11/03 18:40:12
vectorは既存のC/C++ソースの流用に関して柔軟に移植できる。
コピペ野郎には欠かせない存在だ。
・・・ま、生粋のコピペ野郎ならメモリ管理部分も
そのまま低レベル記述のままにしておくのだろうけど。
55:デフォルトの名無しさん
05/11/03 18:42:02
ま、確かにコンテナの中でstd::vectorだけは別格だという事は認める。
56:デフォルトの名無しさん
05/11/03 21:58:04
回帰と言うか、漏れにとっては「取り敢えずvector」とか「迷ったらvector」だなw
57:デフォルトの名無しさん
05/11/03 23:03:55
vectorから他のコンテナへの置換は大抵簡単だが、
逆は難しい場合が多いもんね。
とりあえずvector。
迷ったらvector。
58:デフォルトの名無しさん
05/11/04 00:20:38
STLとboostを使いこなせるほどのレベルになると、
C言語固有分野の実力もそれなりのものになっている可能性が高い。
このレベルになるとアドレスシーケンスが保証されたvectorだけで十分になってしまったりする。
C言語にはいくつかのループ記述（for、while、do-while）があるが、
結局最後にはforしか使わなくなるのに似ている、・・・と思ったがやっぱ似てないな。
美食家が最後に茶漬けに戻るのに似ている、侘び寂びの世界だ、・・・と思ったがやっぱ似てないな。
59:デフォルトの名無しさん
05/11/04 00:32:18
＞結局最後にはforしか使わなくなるのに
んなこたーない。
60:デフォルトの名無しさん
05/11/04 01:14:19
for(;;)
while(1)
くらべてみよー
61:デフォルトの名無しさん
05/11/04 01:38:58
漢なら while (true) だ！
62:デフォルトの名無しさん
05/11/04 01:42:07
最近はfor(;;) しか見てないなー
ひょっとして陰で統一されつつあるのか？？
63:デフォルトの名無しさん
05/11/04 01:51:43
そりゃぁ、ansiでわざわざそのためにfor(;;)を規格化したわけですから。
while (1)や while (true)は警告対象になるコンパイラも多いことだし。
64:デフォルトの名無しさん
05/11/04 02:57:26
>>63
マジデスカ
今までずっとwhile(true)だったよ…
65:39
05/11/04 03:43:52
>58
えぇー
例えば、listだと多くの操作が例外安全だからvectorよりも使い勝手が
良かったりするけどね……「取りあえずvector」というのはあるかもしれんが……
>ループ記述
最近はforも使わずにアルゴリズムに落としこむなぁ。
66:デフォルトの名無しさん
05/11/04 04:31:34
つーかさ
>>54あたりから>>58位までの、多くのレスは
ずっと自作自演やってる奴の１人の仕業だろ
バレテンダヨ
さっきからvectorの擁護ばかりで
ウザイ
67:>>56=59=63
05/11/04 04:43:10
>>66
んなこたーない。
68:デフォルトの名無しさん
05/11/04 11:24:55
> vectorの擁護
ﾜﾗﾀ
アホの子もここまでくるとちょっとな
69:デフォルトの名無しさん
05/11/04 12:05:15
＞最近はforも使わずにアルゴリズムに落としこむなぁ。
馬鹿丸出しだな。
コールバック関数を用意してループ処理を隔離する事が、
常に近道だとは到底思えない。
コールバック関数とともにアプリ定義の引数渡しができない場合は、
スレッドセーフにするのが面倒である点も致命的。
70:デフォルトの名無しさん
05/11/04 12:47:55
>>69
つまり、
STLを否定してる発言
もう、こいつにつける薬はないな。
71:デフォルトの名無しさん
05/11/04 12:50:21
STLに馴染めないロートルは放っときゃいいんだよ。
72:デフォルトの名無しさん
05/11/04 12:58:24
たった今、STL全体とalgorithmを同一視する馬鹿な>>70を発見した。
新鮮な驚きだ。
73:デフォルトの名無しさん
05/11/04 13:12:48
>>72
負け犬の遠吠え
74:デフォルトの名無しさん
05/11/04 16:29:00
>>69
> コールバック関数とともにアプリ定義の引数渡しができない場合は、スレッドセーフにするのが面倒である点も致命的。
は
> コールバック関数を用意してループ処理を隔離する事が、常に近道だとは到底思えない。
の理由や説明になっていない。
75:デフォルトの名無しさん
05/11/04 16:57:18
並列だろ
76:デフォルトの名無しさん
05/11/04 18:44:04
どこにでも盲信者とアンチがいるのですね
77:デフォルトの名無しさん
05/11/04 18:56:24
理解できない話に出くわした時は
とりあえず信者・アンチと言っておけば
わかってるフリができる
78:デフォルトの名無しさん
05/11/04 20:47:17
確かにalgorithm関連の関数は引数仕様を変更して貰いたいと感じる。
Win32APIのようにマルチスレッドが前提となるOSのAPIはその点で抜け目がない。
79:デフォルトの名無しさん
05/11/04 21:11:06
>>78
STLのalgorithmは関数オブジェクトを渡せばいいだろ。
その関数オブジェクトのメンバでいくらでも渡せる。
80:デフォルトの名無しさん
05/11/04 21:15:16
>>78
bind1st bind2nd mem_fun って知ってますか？
81:デフォルトの名無しさん
05/11/04 23:25:57
もうSTLport5も出たっていうのに。
URLﾘﾝｸ(sourceforge.net)
82:39
05/11/04 23:59:36
>69
>コールバック関数とともにアプリ定義の引数渡しができない場合は、
>スレッドセーフにするのが面倒である
どういうこと？C++ではカリー化ができないという意味？
83:デフォルトの名無しさん
05/11/06 16:56:25
BCB6付属のSTLPortを最新版に変えるにはどうしたらいいの？
84:デフォルトの名無しさん
05/11/08 03:18:11
非常に初心者な質問ですみません。
VC++Toolkit2003のコマンドプロンプトにて
nmake -f vc71.mak
としてmakeしようとすると、エラーが大量に出てコンパイルが通りません。例えば
dll_main.cpp(86) : error C2084: function 'void _STL::__stl_throw_range_error(const char *)' already has a body
といったようなエラーが出ています。
どういう原因でエラーが出てるんでしょうか？また、どうすればきちんとコンパイルが通るようになるでしょうか？
85:デフォルトの名無しさん
05/11/08 03:39:19
祈る。
86:デフォルトの名無しさん
05/11/08 05:31:28
ダウンロードして上書き
エラーがでたら修正
87:デフォルトの名無しさん
05/11/08 08:35:44
>>84
STLportを使うのを諦める。
88:デフォルトの名無しさん
05/11/08 15:20:36
ちゃんとしたインストーラついたやつないの？
89:デフォルトの名無しさん
05/11/08 21:54:42
>>88
そんなに欲しけりゃ自分でインストーラ作れ。
ただでこんな素晴らしいライブラリが手に入る事だけでも感謝できないのかね君は？
90:デフォルトの名無しさん
05/11/08 22:25:40
インストーラが無いと使えないような香具師はプログラマを諦めた方がいい。
91:デフォルトの名無しさん
05/11/09 01:02:23
っていうかインストーラいらんじゃん
92:デフォルトの名無しさん
05/11/09 12:09:00
いるよバカ
93:デフォルトの名無しさん
05/11/09 13:49:09
>>92
>>90
94:デフォルトの名無しさん
05/11/09 21:08:12
無いと使えないような奴だけが必要なわけじゃないしな
95:デフォルトの名無しさん
05/11/10 00:04:19
list::sort()のアルゴリズムがよく解らないのですが、
これは何か名のあるアルゴリズムなのでしょうか？
96:デフォルトの名無しさん
05/11/10 00:11:19
template<class T>
class Hoge {
....
int foo(T arg);
};
で、
Hoge<void> hoge；
でも使える様にする、上手い手段って無い？？
97:デフォルトの名無しさん
05/11/10 00:13:01
>>96
テンプレートの特殊化で検索汁
98:デフォルトの名無しさん
05/11/10 00:23:19
>>95
実装にもよるけど、大雑把にクイックソートしてから最後に挿入ソートが一般的
99:デフォルトの名無しさん
05/11/10 00:35:02
>>97
それだと
........
の部分を、ほぼコピペしなくてはいけなくなるので、それを回避したい
100:デフォルトの名無しさん
05/11/10 00:49:44
>>99
template<class T>
class SuperHoge {
....
};
template<class T>
class Hoge: public SuperHoge<T>
{
int foo(T arg);
};
template<> class Hoge<void>: public SuperHoge<void>
{
int foo(void);
};
ってやってSuperHogeで....の部分を共有すればいい
101:デフォルトの名無しさん
05/11/10 01:12:01
>>100
サンクス！！
明日、これを利用して発展させてみます
102:デフォルトの名無しさん
05/11/10 02:18:58
>98
いやlistのsortなんですが。
で、風呂に入ってゆっくり考えてたら、
再帰を使わないマージソートだと気が付いた。
103:98
05/11/10 02:31:38
>>102
ごめん。
普通のstd::sortと読み間違えてた。
104:デフォルトの名無しさん
05/11/10 17:22:48
std::mapのfindで、指定したキーの要素が無かった場合はNULLが返るんでしょうか？
105:デフォルトの名無しさん
05/11/10 17:25:16
map<>::iteratorにNULLはない。
返るのはend
106:デフォルトの名無しさん
05/11/10 17:28:55
受け取ったiterator == endならば無いと言うことなんですね
わかりました
107:デフォルトの名無しさん
05/11/10 19:30:44
ｷﾓｲ仕様ですね
108:デフォルトの名無しさん
05/11/10 19:43:22
まぁstd::mapで要素の有無を調べるなら
countを使うしな。
109:デフォルトの名無しさん
05/11/10 19:48:28
こうして糞プログラムが量産されていくのでした
110:デフォルトの名無しさん
05/11/10 20:00:16
>>108
findならiteratorがそのまま処理に使えるしｗ
111:デフォルトの名無しさん
05/11/10 20:02:51
countの方が多少分かりやすいんだろうな
multi-ならfindじゃなきゃﾀﾞﾒだろうけど
112:デフォルトの名無しさん
05/11/10 20:08:07
ソースの読みやすいＳＴＬはどれですか？
113:デフォルトの名無しさん
05/11/10 20:28:28
>>110
見つけた要素を使って何か処理をするなら、勿論findだね。
でも有無を調べるなら、findは（ちょっとの差だけど）冗長だし直観的ではないと思う。
114:デフォルトの名無しさん
05/11/10 20:39:13
>>112
読みやすいかどうかは主観的なものなので、答えるとしたら
「知ったこっちゃねぇよ」だ。
115:デフォルトの名無しさん
05/11/11 01:52:17
そういえば、個人でOpen系に参加してるプロジェクトはSTLもboostも問題ないのに
今飯の種で参加してるVC6系の業務はSTLを使うと嫌われて、MFCのコンテナ使えって
お達しが来たなぁ
なんとか、STLをもっとC++ユーザに普及される道は無いんだろうか
あのままCPtrListをposを介してアクセスしてる糞ソースを見ると
今のプロジェクトが哀れに見えてくるんだが
116:デフォルトの名無しさん
05/11/11 10:05:46
初歩的な質問かもしれませんが
循環参照リスト（map）を作りたいです
循環参照といっても単なるディレクトリ構造で
１対多の双方向Treeなんですが（言葉が良くわからなくてゴメンナサイ）
どのコンポーネント使えばいいでしょうか
今はmapを使って smartポインタで構造体をラップして値を入れています
子→親は shared_ptr、親→子はweak_ptr
最後の子はヒープに残さないと消えてしまったり
delete時に親のmapから自分の登録を消す必要があったりと
なんか実装間違ってる気がしています
＃今までSTLもMFCも毛嫌いしていましたけど、今回から仕事でも導入です
117:デフォルトの名無しさん
05/11/11 12:01:15
>>115
VC6付属のSTLはバグが多いのでそのお達しは正しい。
118:デフォルトの名無しさん
05/11/11 12:09:05
>>117
それはSTLじゃなくてtemplateの問題だろうに.
119:デフォルトの名無しさん
05/11/11 12:51:37
VC6同梱のバグ有りSTLはDinkumwareで修正した奴配ってたような気がする。
120:デフォルトの名無しさん
05/11/11 12:56:32
ついでだから調べて見たけど、リンク切れてるな。
URLﾘﾝｸ(dinkumware.com)
なんでもvectorの要素数拡張にバグがあったみたいね。
121:119=120
05/11/11 13:00:38
URL間違ってたｽﾏﾇorz
ここに詳細があった。
URLﾘﾝｸ(www.dinkumware.com)
SP3当たってればFixされてるようなことも書いてあった。
122:デフォルトの名無しさん
05/11/11 13:17:12
template<typename PosT>
class Coordinate2D{
PosT x, z;
};
template<typename PosT>
class Coordinate3D : public Coordinate2D{
PosT y;
};
template<typename CoordT, typename PosT>
class Polygon : public std::vector<CoordT<PosT> >{ //CoordTがテンプレートじゃねぇと怒られる
};
こんな感じで、class Polygon に std::vectorを継承し、
また、CoordT は Coordinate2D<PosT> か Coordinate3D<PosT> のみを
受け付けるようにするにはどうしたらいいのでしょうか？
あと、もしよろしければこういう設計のほうがいいとかあれば指摘お願いします
123:デフォルトの名無しさん
05/11/11 13:35:45
template<typename PosT>
-class Coordinate3D : public Coordinate2D{
+class Coordinate3D : public Coordinate2D <PosT> {
PosT y;
};
-template<typename CoordT, typename PosT>
+template<template <typename> class CoordT, typename PosT>
class Polygon : public std::vector<CoordT<PosT> >{ //CoordTがテンプレートじゃねぇと怒られる
};
+int main ()
+{
+ Polygon <Coordinate2D, double> p2;
+ Polygon <Coordinate3D, double> p3;
+ return 0;
+}
124:デフォルトの名無しさん
05/11/11 13:58:15
>>123
期待通りのものができそうです
ついでに typename と class の違いも消化できそうです
ありがとうございました
125:デフォルトの名無しさん
05/11/12 09:36:14
URLﾘﾝｸ(sourceforge.net)
STLport 5.0 正式版がリリースされているようですよ
126:デフォルトの名無しさん
05/11/12 09:55:16
>>81でがいしゅつ
127:デフォルトの名無しさん
05/11/12 10:00:04
だヵら何？
128:デフォルトの名無しさん
05/11/12 14:15:00
Q: それ自体が意味を持つ情報に向かって、「それで？」とか「だから何？」とか
返す人がいますが、これはどういう意味なのでしょう？
A: 「どうだ！」とばかりに披露した投稿にケチをつけられて悔しかった人が、
相手の発言を「その先に何かが無いと価値がない」ことにしたい時に使います。
しかしご存じのように、大抵は悔しさを見透かされるだけに終わり、成功の望みは薄いです。
129:デフォルトの名無しさん
05/11/12 16:05:28
ある簡単な問題を解くためにプログラムを作ったんですが,
vectorを使った場合とlistを使った場合で結果が異なりました．
問題はある複数の要素を入れ替えるのを繰り返すというものです.
listでやった場合は,要素の集まりlsの入れ替える先頭まで
イテレータを移動して,そこからc個だけ移動するので
さらにc個イテレータを移動し,その間の要素を
insertし,eraseしています.
for (int i = 0; i < n; i++) {
cin >> a >> b;
list<int>::iterator start = ls.begin();
for(int j = 0; j < a; j++) start++;
list<int>::iterator end = start;
for(int j = 0; j < b; j++) end++;
ls.insert(ls.begin(), start, end);
ls.erase(start, end);
}
このlistの部分をvectorに書き換えて,vにしたところ
for (int i = 0; i < n; i++) {
cin >> a >> b;
v<int>::iterator start = v.begin();
for(int j = 0; j < a; j++) start++;
v<int>::iterator end = start;
for(int j = 0; j < b; j++) end++;
v.insert(v.begin(), start, end);
v.erase(start, end);
}
異なる結果が出たのですが,どのような理由が考えられるでしょうか？
130:デフォルトの名無しさん
05/11/12 16:24:16
listの方はinsertしてもイテレータの指してる要素はそのまま使用可能だからいいけど
vectorの方は
v.insert(v.begin(), start, end);のところで
startとendのイテレータが駄目になってしまうから
その後にv.erase(start,end)ってやってはだめ
131:デフォルトの名無しさん
05/11/12 18:10:52
>>130
なるほど,vectorの場合は挿入,削除をしたら再取得しないとだめなのですね.
それに関しては分かったのですが,その後いくつか内容を出力してみたところ,
どうやら
v.insert(v.begin(), start, end);
この時点ですでにstartとendがずれているようでした.
ためしにv（内容は0,1,2,3,4）に対して以下のような操作をしたところ
vector<int>::iterator start = v.begin();
vector<int>::iterator end = start;
end++;
v.insert(v.begin(), start, end);
これと,startをインクリメントしたもの
vector<int>::iterator start = v.begin();
start++;
vector<int>::iterator end = start;
end++;
v.insert(v.begin(), start, end);
これだと結果が変わらないのですが,insert(pos, start, end)の
このstartは挿入したい要素の始まりのイテレータで,
endは挿入したい要素の終わりの要素の次のイテレータを指定しているのですよね？
なぜかstartをインクリメントしてもしなくても結果が変わらないのですが
どうなっているんでしょうか？
132:デフォルトの名無しさん
05/11/12 18:13:13
STLPort5.0.0をMinGWに無事インストールして、動いた人いる？
俺はビルドは成功したものの、いざプログラムで使うと、リンク時に
多量のリンカエラーが出て、今の所使えないので、4.6.2に戻してしまった。
133:デフォルトの名無しさん
05/11/12 19:58:59
vectorの全要素をファイルに出力したいんだけど、まとめてやる方法とかないの？
やっぱり、要素を一つずつファイルに出力するしかないのかな？
134:デフォルトの名無しさん
05/11/12 20:04:14
>133
std::for_each
135:デフォルトの名無しさん
05/11/12 20:04:41
>>133
copy+ostream_iterator
136:133
05/11/12 20:05:31
さっそくどうも
137:デフォルトの名無しさん
05/11/12 20:16:13
>>131
どうなると思っていて、実際にはどうなったかをちゃんと書け。
138:デフォルトの名無しさん
05/11/12 20:47:55
>>137
インクリメントとかは関係なかったようです.
知りたいことは,insert(v.begin(), start, end)として,
vの中身は 5 4 3 2 1. また,startは3で,endが2, なので
この場合3をbegin()の直前に挿入して 3 5 4 3 2 1 としたいのですが,
これが 4 5 4 3 2 1 になってしまいます.
挿入する位置,この場合であればbegin()よりも後にstartとendが
位置しているからおかしくなっているとは思うのですが,実際のところ
範囲を指定して挿入するinsert()は,挿入する位置よりも後にある
部分はvectorの場合指定できないということでいいのでしょうか？
139:デフォルトの名無しさん
05/11/12 21:02:51
ていうか挿入元の値が挿入してる最中に変わってしまうようなやり方は危険だからやめた方がいいよ
一度別のvectorにコピーしてから挿入するとかしないと
140:デフォルトの名無しさん
05/11/12 21:17:51
>>139
うーむやはり無難にコピーしたほうがいいのですね.
ありがとうございました.
141:デフォルトの名無しさん
05/11/12 21:22:43
>>138
23.1.1 Sequences Table 67
Sequence requirements (in addition to container)
expression │return type │assertion/note
│ │pre/post-condition
────────────
a.insert(p,i,j) │void . │pre: i,j are not iterators into a.
│ │inserts copies of elements in [i,j) before p.
とあるから、std::vectorにおいて、自分のiteratorを使っての
挿入にはinsertを使用してはならない。
142:デフォルトの名無しさん
05/11/13 15:59:15
>138
vectorの構造を考えれば、まあねぇ……
vectorが挿入用のスペースを用意するには、挿入箇所より後ろの部分を
順繰りに後ろにずらすのが一番手っ取り早いんだけど、そうすると、保存し
ておいたIteratorが使い物にならなくなるんだよね。
143:デフォルトの名無しさん
05/11/13 16:00:10
>138
あと、advacteとか使ったら？
144:デフォルトの名無しさん
05/11/13 16:02:26
>>142
ずらすだけで済めばまだいいが、再確保が起こる可能性まである。
どっちにしても使い物にならないという結論になるんだけどね。
145:デフォルトの名無しさん
05/11/13 18:50:32
>>143
advacteって何？std::advanceの事か？
146:デフォルトの名無しさん
05/11/13 20:24:57
std::mapで、文字列をキーにして使うことってできますか？
147:デフォルトの名無しさん
05/11/13 20:30:20
>>146
std::stringなら特に何も考えずに出来る。
148:デフォルトの名無しさん
05/11/13 20:38:04
stringってcinで使えないからなんかヤダ
149:デフォルトの名無しさん
05/11/13 20:39:17
>>147
ありがとうございます
150:デフォルトの名無しさん
05/11/13 20:45:21
stlのstringって中途半端だよね
sprintfみたいなの無いし
151:デフォルトの名無しさん
05/11/13 20:48:41
じゃあ作ってくれよ
152:デフォルトの名無しさん
05/11/13 20:56:50
>>150
stringはSTLじゃない。
153:デフォルトの名無しさん
05/11/13 21:00:41
なんで？
154:デフォルトの名無しさん
05/11/13 21:20:54
>>153
STLにbasic_stringなんてコンテナはないから。
STLのコンテナは
vector
list
deque
stack/queue/priority_queue
map/multimap
set/multiset
だけ。
STLに含めてもいいんじゃないかという意見もあるけど、
class myClass;
basic_string<myClass> str1;
ということが出来るclassはユーザー定義コピーコンストラクタ、
デストラクタ、コピー代入を持てないから一緒にするのはまずい。
155:デフォルトの名無しさん
05/11/13 21:25:12
>>150
(f)printf/(f)scanfがo(f)stream/i(f)stream(cout/cin)になったように、
sprintf/sscanfにはostringstream/istringstreamが存在する。
それが嫌ならboost::formatがある。
156:デフォルトの名無しさん
05/11/13 21:36:20
>>150
vectorとstringでいいじゃん
157:デフォルトの名無しさん
05/11/13 21:44:00
>154
C++ standardにはかわりないって。
string用のライブラリということでいいじゃない。そもそもSTLという用語自体あいまいだし。
>一緒にするのはまずい。
一緒にしちゃいけないのはコンテナも一緒だよ。
まあ、std::stringは失敗作くさいけどね……
158:デフォルトの名無しさん
05/11/13 21:45:09
>>154
STLってコンテナとアルゴリズムだけだっけ？
stirngとかbitsetは含まないのか。
159:デフォルトの名無しさん
05/11/13 21:49:02
std::stringは専用のﾒﾝﾊﾞ関数が大杉
boost::string_algoみたいに非ﾒﾝﾊﾞでもっと汎用的に実装できなかったものか
160:デフォルトの名無しさん
05/11/13 21:54:27
std::basic_string<>がSTLじゃないというのは操作がiteratorベースじゃない点。
161:デフォルトの名無しさん
05/11/13 22:13:21
>>152-160 >>14
162:デフォルトの名無しさん
05/11/13 22:17:01
大量の文字列をstringに突っ込んでるときに一文字増やすと大変なことになるなｗ
領域確保無しでなｗ
やっぱり、動作まで考えるとメモリは気がぬけねーなｗ
メモリボコボコになってもいいから、再確保なんてしないで、
つけたし部分をリストのノードを追加する感じでやってほしかった。
163:デフォルトの名無しさん
05/11/13 22:21:13
大量の文字列をstringに突っ込むなよ
164:デフォルトの名無しさん
05/11/13 22:27:20
長い文字列は非標準だがropeクラスでいける・・らしい
165:デフォルトの名無しさん
05/11/13 22:45:05
std::stringはstd名前空間にあるのにSTLじゃないんですか？
std名前空間の定義って何ですか？
166:デフォルトの名無しさん
05/11/13 22:51:15
std名前空間にあるのはC++標準ライブラリ。勝手にhash_mapとか突っ込んだ馬鹿も複数居るが。
狭義のSTLと呼ばれるのはAlex Stepanovが作成しC++標準化委員会に提案した一連のライブラリに属するもの。
ついでにいうとStepanovのオリジナルには含まれていたがC++標準ライブラリには含まれて居ないものもある。
167:デフォルトの名無しさん
05/11/13 23:04:39
>>162
VCならvectorと同様reserve()が使える。
GCCの場合、reserve()は実装されていない。
メモリ再確保時に多めに確保されるのでそれで我慢するしかない。
168:デフォルトの名無しさん
05/11/13 23:09:28
>>167
> GCCの場合、reserve()は実装されていない。
はつみみです。
ソースきぼん。
169:デフォルトの名無しさん
05/11/13 23:13:04
stringってバッファをこま切れのポインタ配列で管理してんじゃなかったっけ、
んで、c_str()した時に一つの配列に確保し直すとかじゃないの？
170:デフォルトの名無しさん
05/11/13 23:17:53
stringにもiteratorあるよ？
171:デフォルトの名無しさん
05/11/13 23:18:43
>>169
他のstlは知らないが少なくともvcに付属のstlは
駒切れじゃなくてcapacity()を超えるごとに確保しなおしてるよ
172:デフォルトの名無しさん
05/11/13 23:18:47
>>169
何その無駄仕様な妄想
173:デフォルトの名無しさん
05/11/13 23:19:02
>>168
今gccのヘッダー見てみたけどreverse()はなかったよ。
174:デフォルトの名無しさん
05/11/13 23:23:15
stringの場合vectorと違って連続したバッファに確保しろと規定されてないからどう実装しようとOK
175:デフォルトの名無しさん
05/11/13 23:27:54
>>173
#include <string>
void f(std::string& s) { s.reserve(1); }
これがエラーになるのか？
手元の gcc 3.4.4 @cygwin では普通にコンパイルできたよ。
176:デフォルトの名無しさん
05/11/13 23:41:07
いつになったら>>173の大馬鹿が露見することやらｗ
177:デフォルトの名無しさん
05/11/13 23:42:47
>>176
お前ヘッダファイルって、もしかして読んだこと無いのか？ｗ
178:デフォルトの名無しさん
05/11/13 23:43:26
×>>176
○>>173
>>173
どのヘッダー読んだんだ？ｗ
179:デフォルトの名無しさん
05/11/13 23:44:51
<string.h>か<cstring>じゃまいか
180:デフォルトの名無しさん
05/11/13 23:46:57
>>179
それだと「GCCの場合、 basic_string は実装されていない。」ってなるだろ。
181:デフォルトの名無しさん
05/11/13 23:47:09
もっと根本的な問題でマジでreverseを検索したに1票ｗ
~~~~~
182:デフォルトの名無しさん
05/11/13 23:47:18
良くﾜｶﾗﾝが、昔のgccを見たのかもね
なんにせよﾎﾞｹだが
183:デフォルトの名無しさん
05/11/13 23:47:41
>> 172
Stroustrup の C++ 本にはそんな感じの図(S式っぽいの)がのってたんで、
そんな感じだと思い込んでたが、違ったのね Σ（ﾟдﾟlll）ｶﾞｰﾝ
184:デフォルトの名無しさん
05/11/14 00:05:28
reserve()がビルド通っただけでご満悦の>>175も問題だぞ。
誰か>>175にかまってやれよ。
185:175
05/11/14 00:10:10
いや、おかまいなく。
186:デフォルトの名無しさん
05/11/14 00:18:20
実運用上、ほとんどのケースで便利なのはGCCの仕様。
むしろVCのreserve()は、reserve()を呼び出さなければパフォーマンスが低下するので、
必要に迫られてreserve()を使う場合が多い。
いちいちreserve()呼び出ししなくてもそれなりのパフォーマンスを出すGCCの方が扱いが楽。
それはちょうど、FILEの入出力でいちいちフラッシュする手間が必要か否かに似ている。
明示的にフラッシュする必要がない方が楽なのは言うまでもない。
187:デフォルトの名無しさん
05/11/14 00:55:45
>>186
GCC と VC の reserve の仕様ってどう違うんですか？
188:デフォルトの名無しさん
05/11/14 01:04:30
reserveの仕様じゃなくてバッファ確保の仕様が違うんだろ？
189:デフォルトの名無しさん
05/11/14 01:10:02
>>187,188
reserve()に大きな数字を指定したのち、capacity()の戻り値を調べる。
さあ試せ。そして報告しろ。
190:デフォルトの名無しさん
05/11/14 02:40:41
結論：ＧＣＣ最強
ＶＣは糞
191:デフォルトの名無しさん
05/11/14 03:39:45
>>190
何が最強なのか言ってみ
192:デフォルトの名無しさん
05/11/14 03:45:27
・VCは以下の項目で最強です
シェア
ANSI準拠度
サポート
ヘルプ
ライブラリ
最適化
開発環境の使いやすさ
開発環境が求めるスペック
クライアントの盲信度
ゲイツ度
193:デフォルトの名無しさん
05/11/14 03:46:28
listの要素を追加するとき、push_back関数で一つずつ追加するのが
面倒なんだけど、これを一挙にやる方法は標準で装備されてないのかな？
例えば、
list<int> a;
a.push_back(34);
a.push_back(77);
a.push_back(25);
ってことをする代わりに、
a.add(34, 77, 25)
あるいは
a.add(3, 34, 77, 25)
みたいなことができればうれしいんだが。
ちょっと調べた感じでは無いみたいなんだけどな。
もし無いとしたら、これってちょっと面倒くさくない？
194:デフォルトの名無しさん
05/11/14 04:03:04
便利になる場面が思いつかない
195:デフォルトの名無しさん
05/11/14 04:10:50
list<int>& operator << (list<int>& a, int b) { a.push_back(b); return a; }
list<int>& operator , (list<int>& a, int b) { a.push_back(b); return a; }
list<int> lis;
lis << 1, 2, 3, 4, 5;
196:デフォルトの名無しさん
05/11/14 04:27:04
>>193
そんなに面倒だと思うなら自分で勝手に実装しろよ。
って書こうとしたら既に>195まで書かれていた罠。
197:デフォルトの名無しさん
05/11/14 04:33:03
自分で実装するんならBoost.Assignでも使った方が良さげ
198:デフォルトの名無しさん
05/11/14 04:35:44
そういや禿って不自然な演算子は書くな(widget += buttonみたいな)って行ってるのに
何で<<←こんな変なもん作ったんだ？
199:デフォルトの名無しさん
05/11/14 04:37:43
>>195
サンクス。非常に参考になりました。
200:デフォルトの名無しさん
05/11/14 04:39:40
operatorで変な定義しとくと後で困るのにwww
201:デフォルトの名無しさん
05/11/14 04:54:57
>>195
これって1,2,3,4,5の順に代入されるのって保証される？
202:デフォルトの名無しさん
05/11/14 05:16:26
yes
C++本3rd 6.2.2:
,(コンマ)、&&(論理積)、||(論理和)演算子では、左側の被演算子の方が右側の被
演算子よりも先に評価されることが保証されている。
だってさ
203:デフォルトの名無しさん
05/11/14 05:20:57
というか普通の2項演算子(左結合)と同じってだけか
204:デフォルトの名無しさん
05/11/14 05:22:59
operator<<は許せるとして
「,」にそんな定義したらまずいだろｗ
関数の引数にするときとかどうなるんだよｗ
205:デフォルトの名無しさん
05/11/14 07:31:47
>>204
func(lis, 1, 2) ← funcを3引数でcall
func((lis, 1, 2)) ← lis, 1, 2を実行の後、funcを1引数でcall
206:デフォルトの名無しさん
05/11/14 19:17:50
>push_back関数で一つずつ追加するのが
>面倒なんだけど、これを一挙にやる方法は標準で装備されてないのかな？
普通は、こんな漢字でない。？
strstreamでも同じでない。
std::ifstream in_file("sample_students.txt");
while (read(in_file, record)) // read and store all the records
{students.push_back(record);}
詳細は、acceleratedC++のソースを
207:デフォルトの名無しさん
05/11/14 19:32:17
>>202
それは組み込みの演算子だけの事情だし、評価順序と結合規則は別の概念だからここでは関係ない。
>>203で正解
208:デフォルトの名無しさん
05/11/14 19:56:09
>>193
Boostが嫌なら配列を使って何とかするというのもなくはない。
int Initializer[] = {34, 77, 25};
std::list<int> a(Initializer, Initializer + sizeof Initializer / sizeof Initializer[0]);
>>198
見た目からしていかにも流し込むという感じがして、なおかつ
元々の<<（シフト）の意味だってCで作られたものであり、数学的な歴史を持ったものでないから、
人々も比較的思い入れがなく馴染みやすいだろうということでこれにした、
というようなことがD&Eに書いてあったはず。
今手元になくて、大まかにしか思い出せないけど。
209:デフォルトの名無しさん
05/11/14 21:32:06
最初は < と > にしようと思ったけど、人々の頭には既に
「より小さい」「より大きい」という意味が強く刷り込まれていたので
シフト演算子にした、というのは、C++3rdのほうの氏の表現。
まぁ同じことを言っているのだと見ていいだろうね。
210:デフォルトの名無しさん
05/11/14 21:35:36
>>209
そう言われればそんなこともD&Eに書いてあったな。
211:デフォルトの名無しさん
05/11/15 20:05:54
<<= 演算子じゃいけなかったのかな？
212:デフォルトの名無しさん
05/11/15 20:07:18
あ、よく考えたら、<< と、<<= だと優先順位などの関係で
まとめてかけなくなるからダメか。
213:デフォルトの名無しさん
05/11/15 20:37:00
どっちにしてもキモくてなじめないなｗ
214:デフォルトの名無しさん
05/11/15 20:59:09
extern int operator BjaneStroustrup(int x,int y);
...
printf("output = %d",1 BjaneStroustrup 2);
...
output = 禿禿禿
215:デフォルトの名無しさん
05/11/15 21:04:36
ここ死んでるね。
216:デフォルトの名無しさん
05/11/15 21:06:02
>>214
コンパイルエラー
217:デフォルトの名無しさん
05/11/15 21:16:16
>>211
それだと入力が>>=になって見た目の対称が取れない。
218:デフォルトの名無しさん
05/11/15 21:29:49
MFC使いっす。
すっとばしてたSTLのことが気になってるんですけど、
勉強した方がいいコード書けるようになりますか？
winのアプリの性能が上がるとか、効率がよくなるとかなら勉強しようと
思うんですが、詳しい人教えてください。
219:デフォルトの名無しさん
05/11/15 21:33:56
じゃぁまずMFC使うのやめれ
220:デフォルトの名無しさん
05/11/15 21:36:09
MFCとSTLは競合するので同時に使用するのは無理ですよ
221:デフォルトの名無しさん
05/11/15 21:41:11
STL は汎用的な部品であって求めるべきなのは実行効率ではなく、開発効率じゃまいか？
222:デフォルトの名無しさん
05/11/15 21:41:33
>>218
そういうことを人に聞くような奴には使いこなせないと思う
223:デフォルトの名無しさん
05/11/15 21:46:02
>>220
偽。
>>221
何もかもインライン関数で書かれているからなんだかんだいって実行速度だって遅くない。
>>218
とりあえずMFCのコレクションクラスを使わずにSTLのコンテナクラスを使うことから始めてみろ。
224:デフォルトの名無しさん
05/11/15 21:47:55
>>219-220
普通にMFCでSTL使ったアプリを作って納品したことがあるのだが、
MFCとSTLが競合するとはどういうことなのか説明していただけるか。
225:デフォルトの名無しさん
05/11/15 21:49:13
>>218
コンテナクラス各種のことなら、使い方を間違うと性能を落とす可能性もあるが
保守性と開発効率と信頼性に効果があることが多い。
<algorithm>のような関数テンプレートのことなら、修得に難があるが
保守性と開発効率と信頼性に効果があることが多い。
>>219
んな無体な。
>>220
詳しく。
226:デフォルトの名無しさん
05/11/15 21:51:53
>>224
わしゃ、使うのやめろとは言ったが競合するとは言っとらんぞ
227:デフォルトの名無しさん
05/11/15 22:05:41
マルチスレッドのとき競合する事がある
228:デフォルトの名無しさん
05/11/15 22:08:35
>>227
それはMFCとSTLの競合ではないだろ。
229:224
05/11/15 22:22:54
>>226
大変失礼いたしました。てっきり同一人物かと早合点。
230:デフォルトの名無しさん
05/11/16 00:37:35
気になったのでぐぐってみた。
URLﾘﾝｸ(support.microsoft.com)
Q5 : MFC (Microsoft Foundation Classes) アプリケーションで標準 C++ ライブラリを使用した場合、C ランタイム ライブラリとの競合は発生しますか。
A5 : 競合は発生しません。MFC では、標準 C++ ライブラリと競合する C ランタイム関数は使用されていません。
とはいってもMSなので、地雷があったりするのかもしれんが。
231:デフォルトの名無しさん
05/11/16 00:43:06
ここで言ってる競合の意味は？「スレッドセーフでない」という意味？
必要に応じて自分で排他処理を埋め込む必要があるのはMFCだって同じ。
232:デフォルトの名無しさん
05/11/16 01:19:30
ちょい古めのＭＦＣでは CreateThread で作ったスレッドで
Ｃランタイムライブラリ使うとメモリ損失をおこすのでダメ、
でもってSTL も shuffle やらに rand() 使ってたりするんでダメって話題じゃないの？
233:デフォルトの名無しさん
05/11/16 01:23:44
>>232
MFCとSTLの競合とはちょっと意味合いが違うような。
有益な情報だが。
234:デフォルトの名無しさん
05/11/16 04:30:42
下手の考え 休むに似たり
235:デフォルトの名無しさん
05/11/16 06:59:04
>>232
MFCを使った場合も同様。
MFCのクラスや関数を使う場合はAfxBeginThread()を使わなければならない。
STLだけを敬遠する理由にならない。
236:デフォルトの名無しさん
05/11/16 19:10:29
ようじょにインサートするにはどのクラスを使えばいいの？
237:デフォルトの名無しさん
05/11/16 20:08:17
MFC使うとモッサリするからなるべくATＬ+STLでやる
238:デフォルトの名無しさん
05/11/16 20:57:45
ATL使うぐらいなら
COM+SDKでｵﾅﾆｰした方がまし
239:デフォルトの名無しさん
05/11/16 21:30:49
ATL自体には全くといっていいほど魅力がないのだが、
WTLを使う場合に必要なのでいつのまにかATLを使ったことになる。そんな感じ。
240:デフォルトの名無しさん
05/11/16 21:37:14
ATLはATL::CA2Wみたいな文字列変換関連が便利。
あとGetWindowLongPtrなんかをきちんとinline関数で定義しなおしてくれるのがありがたい。
241:デフォルトの名無しさん
05/11/16 23:26:45
ATLはこれ作った奴はイカれた天才だと分かるが
MFCを見るとこいつは俺なみにバカだなと思う
この差はなにか。予算が違うのか
242:デフォルトの名無しさん
05/11/16 23:34:35
単に設計された時代の差。
243:デフォルトの名無しさん
05/11/17 02:39:52
そんないいわけは通用しない！
なんだあのコントロールバーは！
244:デフォルトの名無しさん
05/11/17 20:49:21
listでeraseを使っているとassertに引っかかりました
eraseを使っている行が原因だということまでは突き止めましたが
何が原因かわからないので教えてください
for (it=mylist.begin() ; it!=mylist.end() ; it++)
{
if (条件)
{
it=mylist.erase(it);
}
}
Expression: list iterator not incrementable
For information on how your program can cause an assertion
failure, see the Visual C++ documentation on asserts.
245:デフォルトの名無しさん
05/11/17 20:50:43
>>244
> Expression: list iterator not incrementable
これ読め。
246:デフォルトの名無しさん
05/11/17 20:55:06
>>245
＞リストイテレータは加算できません
だと思うのですが何のことやらさっぱりです
加算といえばit++のことを指しているのでしょうがこれを無くすわけにもいきません
よろしくお願いします
247:デフォルトの名無しさん
05/11/17 20:55:41
お断りします
248:デフォルトの名無しさん
05/11/17 20:56:58
>>247
私のことを弄んだのですか？
249:デフォルトの名無しさん
05/11/17 20:57:13
>>244
つlist<>::remove_if()
250:デフォルトの名無しさん
05/11/17 21:04:00
>>246
ヒント: eraseの戻り値がend()かもしれない
251:デフォルトの名無しさん
05/11/17 21:07:25
>>249-250
ありがとうございます、理解できました
eraseがend()を指しているのにさらにit++してしまったのですね
remove_ifを使えば目的は達せられそうです
本当にありがとうございました
252:デフォルトの名無しさん
05/11/18 00:31:36
イテレータの不正領域インクリメントをassert()で教えてくれてるうちは、まだいい方でしょ。
インクリメント演算子の中で無限ループされた日には(ry
ブレークポイント置いてもどこで無限ループに突入したのか分からず困ったことがある。
253:デフォルトの名無しさん
05/11/18 01:24:47
アセンブラ読めないお前がヘタレすぎるだけだろ
254:デフォルトの名無しさん
05/11/18 07:50:40
つーか、ループ判定に使ってるイテレータを
わざわざeraseの戻り値で更新してるのがバカなだけだろ
255:デフォルトの名無しさん
05/11/18 09:30:07
要するに馬鹿と。
256:デフォルトの名無しさん
05/11/18 10:03:31
>>159
> boost::string_algoみたいに非ﾒﾝﾊﾞでもっと汎用的に実装できなかったものか
boost::string_algoは標準化される見込みが高いです。
URLﾘﾝｸ(www.open-std.org)
まあtemplateがなかった頃に設計されたものだからね。
専用のださメンバ関数は徐々にdeprecatedになっていくといいんだけど…
257:デフォルトの名無しさん
05/11/18 10:05:50
>>242
いや、MFC出た時点で、設計者はうすらとんかちだと思った。
258:デフォルトの名無しさん
05/11/18 15:24:37
>>254
いいえ、それ自体は普通の行動ですね。
バカなのは、それを「上手くやれない」人と、「それ自体がバカだと思っている」人だけです :-)
259:デフォルトの名無しさん
05/11/18 17:31:41
まぁそうむきになるなよｗ
260:デフォルトの名無しさん
05/11/18 18:10:53
>>257
「うすらとんかち」なんて単語見かけたの２０年ぶり位かも。
261:デフォルトの名無しさん
05/11/18 18:38:33
うすらとんかち
262:デフォルトの名無しさん
05/11/18 19:42:33
>>256
うは、ﾏｼﾞすか
次の規格改訂はshared_ptやらbindやらstring_algoやらで
かなり使い勝手が良くなりそうですな
263:デフォルトの名無しさん
05/11/18 19:57:45
標準化委員会はそんなに甘くない。
互換性という壁によって砕け散るだろうね。
264:デフォルトの名無しさん
05/11/18 21:51:31
とりあえずfilebufのコンストラクタにwchar_tなfilenameを渡せるようにしてくれると助かる。
Windowsだとそれなりに便利なのさ。なけりゃ自分で書くだけなんだけど。
265:デフォルトの名無しさん
05/11/18 21:57:47
正直標準にならなくてもboostがしっかり存在し続けていれば
それで良いような気がする。
266:デフォルトの名無しさん
05/11/19 01:32:10
>>264
URLﾘﾝｸ(www.open-std.org)
これのwstring版が欲しいって事だよね。
267:デフォルトの名無しさん
05/11/19 09:12:26
>>264
C++ 0xでfstream類のコンストラクタにFILE *を引数に取るコンストラクタを設けるという提案があった気がする。
これが実現すれば_wfopenが使えるようになって、それだけでもだいぶましなるのではと俺は思っている。
268:デフォルトの名無しさん
05/11/19 11:41:11
vectorって何でサイズ拡張するときにコピーコンストラクタとデストラクタを呼ぶの？
メモリ確保してデータを移動するんだったら↑のを呼ばなくても
ただmalloc→memcpy→freeだけでいいと思うんだが
269:デフォルトの名無しさん
05/11/19 12:19:53
そこまで単純なものじゃないから
270:デフォルトの名無しさん
05/11/19 12:30:44
いくらなんでも頭悪すぎだろ・・・
268はどんなクラス設計してきたんだ？
もしライブラリ自作してたらこいつのだけは
絶対使いたくないな。
271:デフォルトの名無しさん
05/11/19 12:33:14
いや、お前には使わせないから大丈夫(^o^)
272:デフォルトの名無しさん
05/11/19 13:04:21
頼まれても使わないから大丈夫(＾ω＾)
273:デフォルトの名無しさん
05/11/19 13:06:36
>>268
C使っときなさい。
274:デフォルトの名無しさん
05/11/19 13:13:13
まぁ、stlのvectorは無駄が多いのは周知の事実なわけだがな
275:デフォルトの名無しさん
05/11/19 13:23:22
無駄が多いのはおまいの設計が悪いだけ
276:デフォルトの名無しさん
05/11/19 13:35:05
低能はvbでも使っとけ
277:デフォルトの名無しさん
05/11/19 13:45:37
vectorを使ったとしても、プログラマはリソースの明示削除手続きから解放されるだけであり、
無駄が出ないように工夫する義務はプログラマにある。
278:デフォルトの名無しさん
05/11/19 13:55:40
まだvb馬鹿にしてる奴がいるのか、さすがstl厨
279:デフォルトの名無しさん
05/11/19 14:10:26
VBは所詮VB
280:デフォルトの名無しさん
05/11/19 16:07:53
STLとSTOってどっちがつおいの？
281:デフォルトの名無しさん
05/11/19 16:16:46
>>268
たとえばわざとらしいけどこういうクラスをvectorの要素にすることを考えてみたらいい。
class hoge
{
public:
hoge(int n) : num(n), p(this) {}
hoge(const hoge& x) : num(x.num), p(this) {}
int get() const {return p->num;}
private:
int num;
const hoge *p;
};
282:デフォルトの名無しさん
05/11/19 16:18:04
>>280
答えはキミの中にあります
283:デフォルトの名無しさん
05/11/19 17:17:07
コピーコンストラクタがいやなら shared_ptr 使うか、
vector<hoge* > ってすべきだな。
あとインスタンス化のたびに競合おこしたりとかいうのもあるし、
初期化~終了までファイルロックする類のクラス作ったりすると。
284:デフォルトの名無しさん
05/11/19 19:30:38
boost::ptr_vectorでもよい。
285:デフォルトの名無しさん
05/11/21 17:47:41
class FinallyCloseHandle {
private:
HANDLE h_;
public:
FinallyCloseHandle(HANDLE h) : h_(h)
{ if (h==INVALID_HANDLE_VALUE) throw; }
~FinallyCloseHandle() { CloseHandle(h_); }
};
というクラスを用意して
HANDLE file = CreateFile(...)
auto_ptr<FinallyCloseHandle> fch(new FinallyCloseHandle(file));
として、スコープを抜けるときに自動解放するようにしてるんですが、
これを汎用的に行う方法はないでしょうか
CloseHandle以外にも、いろいろ終了処理はありますが、
それに対して毎回似たようなクラスを作るのは、スマートとは思えません
atexitみたいな形で、スコープを抜けるときに呼び出す関数を
積んでおくことができると理想なのですが
286:デフォルトの名無しさん
05/11/21 17:56:11
boost::move_ptrやshared_ptrみたいに削除子を指定するのはﾀﾞﾒ？
287:デフォルトの名無しさん
05/11/21 18:10:35
>>286
サンキュー！そのものズバリが見つかったーよ
URLﾘﾝｸ(boost.cppll.jp)
以前、どこかのWebでスコープを抜けるときにコードを実行できるようなことを読んだ覚えがあって、
「スコープ 終了処理 指定」とかいろいろぐぐっても、なかなか見つけられなかったけど、
削除子で検索したら一発でした
288:デフォルトの名無しさん
05/11/21 18:59:33
その手のテクニックなら ScopeGuard も候補になるかな．
289:デフォルトの名無しさん
05/11/21 21:01:19
>>285
FinallyCloseHandle hFile = CreateFile(...);ではだめなのか？
290:デフォルトの名無しさん
05/11/22 00:49:20
>>288
さんくす！ScopeGuardも調べてみた
URLﾘﾝｸ(www.kmonos.net)
ここに実装例があったけど、ようは終了処理の関数と引数の参照を入れとくのね
勉強になります
>>289
あ、newじゃなくても良いですね
287に書いていますが、以前、どこかのwebでこの方法を見たとき
おぼろげにテンプレートを使って実現していたような覚えがあったので、
こんな風な書き方になってました
291:デフォルトの名無しさん
05/11/22 12:22:58
（数値地図から）200×200の数の行列？を読み込まし、iと、i＋1と、j、 j＋１で四点をとり、その４点の一番大きい値から小さい方へいくプログラムがつくれません
参照できるサイトありますか？わかる人いますか？ヒントください＞＜
もう三ヶ月悩んでます、助けて
馬鹿な為ほんとプログラムわからないんです
292:デフォルトの名無しさん
05/11/22 12:31:21
>>291
マルチ死ね
293:デフォルトの名無しさん
05/11/22 20:16:26
指定した条件に合致したインスタンスを指すイテレータを返す関数を作るときは
その返却値となるイテレータにNULLを使っていいんでしょうか？
294:デフォルトの名無しさん
05/11/22 20:25:50
>>293
つ[std::find_if()]
295:デフォルトの名無しさん
05/11/22 20:29:51
普通はendが返るんじゃね？
296:デフォルトの名無しさん
05/11/22 20:30:05
>>293
NULLはポインタにしかない。
297:デフォルトの名無しさん
05/11/22 21:53:50
>>294
うあ、そんな便利なものが…。
使ってみます。ありがとうございました。
>>295
>>296
なるほど。
std::find_if()してきて、それがend()かでエラー判定するんですね。
ありがとうございました。
298:294
05/11/22 23:17:49
<algorithm>や<numeric>はその手のロジックの宝庫だからね。
この辺に慣れるとちょっとした集計なんかがループを書かずにできる。
299:デフォルトの名無しさん
05/11/24 00:24:57
ちと古いネタにレスします
C++は一週間ぐらい前に始めたばかりなのでよくわかってないかもしれないけど、その辺はフォローよろしくです。
>>267
FILE * からfstreamを生成する場合、FILE*のクローズの責任（というよりFILE*の所有者）は誰になるのでしょう？
古いVCだとFILE*からfstream作った時は明示的にclose()呼ぶようにとか書いてあったような気がするんだけど、これじゃあまり使い道が・・・
自分で作ったfstream(Widefilename版)だとFILE *から作ってもデストラクタでクローズしてしまいます。
fstream(_wfopen(...))みたいな使い方を想定してます。
300:267
05/11/24 07:48:28
>>299
すまん。
たまたま耳にしただけであって，そこまで詳しいところは読んでいない。
でも俺が作るとしたら後者の方式（fstreamが所有権を持ちデストラクタでクローズする）にするな。
301:デフォルトの名無しさん
05/11/24 08:35:29
gcc拡張のstdio_filebuf, stdio_sync_filebufは、closeなし。
cin, cout, cerrのfilebuf先は、main()出た後のstdin, stdout, stderrのclose任せ。
302:デフォルトの名無しさん
05/11/24 18:25:52
ofstream ofs("output", ios::out | ios::binary);
list<int> mylist;
for (int i = 0; i < 10; i++)
mylist.push_back(i);
copy(list.begin(), list.end(), ostream_iterator<int>(ofs));
これで
00 00 00 00 01 00 00 00 02 00 00 00...というバイナリファイルが出来るという
わたしの願いは裏切られ、0123456789というテキストファイルが出来た。
なぜだろうね？
303:デフォルトの名無しさん
05/11/24 18:46:50
>>302
ios::binaryってフラグは、CR+LFのようなOS依存コードをcookedではなくて
rawで書け、って意味。
std::ostream_operator<int>←って指定してるじゃん。これじゃあ << で
出力したのと全く同じ。
バイナリで書きたければwrite()を使いなせえ。
304:デフォルトの名無しさん
05/11/24 18:50:17
あ、put()でもいいよ。
305:デフォルトの名無しさん
05/11/24 18:53:43
どうしてもアルゴリズムでバイナリを出力したければ、ユーザー定義の
バイナリ出力反復子を作るか、<<を多重定義し、バイナリ出力
専用のクラスを作り、for_eachで渡すか、だなあ。
306:302
05/11/24 19:23:10
詳しくありがとう。
307:デフォルトの名無しさん
05/11/24 19:46:18
反復子のユーザ定義は、traitsの引き継ぎが面倒なので、バイナリ出力
クラスを作ってみた。
#include <fstream>
#include <list>
#include <algorithm>
class OutBin {
std::ofstream& of;
public:
OutBin(std::ofstream& ofs) : of(ofs) {}
void operator()(int i) {
of.put(static_cast<char>(i));
}
};
int main()
{
std::ofstream ofs("output", std::ios::out | std::ios::binary);
std::list<int> mylist;
for (int i = 0; i < 10; i++)
mylist.push_back(i);
std::for_each(mylist.begin(), mylist.end(), OutBin(ofs));
}
308:デフォルトの名無しさん
05/11/24 20:07:49
これも反復子に手を加えない一例。std::copy()が使える。
#include <ostream>
#include <fstream>
#include <list>
#include <algorithm>
#include <iterator>
class OutBin {
int j;
public:
friend std::ostream& operator<<(std::ostream& os, const OutBin& o);
OutBin(int i) : j(i) {}
};
std::ostream& operator<<(std::ostream& os, const OutBin& o)
{
os.put(static_cast<char>(o.j));
return os;
}
int main()
{
std::ofstream ofs("output", std::ios::out | std::ios::binary);
std::list<int> mylist;
for (int i = 0; i < 10; i++)
mylist.push_back(i);
std::copy(mylist.begin(), mylist.end(), std::ostream_iterator<OutBin>(ofs));
}
309:デフォルトの名無しさん
05/11/25 07:26:24
私は、fstream系をデバッグトレース出力にしか使わないなぁ。
とりあえずトレースしたいときは、色んな構造体に対して<<演算子がオーバライドされてると、便利だ。
でも、一般のファイルを読み書きする時は専らcstdioを使う。
皆さんはどう？
310:デフォルトの名無しさん
05/11/25 08:30:44
cstdio を使う理由なんて、互換性以外に何があるんだ。
使いわけたりしねぇよ…。
311:デフォルトの名無しさん
05/11/25 09:14:02
fstreamって何でこうもまあ低速なの？
312:デフォルトの名無しさん
05/11/25 09:58:43
>>310
iostream・fstreamはファイルサイズが無駄に大きくなる。
ちょっとしたコンソールアプリには、iostreamは大げさすぎる実装だ。
313:デフォルトの名無しさん
05/11/25 10:31:01
今時数十KB増えるくらい蚊に刺されたようなもんじゃん。
314:デフォルトの名無しさん
05/11/25 10:55:12
>>312
それなら C 使えば？
315:デフォルトの名無しさん
05/11/25 12:38:37
また莫迦が STL ｽﾚで stream の話してるよ…
316:デフォルトの名無しさん
05/11/25 12:45:01
>>315
過去ログと空気は読む物ってことだわな
317:デフォルトの名無しさん
05/11/25 12:55:52
まぁSTLという言葉の定義に持ち込む>>315のほうが馬鹿だけどね。
318:デフォルトの名無しさん
05/11/25 13:07:39
>>307-308
便乗で申し訳ないが、basic_ostream< wchar_t > への対応版も希望
319:デフォルトの名無しさん
05/11/26 10:46:08
URLﾘﾝｸ(dl.njfiw.gov.cn)
320:315
05/11/29 16:18:06
>>316-317
初代ｽﾚから居るが。
時々思い出したように粘着しているだけだ。
321:デフォルトの名無しさん
05/11/29 19:07:08
>>320
？ お前はまさにそこをイジられてるんだが、何をわざわざ説明してるんだ？
322:デフォルトの名無しさん
05/11/29 22:18:12
>>318
亀レスだが、コンストラクタを変換関数の代わりに使っているので、
OutBin(wchar_t)と、intとwchar_tを受け取った場合のフラグでも
増設して、operator<<の動作を切り替えればいいやん。
323:デフォルトの名無しさん
05/11/30 19:03:24
vector とかよりももっと複雑な、
一般のグラフ構造のリンク関係を持ったアイテム集合を
うまく扱うためのコンテナクラスライブラリってありませんか？
324:デフォルトの名無しさん
05/11/30 19:03:55
コンテナクラスライブラリってあんまり使わないみたいなんで
テンプレートクラスライブラリって言い換えます。
325:デフォルトの名無しさん
05/11/30 19:09:37
クラステンプレートであってテンプレートクラスではない。
STLには存在しないがboost::graphというものは存在する。
326:デフォルトの名無しさん
05/11/30 21:57:09
質問です。
以下のテンプレートクラスのstd::map<KEY, VAL>::iterator
の部分でコンパイルエラーが発生します。
コンパイルを通す方法ありますか？
環境： g++ 3.4.2
template<typename KEY, typename VAL>
class MyMap : public std::map<KEY, VAL>
{
public:
MyMap()
{
std::map<KEY, VAL>::iterator it = begin();
}
};
327:デフォルトの名無しさん
05/11/30 22:00:53
>>326
typename std::map<KEY, VAL>::iterator...
328:デフォルトの名無しさん
05/11/30 22:09:59
>>327
ありがとうございます。
どうしてtypenameをつけるとコンパイル通るんですか？
329:デフォルトの名無しさん
05/11/30 22:20:14
>>328
URLﾘﾝｸ(www.fides.dti.ne.jp)
330:デフォルトの名無しさん
05/11/30 23:11:44
>>329
停滞してるな
331:デフォルトの名無しさん
05/11/30 23:12:31
逃した魚は大きいぞ
332:デフォルトの名無しさん
05/11/30 23:59:56
>329
そこを読んで思ったんだが、
typedefの時にtypenameを書かないと通らないコンパイラってあるの？
typedefの引数？は型名に決まっているんだから必要ないように思えるだが。
333:デフォルトの名無しさん
05/12/01 00:14:14
>>332
そうやって勝手に標準規格をねじ曲げたのがVC7.1だろう。
VC7.1だけ使ってると、typenameが必要だって事が学習しにくい。
334:デフォルトの名無しさん
05/12/02 01:38:49
7.1はわりとtypenameについて忠実じゃなかったっけ？
6が酷かったのは覚えているが。
335:デフォルトの名無しさん
05/12/02 02:07:50
いや全然
336:デフォルトの名無しさん
05/12/02 02:12:05
そうか気のせいだったか。
337:デフォルトの名無しさん
05/12/04 20:17:12
>>333
typenameなんていらないじゃん。未熟なコンパイラを救うためだけのもんだろ。
338:デフォルトの名無しさん
05/12/04 20:21:40
>>337
typename は未熟な C++ 言語仕様を救うためのもんだよ。
コンパイラベンダがどうこうするもんじゃない。
339:デフォルトの名無しさん
05/12/04 20:30:15
即ち禿がC++に毛を生やす努力をすればtypenameはいらない。
340:デフォルトの名無しさん
05/12/04 22:16:07
お前らいつもいつも禿禿って…いい加減にしろよ？
341:デフォルトの名無しさん
05/12/04 22:42:49
あ、びょーん先生こんにちは。
今日も落ち武者ヘアー似合ってますよ。
342:デフォルトの名無しさん
05/12/05 22:45:19
vectorの安全性に関する質問です。
先頭要素のポインタを取得して、それを進めた場合
正しいアドレスを指す保障はありますか？
int *p;
std::vector<int> ivec;
ivec.push_back(100);
ivec.push_back(200);
ivec.push_back(300);
p = &ivec[0];
p++;
p++;
printf("%d", p);
一応これの出力は300と出ます。
343:デフォルトの名無しさん
05/12/05 22:53:11
>>342
vector<bool> 以外はある。
23.2.4-1
The Elements of a vector are stored contiguously, meaning
that if v is a vector<T, Allocator> where T is some type
other than bool, then it obeys the identity
&v[n] == &v[0] + n for all 0 <= n < v.size().
344:デフォルトの名無しさん
05/12/05 22:55:11
事前条件として !ivec.empty() に注意ね
345:デフォルトの名無しさん
05/12/07 19:20:03
Boostを使わずにSTLのみで、スマートにcsvファイルを読み込めたりする？
346:デフォルトの名無しさん
05/12/07 19:27:03
>>345
RFC4180を見る限り、スマートにってのは無理みたいだね。
347:デフォルトの名無しさん
05/12/07 19:33:15
>>346 そんな RFC があったのか・・・
348:デフォルトの名無しさん
05/12/07 20:00:03
たしか超最近出来たRFCだろそれ
349:デフォルトの名無しさん
05/12/07 20:56:06
>>346
そんなのあったのか
つかC/C++でCSVファイルを読むのはクソだるいんだよな
書くのは楽なんだが。
350:デフォルトの名無しさん
05/12/07 21:18:00
Java だと楽なの？CSVファイル読むの。
いや、俺、Javaほとんど使ったことないから。
351:デフォルトの名無しさん
05/12/07 21:43:47
CSVつってもExcel仕様のCSVとか色々あるんじゃないの。
引用符の処理や複数行のセルとかどうすんだとか。
352:346
05/12/07 22:26:19
>>347-349
今年10月にできてる
353:デフォルトの名無しさん
05/12/08 00:43:10
URLﾘﾝｸ(www005.upp.so-net.ne.jp)
ここの雛形を使ってイテレータを作ってみようと思ったんですが、
'iterator' : 定義されていない基本クラスが宣言されています
となってしまいます。
#include <iterator>
の他にする事があるんでしょうか？
354:デフォルトの名無しさん
05/12/08 00:57:48
名前空間じゃね?
355:デフォルトの名無しさん
05/12/08 01:06:30
>>354
using namespace std;
または
std::iterator
としたらすんなり通りました。
ありがとうございました。
356:デフォルトの名無しさん
05/12/08 01:18:01
RFCってのは4月にチェックするものだと言うすり込みがあるのでしらんかった。
357:デフォルトの名無しさん
05/12/08 01:23:57
さすがにそれはどうかとｗ
確かに俺も毎年4月は確認するけどさｗｗｗ
358:デフォルトの名無しさん
05/12/08 01:51:41
>>350
Javaは標準ライブラリに、StringTokenizer があるから、
少なくとも、C++標準だけでやるよりは楽。
359:デフォルトの名無しさん
05/12/08 01:53:16
>>358
StringTokenizerはCSVのパーシングにおいては何の役にも立たないと思うぞ
360:デフォルトの名無しさん
05/12/08 01:55:19
そうなの？
まぁ、でもRegexあるけど。
361:デフォルトの名無しさん
05/12/08 01:56:38
>>360
人に聞く前に>>346にせっかく挙がってるRFC嫁よ
362:デフォルトの名無しさん
05/12/08 02:25:12
a","b""bb","ccc CRLF
ﾋﾄﾞｽ
でもBNFがあったのですぐ解った
363:デフォルトの名無しさん
05/12/08 06:39:02
CSVが難しいのは、ハウス規格がたくさんあるからで、
>>358>>359>>360の言っているような問題じゃない。
>>362
Shift_JISだと、あのBNFじゃ駄目だけどね。
364:デフォルトの名無しさん
05/12/08 11:47:10
あー、RFCだから仕方ないけどCrLf限定になってるし2バイト文字が通らない。
これもまた実態に合わないのか。
365:デフォルトの名無しさん
05/12/08 12:02:30
Category: Informational
366:デフォルトの名無しさん
05/12/08 13:55:59
CSVなんかはPerlで読んじゃうな
前処理させとくだけでもずいぶん楽だし
367:デフォルトの名無しさん
05/12/08 20:25:06
>>366
正しいと思う。
CSVファイル読込が全体に占める消費時間は微々たる物になるケースがほとんどだし。
368:デフォルトの名無しさん
05/12/09 04:06:12
RFC 書いた人、実体分かって書いてるのかな。
369:デフォルトの名無しさん
05/12/09 12:23:24
Boost.Spirit フレームワークで、簡単お手軽CSVパーサを作れば
かなりイイ感じだが、>>345 は、「Boost を使わず」といってるし…
370:デフォルトの名無しさん
05/12/09 12:56:16
>>364
詳細きぼん。
マルチバイト文字に関しては
> Common usage of CSV is US-ASCII, but other character sets defined
> by IANA for the "text" tree may be used in conjunction with the
> "charset" parameter.
ってあるし、改行に関しても
> As per section 4.1.1. of RFC 2046 [3], this media type uses CRLF
> to denote line breaks. However, implementors should be aware that
> some implementations may use other values.
とある。別に制限するものではないと思うけど。
371:デフォルトの名無しさん
05/12/09 13:42:54
>>370
> 別に制限するものではないと思うけど。
このメディアタイプではCR LFのみだよ。
曖昧にしたら駄目じゃん。いまさらRFCにする意味が半減。
ローカルシステムはCRのみやLFのみかもしれないから、
実装する奴は気をつけろって事。
世間では色々乱れてるから、このメディアタイプ定義で
(インターネット上での)データ交換の規準ができた。
372:デフォルトの名無しさん
05/12/09 13:45:12
↓これね。
4.1.1. 行分断（改行）の表現
MIME"text"サウブタイプの正式書式は、必ずCRLF列（連続体）として行分断を
表現しなければなりません。同じ様にMIME"text"でのCRLFの出現は如何なるも
のでも行分断を表現します。行分断以外でのCRとLFの使用も禁じられています。
この規則は、書式もしくは文字セットもしくは含まれている設定に関わらず、
適用されます。
URLﾘﾝｸ(www.asahi-net.or.jp)
373:デフォルトの名無しさん
05/12/14 11:18:38
ポインタのlistのsortの仕方が分からないよ！
class MyClass {
int value;
bool operator<(const MyClass& o) {
return value < o.value;
}
};
template<class T>
class ptr_less
{
public:
inline bool operator()(T left, T right)
{ return (*left) < (*right); }
};
int main() {
std::list<MyClass *> mylist;
// 色々と要素挿入（省略）
std::sort(mylist.begin(), mylist.end(), ptr_less<MyClass *>());
}
エラーが一杯出る…
374:デフォルトの名無しさん
05/12/14 11:31:29
mylist.sort()
list に std::sort は使えないんじゃ
375:デフォルトの名無しさん
05/12/14 11:34:55
>>373
list.sort();
376:デフォルトの名無しさん
05/12/14 11:37:23
>>373
もうちと付け足す。std::sort()は、random access iteratorを要求している。
しかし、std::list::iteratorは、bidirectional iterator なので、コンパイルが
通らない。
それでは使い勝手が悪いので、std::list::sort()が用意されている。こちらは
マージソートが歴史的な理由から採用されており、bidirectional iterator
でも動くようになっている。
377:373
05/12/14 12:38:31
どうもありがとう！
でも、mylist.sort(ptr_less<MyClass *>());とやると、
error C2664: 'void __thiscall std::list<class MyClass *,class std::allocator
<class MyClass *> >::sort(struct std::greater<class MyClass *>)'
: 1 番目の引数を 'class ptr_less<class MyClass *>' から 'struct std::greater
<class MyClass *>' に変換できません。 (新しい機能 ; ﾍﾙﾌﾟを参照)
ｺﾝｽﾄﾗｸﾀはｿｰｽ型を持てません、またはｺﾝｽﾄﾗｸﾀのｵｰﾊﾞｰﾛｰﾄﾞ ﾚｿﾞﾘｭｰｼｮﾝがあいまいです。
というお叱りが。std::greaterしか受け付けない？
URLﾘﾝｸ(rararahp.cool.ne.jp)
ここのページによると原因はVC6だかららしい。
ついでに解決策を参考にして、何とかソート出来た！
378:デフォルトの名無しさん
05/12/14 14:06:07
>>376
ついでに補足しておく。
C++標準において、「std::list<>::sort()がStableソートであり、等価な要素の
相対的な位置関係が保たれること」が、保証されている。
で、歴史的な理由により、ほぼ全ての実装でマージソートが採用されている。
(が、その保証はない)
379:デフォルトの名無しさん
05/12/14 19:51:00
επιστημη ←こいつ調子に乗ってるな
何様だよ
380:デフォルトの名無しさん
05/12/14 19:55:23
こんなところで吠えてないで本人に直接言えよ
381:デフォルトの名無しさん
05/12/14 21:58:36
標準化メンバーの1人だっけ?
382:デフォルトの名無しさん
05/12/14 23:28:12
そだよ、標準ライブラリの一部も彼を含めた日本の標準化委員会の案
383:デフォルトの名無しさん
05/12/14 23:53:13
>>379
過疎スレにいってらっしゃい。
επιστημηってウザくね？
ｽﾚﾘﾝｸ(tech板)
384:デフォルトの名無しさん
05/12/15 23:21:33
ハーバート・シルトのSTL標準講座という本でSTLの勉強をしていたのですが
どうしてもわからないものにぶち当たってしましたました。
下記のソースのなかで
p = find_if(v.begin(), v.end(), iscomma);
とありますがこの中のiscommaが何も実引数を持たずに呼び出されています。
これってどういうことなのでしょうか？
もしお時間のある方いらっしゃいましたらご教授お願いいたします。
･･･････････････････････････・・・・・・・・・・・・・・・・
// find()とfind_if()の用例
#include <iostream>
#include <vector>
#include <algorithm>
#include <cstring>
using namespace std;
// chがカンマならtrueを返す
bool iscomma(char ch) {
if(ch==',') return true;
return false;
}
int main() {
vector<char> v;
vector<char>::iterator p;
char str[] = "One, Two, Three";
int i;
for(i=0; i<strlen(str); i++) v.push_back(str[i]);
p = find_if(v.begin(), v.end(), iscomma);
cout << "After find first comma: ";
while(p != v.end()) cout << *p++;
cout << endl;
return 0;
}
385:デフォルトの名無しさん
05/12/15 23:25:25
そこで呼び出されてるわけじゃない。
関数のアドレスを渡してるだけ。
386:デフォルトの名無しさん
05/12/15 23:26:58
>>384
そもそも呼び出されてすらないし。find_ifに関数渡してるだけでしょ。
find_ifの中の人がiteratorを実引数にしてiscommaを呼び出すってだけの話。
387:デフォルトの名無しさん
05/12/15 23:27:40
Oppsかぶったかぶった。
388:デフォルトの名無しさん
05/12/15 23:51:56
>>385-386
ものすごく納得いきました。ありがとうございます。
389:デフォルトの名無しさん
05/12/16 02:58:10
>>388 は qsort とか使ったことなかったのかな・・
390:デフォルトの名無しさん
05/12/16 06:00:51
皆が皆CからC++へ行くわけじゃないからね。
391:デフォルトの名無しさん
05/12/16 06:34:27
qsortはCの関数だがな
392:デフォルトの名無しさん
05/12/16 07:00:16
話がかみ合ってない悪寒
393:デフォルトの名無しさん
05/12/16 08:10:52
>>385
> 関数のアドレスを渡してるだけ。
関数オブジェクトを渡しています。
394:デフォルトの名無しさん
05/12/16 08:12:50
>>393
馬鹿ですか？関数と関数オブジェクトの見分け方ぐらい
付けられるようになっとけ。
395:デフォルトの名無しさん
05/12/16 11:09:08
>>387
オップス?
もしかして：Oops!
396:デフォルトの名無しさん
05/12/16 14:31:25
↓>>393の必死な言い訳
397:デフォルトの名無しさん
05/12/16 16:22:37
関数⊂関数オブジェクト
398:デフォルトの名無しさん
05/12/16 16:25:37
もう少しこう、うっかり騙されそうなネタで頼む
399:デフォルトの名無しさん
05/12/16 16:43:58
↓素直に自分の無能を認める>>393
400:デフォルトの名無しさん
05/12/16 17:07:28
俺が悪かった
401:デフォルトの名無しさん
05/12/16 17:12:16
いや俺のほうが悪い
402:デフォルトの名無しさん
05/12/16 17:51:26
私のために争わないで！
403:デフォルトの名無しさん
05/12/16 18:21:45
もうこれ以上
404:デフォルトの名無しさん
05/12/16 18:55:58
君のまわりに不幸の存在を俺は認めない
405:デフォルトの名無しさん
05/12/16 20:07:19
>>389
10月中旬ごろ標準Cの勉強を始めて
11月下旬に標準C++へ、MFCを使って電卓を作って、WinSockでechoサーバをみようみマネでつくり
昨日、初めてSTLの勉強を始めて・・・何故か本の真ん中からはじめたので右も左もわからず・・・・
って感じです。今までネットワークエンジニアとして修行していたのでプログラミングは、つぅあっパリですｗ
406:デフォルトの名無しさん
05/12/16 23:47:13
最初から読もうぜ。結構なんとかなってしまうけど、基本も大事だしね。
407:デフォルトの名無しさん
05/12/17 00:43:22
>>406
STLにも勉強する順番があるんですか？
408:デフォルトの名無しさん
05/12/17 00:55:26
>>407
私は>>406ではありませんが。勉強に順序はありません。でも、
一般的にはstd::vector<>が最初に紹介されていませんかね？
409:デフォルトの名無しさん
05/12/17 00:59:32
>>407
俺は>>406じゃないけど、STLを基本概念から全部理解しようと
したら大変だぜ。本が何冊も出ている。
よく使うコンテナやアルゴリズム、関数オブジェクトの使い方あたり
から少しずつ入って行けば楽なのではないかと思う。
410:デフォルトの名無しさん
05/12/17 01:22:06
vector → list → iterator → algorithm → functional → その他
くらいでいいんじゃね？
411:デフォルトの名無しさん
05/12/17 02:25:01
>>410
ご教授、ありがとうございます。
時間があればそのようなことをしたいと思います。
412:デフォルトの名無しさん
05/12/17 02:36:29
>>411
vector→list→map→algorithm→functional→[boost]
413:デフォルトの名無しさん
05/12/17 03:26:07
最初からLoki
414:デフォルトの名無しさん
05/12/17 03:48:00
>>412
はいはい。じゃーそれで
415:デフォルトの名無しさん
05/12/17 07:17:05
Vector → 窓の杜
416:デフォルトの名無しさん
05/12/17 09:35:09
Vector→Quaternion→Matrix
417:デフォルトの名無しさん
05/12/17 10:16:04
テンソルは？
418:デフォルトの名無しさん
05/12/17 10:41:51
>>414
わかればよろしい。
419:デフォルトの名無しさん
05/12/17 10:54:53
Scalar → Vector → Tensor
はいはい、テンソルテンソル。
420:デフォルトの名無しさん
05/12/17 11:04:45
>>419 わかればよろしい
421:デフォルトの名無しさん
05/12/17 11:08:09
>>419
わかればよろしい。
422:デフォルトの名無しさん
05/12/17 11:10:04
はいはい、すごいね、テンソルテンソル
423:デフォルトの名無しさん
05/12/17 12:19:52
>>410
> vector → list → iterator → algorithm → functional → その他
>>412
> vector→list→map→algorithm→functional→[boost]
俺は最初からiterator、algorithm、functionalを軽くやるスタイルが良いと思う。
ステファノフさんのオリジナルSTL本はこの流儀。
そういう意味ではvectorはC的な操作への誘惑が強く、
mapやsetが最初のコンテナとして適当ではないかと。
424:デフォルトの名無しさん
05/12/17 13:02:54
私は実務で使いながらだったから
vector → iterator → algorithm
の順に入ったな。
Cの経験が充分あるなら、取り敢えず可変長配列としてのvectorを見てから
それを一通り使い倒して他にいくと言う意味で悪くないと思う。
#例えばvectorのoperator[]に馴れてそこで留まる香具師にはどうせalgorithmなんて使いこなせないわけだし。
425:デフォルトの名無しさん
05/12/17 13:54:13
>>424
そえは業務でalgorithmを使っていないって事ですか？
426:デフォルトの名無しさん
05/12/17 14:02:05
ヘタレがvector使うとバグの温床になる
listとか使った方がまだまし
427:デフォルトの名無しさん
05/12/17 14:14:24
>>426
なんで？逆じゃないの？
428:デフォルトの名無しさん
05/12/17 14:23:39
vectorやstringは、今となっては設計が5年は古いよな。
algorithmを使えば済むものが、内部メソッドになってしまっている。
429:デフォルトの名無しさん
05/12/17 14:31:45
>428
stringはともかくvectorにそれ当てはまる？
430:デフォルトの名無しさん
05/12/17 15:18:02
>>428
あんた、実はあんまりSTLを知らないね。
std::algorithmを適用できないイテレータを持つコンテナに最適な
アルゴリズムを用意したのが、大抵の内部メソッドだ。
それから、std::stringは、STLには大抵入れない。random access iterator
を使えるので、適用できるアルゴリズムが多いのは確かだが、
用途が主に文字列の操作なので、Cのstring.hに対応する関数を
内部で持っただけ。
431:デフォルトの名無しさん
05/12/17 15:36:34
>>430
stringの後半の主張はどうかと思うぞ。
STL以前からあるクラスで、今やオールドタイプだ。
432:デフォルトの名無しさん
05/12/17 15:50:32
std::stringにバイナリを入れられるのは知ってるけど、果たして
std::stringの内部メソッドがそれに適したような格好になってるかな？
433:デフォルトの名無しさん
05/12/17 18:51:43
>>432
何がいいたいかよくわからん。
434:デフォルトの名無しさん
05/12/17 19:23:27
>>432
typedef basic_string<char> string; ですから、charなんなんでもありです。
ただしc_str()は'\0'が途中にあるとまずいですが。
>>430
SGIのSTLにstring入ってるぞ。
435:デフォルトの名無しさん
05/12/17 19:55:23
>>434
＞ただしc_str()は'\0'が途中にあるとまずいですが。
まずくないよ。size()とともに用いればいいだけ。
下のコードでヌル100文字で埋められていることを確認汁。
string str;
str.resize(100);
fwrite(str.c_str(), sizeof(string::value_type), str.size(), fp);
436:デフォルトの名無しさん
05/12/17 20:02:02
>>435
まずくないのには同意だが、そういうとき普通はc_strじゃなくdataを使うだろ。
437:デフォルトの名無しさん
05/12/17 20:15:33
>>436
data()は今の議論のテーマではない。
終端に確実にヌルが付加されるc_str()を使わずdata()を用いる利点など一切ない。
438:デフォルトの名無しさん
05/12/17 20:18:49
>>437
fwriteに渡すのに終端文字がいちいち付加される意味ないのでc_str()なんか使う意味ないだろ
439:デフォルトの名無しさん
05/12/17 20:19:39
何故?
実装によっては、capacity() != size() の時、
c_str()はdata()より重い処理になるよ。
>>435のようにsize()と使うならdata()ってのが定石だと思う。
440:デフォルトの名無しさん
05/12/17 20:20:10
>>439は、>>437へのレス
441:デフォルトの名無しさん
05/12/17 20:26:47
>>438
仕様変更に対する事前策を用意しておくことを無意味とは、大胆発言だな。
ヌル終端文字列を前提とした既存のC関数に渡すとき、
バッファオーバランの可能性を軽減することができる。
この点においてstring::c_str()は、string::data()やstringstream::str()より安全性に優れている。
ヌル終端保証されたc_str()と保証されないdata()。
一方で、c_str()とdata()が同じ挙動をするSTLも存在する。
どちらを使うべきかは一目瞭然だろう。
442:デフォルトの名無しさん
05/12/17 20:28:22
>>439
サンプルとなる、ソースと開発環境を書け。
443:デフォルトの名無しさん
05/12/17 20:32:35
>>441
バイナリデータブロックを扱っているところをnul文字終端に仕様変更する準備をしておくなんて
普通じゃないな
444:デフォルトの名無しさん
05/12/17 20:35:43
>>443
Unicode文字列をバイナリデータとして扱っている場合などはそうでもない。
何をもって普通というのかその人の経験量だろうけど。
445:デフォルトの名無しさん
05/12/17 20:38:55
１．c_str()は'\0'が途中にあるとまずい
２．size()とともに用いればまずくない
３．そういうときはc_strじゃなくdataを使う
４．ヌル終端文字列を前提とした既存のC関数に渡すときc_str()のほうが安全
５．1に戻る
446:デフォルトの名無しさん
05/12/17 20:40:22
>>439の実証コードはまだですか？
>>439の正しさが確認されないことには、
議論が進まないのでなるべく早目にお願いします。
447:デフォルトの名無しさん
05/12/17 20:44:06
>>445
多分、３．は必要ないから、無限ループには陥らない。
448:デフォルトの名無しさん
05/12/17 20:55:04
結論としては、nul終端が必要ない時はdata()を使え。ただし義務ではない。