1001コメント287KB

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

レス数が1000を超えています。これ以上書き込みはできません。

0001デフォルトの名無しさん

2005/10/30(日) 22:51:04

【C++】STL（Standard Template Library）相談室 3
http://pc8.2ch.net/test/read.cgi/tech/1116559700/
【C++】STL（Standard Template Library）相談室 2
http://pc8.2ch.net/test/read.cgi/tech/1104898734/
【C++】STL（Standard Template Library）相談室
http://pc5.2ch.net/test/read.cgi/tech/1095583235/

入門ページなど
ttp://www.wakhok.ac.jp/~sumi/stl/
ttp://www.jah.ne.jp/~naoyuki/Writings/STL.html
ttp://e-words.jp/w/STL.html
ttp://www5c.biglobe.ne.jp/~ecb/cpp/07_01.html
ttp://www.nantekotta.com/stl.html
ttp://www.s34.co.jp/cpptechdoc/reference/stl_samples/
ttp://www.kab-studio.biz/Programing/STLiostream/
ttp://www.itmedia.co.jp/dict/programming/language/kind/c/01486.html
ttp://ja.wikipedia.org/wiki/Standard_Template_Library
ttp://www.shibu.jp/cppreference/cpp_stl.html
ttp://www-ise2.ise.eng.osaka-u.ac.jp/~iwanaga/programming/stl/about_stl.html

マルチスレッドプログラミングの時には、
ttp://www.logos.ic.i.u-tokyo.ac.jp/~yokoyama/trash/stl_thread.html

STLPort
http://www.sgi.com/tech/stl/
http://www.stlport.org/

関連スレ、その他リンクは >>2-9 ぐらい

0002デフォルトの名無しさん

2005/10/30(日) 23:12:16

【注意】STLの落とし穴【危険】
http://pc8.2ch.net/test/read.cgi/tech/1104092624/

0003デフォルトの名無しさん

2005/10/30(日) 23:14:20

>>1
乙

0004デフォルトの名無しさん

2005/10/30(日) 23:21:13

C++関連スレ

【C++】template 統合スレ -- Part6
http://pc8.2ch.net/test/read.cgi/tech/1101384692/l50
C++相談室 part44
http://pc8.2ch.net/test/read.cgi/tech/1128512737/l50
【初心者歓迎】C/C++室 Ver.22【環境依存OK】
http://pc8.2ch.net/test/read.cgi/tech/1128872687/l50

0005デフォルトの名無しさん

2005/10/30(日) 23:22:27

ここらへんもいれておくかな。

BOOSTを語れゴラァ
http://pc8.2ch.net/test/read.cgi/tech/1091198276/l50
内藤ﾎﾗｲｿﾞﾝがC/C++の宿題を片付けます 49
http://pc8.2ch.net/test/read.cgi/tech/1122705615/l50

0006デフォルトの名無しさん

2005/10/30(日) 23:38:00

Apache C++ Standard Library
http://incubator.apache.org/stdcxx/

STLpotrがあるならこれも

0007デフォルトの名無しさん

2005/10/31(月) 00:05:07

じゃあこれも
http://gcc.gnu.org/libstdc++/

0008デフォルトの名無しさん

2005/10/31(月) 01:03:34

STL分けるのもう良そうよ
C++相談室が閑散としすぎ

0009デフォルトの名無しさん

2005/10/31(月) 01:08:59

>>8
ところがC++相談室には、STLの質問が滅多に来ないんだなこれが。
C++を使いながらも、STLを忌避している香具師が多いという証拠だろう。

0010デフォルトの名無しさん

2005/10/31(月) 01:21:49

>>9
単にここがあるからでは?

0011デフォルトの名無しさん

2005/10/31(月) 05:32:30

言語とライブラリは分けたほうがいい。

0012デフォルトの名無しさん

2005/10/31(月) 05:35:51

>>11
標準ライブラリ

0013デフォルトの名無しさん

2005/10/31(月) 06:39:07

標準ライブラリーもライブラリーなのでは？

0014デフォルトの名無しさん

2005/10/31(月) 07:43:06

http://pc8.2ch.net/test/read.cgi/tech/1104898734/562

562 名前：デフォルトの名無しさん[sage] 投稿日：2005/05/05(木) 02:58:39
"STL"なんて呼称の範囲は、C++の標準ライブラリに
取り込まれてしまった今となっては明確に区切れる物では無い。
HP STL や SGI STL のことを指して言ってるのかもしれないが、
今使われてるのはそれらをベースにしたC++標準ライブラリだ。
範囲が明確に決まってるかのように、含まれるだの含まれないだの言うのは時代遅れだぞ。

このスレが不要である事に疑いの余地は無い。

0015デフォルトの名無しさん

2005/10/31(月) 08:42:05

個人的には別に他のスレに統合されてもいいかなとも思うけど、
過去ログを参照するときは適度にカテゴライズされてたほうが都合がいいかな。
そういう意味ではC++に関する話題を分類するとき、
STLを一つのカテゴリーにするのは結構無難な選択かも。

0016デフォルトの名無しさん

2005/10/31(月) 14:17:29

>>9
バカばっか、という事でしょう。

0017デフォルトの名無しさん

2005/10/31(月) 15:37:05

厨ほどスレを分化させたがるよな

0018デフォルトの名無しさん

2005/10/31(月) 16:31:12

　＿　　　　 -―-　　　　＿
, ',　-､ヽ'´　　　　　　｀'´, -､ヽ
! {　　/　　　　　　　　　ﾞ　 } i
ヽ｀ｰ,'　　 ●　　　 ●　ﾞｰ'ノ　
　｀ !　　　　　　┬　　　　 l"　 < 厨ー
　　｀ヽ.　　　　 ┴　　　　ﾉ　　
　　　 /｀＝=ｧ'⌒ヽ=＝'ヽ

0019デフォルトの名無しさん

2005/10/31(月) 16:41:03

厨w

0020デフォルトの名無しさん

2005/10/31(月) 17:02:46

コンテナとアルゴリズムは分けるべきじゃねw?

0021デフォルトの名無しさん

2005/10/31(月) 17:15:23

細かすぎる分類はごめんだが、悪くないと思うけどなぁ。STLスレ。

言語の規格が巨大なC++の分類の仕方としてはごく普通な発想って気が・・・
STLに焦点をしぼった書籍もたくさんあることだしさ。

0022デフォルトの名無しさん

2005/10/31(月) 19:37:16

>>18
巣に帰れ

0023デフォルトの名無しさん

2005/10/31(月) 22:03:55

>>9
C++相談室にSTLの質問が来ないのは、忌避も何もその前に
テンプレートを使うようなレベルに達していないようなやつばかりが質問してくるからだと思うが。

>>11
ならSTLと言わず標準ライブラリ全てを扱うスレが存在すべき。

0024デフォルトの名無しさん

2005/10/31(月) 23:08:12

serializationで抽象クラスのポインタシリアライズがうまくいきません。

どこかにサンプルコードとかありませんかね？

0025デフォルトの名無しさん

2005/10/31(月) 23:14:38

前スレのもそうだがboostスレで質問したほうが良いのではないだろうか？

0026デフォルトの名無しさん

2005/10/31(月) 23:55:14

template<T>のTがあるインターフェイスを実装しているとか
引数なしPublicコンストラクタがあるとかの制限
ってどうやったらできますか

0027デフォルトの名無しさん

2005/11/01(火) 00:00:52

>>26 concept_check

0028デフォルトの名無しさん

2005/11/01(火) 00:02:43

実際に呼べば判るとおもうが

0029デフォルトの名無しさん

2005/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
        ]

どなたか原因がわかりませんか？？

0030デフォルトの名無しさん

2005/11/02(水) 23:01:52

listをdequeにしたら?

0031デフォルトの名無しさん

2005/11/02(水) 23:04:19

>>30
レスありがとう。
ちょっとやってみます。

0032デフォルトの名無しさん

2005/11/02(水) 23:04:33

>>29
random_shuffleはrandom access iteratorが必要。
しかしstd::listのイテレータはbidirectional iteratorなのでエラーになった。
random access iteratorはbidirectional iteratorに加え+, -, +=, -=, []の演算子が使える。

これはもうどうでもいいことだが今回はエラーメッセージを見ると+がないというエラーのようだ。

0033デフォルトの名無しさん

2005/11/02(水) 23:20:53

dequeにするくらいならvectorにするべきじゃないか？
要素がBYTE型なのだから、コピーのコストなんてたかが知れてる。

0034デフォルトの名無しさん

2005/11/02(水) 23:24:11

>>32
レスありがとう。
リストは付け替えるだけで順番も変わるのと時間かかるけど場所の特定が簡単なので、ランダムアクセスできると思い込んでました。（自分で作るときはそうすると思う・・・。
うーん。思い込みはいけませんね。勉強になりました。

そうそう。dequeにしたらちゃんと通りました。
ありがとうございます。

0035デフォルトの名無しさん

2005/11/02(水) 23:36:14

>>33
レスありがとう。
今回の場合ランダムシャッフルさえできれば、一列に並んでる構造ならばなんでもいいのですが、
今回は試す意味でdeque使ってみようと思います。
提案ありがとう。

0036デフォルトの名無しさん

2005/11/03(木) 00:09:45

vectorは、要素削除後の管理が自己責任で面倒である点を除けば、
list,set,dequeのいずれよりも、メモリ消費量や速度・柔軟性で上。
引数に配列形式でアドレスを渡す各種API関数でコンテナを流用できるのは、vectorだけ。

色々試した結果、最後にはvectorに回帰する。
これは誰もが辿る道だ。

003736

2005/11/03(木) 00:21:00

補足。
自己責任と書いてしまったが、insert()を遠慮なく使えるなら気にしなくていいことだった。

0038デフォルトの名無しさん

2005/11/03(木) 00:26:10

>>36
今のところセッパつまってないので、いいのですが。
最後はベクタというのはちょっと面白いです。
そこまで行くにはまだ時間がかかりそうですが、それまで色々やってみたいです。

0039デフォルトの名無しさん

2005/11/03(木) 01:00:26

>36
>最後にはvectorに回帰する。
トランプゲームの内容次第ですな。
山から引いたカードを二度と使わないようなゲームならvectorをスタックとして
使用すればいいけど、山の下に戻すようなゲームだとvectorよりはdequeの
方がいいですな。

まあ、たかが53枚だからC互換のvectorの方が良いという意見もあるかもしれんが……

0040デフォルトの名無しさん

2005/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で１件ずつ回してコピーするしかないのでしょうか?

0041デフォルトの名無しさん

2005/11/03(木) 02:47:45

>>40
list1.insert(list1begin(), list2.begin(), list2.end());

0042デフォルトの名無しさん

2005/11/03(木) 02:56:51

>>40
ソースはそのままでいい。
むしろ、list1とlist2のiteratorをちゃんと区別してコンテナ操作できてるかチェック。

0043デフォルトの名無しさん

2005/11/03(木) 03:38:09

>>41
×でした。>>40と同じく追加後の件数が実データ数を大きく越えていました。

>>42
for (vector<CHoge *>::iterator it = list2.begin(); it != list2.end(); it++)
　 list1.push_back(*it);
これで正しくコピーできるので、自分の中でiteratorの区別はできていると思っています。

004440

2005/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();
上記のように修正したらうまくいきました。皆さんお騒がせしてすみませんでした。

004529

2005/11/03(木) 04:46:26

このすれのおかげで完成しました。例のトランプゲームです。
内容はスピードってゲームなんですけど、適当に実装したCPUが超速でカード出してくるので勝てません。（@@;
うひー。orz

0046デフォルトの名無しさん

2005/11/03(木) 07:29:52

>>36
>色々試した結果、最後にはvectorに回帰する。

だって、ププッwwwwwwwwwww

0047デフォルトの名無しさん

2005/11/03(木) 13:43:21

正論すぎて反論できないのが可哀相

0048デフォルトの名無しさん

2005/11/03(木) 15:12:47

>>36
>vectorは、要素削除後の管理が自己責任で面倒である点を除けば、
>list,set,dequeのいずれよりも、メモリ消費量や速度・柔軟性で上。
　　　中略
>色々試した結果、最後にはvectorに回帰する。
>これは誰もが辿る道だ。

それぞれのコンテナは、用途と状況に応じてパフォーマンスが違う。
例えば、シーケンスの途中に要素の挿入・削除が頻繁にある場合はlistを使うべき。
それを、一列に比べても意味が無い。
もしかしてvectorが全てだとでも思っているのか。

0049デフォルトの名無しさん

2005/11/03(木) 15:28:09

おまいら既存のコンテナに頼りすぎてないか？
例えばvectorのインデックスで木を表現しても良いはずだ。

0050デフォルトの名無しさん

2005/11/03(木) 15:31:39

ならvector使わなくてもいいはずだ

0051デフォルトの名無しさん

2005/11/03(木) 16:19:13

>>49
読みにくいだろ。
ほかのコンテナをvectorで代用していったら、
何やってるか、わかんなくなってくよ。

0052sage

2005/11/03(木) 17:09:42

>これは誰もが辿る道だ。

え、オレ、そんな道辿ってないんだけど。
vectorに回帰と言うよりも、
どちらかというとboostにたどり着いたかな

0053デフォルトの名無しさん

2005/11/03(木) 17:37:53

0054デフォルトの名無しさん

2005/11/03(木) 18:40:12

vectorは既存のC/C++ソースの流用に関して柔軟に移植できる。
コピペ野郎には欠かせない存在だ。

・・・ま、生粋のコピペ野郎ならメモリ管理部分も
そのまま低レベル記述のままにしておくのだろうけど。

0055デフォルトの名無しさん

2005/11/03(木) 18:42:02

ま、確かにコンテナの中でstd::vectorだけは別格だという事は認める。

0056デフォルトの名無しさん

2005/11/03(木) 21:58:04

回帰と言うか、漏れにとっては「取り敢えずvector」とか「迷ったらvector」だなw

0057デフォルトの名無しさん

2005/11/03(木) 23:03:55

vectorから他のコンテナへの置換は大抵簡単だが、
逆は難しい場合が多いもんね。

とりあえずvector。
迷ったらvector。

0058デフォルトの名無しさん

2005/11/04(金) 00:20:38

STLとboostを使いこなせるほどのレベルになると、
C言語固有分野の実力もそれなりのものになっている可能性が高い。
このレベルになるとアドレスシーケンスが保証されたvectorだけで十分になってしまったりする。

C言語にはいくつかのループ記述（for、while、do-while）があるが、
結局最後にはforしか使わなくなるのに似ている、・・・と思ったがやっぱ似てないな。

美食家が最後に茶漬けに戻るのに似ている、侘び寂びの世界だ、・・・と思ったがやっぱ似てないな。

0059デフォルトの名無しさん

2005/11/04(金) 00:32:18

＞結局最後にはforしか使わなくなるのに
んなこたーない。

0060デフォルトの名無しさん

2005/11/04(金) 01:14:19

for(;;)
while(1)

くらべてみよー

0061デフォルトの名無しさん

2005/11/04(金) 01:38:58

漢なら while (true) だ！

0062デフォルトの名無しさん

2005/11/04(金) 01:42:07

最近はfor(;;) しか見てないなー
ひょっとして陰で統一されつつあるのか？？

0063デフォルトの名無しさん

2005/11/04(金) 01:51:43

そりゃぁ、ansiでわざわざそのためにfor(;;)を規格化したわけですから。
while (1)や while (true)は警告対象になるコンパイラも多いことだし。

0064デフォルトの名無しさん

2005/11/04(金) 02:57:26

>>63
マジデスカ
今までずっとwhile(true)だったよ…

006539

2005/11/04(金) 03:43:52

>58
えぇー

例えば、listだと多くの操作が例外安全だからvectorよりも使い勝手が
良かったりするけどね……「取りあえずvector」というのはあるかもしれんが……

>ループ記述
最近はforも使わずにアルゴリズムに落としこむなぁ。

0066デフォルトの名無しさん

2005/11/04(金) 04:31:34

つーかさ
>>54あたりから>>58位までの、多くのレスは
ずっと自作自演やってる奴の１人の仕業だろ
バレテンダヨ
さっきからvectorの擁護ばかりで
ウザイ

0067>>56=59=63

2005/11/04(金) 04:43:10

>>66
んなこたーない。

0068デフォルトの名無しさん

2005/11/04(金) 11:24:55

> vectorの擁護
ﾜﾗﾀ
アホの子もここまでくるとちょっとな

0069デフォルトの名無しさん

2005/11/04(金) 12:05:15

＞最近はforも使わずにアルゴリズムに落としこむなぁ。

馬鹿丸出しだな。
コールバック関数を用意してループ処理を隔離する事が、
常に近道だとは到底思えない。
コールバック関数とともにアプリ定義の引数渡しができない場合は、
スレッドセーフにするのが面倒である点も致命的。

0070デフォルトの名無しさん

2005/11/04(金) 12:47:55

>>69
つまり、
STLを否定してる発言
もう、こいつにつける薬はないな。

0071デフォルトの名無しさん

2005/11/04(金) 12:50:21

STLに馴染めないロートルは放っときゃいいんだよ。

0072デフォルトの名無しさん

2005/11/04(金) 12:58:24

たった今、STL全体とalgorithmを同一視する馬鹿な>>70を発見した。
新鮮な驚きだ。

0073デフォルトの名無しさん

2005/11/04(金) 13:12:48

>>72
負け犬の遠吠え

0074デフォルトの名無しさん

2005/11/04(金) 16:29:00

>>69
> コールバック関数とともにアプリ定義の引数渡しができない場合は、スレッドセーフにするのが面倒である点も致命的。
は
> コールバック関数を用意してループ処理を隔離する事が、常に近道だとは到底思えない。
の理由や説明になっていない。

0075デフォルトの名無しさん

2005/11/04(金) 16:57:18

並列だろ

0076デフォルトの名無しさん

2005/11/04(金) 18:44:04

どこにでも盲信者とアンチがいるのですね

0077デフォルトの名無しさん

2005/11/04(金) 18:56:24

理解できない話に出くわした時は
とりあえず信者・アンチと言っておけば
わかってるフリができる

0078デフォルトの名無しさん

2005/11/04(金) 20:47:17

確かにalgorithm関連の関数は引数仕様を変更して貰いたいと感じる。
Win32APIのようにマルチスレッドが前提となるOSのAPIはその点で抜け目がない。

0079デフォルトの名無しさん

2005/11/04(金) 21:11:06

>>78
STLのalgorithmは関数オブジェクトを渡せばいいだろ。
その関数オブジェクトのメンバでいくらでも渡せる。

0080デフォルトの名無しさん

2005/11/04(金) 21:15:16

>>78
bind1st bind2nd mem_fun って知ってますか？

0081デフォルトの名無しさん

2005/11/04(金) 23:25:57

もうSTLport5も出たっていうのに。
http://sourceforge.net/projects/stlport

008239

2005/11/04(金) 23:59:36

>69
>コールバック関数とともにアプリ定義の引数渡しができない場合は、
>スレッドセーフにするのが面倒である

どういうこと？C++ではカリー化ができないという意味？

0083デフォルトの名無しさん

2005/11/06(日) 16:56:25

BCB6付属のSTLPortを最新版に変えるにはどうしたらいいの？

0084デフォルトの名無しさん

2005/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

といったようなエラーが出ています。
どういう原因でエラーが出てるんでしょうか？また、どうすればきちんとコンパイルが通るようになるでしょうか？

0085デフォルトの名無しさん

2005/11/08(火) 03:39:19

祈る。

0086デフォルトの名無しさん

2005/11/08(火) 05:31:28

ダウンロードして上書き
エラーがでたら修正

0087デフォルトの名無しさん

2005/11/08(火) 08:35:44

>>84
STLportを使うのを諦める。

0088デフォルトの名無しさん

2005/11/08(火) 15:20:36

ちゃんとしたインストーラついたやつないの？

0089デフォルトの名無しさん

2005/11/08(火) 21:54:42

>>88
そんなに欲しけりゃ自分でインストーラ作れ。
ただでこんな素晴らしいライブラリが手に入る事だけでも感謝できないのかね君は？

0090デフォルトの名無しさん

2005/11/08(火) 22:25:40

インストーラが無いと使えないような香具師はプログラマを諦めた方がいい。

0091デフォルトの名無しさん

2005/11/09(水) 01:02:23

っていうかインストーラいらんじゃん

0092デフォルトの名無しさん

2005/11/09(水) 12:09:00

いるよバカ

0093デフォルトの名無しさん

2005/11/09(水) 13:49:09

>>92
>>90

0094デフォルトの名無しさん

2005/11/09(水) 21:08:12

無いと使えないような奴だけが必要なわけじゃないしな

0095デフォルトの名無しさん

2005/11/10(木) 00:04:19

list::sort()のアルゴリズムがよく解らないのですが、
これは何か名のあるアルゴリズムなのでしょうか？

0096デフォルトの名無しさん

2005/11/10(木) 00:11:19

template<class T>
class Hoge {
....
int foo(T arg);
};

で、
Hoge<void>　hoge；
でも使える様にする、上手い手段って無い？？

0097デフォルトの名無しさん

2005/11/10(木) 00:13:01

>>96
テンプレートの特殊化で検索汁

0098デフォルトの名無しさん

2005/11/10(木) 00:23:19

>>95
実装にもよるけど、大雑把にクイックソートしてから最後に挿入ソートが一般的

0099デフォルトの名無しさん

2005/11/10(木) 00:35:02

>>97
それだと
........
の部分を、ほぼコピペしなくてはいけなくなるので、それを回避したい

0100デフォルトの名無しさん

2005/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で....の部分を共有すればいい

0101デフォルトの名無しさん

2005/11/10(木) 01:12:01

>>100
サンクス！！
明日、これを利用して発展させてみます

0102デフォルトの名無しさん

2005/11/10(木) 02:18:58

>98
いやlistのsortなんですが。
で、風呂に入ってゆっくり考えてたら、
再帰を使わないマージソートだと気が付いた。

010398

2005/11/10(木) 02:31:38

>>102
ごめん。
普通のstd::sortと読み間違えてた。

0104デフォルトの名無しさん

2005/11/10(木) 17:22:48

std::mapのfindで、指定したキーの要素が無かった場合はNULLが返るんでしょうか？

0105デフォルトの名無しさん

2005/11/10(木) 17:25:16

map<>::iteratorにNULLはない。
返るのはend

0106デフォルトの名無しさん

2005/11/10(木) 17:28:55

受け取ったiterator == endならば無いと言うことなんですね
わかりました

0107デフォルトの名無しさん

2005/11/10(木) 19:30:44

ｷﾓｲ仕様ですね

0108デフォルトの名無しさん

2005/11/10(木) 19:43:22

まぁstd::mapで要素の有無を調べるなら
countを使うしな。

0109デフォルトの名無しさん

2005/11/10(木) 19:48:28

こうして糞プログラムが量産されていくのでした

0110デフォルトの名無しさん

2005/11/10(木) 20:00:16

>>108
findならiteratorがそのまま処理に使えるしｗ

0111デフォルトの名無しさん

2005/11/10(木) 20:02:51

countの方が多少分かりやすいんだろうな
multi-ならfindじゃなきゃﾀﾞﾒだろうけど

0112デフォルトの名無しさん

2005/11/10(木) 20:08:07

ソースの読みやすいＳＴＬはどれですか？

0113デフォルトの名無しさん

2005/11/10(木) 20:28:28

>>110
見つけた要素を使って何か処理をするなら、勿論findだね。
でも有無を調べるなら、findは（ちょっとの差だけど）冗長だし直観的ではないと思う。

0114デフォルトの名無しさん

2005/11/10(木) 20:39:13

>>112
読みやすいかどうかは主観的なものなので、答えるとしたら
「知ったこっちゃねぇよ」だ。

0115デフォルトの名無しさん

2005/11/11(金) 01:52:17

そういえば、個人でOpen系に参加してるプロジェクトはSTLもboostも問題ないのに
今飯の種で参加してるVC6系の業務はSTLを使うと嫌われて、MFCのコンテナ使えって
お達しが来たなぁ
なんとか、STLをもっとC++ユーザに普及される道は無いんだろうか
あのままCPtrListをposを介してアクセスしてる糞ソースを見ると
今のプロジェクトが哀れに見えてくるんだが

0116デフォルトの名無しさん

2005/11/11(金) 10:05:46

初歩的な質問かもしれませんが
循環参照リスト（map）を作りたいです
循環参照といっても単なるディレクトリ構造で
１対多の双方向Treeなんですが（言葉が良くわからなくてゴメンナサイ）
どのコンポーネント使えばいいでしょうか

今はmapを使って smartポインタで構造体をラップして値を入れています
子→親は shared_ptr、親→子はweak_ptr
最後の子はヒープに残さないと消えてしまったり
delete時に親のmapから自分の登録を消す必要があったりと
なんか実装間違ってる気がしています

＃今までSTLもMFCも毛嫌いしていましたけど、今回から仕事でも導入です

0117デフォルトの名無しさん

2005/11/11(金) 12:01:15

>>115
VC6付属のSTLはバグが多いのでそのお達しは正しい。

0118デフォルトの名無しさん

2005/11/11(金) 12:09:05

>>117
それはSTLじゃなくてtemplateの問題だろうに.

0119デフォルトの名無しさん

2005/11/11(金) 12:51:37

VC6同梱のバグ有りSTLはDinkumwareで修正した奴配ってたような気がする。

0120デフォルトの名無しさん

2005/11/11(金) 12:56:32

ついでだから調べて見たけど、リンク切れてるな。
http://dinkumware.com/vc_fixes.html
なんでもvectorの要素数拡張にバグがあったみたいね。

0121119=120

2005/11/11(金) 13:00:38

URL間違ってたｽﾏﾇorz

ここに詳細があった。
ttp://www.dinkumware.com/vc_fixes.html
SP3当たってればFixされてるようなことも書いてあった。

0122デフォルトの名無しさん

2005/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> のみを
受け付けるようにするにはどうしたらいいのでしょうか？

あと、もしよろしければこういう設計のほうがいいとかあれば指摘お願いします

0123デフォルトの名無しさん

2005/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;
+}

0124デフォルトの名無しさん

2005/11/11(金) 13:58:15

>>123
期待通りのものができそうです
ついでに typename と class の違いも消化できそうです
ありがとうございました

0125デフォルトの名無しさん

2005/11/12(土) 09:36:14

http://sourceforge.net/projects/stlport

STLport 5.0 正式版がリリースされているようですよ

0126デフォルトの名無しさん

2005/11/12(土) 09:55:16

>>81でがいしゅつ

0127デフォルトの名無しさん

2005/11/12(土) 10:00:04

だヵら何？

0128デフォルトの名無しさん

2005/11/12(土) 14:15:00

Q: それ自体が意味を持つ情報に向かって、「それで？」とか「だから何？」とか
　　返す人がいますが、これはどういう意味なのでしょう？

A: 「どうだ！」とばかりに披露した投稿にケチをつけられて悔しかった人が、
　　相手の発言を「その先に何かが無いと価値がない」ことにしたい時に使います。
　　しかしご存じのように、大抵は悔しさを見透かされるだけに終わり、成功の望みは薄いです。

0129デフォルトの名無しさん

2005/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);
}

異なる結果が出たのですが,どのような理由が考えられるでしょうか？

0130デフォルトの名無しさん

2005/11/12(土) 16:24:16

listの方はinsertしてもイテレータの指してる要素はそのまま使用可能だからいいけど
vectorの方は
v.insert(v.begin(), start, end);のところで
startとendのイテレータが駄目になってしまうから
その後にv.erase(start,end)ってやってはだめ

0131デフォルトの名無しさん

2005/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をインクリメントしてもしなくても結果が変わらないのですが
どうなっているんでしょうか？

0132デフォルトの名無しさん

2005/11/12(土) 18:13:13

STLPort5.0.0をMinGWに無事インストールして、動いた人いる？
俺はビルドは成功したものの、いざプログラムで使うと、リンク時に
多量のリンカエラーが出て、今の所使えないので、4.6.2に戻してしまった。

0133デフォルトの名無しさん

2005/11/12(土) 19:58:59

vectorの全要素をファイルに出力したいんだけど、まとめてやる方法とかないの？
やっぱり、要素を一つずつファイルに出力するしかないのかな？

0134デフォルトの名無しさん

2005/11/12(土) 20:04:14

>133
std::for_each

0135デフォルトの名無しさん

2005/11/12(土) 20:04:41

>>133
copy+ostream_iterator

0136133

2005/11/12(土) 20:05:31

さっそくどうも

0137デフォルトの名無しさん

2005/11/12(土) 20:16:13

>>131
どうなると思っていて、実際にはどうなったかをちゃんと書け。

0138デフォルトの名無しさん

2005/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の場合指定できないということでいいのでしょうか？

0139デフォルトの名無しさん

2005/11/12(土) 21:02:51

ていうか挿入元の値が挿入してる最中に変わってしまうようなやり方は危険だからやめた方がいいよ
一度別のvectorにコピーしてから挿入するとかしないと

0140デフォルトの名無しさん

2005/11/12(土) 21:17:51

>>139
うーむやはり無難にコピーしたほうがいいのですね.
ありがとうございました.

0141デフォルトの名無しさん

2005/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を使用してはならない。

0142デフォルトの名無しさん

2005/11/13(日) 15:59:15

>138
vectorの構造を考えれば、まあねぇ……
vectorが挿入用のスペースを用意するには、挿入箇所より後ろの部分を
順繰りに後ろにずらすのが一番手っ取り早いんだけど、そうすると、保存し
ておいたIteratorが使い物にならなくなるんだよね。

0143デフォルトの名無しさん

2005/11/13(日) 16:00:10

>138
あと、advacteとか使ったら？

0144デフォルトの名無しさん

2005/11/13(日) 16:02:26

>>142
ずらすだけで済めばまだいいが、再確保が起こる可能性まである。
どっちにしても使い物にならないという結論になるんだけどね。

0145デフォルトの名無しさん

2005/11/13(日) 18:50:32

>>143
advacteって何？std::advanceの事か？

0146デフォルトの名無しさん

2005/11/13(日) 20:24:57

std::mapで、文字列をキーにして使うことってできますか？

0147デフォルトの名無しさん

2005/11/13(日) 20:30:20

>>146
std::stringなら特に何も考えずに出来る。

0148デフォルトの名無しさん

2005/11/13(日) 20:38:04

stringってcinで使えないからなんかヤダ

0149デフォルトの名無しさん

2005/11/13(日) 20:39:17

>>147
ありがとうございます

0150デフォルトの名無しさん

2005/11/13(日) 20:45:21

stlのstringって中途半端だよね
sprintfみたいなの無いし

0151デフォルトの名無しさん

2005/11/13(日) 20:48:41

じゃあ作ってくれよ

0152デフォルトの名無しさん

2005/11/13(日) 20:56:50

>>150
stringはSTLじゃない。

0153デフォルトの名無しさん

2005/11/13(日) 21:00:41

なんで？

0154デフォルトの名無しさん

2005/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はユーザー定義コピーコンストラクタ、
デストラクタ、コピー代入を持てないから一緒にするのはまずい。

0155デフォルトの名無しさん

2005/11/13(日) 21:25:12

>>150
(f)printf/(f)scanfがo(f)stream/i(f)stream(cout/cin)になったように、
sprintf/sscanfにはostringstream/istringstreamが存在する。
それが嫌ならboost::formatがある。

0156デフォルトの名無しさん

2005/11/13(日) 21:36:20

>>150
vectorとstringでいいじゃん

0157デフォルトの名無しさん

2005/11/13(日) 21:44:00

>154
C++ standardにはかわりないって。
string用のライブラリということでいいじゃない。そもそもSTLという用語自体あいまいだし。

>一緒にするのはまずい。
一緒にしちゃいけないのはコンテナも一緒だよ。

まあ、std::stringは失敗作くさいけどね……

0158デフォルトの名無しさん

2005/11/13(日) 21:45:09

>>154
STLってコンテナとアルゴリズムだけだっけ？
stirngとかbitsetは含まないのか。

0159デフォルトの名無しさん

2005/11/13(日) 21:49:02

std::stringは専用のﾒﾝﾊﾞ関数が大杉
boost::string_algoみたいに非ﾒﾝﾊﾞでもっと汎用的に実装できなかったものか

0160デフォルトの名無しさん

2005/11/13(日) 21:54:27

std::basic_string<>がSTLじゃないというのは操作がiteratorベースじゃない点。

0161デフォルトの名無しさん

2005/11/13(日) 22:13:21

>>152-160　>>14

0162デフォルトの名無しさん

2005/11/13(日) 22:17:01

大量の文字列をstringに突っ込んでるときに一文字増やすと大変なことになるなｗ
領域確保無しでなｗ
やっぱり、動作まで考えるとメモリは気がぬけねーなｗ
メモリボコボコになってもいいから、再確保なんてしないで、
つけたし部分をリストのノードを追加する感じでやってほしかった。

0163デフォルトの名無しさん

2005/11/13(日) 22:21:13

大量の文字列をstringに突っ込むなよ

0164デフォルトの名無しさん

2005/11/13(日) 22:27:20

長い文字列は非標準だがropeクラスでいける・・らしい

0165デフォルトの名無しさん

2005/11/13(日) 22:45:05

std::stringはstd名前空間にあるのにSTLじゃないんですか？
std名前空間の定義って何ですか？

0166デフォルトの名無しさん

2005/11/13(日) 22:51:15

std名前空間にあるのはC++標準ライブラリ。勝手にhash_mapとか突っ込んだ馬鹿も複数居るが。
狭義のSTLと呼ばれるのはAlex Stepanovが作成しC++標準化委員会に提案した一連のライブラリに属するもの。
ついでにいうとStepanovのオリジナルには含まれていたがC++標準ライブラリには含まれて居ないものもある。

0167デフォルトの名無しさん

2005/11/13(日) 23:04:39

>>162
VCならvectorと同様reserve()が使える。
GCCの場合、reserve()は実装されていない。
メモリ再確保時に多めに確保されるのでそれで我慢するしかない。

0168デフォルトの名無しさん

2005/11/13(日) 23:09:28

>>167
> GCCの場合、reserve()は実装されていない。

はつみみです。
ソースきぼん。

0169デフォルトの名無しさん

2005/11/13(日) 23:13:04

stringってバッファをこま切れのポインタ配列で管理してんじゃなかったっけ、
んで、c_str()した時に一つの配列に確保し直すとかじゃないの？

0170デフォルトの名無しさん

2005/11/13(日) 23:17:53

stringにもiteratorあるよ？

0171デフォルトの名無しさん

2005/11/13(日) 23:18:43

>>169
他のstlは知らないが少なくともvcに付属のstlは
駒切れじゃなくてcapacity()を超えるごとに確保しなおしてるよ

0172デフォルトの名無しさん

2005/11/13(日) 23:18:47

>>169
何その無駄仕様な妄想

0173デフォルトの名無しさん

2005/11/13(日) 23:19:02

>>168
今gccのヘッダー見てみたけどreverse()はなかったよ。

0174デフォルトの名無しさん

2005/11/13(日) 23:23:15

stringの場合vectorと違って連続したバッファに確保しろと規定されてないからどう実装しようとOK

0175デフォルトの名無しさん

2005/11/13(日) 23:27:54

>>173
#include <string>
void f(std::string& s) { s.reserve(1); }

これがエラーになるのか？
手元の gcc 3.4.4 @cygwin では普通にコンパイルできたよ。

0176デフォルトの名無しさん

2005/11/13(日) 23:41:07

いつになったら>>173の大馬鹿が露見することやらｗ

0177デフォルトの名無しさん

2005/11/13(日) 23:42:47

>>176
お前ヘッダファイルって、もしかして読んだこと無いのか？ｗ

0178デフォルトの名無しさん

2005/11/13(日) 23:43:26

×>>176
○>>173

>>173
どのヘッダー読んだんだ？ｗ

0179デフォルトの名無しさん

2005/11/13(日) 23:44:51

<string.h>か<cstring>じゃまいか

0180デフォルトの名無しさん

2005/11/13(日) 23:46:57

>>179
それだと「GCCの場合、 basic_string は実装されていない。」ってなるだろ。

0181デフォルトの名無しさん

2005/11/13(日) 23:47:09

もっと根本的な問題でマジでreverseを検索したに1票ｗ
　　　　　　　　　　　　　　　　　　 ~~~~~

0182デフォルトの名無しさん

2005/11/13(日) 23:47:18

良くﾜｶﾗﾝが、昔のgccを見たのかもね
なんにせよﾎﾞｹだが

0183デフォルトの名無しさん

2005/11/13(日) 23:47:41

>> 172
Stroustrup の C++ 本にはそんな感じの図(S式っぽいの)がのってたんで、
そんな感じだと思い込んでたが、違ったのね Σ（ﾟдﾟlll）ｶﾞｰﾝ

0184デフォルトの名無しさん

2005/11/14(月) 00:05:28

reserve()がビルド通っただけでご満悦の>>175も問題だぞ。
誰か>>175にかまってやれよ。

0185175

2005/11/14(月) 00:10:10

いや、おかまいなく。

0186デフォルトの名無しさん

2005/11/14(月) 00:18:20

実運用上、ほとんどのケースで便利なのはGCCの仕様。
むしろVCのreserve()は、reserve()を呼び出さなければパフォーマンスが低下するので、
必要に迫られてreserve()を使う場合が多い。
いちいちreserve()呼び出ししなくてもそれなりのパフォーマンスを出すGCCの方が扱いが楽。

それはちょうど、FILEの入出力でいちいちフラッシュする手間が必要か否かに似ている。
明示的にフラッシュする必要がない方が楽なのは言うまでもない。

0187デフォルトの名無しさん

2005/11/14(月) 00:55:45

>>186
GCC と VC の reserve の仕様ってどう違うんですか？

0188デフォルトの名無しさん

2005/11/14(月) 01:04:30

reserveの仕様じゃなくてバッファ確保の仕様が違うんだろ？

0189デフォルトの名無しさん

2005/11/14(月) 01:10:02

>>187,188
reserve()に大きな数字を指定したのち、capacity()の戻り値を調べる。
さあ試せ。そして報告しろ。

0190デフォルトの名無しさん

2005/11/14(月) 02:40:41

結論：ＧＣＣ最強
ＶＣは糞

0191デフォルトの名無しさん

2005/11/14(月) 03:39:45

>>190
何が最強なのか言ってみ

0192デフォルトの名無しさん

2005/11/14(月) 03:45:27

・VCは以下の項目で最強です
シェア
ANSI準拠度
サポート
ヘルプ
ライブラリ
最適化
開発環境の使いやすさ
開発環境が求めるスペック
クライアントの盲信度
ゲイツ度

0193デフォルトの名無しさん

2005/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)
みたいなことができればうれしいんだが。

ちょっと調べた感じでは無いみたいなんだけどな。
もし無いとしたら、これってちょっと面倒くさくない？

0194デフォルトの名無しさん

2005/11/14(月) 04:03:04

便利になる場面が思いつかない

0195デフォルトの名無しさん

2005/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;

0196デフォルトの名無しさん

2005/11/14(月) 04:27:04

>>193
そんなに面倒だと思うなら自分で勝手に実装しろよ。
って書こうとしたら既に>195まで書かれていた罠。

0197デフォルトの名無しさん

2005/11/14(月) 04:33:03

自分で実装するんならBoost.Assignでも使った方が良さげ

0198デフォルトの名無しさん

2005/11/14(月) 04:35:44

そういや禿って不自然な演算子は書くな(widget += buttonみたいな)って行ってるのに
何で<<←こんな変なもん作ったんだ？

0199デフォルトの名無しさん

2005/11/14(月) 04:37:43

>>195
サンクス。非常に参考になりました。

0200デフォルトの名無しさん

2005/11/14(月) 04:39:40

operatorで変な定義しとくと後で困るのにwww

0201デフォルトの名無しさん

2005/11/14(月) 04:54:57

>>195
これって1,2,3,4,5の順に代入されるのって保証される？

0202デフォルトの名無しさん

2005/11/14(月) 05:16:26

yes
C++本3rd 6.2.2:
,(コンマ)、&&(論理積)、||(論理和)演算子では、左側の被演算子の方が右側の被
演算子よりも先に評価されることが保証されている。
だってさ

0203デフォルトの名無しさん

2005/11/14(月) 05:20:57

というか普通の2項演算子(左結合)と同じってだけか

0204デフォルトの名無しさん

2005/11/14(月) 05:22:59

operator<<は許せるとして
「,」にそんな定義したらまずいだろｗ
関数の引数にするときとかどうなるんだよｗ

0205デフォルトの名無しさん

2005/11/14(月) 07:31:47

>>204
func(lis, 1, 2)　←　funcを3引数でcall
func((lis, 1, 2))　←　lis, 1, 2を実行の後、funcを1引数でcall

0206デフォルトの名無しさん

2005/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++のソースを

0207デフォルトの名無しさん

2005/11/14(月) 19:32:17

>>202
それは組み込みの演算子だけの事情だし、評価順序と結合規則は別の概念だからここでは関係ない。

>>203で正解

0208デフォルトの名無しさん

2005/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に書いてあったはず。
今手元になくて、大まかにしか思い出せないけど。

0209デフォルトの名無しさん

2005/11/14(月) 21:32:06

最初は < と > にしようと思ったけど、人々の頭には既に
「より小さい」「より大きい」という意味が強く刷り込まれていたので
シフト演算子にした、というのは、C++3rdのほうの氏の表現。

まぁ同じことを言っているのだと見ていいだろうね。

0210デフォルトの名無しさん

2005/11/14(月) 21:35:36

>>209
そう言われればそんなこともD&Eに書いてあったな。

0211デフォルトの名無しさん

2005/11/15(火) 20:05:54

<<= 演算子じゃいけなかったのかな？

0212デフォルトの名無しさん

2005/11/15(火) 20:07:18

あ、よく考えたら、<< と、<<= だと優先順位などの関係で
まとめてかけなくなるからダメか。

0213デフォルトの名無しさん

2005/11/15(火) 20:37:00

どっちにしてもキモくてなじめないなｗ

0214デフォルトの名無しさん

2005/11/15(火) 20:59:09

extern int operator BjaneStroustrup(int x,int y);
...
printf("output = %d",1 BjaneStroustrup 2);
...

output = 禿禿禿

0215デフォルトの名無しさん

2005/11/15(火) 21:04:36

ここ死んでるね。

0216デフォルトの名無しさん

2005/11/15(火) 21:06:02

>>214
コンパイルエラー

0217デフォルトの名無しさん

2005/11/15(火) 21:16:16

>>211
それだと入力が>>=になって見た目の対称が取れない。

0218デフォルトの名無しさん

2005/11/15(火) 21:29:49

MFC使いっす。
すっとばしてたSTLのことが気になってるんですけど、
勉強した方がいいコード書けるようになりますか？
winのアプリの性能が上がるとか、効率がよくなるとかなら勉強しようと
思うんですが、詳しい人教えてください。

0219デフォルトの名無しさん

2005/11/15(火) 21:33:56

じゃぁまずMFC使うのやめれ

0220デフォルトの名無しさん

2005/11/15(火) 21:36:09

MFCとSTLは競合するので同時に使用するのは無理ですよ

0221デフォルトの名無しさん

2005/11/15(火) 21:41:11

STL は汎用的な部品であって求めるべきなのは実行効率ではなく、開発効率じゃまいか？

0222デフォルトの名無しさん

2005/11/15(火) 21:41:33

>>218
そういうことを人に聞くような奴には使いこなせないと思う

0223デフォルトの名無しさん

2005/11/15(火) 21:46:02

>>220
偽。

>>221
何もかもインライン関数で書かれているからなんだかんだいって実行速度だって遅くない。

>>218
とりあえずMFCのコレクションクラスを使わずにSTLのコンテナクラスを使うことから始めてみろ。

0224デフォルトの名無しさん

2005/11/15(火) 21:47:55

>>219-220
普通にMFCでSTL使ったアプリを作って納品したことがあるのだが、
MFCとSTLが競合するとはどういうことなのか説明していただけるか。

0225デフォルトの名無しさん

2005/11/15(火) 21:49:13

>>218
コンテナクラス各種のことなら、使い方を間違うと性能を落とす可能性もあるが
保守性と開発効率と信頼性に効果があることが多い。
<algorithm>のような関数テンプレートのことなら、修得に難があるが
保守性と開発効率と信頼性に効果があることが多い。

>>219
んな無体な。

>>220
詳しく。

0226デフォルトの名無しさん

2005/11/15(火) 21:51:53

>>224
わしゃ、使うのやめろとは言ったが競合するとは言っとらんぞ

0227デフォルトの名無しさん

2005/11/15(火) 22:05:41

マルチスレッドのとき競合する事がある

0228デフォルトの名無しさん

2005/11/15(火) 22:08:35

>>227
それはMFCとSTLの競合ではないだろ。

0229224

2005/11/15(火) 22:22:54

>>226
大変失礼いたしました。てっきり同一人物かと早合点。

0230デフォルトの名無しさん

2005/11/16(水) 00:37:35

気になったのでぐぐってみた。

ttp://support.microsoft.com/default.aspx?scid=kb;ja;154419
Q5 : MFC (Microsoft Foundation Classes) アプリケーションで標準 C++ ライブラリを使用した場合、C ランタイムライブラリとの競合は発生しますか。
A5 : 競合は発生しません。MFC では、標準 C++ ライブラリと競合する C ランタイム関数は使用されていません。

とはいってもMSなので、地雷があったりするのかもしれんが。

0231デフォルトの名無しさん

2005/11/16(水) 00:43:06

ここで言ってる競合の意味は？「スレッドセーフでない」という意味？
必要に応じて自分で排他処理を埋め込む必要があるのはMFCだって同じ。

0232デフォルトの名無しさん

2005/11/16(水) 01:19:30

ちょい古めのＭＦＣでは CreateThread で作ったスレッドで
Ｃランタイムライブラリ使うとメモリ損失をおこすのでダメ、
でもってSTL も shuffle やらに rand() 使ってたりするんでダメって話題じゃないの？

0233デフォルトの名無しさん

2005/11/16(水) 01:23:44

>>232
MFCとSTLの競合とはちょっと意味合いが違うような。
有益な情報だが。

0234デフォルトの名無しさん

2005/11/16(水) 04:30:42

下手の考え休むに似たり

0235デフォルトの名無しさん

2005/11/16(水) 06:59:04

>>232
MFCを使った場合も同様。
MFCのクラスや関数を使う場合はAfxBeginThread()を使わなければならない。
STLだけを敬遠する理由にならない。

0236デフォルトの名無しさん

2005/11/16(水) 19:10:29

ようじょにインサートするにはどのクラスを使えばいいの？

0237デフォルトの名無しさん

2005/11/16(水) 20:08:17

MFC使うとモッサリするからなるべくATＬ+STLでやる

0238デフォルトの名無しさん

2005/11/16(水) 20:57:45

ATL使うぐらいなら
COM+SDKでｵﾅﾆｰした方がまし

0239デフォルトの名無しさん

2005/11/16(水) 21:30:49

ATL自体には全くといっていいほど魅力がないのだが、
WTLを使う場合に必要なのでいつのまにかATLを使ったことになる。そんな感じ。

0240デフォルトの名無しさん

2005/11/16(水) 21:37:14

ATLはATL::CA2Wみたいな文字列変換関連が便利。
あとGetWindowLongPtrなんかをきちんとinline関数で定義しなおしてくれるのがありがたい。

0241デフォルトの名無しさん

2005/11/16(水) 23:26:45

ATLはこれ作った奴はイカれた天才だと分かるが
MFCを見るとこいつは俺なみにバカだなと思う
この差はなにか。予算が違うのか

0242デフォルトの名無しさん

2005/11/16(水) 23:34:35

単に設計された時代の差。

0243デフォルトの名無しさん

2005/11/17(木) 02:39:52

そんないいわけは通用しない！
なんだあのコントロールバーは！

0244デフォルトの名無しさん

2005/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.

0245デフォルトの名無しさん

2005/11/17(木) 20:50:43

>>244
> Expression: list iterator not incrementable
これ読め。

0246デフォルトの名無しさん

2005/11/17(木) 20:55:06

>>245
＞リストイテレータは加算できません
だと思うのですが何のことやらさっぱりです
加算といえばit++のことを指しているのでしょうがこれを無くすわけにもいきません
よろしくお願いします

0247デフォルトの名無しさん

2005/11/17(木) 20:55:41

お断りします

0248デフォルトの名無しさん

2005/11/17(木) 20:56:58

>>247
私のことを弄んだのですか？

0249デフォルトの名無しさん

2005/11/17(木) 20:57:13

>>244
つlist<>::remove_if()

0250デフォルトの名無しさん

2005/11/17(木) 21:04:00

>>246
ヒント: eraseの戻り値がend()かもしれない

0251デフォルトの名無しさん

2005/11/17(木) 21:07:25

>>249-250
ありがとうございます、理解できました
eraseがend()を指しているのにさらにit++してしまったのですね
remove_ifを使えば目的は達せられそうです
本当にありがとうございました

0252デフォルトの名無しさん

2005/11/18(金) 00:31:36

イテレータの不正領域インクリメントをassert()で教えてくれてるうちは、まだいい方でしょ。
インクリメント演算子の中で無限ループされた日には(ry
ブレークポイント置いてもどこで無限ループに突入したのか分からず困ったことがある。

0253デフォルトの名無しさん

2005/11/18(金) 01:24:47

アセンブラ読めないお前がヘタレすぎるだけだろ

0254デフォルトの名無しさん

2005/11/18(金) 07:50:40

つーか、ループ判定に使ってるイテレータを
わざわざeraseの戻り値で更新してるのがバカなだけだろ

0255デフォルトの名無しさん

2005/11/18(金) 09:30:07

要するに馬鹿と。

0256デフォルトの名無しさん

2005/11/18(金) 10:03:31

>>159
> boost::string_algoみたいに非ﾒﾝﾊﾞでもっと汎用的に実装できなかったものか

boost::string_algoは標準化される見込みが高いです。
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1872.html
まあtemplateがなかった頃に設計されたものだからね。

専用のださメンバ関数は徐々にdeprecatedになっていくといいんだけど…

0257デフォルトの名無しさん

2005/11/18(金) 10:05:50

>>242
いや、MFC出た時点で、設計者はうすらとんかちだと思った。

0258デフォルトの名無しさん

2005/11/18(金) 15:24:37

>>254
いいえ、それ自体は普通の行動ですね。
バカなのは、それを「上手くやれない」人と、「それ自体がバカだと思っている」人だけです :-)

0259デフォルトの名無しさん

2005/11/18(金) 17:31:41

まぁそうむきになるなよｗ

0260デフォルトの名無しさん

2005/11/18(金) 18:10:53

>>257
「うすらとんかち」なんて単語見かけたの２０年ぶり位かも。

0261デフォルトの名無しさん

2005/11/18(金) 18:38:33

うすらとんかち

0262デフォルトの名無しさん

2005/11/18(金) 19:42:33

>>256
うは、ﾏｼﾞすか
次の規格改訂はshared_ptやらbindやらstring_algoやらで
かなり使い勝手が良くなりそうですな

0263デフォルトの名無しさん

2005/11/18(金) 19:57:45

標準化委員会はそんなに甘くない。
互換性という壁によって砕け散るだろうね。

0264デフォルトの名無しさん

2005/11/18(金) 21:51:31

とりあえずfilebufのコンストラクタにwchar_tなfilenameを渡せるようにしてくれると助かる。
Windowsだとそれなりに便利なのさ。なけりゃ自分で書くだけなんだけど。

0265デフォルトの名無しさん

2005/11/18(金) 21:57:47

正直標準にならなくてもboostがしっかり存在し続けていれば
それで良いような気がする。

0266デフォルトの名無しさん

2005/11/19(土) 01:32:10

>>264
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1802.html
これのwstring版が欲しいって事だよね。

0267デフォルトの名無しさん

2005/11/19(土) 09:12:26

>>264
C++ 0xでfstream類のコンストラクタにFILE *を引数に取るコンストラクタを設けるという提案があった気がする。
これが実現すれば_wfopenが使えるようになって、それだけでもだいぶましなるのではと俺は思っている。

0268デフォルトの名無しさん

2005/11/19(土) 11:41:11

vectorって何でサイズ拡張するときにコピーコンストラクタとデストラクタを呼ぶの？
メモリ確保してデータを移動するんだったら↑のを呼ばなくても
ただmalloc→memcpy→freeだけでいいと思うんだが

0269デフォルトの名無しさん

2005/11/19(土) 12:19:53

そこまで単純なものじゃないから

0270デフォルトの名無しさん

2005/11/19(土) 12:30:44

いくらなんでも頭悪すぎだろ・・・
268はどんなクラス設計してきたんだ？
もしライブラリ自作してたらこいつのだけは
絶対使いたくないな。

0271デフォルトの名無しさん

2005/11/19(土) 12:33:14

いや、お前には使わせないから大丈夫(^o^)

0272デフォルトの名無しさん

2005/11/19(土) 13:04:21

頼まれても使わないから大丈夫(＾ω＾)

0273デフォルトの名無しさん

2005/11/19(土) 13:06:36

>>268
C使っときなさい。

0274デフォルトの名無しさん

2005/11/19(土) 13:13:13

まぁ、stlのvectorは無駄が多いのは周知の事実なわけだがな

0275デフォルトの名無しさん

2005/11/19(土) 13:23:22

無駄が多いのはおまいの設計が悪いだけ

0276デフォルトの名無しさん

2005/11/19(土) 13:35:05

低能はvbでも使っとけ

0277デフォルトの名無しさん

2005/11/19(土) 13:45:37

vectorを使ったとしても、プログラマはリソースの明示削除手続きから解放されるだけであり、
無駄が出ないように工夫する義務はプログラマにある。

0278デフォルトの名無しさん

2005/11/19(土) 13:55:40

まだvb馬鹿にしてる奴がいるのか、さすがstl厨

0279デフォルトの名無しさん

2005/11/19(土) 14:10:26

VBは所詮VB

0280デフォルトの名無しさん

2005/11/19(土) 16:07:53

STLとSTOってどっちがつおいの？

0281デフォルトの名無しさん

2005/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;
};

0282デフォルトの名無しさん

2005/11/19(土) 16:18:04

>>280
答えはキミの中にあります

0283デフォルトの名無しさん

2005/11/19(土) 17:17:07

コピーコンストラクタがいやなら shared_ptr 使うか、
vector<hoge* > ってすべきだな。
あとインスタンス化のたびに競合おこしたりとかいうのもあるし、
初期化~終了までファイルロックする類のクラス作ったりすると。

0284デフォルトの名無しさん

2005/11/19(土) 19:30:38

boost::ptr_vectorでもよい。

0285デフォルトの名無しさん

2005/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みたいな形で、スコープを抜けるときに呼び出す関数を
積んでおくことができると理想なのですが

0286デフォルトの名無しさん

2005/11/21(月) 17:56:11

boost::move_ptrやshared_ptrみたいに削除子を指定するのはﾀﾞﾒ？

0287デフォルトの名無しさん

2005/11/21(月) 18:10:35

>>286
サンキュー！そのものズバリが見つかったーよ
http://boost.cppll.jp/HEAD/libs/smart_ptr/sp_techniques.html#on_block_exit

以前、どこかのWebでスコープを抜けるときにコードを実行できるようなことを読んだ覚えがあって、
「スコープ終了処理指定」とかいろいろぐぐっても、なかなか見つけられなかったけど、
削除子で検索したら一発でした

0288デフォルトの名無しさん

2005/11/21(月) 18:59:33

その手のテクニックなら ScopeGuard も候補になるかな．

0289デフォルトの名無しさん

2005/11/21(月) 21:01:19

>>285
FinallyCloseHandle hFile = CreateFile(...);ではだめなのか？

0290デフォルトの名無しさん

2005/11/22(火) 00:49:20

>>288
さんくす！ScopeGuardも調べてみた

http://www.kmonos.net/alang/klx/
ここに実装例があったけど、ようは終了処理の関数と引数の参照を入れとくのね
勉強になります

>>289
あ、newじゃなくても良いですね
287に書いていますが、以前、どこかのwebでこの方法を見たとき
おぼろげにテンプレートを使って実現していたような覚えがあったので、
こんな風な書き方になってました

0291デフォルトの名無しさん

2005/11/22(火) 12:22:58

（数値地図から）200×200の数の行列？を読み込まし、iと、i＋1と、j、　j＋１で四点をとり、その４点の一番大きい値から小さい方へいくプログラムがつくれません
参照できるサイトありますか？わかる人いますか？ヒントください＞＜
もう三ヶ月悩んでます、助けて
馬鹿な為ほんとプログラムわからないんです

0292デフォルトの名無しさん

2005/11/22(火) 12:31:21

>>291
マルチ死ね

0293デフォルトの名無しさん

2005/11/22(火) 20:16:26

指定した条件に合致したインスタンスを指すイテレータを返す関数を作るときは
その返却値となるイテレータにNULLを使っていいんでしょうか？

0294デフォルトの名無しさん

2005/11/22(火) 20:25:50

>>293
つ[std::find_if()]

0295デフォルトの名無しさん

2005/11/22(火) 20:29:51

普通はendが返るんじゃね？

0296デフォルトの名無しさん

2005/11/22(火) 20:30:05

>>293
NULLはポインタにしかない。

0297デフォルトの名無しさん

2005/11/22(火) 21:53:50

>>294
うあ、そんな便利なものが…。
使ってみます。ありがとうございました。

>>295
>>296
なるほど。
std::find_if()してきて、それがend()かでエラー判定するんですね。
ありがとうございました。

0298294

2005/11/22(火) 23:17:49

<algorithm>や<numeric>はその手のロジックの宝庫だからね。
この辺に慣れるとちょっとした集計なんかがループを書かずにできる。

0299デフォルトの名無しさん

2005/11/24(木) 00:24:57

ちと古いネタにレスします
C++は一週間ぐらい前に始めたばかりなのでよくわかってないかもしれないけど、その辺はフォローよろしくです。
>>267
FILE * からfstreamを生成する場合、FILE*のクローズの責任（というよりFILE*の所有者）は誰になるのでしょう？
古いVCだとFILE*からfstream作った時は明示的にclose()呼ぶようにとか書いてあったような気がするんだけど、これじゃあまり使い道が・・・
自分で作ったfstream(Widefilename版)だとFILE *から作ってもデストラクタでクローズしてしまいます。
fstream(_wfopen(...))みたいな使い方を想定してます。

0300267

2005/11/24(木) 07:48:28

>>299
すまん。
たまたま耳にしただけであって，そこまで詳しいところは読んでいない。
でも俺が作るとしたら後者の方式（fstreamが所有権を持ちデストラクタでクローズする）にするな。

0301デフォルトの名無しさん

2005/11/24(木) 08:35:29

gcc拡張のstdio_filebuf, stdio_sync_filebufは、closeなし。
cin, cout, cerrのfilebuf先は、main()出た後のstdin, stdout, stderrのclose任せ。

0302デフォルトの名無しさん

2005/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というテキストファイルが出来た。
なぜだろうね？

0303デフォルトの名無しさん

2005/11/24(木) 18:46:50

>>302
ios::binaryってフラグは、CR+LFのようなOS依存コードをcookedではなくて
rawで書け、って意味。

std::ostream_operator<int>←って指定してるじゃん。これじゃあ　<< で
出力したのと全く同じ。

バイナリで書きたければwrite()を使いなせえ。

0304デフォルトの名無しさん

2005/11/24(木) 18:50:17

あ、put()でもいいよ。

0305デフォルトの名無しさん

2005/11/24(木) 18:53:43

どうしてもアルゴリズムでバイナリを出力したければ、ユーザー定義の
バイナリ出力反復子を作るか、<<を多重定義し、バイナリ出力
専用のクラスを作り、for_eachで渡すか、だなあ。

0306302

2005/11/24(木) 19:23:10

詳しくありがとう。

0307デフォルトの名無しさん

2005/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));
}

0308デフォルトの名無しさん

2005/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));
}

0309デフォルトの名無しさん

2005/11/25(金) 07:26:24

私は、fstream系をデバッグトレース出力にしか使わないなぁ。
とりあえずトレースしたいときは、色んな構造体に対して<<演算子がオーバライドされてると、便利だ。
でも、一般のファイルを読み書きする時は専らcstdioを使う。
皆さんはどう？

0310デフォルトの名無しさん

2005/11/25(金) 08:30:44

cstdio を使う理由なんて、互換性以外に何があるんだ。
使いわけたりしねぇよ…。

0311デフォルトの名無しさん

2005/11/25(金) 09:14:02

fstreamって何でこうもまあ低速なの？

0312デフォルトの名無しさん

2005/11/25(金) 09:58:43

>>310
iostream・fstreamはファイルサイズが無駄に大きくなる。
ちょっとしたコンソールアプリには、iostreamは大げさすぎる実装だ。

0313デフォルトの名無しさん

2005/11/25(金) 10:31:01

今時数十KB増えるくらい蚊に刺されたようなもんじゃん。

0314デフォルトの名無しさん

2005/11/25(金) 10:55:12

>>312
それなら C 使えば？

0315デフォルトの名無しさん

2005/11/25(金) 12:38:37

また莫迦が STL ｽﾚで stream の話してるよ…

0316デフォルトの名無しさん

2005/11/25(金) 12:45:01

>>315
過去ログと空気は読む物ってことだわな

0317デフォルトの名無しさん

2005/11/25(金) 12:55:52

まぁSTLという言葉の定義に持ち込む>>315のほうが馬鹿だけどね。

0318デフォルトの名無しさん

2005/11/25(金) 13:07:39

>>307-308
便乗で申し訳ないが、basic_ostream< wchar_t > への対応版も希望

0319デフォルトの名無しさん

2005/11/26(土) 10:46:08

http://dl.njfiw.gov.cn/books/C/

0320315

2005/11/29(火) 16:18:06

>>316-317
初代ｽﾚから居るが。
時々思い出したように粘着しているだけだ。

0321デフォルトの名無しさん

2005/11/29(火) 19:07:08

>>320
？　お前はまさにそこをイジられてるんだが、何をわざわざ説明してるんだ？

0322デフォルトの名無しさん

2005/11/29(火) 22:18:12

>>318
亀レスだが、コンストラクタを変換関数の代わりに使っているので、
OutBin(wchar_t)と、intとwchar_tを受け取った場合のフラグでも
増設して、operator<<の動作を切り替えればいいやん。

0323デフォルトの名無しさん

2005/11/30(水) 19:03:24

vector とかよりももっと複雑な、
一般のグラフ構造のリンク関係を持ったアイテム集合を
うまく扱うためのコンテナクラスライブラリってありませんか？

0324デフォルトの名無しさん

2005/11/30(水) 19:03:55

コンテナクラスライブラリってあんまり使わないみたいなんで
テンプレートクラスライブラリって言い換えます。

0325デフォルトの名無しさん

2005/11/30(水) 19:09:37

クラステンプレートであってテンプレートクラスではない。
STLには存在しないがboost::graphというものは存在する。

0326デフォルトの名無しさん

2005/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();
}
};

0327デフォルトの名無しさん

2005/11/30(水) 22:00:53

>>326
typename std::map<KEY, VAL>::iterator...

0328デフォルトの名無しさん

2005/11/30(水) 22:09:59

>>327
ありがとうございます。
どうしてtypenameをつけるとコンパイル通るんですか？

0329デフォルトの名無しさん

2005/11/30(水) 22:20:14

>>328
http://www.fides.dti.ne.jp/~oka-t/cpplab-template-4.html

0330デフォルトの名無しさん

2005/11/30(水) 23:11:44

>>329
停滞してるな

0331デフォルトの名無しさん

2005/11/30(水) 23:12:31

逃した魚は大きいぞ

0332デフォルトの名無しさん

2005/11/30(水) 23:59:56

>329
そこを読んで思ったんだが、
typedefの時にtypenameを書かないと通らないコンパイラってあるの？
typedefの引数？は型名に決まっているんだから必要ないように思えるだが。

0333デフォルトの名無しさん

2005/12/01(木) 00:14:14

>>332
そうやって勝手に標準規格をねじ曲げたのがVC7.1だろう。
VC7.1だけ使ってると、typenameが必要だって事が学習しにくい。

0334デフォルトの名無しさん

2005/12/02(金) 01:38:49

7.1はわりとtypenameについて忠実じゃなかったっけ？
6が酷かったのは覚えているが。

0335デフォルトの名無しさん

2005/12/02(金) 02:07:50

いや全然

0336デフォルトの名無しさん

2005/12/02(金) 02:12:05

そうか気のせいだったか。

0337デフォルトの名無しさん

2005/12/04(日) 20:17:12

>>333
typenameなんていらないじゃん。未熟なコンパイラを救うためだけのもんだろ。

0338デフォルトの名無しさん

2005/12/04(日) 20:21:40

>>337
typename は未熟な C++ 言語仕様を救うためのもんだよ。
コンパイラベンダがどうこうするもんじゃない。

0339デフォルトの名無しさん

2005/12/04(日) 20:30:15

即ち禿がC++に毛を生やす努力をすればtypenameはいらない。

0340デフォルトの名無しさん

2005/12/04(日) 22:16:07

お前らいつもいつも禿禿って…いい加減にしろよ？

0341デフォルトの名無しさん

2005/12/04(日) 22:42:49

あ、びょーん先生こんにちは。
今日も落ち武者ヘアー似合ってますよ。

0342デフォルトの名無しさん

2005/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と出ます。

0343デフォルトの名無しさん

2005/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().

0344デフォルトの名無しさん

2005/12/05(月) 22:55:11

事前条件として !ivec.empty() に注意ね

0345デフォルトの名無しさん

2005/12/07(水) 19:20:03

Boostを使わずにSTLのみで、スマートにcsvファイルを読み込めたりする？

0346デフォルトの名無しさん

2005/12/07(水) 19:27:03

>>345
RFC4180を見る限り、スマートにってのは無理みたいだね。

0347デフォルトの名無しさん

2005/12/07(水) 19:33:15

>>346 そんな RFC があったのか・・・

0348デフォルトの名無しさん

2005/12/07(水) 20:00:03

たしか超最近出来たRFCだろそれ

0349デフォルトの名無しさん

2005/12/07(水) 20:56:06

>>346
そんなのあったのか

つかC/C++でCSVファイルを読むのはクソだるいんだよな
書くのは楽なんだが。

0350デフォルトの名無しさん

2005/12/07(水) 21:18:00

Java だと楽なの？CSVファイル読むの。
いや、俺、Javaほとんど使ったことないから。

0351デフォルトの名無しさん

2005/12/07(水) 21:43:47

CSVつってもExcel仕様のCSVとか色々あるんじゃないの。
引用符の処理や複数行のセルとかどうすんだとか。

0352346

2005/12/07(水) 22:26:19

>>347-349
今年10月にできてる

0353デフォルトの名無しさん

2005/12/08(木) 00:43:10

ttp://www005.upp.so-net.ne.jp/episteme/html/stlprog/_02.html#making_iterator
ここの雛形を使ってイテレータを作ってみようと思ったんですが、

'iterator' : 定義されていない基本クラスが宣言されています
となってしまいます。
#include <iterator>
の他にする事があるんでしょうか？

0354デフォルトの名無しさん

2005/12/08(木) 00:57:48

名前空間じゃね?

0355デフォルトの名無しさん

2005/12/08(木) 01:06:30

>>354
using namespace std;
または
std::iterator
としたらすんなり通りました。
ありがとうございました。

0356デフォルトの名無しさん

2005/12/08(木) 01:18:01

RFCってのは4月にチェックするものだと言うすり込みがあるのでしらんかった。

0357デフォルトの名無しさん

2005/12/08(木) 01:23:57

さすがにそれはどうかとｗ
確かに俺も毎年4月は確認するけどさｗｗｗ

0358デフォルトの名無しさん

2005/12/08(木) 01:51:41

>>350
Javaは標準ライブラリに、StringTokenizer があるから、
少なくとも、C++標準だけでやるよりは楽。

0359デフォルトの名無しさん

2005/12/08(木) 01:53:16

>>358
StringTokenizerはCSVのパーシングにおいては何の役にも立たないと思うぞ

0360デフォルトの名無しさん

2005/12/08(木) 01:55:19

そうなの？
まぁ、でもRegexあるけど。

0361デフォルトの名無しさん

2005/12/08(木) 01:56:38

>>360
人に聞く前に>>346にせっかく挙がってるRFC嫁よ

0362デフォルトの名無しさん

2005/12/08(木) 02:25:12

a","b""bb","ccc CRLF
ﾋﾄﾞｽ

でもBNFがあったのですぐ解った

0363デフォルトの名無しさん

2005/12/08(木) 06:39:02

CSVが難しいのは、ハウス規格がたくさんあるからで、
>>358 >>359 >>360の言っているような問題じゃない。

>>362
Shift_JISだと、あのBNFじゃ駄目だけどね。

0364デフォルトの名無しさん

2005/12/08(木) 11:47:10

あー、RFCだから仕方ないけどCrLf限定になってるし2バイト文字が通らない。
これもまた実態に合わないのか。

0365デフォルトの名無しさん

2005/12/08(木) 12:02:30

Category: Informational

0366デフォルトの名無しさん

2005/12/08(木) 13:55:59

CSVなんかはPerlで読んじゃうな
前処理させとくだけでもずいぶん楽だし

0367デフォルトの名無しさん

2005/12/08(木) 20:25:06

>>366
正しいと思う。
CSVファイル読込が全体に占める消費時間は微々たる物になるケースがほとんどだし。

0368デフォルトの名無しさん

2005/12/09(金) 04:06:12

RFC 書いた人、実体分かって書いてるのかな。

0369デフォルトの名無しさん

2005/12/09(金) 12:23:24

Boost.Spirit フレームワークで、簡単お手軽CSVパーサを作れば
かなりイイ感じだが、>>345 は、「Boost を使わず」といってるし…

0370デフォルトの名無しさん

2005/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.

とある。別に制限するものではないと思うけど。

0371デフォルトの名無しさん

2005/12/09(金) 13:42:54

>>370
> 別に制限するものではないと思うけど。

このメディアタイプではCR LFのみだよ。
曖昧にしたら駄目じゃん。いまさらRFCにする意味が半減。

ローカルシステムはCRのみやLFのみかもしれないから、
実装する奴は気をつけろって事。

世間では色々乱れてるから、このメディアタイプ定義で
(インターネット上での)データ交換の規準ができた。

0372デフォルトの名無しさん

2005/12/09(金) 13:45:12

↓これね。

4.1.1. 行分断（改行）の表現

MIME"text"サウブタイプの正式書式は、必ずCRLF列（連続体）として行分断を
表現しなければなりません。同じ様にMIME"text"でのCRLFの出現は如何なるも
のでも行分断を表現します。行分断以外でのCRとLFの使用も禁じられています。

この規則は、書式もしくは文字セットもしくは含まれている設定に関わらず、
適用されます。

http://www.asahi-net.or.jp/~bd9y-ktu/dtd_f/rfc_f/rfc2046j.html

0373デフォルトの名無しさん

2005/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 *>());
}

エラーが一杯出る…

0374デフォルトの名無しさん

2005/12/14(水) 11:31:29

mylist.sort()

list に std::sort は使えないんじゃ

0375デフォルトの名無しさん

2005/12/14(水) 11:34:55

>>373
list.sort();

0376デフォルトの名無しさん

2005/12/14(水) 11:37:23

>>373
もうちと付け足す。std::sort()は、random access iteratorを要求している。
しかし、std::list::iteratorは、bidirectional iterator なので、コンパイルが
通らない。

それでは使い勝手が悪いので、std::list::sort()が用意されている。こちらは
マージソートが歴史的な理由から採用されており、bidirectional iterator
でも動くようになっている。

0377373

2005/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しか受け付けない？

http://rararahp.cool.ne.jp/cgi-bin/lng/vc/vclng.cgi?print+200312/03120061.txt
ここのページによると原因はVC6だかららしい。
ついでに解決策を参考にして、何とかソート出来た！

0378デフォルトの名無しさん

2005/12/14(水) 14:06:07

>>376
ついでに補足しておく。
C++標準において、「std::list<>::sort()がStableソートであり、等価な要素の
相対的な位置関係が保たれること」が、保証されている。
で、歴史的な理由により、ほぼ全ての実装でマージソートが採用されている。
(が、その保証はない)

0379デフォルトの名無しさん

2005/12/14(水) 19:51:00

επιστημη ←こいつ調子に乗ってるな
何様だよ

0380デフォルトの名無しさん

2005/12/14(水) 19:55:23

こんなところで吠えてないで本人に直接言えよ

0381デフォルトの名無しさん

2005/12/14(水) 21:58:36

標準化メンバーの1人だっけ?

0382デフォルトの名無しさん

2005/12/14(水) 23:28:12

そだよ、標準ライブラリの一部も彼を含めた日本の標準化委員会の案

0383デフォルトの名無しさん

2005/12/14(水) 23:53:13

>>379
過疎スレにいってらっしゃい。

επιστημηってウザくね？
http://pc8.2ch.net/test/read.cgi/tech/1091350633/

0384デフォルトの名無しさん

2005/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;
}

0385デフォルトの名無しさん

2005/12/15(木) 23:25:25

そこで呼び出されてるわけじゃない。
関数のアドレスを渡してるだけ。

0386デフォルトの名無しさん

2005/12/15(木) 23:26:58

>>384
そもそも呼び出されてすらないし。find_ifに関数渡してるだけでしょ。
find_ifの中の人がiteratorを実引数にしてiscommaを呼び出すってだけの話。

0387デフォルトの名無しさん

2005/12/15(木) 23:27:40

Oppsかぶったかぶった。

0388デフォルトの名無しさん

2005/12/15(木) 23:51:56

>>385-386
ものすごく納得いきました。ありがとうございます。

0389デフォルトの名無しさん

2005/12/16(金) 02:58:10

>>388 は qsort とか使ったことなかったのかな・・

0390デフォルトの名無しさん

2005/12/16(金) 06:00:51

皆が皆CからC++へ行くわけじゃないからね。

0391デフォルトの名無しさん

2005/12/16(金) 06:34:27

qsortはCの関数だがな

0392デフォルトの名無しさん

2005/12/16(金) 07:00:16

話がかみ合ってない悪寒

0393デフォルトの名無しさん

2005/12/16(金) 08:10:52

>>385
> 関数のアドレスを渡してるだけ。

関数オブジェクトを渡しています。

0394デフォルトの名無しさん

2005/12/16(金) 08:12:50

>>393
馬鹿ですか？関数と関数オブジェクトの見分け方ぐらい
付けられるようになっとけ。

0395デフォルトの名無しさん

2005/12/16(金) 11:09:08

>>387
オップス?
もしかして：Oops!

0396デフォルトの名無しさん

2005/12/16(金) 14:31:25

↓>>393の必死な言い訳

0397デフォルトの名無しさん

2005/12/16(金) 16:22:37

関数⊂関数オブジェクト

0398デフォルトの名無しさん

2005/12/16(金) 16:25:37

もう少しこう、うっかり騙されそうなネタで頼む

0399デフォルトの名無しさん

2005/12/16(金) 16:43:58

↓素直に自分の無能を認める>>393

0400デフォルトの名無しさん

2005/12/16(金) 17:07:28

俺が悪かった

0401デフォルトの名無しさん

2005/12/16(金) 17:12:16

いや俺のほうが悪い

0402デフォルトの名無しさん

2005/12/16(金) 17:51:26

私のために争わないで！

0403デフォルトの名無しさん

2005/12/16(金) 18:21:45

もうこれ以上

0404デフォルトの名無しさん

2005/12/16(金) 18:55:58

君のまわりに不幸の存在を俺は認めない

0405デフォルトの名無しさん

2005/12/16(金) 20:07:19

>>389
10月中旬ごろ標準Cの勉強を始めて
11月下旬に標準C++へ、MFCを使って電卓を作って、WinSockでechoサーバをみようみマネでつくり
昨日、初めてSTLの勉強を始めて・・・何故か本の真ん中からはじめたので右も左もわからず・・・・

って感じです。今までネットワークエンジニアとして修行していたのでプログラミングは、つぅあっパリですｗ

0406デフォルトの名無しさん

2005/12/16(金) 23:47:13

最初から読もうぜ。結構なんとかなってしまうけど、基本も大事だしね。

0407デフォルトの名無しさん

2005/12/17(土) 00:43:22

>>406
STLにも勉強する順番があるんですか？

0408デフォルトの名無しさん

2005/12/17(土) 00:55:26

>>407
私は>>406ではありませんが。勉強に順序はありません。でも、
一般的にはstd::vector<>が最初に紹介されていませんかね？

0409デフォルトの名無しさん

2005/12/17(土) 00:59:32

>>407
俺は>>406じゃないけど、STLを基本概念から全部理解しようと
したら大変だぜ。本が何冊も出ている。

よく使うコンテナやアルゴリズム、関数オブジェクトの使い方あたり
から少しずつ入って行けば楽なのではないかと思う。

0410デフォルトの名無しさん

2005/12/17(土) 01:22:06

vector → list → iterator → algorithm → functional → その他

くらいでいいんじゃね？

0411デフォルトの名無しさん

2005/12/17(土) 02:25:01

>>410
ご教授、ありがとうございます。
時間があればそのようなことをしたいと思います。

0412デフォルトの名無しさん

2005/12/17(土) 02:36:29

>>411
vector→list→map→algorithm→functional→[boost]

0413デフォルトの名無しさん

2005/12/17(土) 03:26:07

最初からLoki

0414デフォルトの名無しさん

2005/12/17(土) 03:48:00

>>412
はいはい。じゃーそれで

0415デフォルトの名無しさん

2005/12/17(土) 07:17:05

Vector → 窓の杜

0416デフォルトの名無しさん

2005/12/17(土) 09:35:09

Vector→Quaternion→Matrix

0417デフォルトの名無しさん

2005/12/17(土) 10:16:04

テンソルは？

0418デフォルトの名無しさん

2005/12/17(土) 10:41:51

>>414
わかればよろしい。

0419デフォルトの名無しさん

2005/12/17(土) 10:54:53

Scalar → Vector → Tensor

はいはい、テンソルテンソル。

0420デフォルトの名無しさん

2005/12/17(土) 11:04:45

>>419 わかればよろしい

0421デフォルトの名無しさん

2005/12/17(土) 11:08:09

>>419
わかればよろしい。

0422デフォルトの名無しさん

2005/12/17(土) 11:10:04

はいはい、すごいね、テンソルテンソル

0423デフォルトの名無しさん

2005/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が最初のコンテナとして適当ではないかと。

0424デフォルトの名無しさん

2005/12/17(土) 13:02:54

私は実務で使いながらだったから
vector → iterator → algorithm
の順に入ったな。
Cの経験が充分あるなら、取り敢えず可変長配列としてのvectorを見てから
それを一通り使い倒して他にいくと言う意味で悪くないと思う。
#例えばvectorのoperator[]に馴れてそこで留まる香具師にはどうせalgorithmなんて使いこなせないわけだし。

0425デフォルトの名無しさん

2005/12/17(土) 13:54:13

>>424
そえは業務でalgorithmを使っていないって事ですか？

0426デフォルトの名無しさん

2005/12/17(土) 14:02:05

ヘタレがvector使うとバグの温床になる
listとか使った方がまだまし

0427デフォルトの名無しさん

2005/12/17(土) 14:14:24

>>426
なんで？逆じゃないの？

0428デフォルトの名無しさん

2005/12/17(土) 14:23:39

vectorやstringは、今となっては設計が5年は古いよな。
algorithmを使えば済むものが、内部メソッドになってしまっている。

0429デフォルトの名無しさん

2005/12/17(土) 14:31:45

>428
stringはともかくvectorにそれ当てはまる？

0430デフォルトの名無しさん

2005/12/17(土) 15:18:02

>>428
あんた、実はあんまりSTLを知らないね。

std::algorithmを適用できないイテレータを持つコンテナに最適な
アルゴリズムを用意したのが、大抵の内部メソッドだ。

それから、std::stringは、STLには大抵入れない。random access iterator
を使えるので、適用できるアルゴリズムが多いのは確かだが、
用途が主に文字列の操作なので、Cのstring.hに対応する関数を
内部で持っただけ。

0431デフォルトの名無しさん

2005/12/17(土) 15:36:34

>>430
stringの後半の主張はどうかと思うぞ。
STL以前からあるクラスで、今やオールドタイプだ。

0432デフォルトの名無しさん

2005/12/17(土) 15:50:32

std::stringにバイナリを入れられるのは知ってるけど、果たして
std::stringの内部メソッドがそれに適したような格好になってるかな？

0433デフォルトの名無しさん

2005/12/17(土) 18:51:43

>>432
何がいいたいかよくわからん。

0434デフォルトの名無しさん

2005/12/17(土) 19:23:27

>>432
typedef basic_string<char> string; ですから、charなんなんでもありです。
ただしc_str()は'\0'が途中にあるとまずいですが。

>>430
SGIのSTLにstring入ってるぞ。

0435デフォルトの名無しさん

2005/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);

0436デフォルトの名無しさん

2005/12/17(土) 20:02:02

>>435
まずくないのには同意だが、そういうとき普通はc_strじゃなくdataを使うだろ。

0437デフォルトの名無しさん

2005/12/17(土) 20:15:33

>>436
data()は今の議論のテーマではない。
終端に確実にヌルが付加されるc_str()を使わずdata()を用いる利点など一切ない。

0438デフォルトの名無しさん

2005/12/17(土) 20:18:49

>>437
fwriteに渡すのに終端文字がいちいち付加される意味ないのでc_str()なんか使う意味ないだろ

0439デフォルトの名無しさん

2005/12/17(土) 20:19:39

何故?

実装によっては、capacity() != size() の時、
c_str()はdata()より重い処理になるよ。

>>435のようにsize()と使うならdata()ってのが定石だと思う。

0440デフォルトの名無しさん

2005/12/17(土) 20:20:10

>>439は、>>437へのレス

0441デフォルトの名無しさん

2005/12/17(土) 20:26:47

>>438
仕様変更に対する事前策を用意しておくことを無意味とは、大胆発言だな。

ヌル終端文字列を前提とした既存のC関数に渡すとき、
バッファオーバランの可能性を軽減することができる。
この点においてstring::c_str()は、string::data()やstringstream::str()より安全性に優れている。

ヌル終端保証されたc_str()と保証されないdata()。
一方で、c_str()とdata()が同じ挙動をするSTLも存在する。
どちらを使うべきかは一目瞭然だろう。

0442デフォルトの名無しさん

2005/12/17(土) 20:28:22

>>439
サンプルとなる、ソースと開発環境を書け。

0443デフォルトの名無しさん

2005/12/17(土) 20:32:35

>>441
バイナリデータブロックを扱っているところをnul文字終端に仕様変更する準備をしておくなんて
普通じゃないな

0444デフォルトの名無しさん

2005/12/17(土) 20:35:43

>>443
Unicode文字列をバイナリデータとして扱っている場合などはそうでもない。
何をもって普通というのかその人の経験量だろうけど。

0445デフォルトの名無しさん

2005/12/17(土) 20:38:55

１．c_str()は'\0'が途中にあるとまずい
２．size()とともに用いればまずくない
３．そういうときはc_strじゃなくdataを使う
４．ヌル終端文字列を前提とした既存のC関数に渡すときc_str()のほうが安全
５．1に戻る

0446デフォルトの名無しさん

2005/12/17(土) 20:40:22

>>439の実証コードはまだですか？
>>439の正しさが確認されないことには、
議論が進まないのでなるべく早目にお願いします。

0447デフォルトの名無しさん

2005/12/17(土) 20:44:06

>>445
多分、３．は必要ないから、無限ループには陥らない。

0448デフォルトの名無しさん

2005/12/17(土) 20:55:04

結論としては、nul終端が必要ない時はdata()を使え。ただし義務ではない。

0449デフォルトの名無しさん

2005/12/17(土) 20:59:41

data()を使う合理性が確認できない。という限定された結論しか出ていない。
c_str()に対するdata()のパフォーマンス優位性も一切確認されていない。

全ては信者の脳内にしか存在しない。

0450デフォルトの名無しさん

2005/12/17(土) 21:07:02

逆にc_str()の方が安全である実装はあるのか?
俺の知っている実装は全て、data()とc_str()は同じものを返すよ。
data()の時も実は'\0'で終端されているという…

0451デフォルトの名無しさん

2005/12/17(土) 21:13:43

>>450
size() == 0の時少し振る舞いが違うぞ。
まあ多くの実装で返ってくるものは同じだが(w

0452デフォルトの名無しさん

2005/12/17(土) 21:14:32

c_str()のdata()に対する優位性
・ヌル終端保証
・"c_str"というキーワードが他であまり使われないので、文字列検索が"data"に比べて簡単

data()のc_str()に対する優位性
・不明

0453デフォルトの名無しさん

2005/12/17(土) 21:15:15

VC++7.1はdata()がc_str()を呼んで、c_str()が_Myptr()を呼んでるよ。

0454デフォルトの名無しさん

2005/12/17(土) 21:17:31

>>441
そこでstringstream::str()を引き合いに出してくる理由がわからない。

0455デフォルトの名無しさん

2005/12/17(土) 21:19:15

data()のc_str()に対する優位性
・ソース内にc_str()と混在させることにより難読性を高めて、他のプログラマがコピペしにくくする著作権保護効果。

0456デフォルトの名無しさん

2005/12/17(土) 21:23:13

>>454
己の経験不足を報告するスレじゃないはずだぞ。

0457デフォルトの名無しさん

2005/12/17(土) 21:32:22

stringstream::str()はstd::stringを返すのだからss.str().c_str()という手段はないのか？

0458デフォルトの名無しさん

2005/12/17(土) 21:33:10

>>452
> data()のc_str()に対する優位性

Cスタイルの文字列を必要としている局面でないことが明確。

0459デフォルトの名無しさん

2005/12/17(土) 21:44:24

問題があるのは、stringstream::str()じゃなくてstrstream::str()だった。スマソ。

0460デフォルトの名無しさん

2005/12/18(日) 00:07:21

STL使うとどうなるの？

0461デフォルトの名無しさん

2005/12/18(日) 00:12:32

>>460
一気に実行ファイルサイズが10倍になります。

0462デフォルトの名無しさん

2005/12/18(日) 00:14:24

>>460
別世界が開ける。

0463デフォルトの名無しさん

2005/12/18(日) 00:48:02

>>461
環境によるだろ。
俺はBorland-C++5.6.2に -D_RTLDLL オプションを指定して、極力
ランタイムを使用するようにして使っているが、例えばstd::vectorを
使っても使わない時と比べ10Kほどしか増えない。

0464デフォルトの名無しさん

2005/12/18(日) 00:57:46

>>461,463
はいはい、他スレのテンプレわろすわろす

0465デフォルトの名無しさん

2005/12/18(日) 00:57:49

すげえ。ダイナミックリンクしといてファイルサイズが増えないとかいってるよ。この人。

0466デフォルトの名無しさん

2005/12/18(日) 01:03:05

懐かしいなｗ

0467not 463

2005/12/18(日) 01:03:25

そりゃそうでしょ。
「実行ファイルのサイズが１０倍になる」を受けてるレスだから。

0468デフォルトの名無しさん

2005/12/18(日) 01:12:09

http://www.google.com/search?q=%22-D_RTLDLL+%E3%82%AA%E3%83%97%E3%82%B7%E3%83%A7%E3%83%B3%22+%22%E3%83%80%E3%82%A4%E3%83%8A%E3%83%9F%E3%83%83%E3%82%AF%E3%83%AA%E3%83%B3%E3%82%AF%E3%81%97%E3%81%A8%E3%81%84%E3%81%A6%22&num=50&hl=ja&lr=&filter=0

0469デフォルトの名無しさん

2005/12/18(日) 01:30:19

>>468
ﾜﾛｽｗｗｗｗｗ

0470デフォルトの名無しさん

2005/12/18(日) 01:36:26

懐かしさと共にﾜﾛｽｗｗｗｗ

0471デフォルトの名無しさん

2005/12/18(日) 01:45:39

自作自演乙

0472デフォルトの名無しさん

2005/12/18(日) 02:03:26

>>471 がどれを自作自演と言いたいのか判らない。

0473デフォルトの名無しさん

2005/12/18(日) 05:32:51

だってこのスレに書き込んでるの俺一人しかいないしｗ

0474デフォルトの名無しさん

2005/12/18(日) 07:27:07

いつも思うのだが、>>463は正しいことを書いてる。
あの時点で注目されているのはテンプレートのコード生成に伴うサイズ増量であって、
Cランタイムがどのようにリンクされようがテンプレートと何の関係もない。
むしろ動的リンクの方がテンプレートによる増量がわかりやすいかもしれない。

0475デフォルトの名無しさん

2005/12/18(日) 07:31:10

　　　　　　　　　　　i::::::::/'"￣￣ヾi
　　　　　　　　　　　|:::::::|　,,,,,_　 ,,,,,,|
　　　　　　　　　　　|r-==（　｡);（　｡)
　　　　　　　　　　　(　ヽ　　:::__)..:: }
　　　　 ,＿＿__／ヽ　　ー==　;　ほほう　それでそれで？
　　　　 r'"ヽ　　 t､　　＼＿＿_ !
　　　　/ ､､i　　　ヽ＿＿,,/
　　　 /　ヽﾉ　　j　,　　　j　|ヽ　
　　　 |⌒`'､__ /　/　　　/r　 |
　　　 {　　　　￣''ｰ-､,,_,ﾍ＾　|
　　　　ゝ-,,,＿＿＿＿_）--､j
　　　 /　　＼__　　　　　　/
　　　|　　　　"'ｰ‐‐---''

0476デフォルトの名無しさん

2005/12/18(日) 07:48:26

std::string使ってないなあ
MBSやsurrogateやらの対応が甘そうだったので自前で作った

0477デフォルトの名無しさん

2005/12/18(日) 08:06:26

std::stringから継承するという選択肢は無視かね。
MBS対応メソッドを追加すればすむだけなのに。

0478デフォルトの名無しさん

2005/12/18(日) 09:40:48

std::stringから派生するのはやめた方が……。
非仮想デストラクタだし、スライスも怖いし……。

0479デフォルトの名無しさん

2005/12/18(日) 10:03:16

>>478
非仮想デストラクタの心配は杞憂。

別のスコープで作られた派生クラスインスタンスを
基底クラスのポインタで破棄すべき状況が、
果たして文字列クラスで起こりうるかどうか考えよう。
ポインタを使いたくないからクラス化しているのに本末転倒な状況だ。

また、STLのコンテナやアルゴリズムがテンプレートを用いており、
継承をあえて使っていない理由についても考えよう。

ところで、「スライス」とは何？

0480デフォルトの名無しさん

2005/12/18(日) 11:36:17

>>479
基底クラスへのスライシングだろ。
非仮想デストラクタの場合と心配してるところの根は同じだと思う。

0481デフォルトの名無しさん

2005/12/18(日) 11:40:33

>>479
> ポインタを使いたくないからクラス化しているのに本末転倒な状況だ。

そんなあほな。

0482デフォルトの名無しさん

2005/12/18(日) 11:58:05

>>480
スライスが動詞でスライシングが動名詞だということだけはわかりました。本当にありがとうございました。

>>481
そういうもんですか？
自分でバッファを確保・解放するなら、
文字列クラスじゃなくて生のchar*でいい気がするけど、どうでしょうか。
暗黙のうちに解放されるコンテナの場合、>>479が触れているとおりテンプレートだし。
だめ？

0483デフォルトの名無しさん

2005/12/18(日) 12:40:10

スライシングすらわからんのなら出直してこい

0484デフォルトの名無しさん

2005/12/18(日) 12:46:34

>>476
std::wstringは？

>>477
char_traitsの自作は？

0485デフォルトの名無しさん

2005/12/18(日) 14:40:45

オススメはbasic_string<unsigned char>でUTF-8

いや、マジで。

0486デフォルトの名無しさん

2005/12/18(日) 14:55:54

1文字進めるとかは？

0487デフォルトの名無しさん

2005/12/18(日) 15:01:58

>>484
>std::wstringは？
ワイド文字列の罠
ttp://hw001.gate01.com/eggplant/tcf/cpp/wchar_t_trap.html

0488デフォルトの名無しさん

2005/12/18(日) 15:34:13

Windows上で多言語対応が必要ないなら16bit化SJISをwstringにつっこむのが最強。

0489デフォルトの名無しさん

2005/12/18(日) 18:40:23

>>488
それAPIやライブラリ関数呼び出しの度にchar*またはwchar_t*に
変換せなあかんのか
最悪じゃん

0490デフォルトの名無しさん

2005/12/18(日) 19:28:16

>>488
UTF-16をwstringに格納することに比べどんな利点があるのか？

0491デフォルトの名無しさん

2005/12/18(日) 21:56:36

1文字進めるのが簡単

0492デフォルトの名無しさん

2005/12/18(日) 22:04:08

そして2文字戻す。

0493デフォルトの名無しさん

2005/12/18(日) 22:51:03

三歩進んで二歩下がる

0494デフォルトの名無しさん

2005/12/19(月) 09:49:59

>>479
> また、STLのコンテナやアルゴリズムがテンプレートを用いており、
> 継承をあえて使っていない理由についても考えよう。

(ﾟДﾟ)ﾊｧ?
テンプレート関係ないやん

0495デフォルトの名無しさん

2005/12/19(月) 10:12:46

0496デフォルトの名無しさん

2005/12/19(月) 11:18:52

0497デフォルトの名無しさん

2005/12/20(火) 21:18:46

0498デフォルトの名無しさん

2005/12/20(火) 21:37:00

0499デフォルトの名無しさん

2005/12/20(火) 22:42:51

0500デフォルトの名無しさん

2005/12/20(火) 23:23:51

よくわからん流れだが
５００は頂いとくよ

0501デフォルトの名無しさん

2005/12/20(火) 23:26:28

ショック！自作ゲームでわざわざタスクシステムを自前リストで作ってたけど、
STL使ったら直ぐに出来上がった。
今まで食わず嫌いしてて損したよﾏﾏﾝ。

0502デフォルトの名無しさん

2005/12/20(火) 23:47:06

まあまあ、苦労は一回はいいんでないかい。一回だけね。

0503デフォルトの名無しさん

2005/12/20(火) 23:59:43

ゲームのタスクシステムに向いてるのってsetとlistどっちでしょうか？

0504デフォルトの名無しさん

2005/12/21(水) 00:08:58

普通は組み合わせることになるんじゃないの？

mapのlistとか、vectorのmapとか。
setはあんまり出番なさそうだけど。

0505デフォルトの名無しさん

2005/12/21(水) 00:10:53

priority_queueだと思うが。

0506501

2005/12/21(水) 00:16:04

俺はlistで作ってみた。で、タスクは一定のメモリを使い回すのが利点なので、動的メモリ確保開放しないように作りたい。
で、結局push_frontでダミーを一定量確保したら一旦clearするようにタスクのファクトリを作ってみた。

push_back等で一定量確保した後で、eraseやclearを使った後は、前に確保した領域は使い回されている保障はあるのかな。
誰か詳細ｷﾎﾞﾝ。

0507デフォルトの名無しさん

2005/12/21(水) 00:18:58

そういう場合のためにアロケータがあるんだけどな。

0508501

2005/12/21(水) 00:21:48

>>507
なるほど偉い便利だな。これで心置きなく作れる。
ｻﾝｸｽ。

0509デフォルトの名無しさん

2005/12/21(水) 00:31:08

>506
そういうのはvectorだけじゃね？
reserve()があるのはvectorだけだし。

0510デフォルトの名無しさん

2005/12/21(水) 01:18:42

するとvectorのarg2に自前のアロケータテンプレート指定して作れって事ですかね。
安心できると思ったけど結構めんどいね。

0511デフォルトの名無しさん

2005/12/21(水) 01:34:11

>510
reserve()はアロケータの呼び出し自体を抑えて、動的メモリの再確保回数を減らす方法。
listで似たような事をしたければ自前アロケータの内部で似たようなことをするように作れ、と言うこと。

0512デフォルトの名無しさん

2005/12/21(水) 04:40:22

boost::poolをコンテナの第三引数に入れて、ベンチマークを取ったり
した。ケースバイケースだけど、こちらの方がわずかに速くなる場合がある。

逆に遅くなる事もある。環境や用途にも大きく左右されると思うので、
各自実験してみて欲しいが、なかなか面白いる

0513デフォルトの名無しさん

2005/12/21(水) 05:02:50

＞面白いる
いらん

0514デフォルトの名無しさん

2005/12/21(水) 05:11:03

かなタイプで、「。」を「る」に打ち間違えただけじゃないかー
そんなに責めるなよーorz

0515デフォルトの名無しさん

2005/12/21(水) 07:04:20

>>510
作らないでもいろいろある。

0516デフォルトの名無しさん

2005/12/21(水) 13:55:28

>>515
それを聞きたいいる

0517デフォルトの名無しさん

2005/12/21(水) 15:08:20

STLを学ぼうとして最初に思い込みが原因か疑問符がついたので質問させてください。
string型なのですが、char型配列→string型はもちろんできます。
逆も「読み取り専用」なら str.c_str(); で出来たのですが、string型に直接値を入れるのはできないのでしょうか。（設計思想的にできないのかなと思ってます）

例えば
strcpy(str.hoge(), "こんにちは");
なんて真似です。
作ってるアプリケーションでGetOpenFileNameを使っているのですが、
一旦char配列にファイルパスを受け取らせ、その後pathを保存しておくためのstring型に変換するべきなのでしょうか。

0518デフォルトの名無しさん

2005/12/21(水) 16:37:52

よくわからないけど、
std::string hoge;
hoge = "こんにちは"
ならできるよ？

0519デフォルトの名無しさん

2005/12/21(水) 16:44:07

お返事ありがとうございます。

それは = 代入演算子が使われているからですよね。
それではなく
sprintf(str.c_str(), "%d", 5);
などが出来ないかなと思いまして。

↑これ自体はやっちゃいけないらしいですけど、他でこの想定にかなう方法はあるのかなと。
Win32APIなどでは、char*を引数で渡して中身を入れてもらうAPIも多くあるので…。

0520デフォルトの名無しさん

2005/12/21(水) 16:48:31

要はstrcpy()とかsprintf()とかfgets()のような振る舞いをする関数で使いたいと言うことだろ。
ポインタを渡してそこに書いてくれるような。

0521520

2005/12/21(水) 16:49:51

がーん、リロードすべきだったw

で、WinAPIを使いたいだけならCStringという妥協でも委員でないの?

0522デフォルトの名無しさん

2005/12/21(水) 17:41:27

STLのstringはそういう扱いはできないということですね。
ありがとうございました。

0523デフォルトの名無しさん

2005/12/21(水) 18:08:18

stdio系使わずにstringstream使え

0524デフォルトの名無しさん

2005/12/21(水) 18:42:47

sprintf -> stringstream
fgets -> getline

とか、代替のものがあるので、それを使うのが一番じゃないかな。

0525デフォルトの名無しさん

2005/12/21(水) 18:59:21

>523>524
WinAPIで使いたい、って書いてあるやん。

0526デフォルトの名無しさん

2005/12/21(水) 20:03:24

std::string strprintf(const char *fmt, ...)
みたいな関数をでっち上げればいい。

0527デフォルトの名無しさん

2005/12/21(水) 20:27:50

んなことやるぐらいならboost::formatで。

0528デフォルトの名無しさん

2005/12/21(水) 20:29:26

boostは使いたくない

0529デフォルトの名無しさん

2005/12/21(水) 21:17:49

>>528　その心は？

0530デフォルトの名無しさん

2005/12/21(水) 21:21:00

>>519
WinAPI相手ならstd::vector<TCHAR>で我慢してくれ。

0531デフォルトの名無しさん

2005/12/21(水) 21:46:12

>>529サイズがでかくなるから

0532デフォルトの名無しさん

2005/12/21(水) 21:50:43

環境によるだろ。
俺は（略）

0533デフォルトの名無しさん

2005/12/21(水) 21:57:57

すげえ。ダイナm(略)

0534デフォルトの名無しさん

2005/12/21(水) 23:27:46

#include <stdafx.h>

後(略)

0535デフォルトの名無しさん

2005/12/21(水) 23:34:43

>>517
望みは捨てるな。
http://pc8.2ch.net/test/read.cgi/tech/1133007604/469-470n

469デフォルトの名無しさん2005/12/21(水) 06:05:51
http://www.open-std.org/jtc1/sc22/wg21/
News 2005-12-19: The 2005-12 mailing is available (1600 kb tar.gz, .zip 1600 kb) individual papers
News 2005-12-17: The C++ Standard Library Issues List (Revision 40) is available (.tar.gz)
News 2005-12-17: C++ Standard Core Language Issues List (Revision 39) is available, also committee version

470デフォルトの名無しさんsage2005/12/21(水) 10:29:39
うげっ、std::string<>もメモリ上の連続性を仮定するようになるのかよ。

0536 http://pc8.2ch.net/test/read.cgi/tech/1133007604/470

2005/12/22(木) 02:30:13

>>535
恥ずかしいから貼らないでくれorz

0537デフォルトの名無しさん

2005/12/22(木) 02:39:38

std::string hage="ﾋﾞｬｰﾈ";
hage[0] = 'ｳ';

いまでもこれならできたりする。

0538デフォルトの名無しさん

2005/12/22(木) 02:53:20

うむふ

0539デフォルトの名無しさん

2005/12/22(木) 10:17:18

>>535
いやっほーう！

0540デフォルトの名無しさん

2005/12/22(木) 10:35:35

>>535
> 530. Must elements of a string be contiguous?
> （中略）
> The characters in a string are stored contiguously, meaning that if
> s is a basic_string<charT, Allocator>, then
> it obeys the identity
> &*(s.begin() + n) == &*s.begin() + n
> for all 0 <= n < s.size().

か。

0541デフォルトの名無しさん

2005/12/23(金) 00:19:34

つ http://tricklib.com/cxx/dagger/xstring.h

std::string location;
sprintf(capture_string(&location), "<%s>#%d", __FILE__, __LINE__);

0542デフォルトの名無しさん

2005/12/23(金) 05:38:16

>>541 突然なんだ？

0543デフォルトの名無しさん

2005/12/23(金) 14:25:28

>>542

ちょっとタイミング外したけど、>>519 に対してのﾚｽ。

0544デフォルトの名無しさん

2005/12/23(金) 18:14:09

dequeがサイズ拡大時に確保するメモリブロックのサイズって大体どれくらいなのでしょうか？

0545デフォルトの名無しさん

2005/12/23(金) 18:17:10

処理系による。

0546デフォルトの名無しさん

2005/12/25(日) 01:50:59

STLportっていつの間にURL変わったんだ？
ver5.0 出てるなんて知らなかった(////)

0547デフォルトの名無しさん

2005/12/25(日) 16:14:29

setとmultisetってどういう風に使い分ければいいんでしょうか？

0548デフォルトの名無しさん

2005/12/25(日) 16:15:32

>>547
使えばすぐにわかる。

0549デフォルトの名無しさん

2005/12/25(日) 22:00:03

setは集合。つまり重複要素を許さない。
multisetってのは集合ではなく、重複要素を許す。

0550デフォルトの名無しさん

2005/12/26(月) 11:31:17

>>549
普通「集合」は重複を許すと思うが。
すくなくとも数学ではそうだ。

0551デフォルトの名無しさん

2005/12/26(月) 12:02:11

>>550
よくわからん。
数学では
{1} = {1,1}
じゃないか？

0552デフォルトの名無しさん

2005/12/26(月) 12:04:06

数学では普通両者を区別するよ
高校数学までではこんなこと気にしないと思うけどね

0553デフォルトの名無しさん

2005/12/26(月) 12:06:13

数学だと重複してるものがいくつあっても同じと考えるから、
実質的に重複を許さないのと同じ

http://ja.wikipedia.org/wiki/%E9%9B%86%E5%90%88
>集合は、順番を入れ替えたり、同じものを付け加えても、もとのものと等しい：
>　　{1,2,5,7,10} = {5,1,7,2,1,5,10,2}.

0554デフォルトの名無しさん

2005/12/26(月) 12:10:04

ZFは普通じゃないのか。
外延性公理
∀a∀b[a=b⇔∀x(x∈a⇔x∈b)]

0555デフォルトの名無しさん

2005/12/26(月) 14:15:30

質問です。
二次元dequeを作ろうと思っているのですが

deque<deque<int> > list;
として
list.push_back(deque<int>());

とすると、deque<int>のデストラクタが2回呼ばれてしまう気がします。
これはやって大丈夫なのでしょうか。

また、
deque<CHoge> > list;
list.push_back(CHoge());
でも同様にCHogeのデストラクタが二回呼ばれてしまい問題が出てしまいました。

dequeはクラスなどの「実体の配列」ではなく、「クラスのポインタの配列」にするべきなのでしょうか。
ですがそうするといちいちpop_backなどをする前にdeleteでデストラクタを呼んでやらなければならなくなり、結構面倒です。
使い方が根本的に間違っているのでしょうか？
実体のdequeがつくれ、pushやpopでコンストラクタやデストラクタが1度ずつ呼ばれてくれるのを期待しているのですが…。

0556555

2005/12/26(月) 14:16:32

補足です。
＞list.push_back(deque<int>());
＞
＞とすると、deque<int>のデストラクタが2回呼ばれてしまう気がします。
引数で作られた無名なくラスのデストラクタと、
アプリケーションの最後でlistが解放される際のデストラクタで計2回ということです。

0557デフォルトの名無しさん

2005/12/26(月) 14:19:42

>>556
コンストラクタが二回、デストラクタが二回走るだけで、
問題はない。

>deque<CHoge> > list;
>list.push_back(CHoge());

これも、CHogeのデフォルトコンストラクタ・コピーコンストラクタ・デストラクタが正しく定義されていれば
問題ないはず。

0558デフォルトの名無しさん

2005/12/26(月) 14:25:53

>>557
ありがとうございます。
なるほど。

しかしCHogeはポインタをメンバー変数として所持し、デストラクタでdeleteするようにつくられています。
auto_ptrを使うとよさそうですが、そうするとアップキャストできなくなるのが(CHoge内ポインタの役割上)問題です。

自前で参照カウントを作るか、素直にポインターで実装するべきでしょうか。
deque<CHoge*>
insertやpop, pushするたびに自前でdeleteすることになりますが…。
アドバイスいただければ幸いです。

ところでSTLには、実体を伸び縮みさせられるコンテナはないのでしょうか？
dequeはどうも実体を伸び縮みさせるのには向かないような…。

0559デフォルトの名無しさん

2005/12/26(月) 14:32:02

vector< vector<char> > を使って、
可変長構造体にキャストして使うことは可能。

ただ、実体自体を伸び縮みさせるのではなく、
そういうのをポインタで保持するのが普通だと思う。

0560デフォルトの名無しさん

2005/12/26(月) 14:35:06

なるほど。
vectorで実体を必要な分確保しておいて、それをdequeにあてはめるわけですね。
しかしvectorは配列が2の乗数を超えるように増えた場合に配列を作り直しますから、コンストラクタとデストラクタがふいなことで呼び出されてしまいそうです。

素直にポインタでやってみようと思います。
ありがとうございました。

しかし>>558でinsertやpop, pushするたびに～って書いてありますが
どう考えてもpopの時しかdeleteは呼びませんね。お恥ずかしい。

0561デフォルトの名無しさん

2005/12/26(月) 17:25:44

ポインタのコンテナで自前deleteがいやなら、スマートポインタのコンテナにすればいいじゃない。

ポインタをメンバー持ってるなら、ちゃんとコピー操作に手をいれておけよ。
禁止だけなら3行で済むし。

0562デフォルトの名無しさん

2005/12/26(月) 18:05:09

auto_ptrはコンテナの要素にすることが禁止されていなかったか？

0563デフォルトの名無しさん

2005/12/26(月) 18:06:51

STLport を使っているんですが、
string にバインドできる stream ってないでしょうか？

std::string str, day_status("善い日");
std::ostrstreambuf out(str);
out << "今日は" << day_status << "だ、便が出る";
std::cout << str << std::endl;
-- outpu --
今日は善い日だ、便が出る

こんなヤツ

0564デフォルトの名無しさん

2005/12/26(月) 18:08:16

>>562
boost::shared_ptr

0565デフォルトの名無しさん

2005/12/26(月) 18:09:43

>>563
stringstream

0566565

2005/12/26(月) 18:10:18

と、ちょっと用途が違うみたい。スマン忘れて

0567デフォルトの名無しさん

2005/12/26(月) 18:11:09

>>563
バインドはできないけど、std::ostringstreamからstr()でstd::stringを取り出せる。

0568デフォルトの名無しさん

2005/12/26(月) 18:20:12

>>564
うお、shared_ptrだったら大丈夫なのか。正直知らんかった。

コンテナが縮む時に、破棄された分の要素についてデストラクタが呼ばれるのって仕様上確定しているのかね？
確定していないからauto_ptr(とかshared_ptr)はダメなんだと思っていたんだが。

0569デフォルトの名無しさん

2005/12/26(月) 18:27:39

>コンテナが縮む時に、破棄された分の要素についてデストラクタが呼ばれるのって仕様上確定しているのかね？
当り前だ。それが保証されてなかったらそもそもコンテナがまともにつかえない。

auto_ptrがコンテナに入れられないのはコピーセマンティクスが破壊的だから。

0570デフォルトの名無しさん

2005/12/26(月) 18:29:38

>>565, >>567
ありがとうございます。
バインドできないのかー。
残念。

0571デフォルトの名無しさん

2005/12/26(月) 19:03:09

boostならpointer_containerもありますよっと。

0572デフォルトの名無しさん

2005/12/26(月) 23:54:01

vectorがA構造体の配列で
Aはメンバにid,dateを持っていて
例えばidが2を持つ一番初めの要素を検索するにはどのようにコーディングしたらよろしいのでしょうか

ご教授お願いします

0573デフォルトの名無しさん

2005/12/27(火) 00:03:34

>>572
自分ならこんな感じかな？

struct A_eq_id:std::binary_function<A,int,bool>{
bool operator()(const A&a,int n)const{return a.id == n;}
};

std::vector<A> vect;

std::vector<A>::iterator itr = find_if(vect.begin(),vect.end(),bind2nd(A_eq_id(),2));

0574デフォルトの名無しさん

2005/12/27(火) 00:07:23

#include <algorithm>

struct A_id_is_2 {
　bool operator()(const A& a) {
　　return a.id == 2;
　}
};

std::find_if(a_vector.begin(), a_vector.end(), A_id_is_2());

おもいっきし簡略化して書くとこんな感じか。
std::find_ifで調べてみるとよろし。

0575デフォルトの名無しさん

2005/12/27(火) 00:14:00

struct A {
bool operator(int key) const {return id == key;}
int id;
T date;
};

std::vector<A> foo;
std::find(foo.begin(), foo.end(), 2);

0576デフォルトの名無しさん

2005/12/27(火) 00:32:06

a_vector.begin() + rand() % a_vector.size(); // ←多分これが2

0577デフォルトの名無しさん

2005/12/27(火) 00:40:10

boost様の登場

#include<boost/lambda/lambda.hpp>
#include<boost/lambda/bind.hpp>
using namespace boost::lambda;
std::find_if(vect.begin(),vect.end(),bind(&A::get_id,_1)==2);

0578577

2005/12/27(火) 00:42:25

あ、getterの定義いらね
std::vector<A>::iterator itr = std::find_if(vect.begin(),vect.end(),bind(&A::id,_1)==2);

0579572

2005/12/28(水) 01:18:49

とりあえず573で出来ました
これは前に書いた出力のやつに似ているので自分にあっているっぽいです

boostも便利らしいですが色々ややこしく…な感じです
STLも殆ど分かっていないですし手をつけるのもどうかなと思うところもあります

(しかしどうしてこのような結果が得られるのか今ひとつ分からん
も少し格闘してきます

0580デフォルトの名無しさん

2005/12/28(水) 10:40:22

>>579
>575と>574が理解できれば>573はその中間と言うか、汎用型じゃん。

0581デフォルトの名無しさん

2005/12/28(水) 11:38:41

>>580
ハイハイ。知ったか君。

0582575=580

2005/12/28(水) 11:53:17

>>581
何か?
#今改めて>575を見たらoperator==になってない……_/￣|○

0583デフォルトの名無しさん

2005/12/28(水) 22:14:09

vector<char>からcharの配列を取り出すのはわかるのですが(&vector.front())、
list<char>からの取り出し方法が分かりません。
リスト構造なのでループで回さないと無理なのかとも思うのですが、良い方法が
あればご教授お願いします。

0584デフォルトの名無しさん

2005/12/28(水) 22:17:05

>>583
empty() の時は front() 呼び出しちゃだめだから気をつけて。
vector 以外のコンテナからC言語の組み込み配列を得るには
コピーして作るしかない。

0585デフォルトの名無しさん

2005/12/28(水) 23:05:23

>>583
ループを回す代わりにイテレータで。
std::list<char> ls;
// ……。
std::vector<char> v(ls.begin(), ls.end());
場合によってはstd::stringのほうが良いかもしれない。

0586デフォルトの名無しさん

2005/12/28(水) 23:53:40

えっと Windows で STLPort 4.6.2 を使っているんだけど、StlPort って
スレッドセーフってことでいいのでしょうか？

マルチスレッドなプログラム書いてて、再現が難しい（リリースモードのみ）
バグがあって原因を追究しているんだけど、スタックトレースを
とったら、stlport の _alloc.c で落ちたみたいなんですが・・・

0587デフォルトの名無しさん

2005/12/29(木) 00:01:47

メモリリークの類がalloc.cで落ちるのはよくある話。

0588デフォルトの名無しさん

2005/12/29(木) 00:32:40

>>584-585
ありがとうございました。

0589デフォルトの名無しさん

2005/12/31(土) 16:33:11

簡単で標準的なスマポを標準テンプレートライブラりーで
教えてくださいって、既にテンプレートを貼ってあったら
ごめんなさい。

ちなみに、紅白の大鳥はスマップです。←見ねーよ
戦後６０年を見るね。0：00英霊たちに合唱・・・亞ボーン

0590デフォルトの名無しさん

2005/12/31(土) 16:37:40

…(;ﾟДﾟ)

0591デフォルトの名無しさん

2005/12/31(土) 17:38:49

>>589 斬新だな。

0592デフォルトの名無しさん

2005/12/31(土) 18:29:36

某より引用　左辺値を減らしてから代入する気が
tPtr->inc(); tPtr = ptr; tPtr->dec();
次に示す簡単なサンプルは，スマートポインタークラスのテンプレート
MemMgrと呼ばれるサポートクラスから作成されます。
SP クラスは，とても基本的で，-> や = といった演算子を唯一，
オーバーライドしたものです。
SP メンバー関数は，カウントの使用方法を保つため，
MemMgr inc()と dec()を呼び出します。
#include <iostream.h>
//--------------- class SP
template <class T>
class SP {
T* tPtr;
public:
SP(T* ptr) : tPtr(ptr) { tPtr->inc(); }
~SP() { tPtr->dec(); }
T* operator->() { return tPtr; }
SP& operator=(T* ptr) {
tPtr->inc();tPtr = ptr;tPtr->dec();
return *this; }
};
//----------- class MemMgr
class MemMgr {
int inUse;
public:
MemMgr(void) { inUse = 0; }
void inc(void) {++inUse;}
void dec(void) {if (--inUse == 0)elete this;}
};

0593デフォルトの名無しさん

2005/12/31(土) 18:32:16

>>592
コンパイルがどう見ても通らないソースなんだが。
何を言いたいんだ？

0594デフォルトの名無しさん

2005/12/31(土) 18:44:22

年の瀬に湧くと話題の馬鹿でしょう。

0595デフォルトの名無しさん

2005/12/31(土) 19:31:46

>>592
http://www.borland.co.jp/qanda/lang/l0003025.html
＞コンパイルがどう見ても通らないソースなんだが。
＞何を言いたいんだ？
某のコンパイラは通らないか、ソースが間違っているのですか。
ついでにＶＣ６　ＶＣ２００５での問題点も指摘してください。

0596デフォルトの名無しさん

2005/12/31(土) 19:44:43

だから elete って何よ。

0597　

2005/12/31(土) 19:46:17

ひょードル強いな！

0598デフォルトの名無しさん

2005/12/31(土) 19:48:47

もう、寝ていいよ　
（596だから elete って何よ）

0599デフォルトの名無しさん

2006/01/03(火) 22:23:13

それはねー、エリート宣言さ～

0600デフォルトの名無しさん

2006/01/04(水) 16:29:26

６００

0601デフォルトの名無しさん

2006/01/06(金) 18:29:58

std::numeric_limits<double> のメンバ関数を使って、
ある double 型の変数に格納されているのが
NaN かどうかを判定するってことは可能ですか？

つまり C99 における isnan() のようなものが
STL にも用意されているのでしょうか??

0602デフォルトの名無しさん

2006/01/06(金) 18:37:44

こんなん見つけた
http://www.kouno.jp/home/c_faq/c14.html#9

0603デフォルトの名無しさん

2006/01/06(金) 18:43:23

結局 isnan() を使うしかないのか・・・
gcc だと C99 準拠だから isnan() がつかえるけど、
Visual C++ だと C99 準拠じゃないから isnan() がないんだよな。
でもよく見たら _isnan() があった。

とはいえ、nan() も処理系によって有ったり無かったりなんで、
std::numeric_limits<double>.quiet_NaN() のほうがいいかも
と思ったんだけど、結局 STL もそこまでは面倒見てくれないのか。

0604デフォルトの名無しさん

2006/01/08(日) 14:50:10

MinGWへのSTLport5.0.1のインストールやっとうまく行った・・・・
今までおかしかった原因は、-mthreadsをコマンドラインに与えてないせいでした。

STLportがマルチスレッドでビルドされるのは知ってたけど、4.6.2までは-mthreads
が不要だったので、はまってました。

この勢いでVC7.1にも入れよう。VC8.0もいじらないといけないし、大変だ。

0605デフォルトの名無しさん

2006/01/09(月) 15:02:07

std::vector<T> や std::list<T> に
T や T の派生クラスを混在して保持するように
したいのですが、可能でしょうか？

0606デフォルトの名無しさん

2006/01/09(月) 15:08:31

ポインタ若しくはスマートポインタを格納することは可能

0607デフォルトの名無しさん

2006/01/09(月) 15:13:50

std::auto_ptr ？
とおもったけど、これは色々文献を読んでみると
STLのコンテナの要素とすることは禁止されているみたいですね。
内部の実装がどうなってるのかは知らないけど。

格納したいクラスへのポインタをメンバに持つ
ラッパークラスでも作ろうかとおもったけど、
もしかして boost::shared_ptr で行けたりします？
って、ためしてみようっと。

0608デフォルトの名無しさん

2006/01/09(月) 15:17:13

>>607
>もしかして boost::shared_ptr で行けたりします？
はい

0609605=607

2006/01/09(月) 15:25:21

ふむ、うまくいったようです。
ありがとうございました。

0610デフォルトの名無しさん

2006/01/09(月) 15:49:29

boost を使っていいなら、 ptr_vector とかもあるよ。

0611605=607

2006/01/09(月) 16:13:01

げ、なんか便利そうなモノが他にもあるんですか。
boost は普段正規表現ライブラリくらいしか使わないんで、
boost の全貌を把握してないんですよ。
boost:ptr_vector もどんなもんか勉強してきます。

0612デフォルトの名無しさん

2006/01/09(月) 21:52:05

std::vector とかって operator[] では
std::out_of_range 例外が発生しないんですね。
at() なら発生するのに。

0613デフォルトの名無しさん

2006/01/09(月) 22:08:35

>>612
at() は範囲チェックをする分パフォーマンスが落ちるから、
範囲外へのアクセスを行う可能性がある時のみ使う感じで使い分けたりする。

0614デフォルトの名無しさん

2006/01/13(金) 01:51:05

mapで一度登録した値を変更したい場合一度削除しないと変更できませんか？

0615デフォルトの名無しさん

2006/01/13(金) 01:58:46

m[key] = value;

0616デフォルトの名無しさん

2006/01/13(金) 01:59:02

>>614
できます

0617デフォルトの名無しさん

2006/01/13(金) 02:11:38

どうもありがとうございます

0618デフォルトの名無しさん

2006/01/13(金) 17:43:32

stringとwstringの相互変換なtemplate又は、関数ってあります？
やっぱ、
MultiByteToWideCharとか使って変換しないと駄目？

0619デフォルトの名無しさん

2006/01/13(金) 18:41:13

お前が変換したいように変換しろ。

0620デフォルトの名無しさん

2006/01/13(金) 21:30:21

>>618
wstringつーかwchar_tのエンコーディングは標準でコレと定められているわけじゃない
（まあそれを言ったらcharだってそうだけどな。EBCDICとかあるし、結局何だって
つっこめる）
だから、実際に自分がどーゆーエンコーディングを用いているかに応じて、
変換も行わなければならない。「常に正しい方法」は存在しない、ということだ。

0621デフォルトの名無しさん

2006/01/13(金) 21:50:18

ISO C++的にはcodecvtクラスだろ。
関連クラス: locale, facets, codecvt_byname

0622デフォルトの名無しさん

2006/01/15(日) 03:12:03

>618
ここの一番下のサンプルでも見るといい。
ttp://hw001.gate01.com/eggplant/tcf/cpp/wchar_t_trap.html

0623本田

2006/01/15(日) 17:58:26

>>586
> えっと Windows で STLPort 4.6.2 を使っているんだけど、StlPort って
> スレッドセーフってことでいいのでしょうか？

BCB6は、マルチスレッド対応と非対応を選択できるようだけど。

0624デフォルトの名無しさん

2006/01/17(火) 20:36:18

　こんにちわ。質問をさせて下さい。

　現在ブラウザからActiveXを介してローカルのEXEを起動するシステムを考えています。
　いくつかのサイトを調査しました。その中でハ○ゲームのゲームインストーラの動作
を見ていて、よく分かりません。

　ActiveX としては C:\WINDOWS\Downloaded Program Files\HgPlugiXJP21 Classとして
ダウンロードされています。

　サイトからダウンローダーを起動しているＨＴＭＬは以下の通りでした。

　　location.href = "hangXme://http://gamestring.hangXme.co.jp:10000/?k22e..なんちゃら";

　試しに【ファイルを指定して実行】で hangXme: と実行してみると、該当ＥＸＥが起
動します。これはプロトコルとして登録されているのでしょうか？よく分からないので
すが　rundll32.exe msconf.dll とかが関係しているのでしょうか？

　ちなみに　「ファイルの関連付け」としてはレジストリに以下が設定されています。

　HKEY_CLASS_ROOT\HanGXme\Shell\Open\Command

　　　値：C:\WINDOWS\Downloaded Program Files\HGStartXJP21.exe %1

　で、hangXame: を実行するとHGStartXJP21.exeが起動します。

　この辺の仕組みが分かりません。よろしくご教授下さい．
　板違いでしたら申し訳ありません。

0625デフォルトの名無しさん

2006/01/17(火) 20:38:59

>>624
全くスレ違い。Win板だと思う。

0626デフォルトの名無しさん

2006/01/17(火) 20:59:07

>>625
すいませんでした。

0627デフォルトの名無しさん

2006/01/18(水) 21:22:52

vector<char>にcharの配列を一気に代入したいです。
forループでpush_backするより効率がいい方法はありますか？

0628デフォルトの名無しさん

2006/01/18(水) 21:28:20

char buf[]="aiueo";
vector<char> hoge(&buf[0],&buf[0] + sizeof(buf)/sizof(buf[0]));

0629デフォルトの名無しさん

2006/01/18(水) 21:48:17

これでもいける
char buf[] = "hello";
std::vector<char> v;
v.assign(buf, buf + strlen(buf));

てか、stringをなぜ使わないのか。
参照カウントが気になる？

0630デフォルトの名無しさん

2006/01/18(水) 22:33:49

string って参照カウンタ持ってるのか。
独自のGCを使ってるってこと？

0631デフォルトの名無しさん

2006/01/18(水) 23:04:10

>>630
参照カウンタを使うかどうかは実装次第。
ただしメモリ確保自体にはテンプレート引数で指定されたアロケータ
（std::stringではstd::allocator<char>）が使われる。

0632デフォルトの名無しさん

2006/01/18(水) 23:06:35

>>630
そういう実装が流行ってた時代もあった。
でも今は全部コピーする実装が主流。
どちらにせよ実装依存

0633デフォルトの名無しさん

2006/01/18(水) 23:29:54

参照カウンタ方式stringが廃れた理由は何？

0634デフォルトの名無しさん

2006/01/18(水) 23:32:35

>>633
たとえばスレッド安全のためということがある。

0635デフォルトの名無しさん

2006/01/19(木) 03:09:19

>>628
>629で充分。つーか、それだとナル文字の分も追加されるぞ。

0636628

2006/01/19(木) 04:23:05

ありがとうございました。

0637デフォルトの名無しさん

2006/01/26(木) 10:27:02

インテルのコンパイラヘルプに、exportのキーワード。
まさか、対応してる？

0638デフォルトの名無しさん

2006/01/26(木) 10:30:40

でも、メンバテンプレートがない？

0639デフォルトの名無しさん

2006/01/26(木) 11:17:04

export ってなに～？これ？
WindowsでCOMコンポーネントを作るときに使うの？

C++ 属性 export は、データ構造体を .idl ファイルに配置し、
すべての言語で使用できるバイナリ互換形式としてタイプ
ライブラリで使用できるようにします。

クラスにパブリックメンバ (struct と同等) だけが含まれる場合でも、
属性 export をクラスに適用することはできません。

無名の enum や struct をエクスポートする場合は、
__unnamedx (x は連番) で始まる名前が付けられます。

// cpp_attr_ref_export.cpp
// compile with: /LD
[module(name=MyLibrary)];

[export]
struct MyStruct
{
int i;
};

もっと具体的に export でうれしくなれる例を教えて！

　　　　　　　　　　　　　　　　　　　　　
　　　　　　　　　　　　　　　　ﾊ_ﾊ　　
　　　　　　　　　　　　　　　('(ﾟ∀ﾟ∩　教えて！
　　　　　　　　　　　　　　　　ヽ　　〈　
　　　　　　　　　　　　　　　　　ヽヽ_)

0640デフォルトの名無しさん

2006/01/26(木) 11:34:17

>>639
そのexportは無関係。

exportはtemplateの実装を隠蔽するための仕組み。
実装するにはリンカから変えなきゃ不可能に近い仕様なので、
実現してるコンパイラは一握りだけ(VCもgccも未実装)

例としてtemplate関数を定義する場合
template<typename T>
T add(T a,T b){return a+b;}
のように同じ翻訳単位に実装も一緒に書かないといけないが

export template<typename T>
T add(T a,T b);
のように書けば実装は別で定義されていることになってリンク時に結合される
これによってヘッダに大量の実装をおく必要が無くなってコンパイル時間の短縮等が期待できる。

0641デフォルトの名無しさん

2006/01/26(木) 11:45:37

まぁコンパイル時間の短縮ってもプリコンパイルヘッダに比べるとどうなんだかな。

0642638

2006/01/26(木) 11:50:25

すみません。自己解決しました。テンプレートの解釈があいまいになるところが
あったせいで、VC7でよくて、intelはだめだったというだけでした。

0643デフォルトの名無しさん

2006/01/26(木) 11:58:10

>>640
thx。

おもわず、だまされました。

0644デフォルトの名無しさん

2006/01/26(木) 17:55:52

std::vector に格納できるのは shared_ptr ですよね？

0645デフォルトの名無しさん

2006/01/26(木) 18:05:31

ほぼなんでも格納できます

0646デフォルトの名無しさん

2006/01/26(木) 18:17:20

>>645 ちょ、まっ、wwww
std::auto_ptr とかヤバス

0647デフォルトの名無しさん

2006/01/26(木) 19:00:36

>645
コピーできないものを「ほぼ」の除外対象にするのは如何なものかと思います。

0648デフォルトの名無しさん

2006/01/26(木) 21:53:10

まったく問題ないと思います。

0649デフォルトの名無しさん

2006/01/26(木) 22:42:49

>641
Sutter’s Mill: “Export” Restrictions, Part 1 & 2
http://www.cuj.com/documents/s=8009/cuj0209sutter/
http://www.cuj.com/documents/s=8007/cuj0211sutter/

↑の記事によると、dependent name はテンプレートの定義された文脈と、インスタンス化された文脈の双方を考慮して、
名前解決する必要があるので、テンプレートの定義が変更された場合、そのテンプレートがインスタンス化されている
翻訳単位を(少なくとも全てのテンプレートパラメータの組み合わせが得られる数までは)再コンパイルしなければならない。
この点は export があってもなくても同じなので、ほとんどの場合 export を使ってもコンパイル時間は短縮されないだろう、とのこと。

0650デフォルトの名無しさん

2006/01/26(木) 23:27:55

別のコンパイル単位で、
同じ文脈でインスタンス化される場合、
exportでやる流儀なら、一度で済むだろ。

0651デフォルトの名無しさん

2006/01/26(木) 23:50:18

>>649
加えて，ビルドツールが export による翻訳単位を超えた依存関係を
識別できなければならない，とか
たとえ無名名前空間で定義された export を指定されていない
テンプレートだとしても他の export されたテンプレート経由で名前が他の
翻訳単位に暴露されるなど，プログラムの挙動が非常に予測しにくくなる，とか
従来の
「～～テンプレートからインスタンス化された～～テンプレートからインスタンス化（以下略」
という楽しいコンパイルエラーメッセージに加えて
「～～翻訳単位からインスタンス化された～～翻訳単位からインスタンス化（以下略」
というさらに楽しいエラーメッセージが付加される，とか色々楽しいことが満載です．
マクロの名前を翻訳単位によって切れるのが，現状 export による
明らかな恩恵だと結論されていますけれど，これも本質的には
別次元の問題（C99 のスコープ付きマクロ）として解決されるべき問題ですし

"Exceptional C++ Style" に，20ページも使って
「現状，いかに export に期待できないか」が， Java の全言語仕様の実装に
2人年かかったのに対して export 「だけ」の実装に3人年かかった，
とかいう話なんかと一緒に恐ろしく詳細に載ってます．

0652651

2006/01/27(金) 00:04:54

649 に挙げられた記事と "Exceptional C++ Style" の
内容はほとんど同じものでした．すいません．

0653デフォルトの名無しさん

2006/01/27(金) 07:57:01

>650
その高速化は export を使わない場合でも可能だ、というのが記事の趣旨。
もちろん、#include してることで実装の読み込み自体は常に発生するけど、コードの生成までは必要ない。
Comeau compiler は export の場合と、#include の場合の両方でその高速化が可能って書いてあるけど
使ってないから本当かどうかは知らない。

0654デフォルトの名無しさん

2006/01/27(金) 08:59:24

>>653
> コードの生成までは必要ない。

一応生成しとかないと。(あるいはソースを保存しとくか)
g++だとweak symbolで生成している。

0655デフォルトの名無しさん

2006/01/27(金) 10:35:58

icc なんかで翻訳単位を超えたインライン化なんかも実装されてるわけで、
本質的に便利なことがあれば export も実装も普及するんでしょうね。

0656デフォルトの名無しさん

2006/01/28(土) 19:50:50

コンテナに位置と大きさを持った物体を格納してます。
物体の数が１万以上あるからいちいち衝突判定をしていると遅くなるので、
どの物体とどの物体が接触しているという情報を記録しておこうと思いました。
要素のアドレスを使おうと思ったのですが、vectorの場合要素の追加･削除で格納アドレスが変わってしまいます。
listならば下のコードで格納されている要素のアドレスが変わらないことは保証されていますか？
もしくはもっといい方法があれば教えてください。

list<int>　a;
a.push_back( 1 );
a.push_back( 2 );
a.push_back( 3 );
a.push_back( 4 );

list<int>::iterator it = a.begin();
it++; it++;
int *p = &*it;
a.erase( a.begin() );
cout << *p << endl; // 3?

0657デフォルトの名無しさん

2006/01/28(土) 20:15:07

>>656
その物体オブジェクトに
ID持たせるとかすればいいんじゃね？
アドレスを使うというのはどうも・・・

オブジェクトの拡張ができないなら
map<id, object>とか
vectorとかlistの要素をpair<id, object>にするとか

0658デフォルトの名無しさん

2006/01/28(土) 20:16:25

>>656
記録しておきたい要素のインデックスをvectorで保持すればいいジャマイカ
それを添え字に使って位置と大きさとやらにアクセスすればよい。
何のためのvectorだよぅ

0659デフォルトの名無しさん

2006/01/28(土) 20:18:42

>>658
それじゃ要素の追加、削除でindexがかわるからまずいんじゃ？

0660デフォルトの名無しさん

2006/01/28(土) 20:24:04

>>656
list,set,mapのイテレータが無効になる条件は、
自分自身のイテレータを削除したときのみなので大丈夫と思う。

0661デフォルトの名無しさん

2006/01/28(土) 20:31:05

>>659
アドレスが変わるってそのことか。
てっきり要素数が変わった時にガバッと取り直すことかと思ったよ。

0662デフォルトの名無しさん

2006/01/28(土) 20:41:56

削除はどのくらいの頻度で起きるのかね。
頻度高いならvectorは得じゃないよね。位置詰めのcopyが起きるから。

0663656

2006/01/28(土) 21:38:49

>>657-662
ありがとうございます。
削除も結構な頻度でおこるんで、
とりあえず物体の情報をlistに格納して、衝突判定はそのイテレータを使う方法でやってみます。

0664デフォルトの名無しさん

2006/01/28(土) 22:10:49

そうね、listで書いてみて、ボトルネックが見つかれば、
自作も含めて、他のコンテナ考えた方がいいだろうね。
とりあえずコンテナの形態にべたべたに依存しないコード書いといて。

0665デフォルトの名無しさん

2006/01/29(日) 05:19:19

コンテナからある条件を満たす要素だけを集めた
新しいコンテナを作るのって一発でできないんですか？

0666デフォルトの名無しさん

2006/01/29(日) 05:30:57

>>665 「一発で」の意味がわからん。

0667デフォルトの名無しさん

2006/01/29(日) 05:43:34

>>665
たぶん、STLの範囲内でやるなら
remove_copy_if + back_inserter + 適当な述語関数

......どうでも良いけど、STLにcopy_ifが無いのは何故だろう。

0668デフォルトの名無しさん

2006/01/29(日) 05:52:19

>>667
入れ忘れちゃった。てへっ♥ by禿

0669667

2006/01/29(日) 06:02:25

>>668
を読んでいくら禿でも、そんなことないだろうとプログラミング言語C++を読んでみたら
------------------------------------------------------
残念なことに、copy_ifはどうしたわけか標準ライブラリが
提供するアルゴリズムセットから抜け落ちてしまった(私の過失である)
---------------------------------------------------------
　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　by 禿
　プログラミング言語C++第三版 P610より

やっぱ禿のせいか
ｳﾜｧｧｧｧｧｧヽ(`Д´)ﾉｧｧｧｧｧｧﾝ!

0670デフォルトの名無しさん

2006/01/29(日) 09:41:20

まあ、logical_not使えばいいし。

0671デフォルトの名無しさん

2006/01/29(日) 10:24:19

_ifなんてついてる時点で設計ミスだから禿は正しい
filter_iterator使え

0672デフォルトの名無しさん

2006/01/29(日) 10:31:49

今禿って言う香具師ちょっと来い( ﾟДﾟ)

0673デフォルトの名無しさん

2006/01/29(日) 10:55:35

はげって誰のこと？
画像はってよ。

0674デフォルトの名無しさん

2006/01/29(日) 11:53:09

http://public.research.att.com/~bs/homepage.html

remove_copyも名前がおかしい。

0675デフォルトの名無しさん

2006/01/29(日) 11:54:21

あれえ？前は椅子に座って机に足かけてる画像だったような気がするけど。
ハゲのくせに足なげえとしか思ってたけど。

0676デフォルトの名無しさん

2006/01/29(日) 12:05:45

名前はAdaでMusser&Stepanovが書いた頃の流儀だな。
removeじゃなくてDeleteだが。Copy_Ifはこの頃からない。

0677デフォルトの名無しさん

2006/01/29(日) 12:15:54

ホントだ。写真変わってるね。
ﾊｹﾞのくせに生意気

0678デフォルトの名無しさん

2006/01/29(日) 12:25:27

このおっさんの名前見るたびに、
インリンの顔が浮かぶ。
なんかＭ字ビターンに似てねぇ？

0679デフォルトの名無しさん

2006/01/29(日) 13:30:48

ｵﾏｲﾗ本人がいないからって言いたい放題だなｗ

0680デフォルトの名無しさん

2006/01/29(日) 13:38:47

禿より♥
template <typename InputIterator, typename OutputIterator, typename Predicate>
inline
OutputIterator
copy_if(InputIterator begin, InputIterator end, OutputIterator destBegin, Predicate p)
{
while (begin != end)
{
if (p(*begin)) *destBegin = *begin;
++destBegin;
++begin;
}
return destBegin;
}

0681デフォルトの名無しさん

2006/01/29(日) 14:01:16

>>679
俺は本人の前でも言えるよ。日本語でなら。

0682デフォルトの名無しさん

2006/01/29(日) 14:03:11

>>679
俺も本人の前でも言えるよ。エスペラント語なら。

0683デフォルトの名無しさん

2006/01/29(日) 14:06:06

ﾋﾞﾔｰｿって言語学者だしエスペラント知ってそうだな

0684デフォルトの名無しさん

2006/01/29(日) 14:23:36

だったら禿がこのスレ見たら泣くな
日本語も分かりそうだしｗ

0685デフォルトの名無しさん

2006/01/29(日) 16:08:10

は・・い、いえビョ～～ン先生ごめんなさい。
私たちが間違ってました。

0686デフォルトの名無しさん

2006/01/29(日) 16:13:40

copy_ifがあるときヽ（´ー`）ノ
//全てのアルファベットを抽出
std::copy_if(hoge.begin(),hoge.end(),back_inserter(x),std::isalpha)

copy_ifがないとき（´д｀）
//全てのアルファベットを抽出
std::remove_copy_if(hoge.begin(),hoge.end(),back_inserter(x),std::not1(std::ptr_fun(std::isalpha)))

0687デフォルトの名無しさん

2006/01/29(日) 20:49:19

何この平和なスレ。

0688デフォルトの名無しさん

2006/01/29(日) 23:30:00

>>686
copy_ifはないけれどBoostがある。
namespace bll = boost::lambda;
std::remove_copy_if(hoge.begin(), hoge.end(), back_inserter(x), !bll::bind(std::isalpha, bll::_1))

0689デフォルトの名無しさん

2006/01/30(月) 23:46:56

あ～るはげた～ひる～さがり～♪

0690デフォルトの名無しさん

2006/01/31(火) 00:06:11

か～つら～につづ～くみち～♪

0691デフォルトの名無しさん

2006/01/31(火) 01:37:40

めーがーねーがーごーとーごーとー♪

0692デフォルトの名無しさん

2006/01/31(火) 12:11:59

func(float a[])
という関数に
vector<float> x;
を引数に渡したくて、
func(&(x[0]))
とやっているんだけど、うまくキャストができません。
どうすればいいでしょうか？ご教授よろしくお願いいたしますm(__)m

0693デフォルトの名無しさん

2006/01/31(火) 12:24:00

>>692
すまん、普通にそれで通るんだがコンパイラ何よ？

#include<vector>
void func(float a[]){}
int main(){
std::vector<float>x;
func(&(x[0]));
}

0694デフォルトの名無しさん

2006/01/31(火) 12:35:35

>>693
すまん、おれのミスだった。まちがって、
int main(){
std::vector<float>x;
func(x);
}
とやっていた。
いずれにしろバグが取れて助かりました。
どうもありがとう！

0695デフォルトの名無しさん

2006/01/31(火) 13:18:55

それバグじゃない

0696デフォルトの名無しさん

2006/01/31(火) 21:45:01

694の頭にバグがあったということだろう。

0697デフォルトの名無しさん

2006/01/31(火) 23:30:35

スキンヘッド推奨

0698デフォルトの名無しさん

2006/02/01(水) 05:53:56

サイドは残さなきゃダメだろ

0699デフォルトの名無しさん

2006/02/06(月) 16:43:38

std::vector<T> にて、T はデフォルトコンストラクタ
T::T() を持たなければダメなんでしょうか？？？？
たしかに T::T() を必要とするメソッドは有るよな。
初期化されないブツが投入されるのがイヤな時には、
とりあえず T::T() の中で何か throw するようにしておく？
でもそれだと実行時にしか検出されない･･･

って、書いてて気づいたんだけど、もしかして
T::T() を宣言だけしておいて定義しなければ
リンク時に気づくかも。

0700デフォルトの名無しさん

2006/02/06(月) 16:50:32

そんなに気になるならデフォルトコンストラクタをprivateにすればいいやん（;´Д｀）

0701デフォルトの名無しさん

2006/02/06(月) 17:05:05

>>700 ΣΣ（ﾟдﾟlll）ｶﾞｶﾞｰﾝ
そ、そうだった・・・・

0702デフォルトの名無しさん

2006/02/06(月) 17:11:54

>>699
>初期化されないブツが投入されるのがイヤな時には、
ってことはそのTは自前のコンストラクタを持ってるわけでしょ
ってことはT::T()が勝手に定義されることはないので
何もしなくてもコンパイルエラーになるよ

0703デフォルトの名無しさん

2006/02/06(月) 17:19:35

>>702 うん、で、そういうクラスを std::vector<T> に
格納しようとしたら、std::vector<T> のコンストラクタの
一つが T のデフォルトコンストラクタを要求するので
エラーになります。 private にしても同じく。

でも実際にはそのコンストラクタは呼ばれないので、
宣言だけして定義はしなくてもリンク可能です。
実際に使われてるか否か（コードが生成されているか否か）
に関わり無く、テンプレートの関数はとりあえず
実体が生成されるものとして構文と識別子のチェックが行われるようです。

0704デフォルトの名無しさん

2006/02/06(月) 17:20:12

って、それは C++99 が要求している事なのか、
たまたま VC++ 2005 の実装がそうなのか分かりません。

0705デフォルトの名無しさん

2006/02/06(月) 17:27:22

JIS X3014ではコンテナの要素の要件に定められていることは、
コピーコンストラクト可能であることと代入可能であることだけだった。
（デフォルトコンストラクト可能である必要はないと）

0706デフォルトの名無しさん

2006/02/06(月) 17:30:26

>>703
VCで試そうとしたけどエラーが出ない......
エラーの出る最小のソース希望

0707ごめん

2006/02/06(月) 17:50:27

俺の勘違い。

class Kurasu {
private:
int i;
public:
Kurasu(const int given_i) { i=given_i;}
};

void KurasuVector() {
std::vector<Kurasu> k(100);
}

そりゃエラーになるわ。
俺が明示的にデフォルトコンストラクタを必要とする
コンストラクタを呼び出してるんだからな。

void KurasuVector() {
std::vector<Kurasu> k;
}

なら問題 nothing 。
正直、スマンカッタ

0708デフォルトの名無しさん

2006/02/06(月) 21:59:19

>>704
C++は98。

0709デフォルトの名無しさん

2006/02/06(月) 22:00:44

>>708
つ2003

0710デフォルトの名無しさん

2006/02/06(月) 22:04:28

禿共のがんばり次第によっては06

0711デフォルトの名無しさん

2006/02/06(月) 22:13:51

>>710
禿曰く09

0712デフォルトの名無しさん

2006/02/06(月) 22:17:47

おのれ禿・・・
そんなに待てぬ

0713デフォルトの名無しさん

2006/02/06(月) 22:29:30

禿禿いうな禿

0714デフォルトの名無しさん

2006/02/06(月) 22:31:23

禿せめて08年中ぐらいにはお願いします。
そうすれば00年代にはそこそこ対応したコンパイラが出るかもしれません。

0715デフォルトの名無しさん

2006/02/07(火) 06:18:41

禿さんの禿って今も進行してるんですか？

0716デフォルトの名無しさん

2006/02/07(火) 07:14:10

>>715
まだ完全には実装されていない。
というか、写真によってちょっとずつちがうから、
そこはベンダー依存ではないか。

0717デフォルトの名無しさん

2006/02/07(火) 07:48:57

10年に出すと言うのも男の勇気ですぜ，禿の兄貴。

0718デフォルトの名無しさん

2006/02/07(火) 11:12:23

確か最速で x=9 ってヒゲが言ってた。
標準化のプロセスに時間がかかるらしいから、
禿やヒゲががんばっても多分早くはならない。

0719デフォルトの名無しさん

2006/02/07(火) 11:19:31

まあ無理に急いで糞言語になるか、標準化遅れて処理系がNEEEEEEになるかはトレードオフだしなぁ

0720デフォルトの名無しさん

2006/02/07(火) 11:29:31

どこがC++0xなんだよ
C++1xじゃねえか
禿だか髭だかフサフサだかしらねーけどとっととしやがれ

0721デフォルトの名無しさん

2006/02/07(火) 11:45:21

C++0x0a

0722デフォルトの名無しさん

2006/02/07(火) 20:19:28

クラスのポインタ配列のvectorを作成し、
foo.push_back(new CFoo()); とやると無論コンストラクタが呼ばれますが
foo.erase(foo.begin()); 等とした際に
CFooのデストラクタが呼ばれないのは、こういう物だと思うしか無いのでしょうか？
foo[0].~CFoo(); みたいな事をeraseする度にやるのは何かおかしい感じがします

0723デフォルトの名無しさん

2006/02/07(火) 20:26:15

>>722
スマートポインタ

0724デフォルトの名無しさん

2006/02/07(火) 20:32:37

>>722
eraseする前にデストラクタではなくdeleteを呼べ。
それでは面倒だから>>723。
或いはboost::ptr_vector。

0725デフォルトの名無しさん

2006/02/07(火) 20:33:52

deleteされるわけじゃないからね、リークするだけ
boost::shared_ptrとかptr_vectorとかあるけど

0726デフォルトの名無しさん

2006/02/07(火) 20:36:09

>>723-725
一応、こういうモノなんですね…、ありがとうございます
ptr_vector ていうのがぱっと見便利そうなので試してみます。
とても参考になります。

0727デフォルトの名無しさん

2006/02/08(水) 00:27:35

>>722,726
もう納得したみたいだが

CFoo* p = new CFoo();
foo.push_back(p);
foo.erase(foo.begin());

で、勝手にdeleteされた方が
おかしい感じがするだろ

0728デフォルトの名無しさん

2006/02/08(水) 09:39:50

boost::ptr_vector と
std::vector<boost::shared_ptr> と
どっちがおすすめ？
っていうか本質的な違いある？

0729デフォルトの名無しさん

2006/02/08(水) 10:53:13

>>728
>どっちがおすすめ？
ケースバイケース

>っていうか本質的な違いある？
要素が生ポインタかスマートポインタか。

0730デフォルトの名無しさん

2006/02/08(水) 10:58:31

>>729 そうか、 boost::ptr_vector は中身が生ポインタか。
だったら std::vector< std::auto_ptr > とおなじようなもんか？
と思ったけど、後者はやっちゃだめなんだよな。
とりあえず boost::ptr_vector のヘッダファイルでも読んでみます。

0731デフォルトの名無しさん

2006/02/08(水) 21:55:40

>>730
ptr_vectorは、ただ単にデストラクタで全要素をdeleteするだけだろ。
auto_ptrとは何の関係もない。

0732デフォルトの名無しさん

2006/02/08(水) 23:20:20

要素が削除されたときにdeleteされるから、概念的に各要素がauto_ptrと言えなくも無い。
所有権の移動が無いからboost::scoped_ptrの方が適当だが。

0733デフォルトの名無しさん

2006/02/09(木) 08:17:21

(ﾟДﾟ)ﾊｧ?

0734デフォルトの名無しさん

2006/02/09(木) 09:28:44

ゆとり世代か

0735デフォルトの名無しさん

2006/02/09(木) 10:47:39

732はきわめて妥当なこと書いてると思うが……

0736デフォルトの名無しさん

2006/02/09(木) 19:14:45

>735
同意。

0737デフォルトの名無しさん

2006/02/09(木) 20:00:25

概念的という言葉を使えば、その記述が妥当であるかのように錯覚する。

しかし、プログラマの目の前にあるものは、
あいまいな「概念」などではなく、具体的で厳密なものだ。

プラットホーム、コンパイラ、ライブラリへの依存を無視した「概念」という言葉は、
プログラマに何の解決ももたらさない。時に誤解さえ与えかねない。

0738デフォルトの名無しさん

2006/02/09(木) 22:09:49

概念は心の拠り所。

0739デフォルトの名無しさん

2006/02/10(金) 00:22:32

>>737
お空に消えてなくなるタバコの煙みたいなレスですね。

0740デフォルトの名無しさん

2006/02/11(土) 14:39:46

先月末にApacheの(元はRogue Waveの)STLが出てるけど、これ既出？
http://incubator.apache.org/stdcxx/download.html の一番下

0741デフォルトの名無しさん

2006/02/12(日) 14:20:46

>>740

DL してみたんですけど、 VC6 へのインストール方法がわかりませんでした。。。

0742デフォルトの名無しさん

2006/02/20(月) 06:46:37

vectorを配列のように使った場合、配列と比較してパフォーマンスは落ちますか？

0743デフォルトの名無しさん

2006/02/20(月) 06:47:16

自分で計れカス

0744デフォルトの名無しさん

2006/02/20(月) 07:15:19

実装にもよるが素人が書いた場合、むしろ速くなる場合が多いのでvectorが利用できるなら利用することをすすめる

0745デフォルトの名無しさん

2006/02/20(月) 10:08:16

>>742 パフォーマンスに一番影響が出そうなところは
at() と operator[] のどちらを使うかってところかなぁ。
俺はもんげ～速度に厳しいときだけ operator[] 使ってる。

0746デフォルトの名無しさん

2006/02/20(月) 11:06:31

未だにat()を使ったことがない。

0747デフォルトの名無しさん

2006/02/20(月) 11:18:38

>>746 とりあえず安全のために
速度にうるさくないところでは
at() を使ってる。冷害出してくれるし。

0748デフォルトの名無しさん

2006/02/20(月) 11:20:28

あー漏れも同じだ
とりあえずat使って例外が飛んでこなかったらホットしてる

0749デフォルトの名無しさん

2006/02/20(月) 11:54:43

ホットで藤井隆を思い出した

0750デフォルトの名無しさん

2006/02/20(月) 13:04:53

漏れはfor_eachを使うからat()もoperator[]も使わんがな。

0751デフォルトの名無しさん

2006/02/20(月) 21:13:31

STL
ST
S
ST
SLL

0752デフォルトの名無しさん

2006/02/20(月) 22:08:02

at は安全だっつって使っておきながら catch してない人が居たなあ……。

0753デフォルトの名無しさん

2006/02/20(月) 22:49:12

>>752
投げられる例外すべてを catch する必要は無い。

0754デフォルトの名無しさん

2006/02/21(火) 12:42:04

>>752
コケてくれるという事は、検出出来ている、という事です。
安全ですね

0755デフォルトの名無しさん

2006/02/21(火) 12:59:15

「こけてくれる=安全」といえばこんな思い出が。
学生時代、あるプロジェクトにバイトで火消し投入された。
バイトを投入するあたり、相当DQNな会社だったわけだが、
まぁ投入される方としては時給もよかったしラッキーって感じ。

で、いつまで経っても原因不明のバグが出たりでなかったりで
リリースできん、って言う物だったんだけど、社内で共通に
使ってるライブラリみて唖然とした。すげぇ臭い物に蓋な
プログラム。例えば年齢を引数に取るコードで、負の値が
与えられたら勝手に0と見なす、みたいなことやってる。
で、漏れが assert 入れたら、お前のせいでバグが増えたってしばかれた。

0756デフォルトの名無しさん

2006/02/21(火) 14:58:19

以下のようなプログラムでa::bを使用すると
public: static class std::map<int,int,struct std::less<int>,class std::allocator<int> > a::b
というリンクエラーが発生します。
これはなぜなのでしょうか？

#include <map>

class a {
public:
　　static std::map<int,int> b;
};

0757デフォルトの名無しさん

2006/02/21(火) 15:03:53

class a{
...
};
static std::map<int,int> a::b; ← static メンバは外部定義しないとダメポ

0758デフォルトの名無しさん

2006/02/21(火) 15:09:38

>>757 宣言もしてないのにそんなこと出来るの？

0759デフォルトの名無しさん

2006/02/21(火) 15:34:47

その質問はよくわからんな

0760デフォルトの名無しさん

2006/02/21(火) 15:36:11

僕がSTLより高速なコードを書ける日来ますか？

0761デフォルトの名無しさん

2006/02/21(火) 15:36:34

来ません。

0762デフォルトの名無しさん

2006/02/21(火) 15:49:21

>>756
何その糞コンパイラ。

0763760

2006/02/21(火) 16:03:57

>>761
ありがとうございました。
それが分かっただけでも大満足です＾＾

0764デフォルトの名無しさん

2006/02/21(火) 16:54:05

>>757
以下のようにしたらエラーが出なくなりました。
ありがとうございます。

#include <MAP>

class a {
public:
　　static std::map<int,int> b;
};

std::map<int,int> a::b;

0765デフォルトの名無しさん

2006/02/21(火) 17:19:24

>>762
そのレスは意味が分からん

0766デフォルトの名無しさん

2006/02/21(火) 17:53:27

>>755
続きは？

0767デフォルトの名無しさん

2006/02/21(火) 18:36:01

>>766
確かにちょっと気になるな

ワッフルワッフル

0768デフォルトの名無しさん

2006/02/21(火) 18:52:03

それはつまり、どういうイヤらしいしばかれ方をしたか
詳細を書けということだな

ワッフルワッフル

0769デフォルトの名無しさん

2006/02/21(火) 22:58:38

キャッチしなくていいってのは、例外安全無視ってこと？

0770デフォルトの名無しさん

2006/02/21(火) 23:02:21

>>769
関係ない。「例外安全」の意味わかってんのか？

0771デフォルトの名無しさん

2006/02/22(水) 07:02:16

>>769
キャッチ漏れがあっても最後に確実に検出できるのがいいとこでそ。

0772デフォルトの名無しさん

2006/02/22(水) 07:10:09

関数内でエラーを拾った場合に、メンバ変数なり引数変数なりを
関数呼び出し前の状態に戻しておいて、処理が呼ばれなかったことにしつつ
例外を投げるのが例外安全だっけ？

0773デフォルトの名無しさん

2006/02/22(水) 07:32:38

>>772
それは例外安全性のレベルが与える保証のうち、強い保証というもの。

0774デフォルトの名無しさん

2006/02/22(水) 08:42:51

>>772
http://www.research.att.com/~bs/glossary.html#Gexception-safety
http://public.research.att.com/~bs/glossary.html#Gbasic-guarantee
http://public.research.att.com/~bs/glossary.html#Gstrong-guarantee
http://public.research.att.com/~bs/glossary.html#Gnothrow-guarantee

用語を知るってのは、単なる記憶力の問題じゃなくて、
基礎概念を整理して理解するってことにつながるから、
http://www.research.att.com/~bs/glossary.htmlにあることくらいは理解した方がいい。

英語苦手でも、簡単な英語で書かれているから、翻訳ソフト併用で問題なく読めるはず。

0775デフォルトの名無しさん

2006/02/22(水) 08:44:20

Deep C++にも例外の記事があったような気がしたがどうだっけ？

0776デフォルトの名無しさん

2006/02/22(水) 08:47:35

手元に「Exceptional C++ (訳本)」があるので、
例外中立と例外安全のところ読み返しときます。

0777デフォルトの名無しさん

2006/02/22(水) 08:47:42

>>775
あれは連載の途中で間違いの訂正が入っていたりするんで
途中だけ読むようなことは危険。
通して読めば、例外への誤解～理解を追えるので有益。

0778デフォルトの名無しさん

2006/02/22(水) 09:03:16

例外中立も例外安全も知らずに
例外を使っていたオレ。

0779デフォルトの名無しさん

2006/02/22(水) 09:35:50

Schmidtってちょっととぼけたところあるからな。
筆量はすごいんだが。

0780デフォルトの名無しさん

2006/02/22(水) 09:39:44

>>752はやっぱり変な気がする。
最終的に例外キャッチしない場所だったら、at使うよりも、
デバッグ版のSTL使うとか、assert入れるとか、デバッグ版とリリース版で[]とatを切り替えるとか
するのが筋でなかろうか。
まぁ速度気にしないならどうでもいいけど。

0781デフォルトの名無しさん

2006/02/22(水) 09:56:15

>>780
最終的に例外をキャッチしない場合でも範囲オーバー時の動作が違うわけで。
operator[]() で範囲オーバーしたら未定義動作。
at() で範囲オーバーしたら terminate() 。
環境によってはこれだけで十分な理由になり得る。

0782デフォルトの名無しさん

2006/02/22(水) 14:49:38

あー確かに。「誤動作即再起動」なプログラムには充分意味があるよ。
U/I持ってたらそうはいかないんだろうけど。

0783デフォルトの名無しさん

2006/02/22(水) 17:40:41

vector<double> a(n),b(n)
の２つの vector があって、
sort(a.begin(),a.end()) とsort をしています。
このとき、a の並び替えと全く同じ順番になるように
b も並び替えたいのですが、どうすればいいでしょうか？
class x{
double a
double b
firend operator<(const x&, const x&)
};
のような構造にして vector<x> c を作り sort(c.begin(),c.end());
とやればいいのは分かるのですが、a と b はメモリ上に
連続して配置する必要があるので、この方法は使えません。
いいアイデアがございましたら、ぜひよろしくお願いいたしますm(__)m

0784デフォルトの名無しさん

2006/02/22(水) 18:11:01

aのsortに合わせてbの要素も入れ替える様、sortを修正しろ。

a,bが小さいなら、class x { double a; int seq; } でseqに順番入れてソート、
bをseqみながら入れ替え。

0785デフォルトの名無しさん

2006/02/22(水) 18:19:03

>>783
boost::zip_iterator + a だけを見る比較
でいけるんじゃね？

0786783

2006/02/22(水) 18:25:56

レスどうもありがとうございます。
STL の sort をどこかに copy して修正すればいいのでしょうか？
STLの改造は今までやった事がないので、よく分からないのですが、
sort 命令に相当する source をSTLの中から探し出して、
それを改造し、自前で修正し、新たなソースファイルに
するということでしょうか？それともsort 文だけ
再定義する方法があるのでしょうか？

0787783

2006/02/22(水) 18:28:37

786は784へのレスです。
>>785
そんなのがあるのですか！boost::zip_iterator というのは
使ったことがなかったのですが、ぜひ勉強してみます。
やはりSTL だけでスマートにやるのは難しいでしょうか？

0788デフォルトの名無しさん

2006/02/22(水) 18:36:48

>>786
sortを修正すると言うより、sortに渡す関数オブジェクトを作れと言うことだろう。

0789デフォルトの名無しさん

2006/02/22(水) 19:32:27

関数オブジェクトによるソートといえば、
VC6のstd::list::sort()は欠陥で有名だよな。
std::sort()は大丈夫だけど。

0790デフォルトの名無しさん

2006/02/22(水) 19:47:39

xをsortしてから、a,bに全要素コピーし直す…
空間的にも時間的にも無駄が多いが

sortを自分で書くしかないか？
std::sortをコピペしてきて
swapの部分だけ二重にするとか

この2通りしか思いつかない

0791デフォルトの名無しさん

2006/02/22(水) 19:55:17

aのソート結果を使ってコピーする関数オブジェクトを作ってbからbNewにコピーしたら?

0792783

2006/02/22(水) 19:55:36

>>788
レスありがとうございます。
790さんが言われるように swap 自体を書き換えないといけない
ような気もするのですが、いかがでしょうか？

0793783

2006/02/22(水) 20:25:16

>>791
すみません、関数オブジェクトを使い慣れていない初心者でして、
考えてみたのですがよく分かりませんでした。具体的に
どのようにすればよろしいでしょうか？

0794デフォルトの名無しさん

2006/02/22(水) 20:31:27

>>790
> xをsortしてから、a,bに全要素コピーし直す…
> 空間的にも時間的にも無駄が多いが

これが一番簡単だよ
vector<x> tmp(n);
として、tmp[i].aとtmp[i].bに、a[i]とb[i]をすべてコピー
つぎにtmp[i].aでtmpをソート
a[i]とb[i]にtmp[i].aとtmp[i].bをすべてコピーする

0795デフォルトの名無しさん

2006/02/22(水) 20:55:42

>>789
VC6はそういうの苦手なの有名じゃん

0796デフォルトの名無しさん

2006/02/22(水) 21:01:24

std::sort(pair_iterator(a.begin(), b.begin()), pair_iterator(a.end(), b.end()));

で、両方のイテレータを操作してくれるような
イテレータアダプタ pair_iterator を作ればいいんじゃね？

0797デフォルトの名無しさん

2006/02/22(水) 21:18:41

>>796
それはsort側で両方の要素を同時にswapできるのか？
iteratorの指す先は単一の要素の気がするが

0798797

2006/02/22(水) 21:26:45

std::swapを特殊化すればできるかもしれないが、
前スレ
http://pc8.2ch.net/test/read.cgi/tech/1116559700/
の議論によれば、
std::sortがstd::swapを使用する保証はないらしい

0799デフォルトの名無しさん

2006/02/22(水) 21:36:20

>>795
苦手て(w

0800デフォルトの名無しさん

2006/02/22(水) 22:08:43

>>799
んじゃ正確に

ダメぽ

0801783

2006/02/22(水) 22:50:23

>>798
なるほど、そうですか。。。
>>794 の方法や、>>784 の class x { double a; int seq; } の方法で
地道にやる事にします。sizeof(double) > sizeof(int)なので、転送する
バイト数が少ない int seq の方法が有利かも。
いろいろとどうもありがとうございましたm(__)m ＞皆様

0802デフォルトの名無しさん

2006/02/22(水) 23:10:09

配列インデックスの配列 vector<size_t> c を作って、
比較関数に a[c[i]] < a[c[j]] のようなものを渡して sort() 。
あとは出来上がった c に従って a, b を並べればいい。
ダメかな？

0803デフォルトの名無しさん

2006/02/22(水) 23:13:40

index table (permutation) から実際の配列をソートしなおす
アルゴリズムって結構面倒だったような

0804デフォルトの名無しさん

2006/02/22(水) 23:15:46

最適化は後からやればいいんだよ

0805デフォルトの名無しさん

2006/02/22(水) 23:24:38

>>803
テンポラリ使えば簡単。

0806783

2006/02/22(水) 23:34:43

>>802 >>805 そうですね。この方法がベターな気がします。
どうもありがとうございました。

>>803 あくまでも tmp を使わない方針で、index table から配列を
ソートしなおすアリゴリズムを実装する位なら、最初から自前で
直接 sort する関数を作ってしまう方がよさそう(w

0807デフォルトの名無しさん

2006/02/23(木) 02:01:07

車輪の再発明をして、STLとのパフォーマンス差に愕然としないと、
一流のプログラマにはなれませんよね？

0808デフォルトの名無しさん

2006/02/23(木) 02:09:05

>>807 先にソースを読んで悟ることができる人もいるだろう。

0809デフォルトの名無しさん

2006/02/23(木) 02:12:13

プログラムを書くのも大事だけど、人のソースを読むのもかなり大事なんだよな
能力を高める秘訣については俺も知りたいもんだけど

0810デフォルトの名無しさん

2006/02/23(木) 08:09:54

人は、「vectorなんて初心者向けだろｗ」とタカをくくって、後で間違いに気づく。

0811デフォルトの名無しさん

2006/02/23(木) 09:56:52

真の初心者にはstd::map<long, T>を使わせるべき。

0812デフォルトの名無しさん

2006/02/23(木) 10:45:02

再発明した車輪の改良をして、STLとのパフォーマンス差に優越感を抱いた後で
例外安全とか柔軟性の差に愕然としないと一流のプログラマにはなれません

0813デフォルトの名無しさん

2006/02/23(木) 10:48:28

初めて出会った時からSTLにどっぷり依存してるから、
STL使わないという人を本気で不思議に思う。

0814デフォルトの名無しさん

2006/02/23(木) 11:03:33

初期の漏れ
　どうでも良いところをstl任せにできるから、
　重要な部分のチューニングに時間取れてｳﾏｰ!

今の漏れ
　パフォーマンスはどうでも良いのでstlで出来ることは非効率でも全てstl任せ。
　その分上位構造として複雑なアルゴリズムで難しい処理が実装できてｳﾏｰ!

特定の処理の実行速度だけ見ると昔の漏れの方が優秀・・・

0815デフォルトの名無しさん

2006/02/23(木) 11:09:10

STLは、フレームワークでもあるから、
自前特定領域チューニングコンテナを作る時にも設計の手間が大幅に省ける。
ステファノフ万歳

0816デフォルトの名無しさん

2006/02/23(木) 11:29:14

>>814
STL使用コードを低レベルなバッファアクセス並みに高速化できないのは、単に君が努力不足だから。

実体コンテナを使うだけでなく、その各要素へのアドレスvectorを利用すれば、
いくらでも低レベルなバッファアクセス並みの速度にできる。

0817デフォルトの名無しさん

2006/02/23(木) 11:38:55

sort()がswap()所以で遅いというなら、ポインタ配列に入れてCライブラリのqsort()すればいいだけ。
STLだと遅くなるとか言ってる奴は馬鹿丸出し。

0818デフォルトの名無しさん

2006/02/23(木) 11:42:52

>>816
なるほど。んではちょっと教えて欲しいんだけど、
「高々N個程度の物を納める可変長配列
　（ただしNは小さくて、全体をスタックにも取れる）」
ってのはどう効率的に書けますか？

vector< int > hoge(); hoge.reserve(N); だと効率悪いし・・・

やっぱり↓こういうのをちゃんと作るのかな。
一度作れば汎用的に使えそうだし。
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2003/n1479.html

0819デフォルトの名無しさん

2006/02/23(木) 11:44:47

boost 使えばいいのか・・・

0820デフォルトの名無しさん

2006/02/23(木) 11:54:29

>>818
＞vector< int > hoge(); hoge.reserve(N); だと効率悪いし・・・

は？vectorのせいじゃなくて、動的メモリを確保するタイミングが悪いだけだろ。
STLコンテナ使用をやめてallocやnewで記述したとしても同じことだ。
設計の段階から見直すことが先だろう。
同じバッファが再利用できないか、つまりは、スコープの見直し。

0821デフォルトの名無しさん

2006/02/23(木) 11:57:33

boost::ptr_container ?
早くこれにもシリアライザを用意して欲しいな。
まぁシリアライザだけ自分で書いてもいいけど。

0822デフォルトの名無しさん

2006/02/23(木) 11:57:38

>>818
Nが固定ならvector(size_type n)を使おうよ…

0823デフォルトの名無しさん

2006/02/23(木) 12:03:27

>>820
再利用できないとき、
あるいはしたくないときにはどうすればよいのか教えてください。

特にマルチスレッドのプログラム（やスレッドセーフなライブラリ）の場合
なかなかそう都合よくは行かないことも多くて。

0824デフォルトの名無しさん

2006/02/23(木) 12:05:41

>>822
それだと最初からサイズNじゃない？
>vector< int > hoge(); hoge.reserve(N);
と意味が違うような・・・

というか(スレ違いだけど) boost::array<int, N> hoge; で解決。

0825デフォルトの名無しさん

2006/02/23(木) 12:08:14

>>824
あ、やっぱりboost::array は完全固定サイズだから、
「高々Nの可変長」ってのとは違うような・・・

寝ます。

0826デフォルトの名無しさん

2006/02/23(木) 12:09:01

>>824
何言っているか理解不能。
お題をちゃんと示せよ。

0827デフォルトの名無しさん

2006/02/23(木) 12:12:29

＞なかなかそう都合よくは行かないことも多くて

多いか？
不可能であると頑なに決め付ける根拠が希薄なわけだが。

0828デフォルトの名無しさん

2006/02/23(木) 12:22:23

「高々N」は「上限がN」ということなので、上限固定として扱って問題ないと思うが、
「高々N」とはどういう意味で使っているのか?

0829デフォルトの名無しさん

2006/02/23(木) 13:28:16

もう面倒だからvalarray使えや

0830デフォルトの名無しさん

2006/02/23(木) 13:34:15

多分capacityが不変でsizeが可変なvector風コンテナのことを言ってるんだと思う。

0831デフォルトの名無しさん

2006/02/23(木) 13:57:40

だったらvectorでいいような。

0832デフォルトの名無しさん

2006/02/23(木) 13:59:10

いや、vectorだとスタックに取れない。

0833デフォルトの名無しさん

2006/02/23(木) 14:01:50

上限はそうだけど、なるべくメモリ消費したくないのでは？

0834デフォルトの名無しさん

2006/02/23(木) 18:56:02

自分でスタックに確保するアロケータを作ってそいつをstd::vectorに渡せばいけるのでは？
と思ったが、標準のコンテナに渡せるアロケータの要件を守れなさそうな気がする。

0835デフォルトの名無しさん

2006/02/23(木) 19:20:58

そこで、std::basic_string<Hoge>。
VC8だと。16バイトまではstackに確保してくれる実装になってた。

0836デフォルトの名無しさん

2006/02/23(木) 19:48:35

>>835
basic_stringは制約が・・・

0837デフォルトの名無しさん

2006/02/23(木) 23:58:27

>>834
allocate()でalloca()使ったからといって問題になることはないよ。

0838デフォルトの名無しさん

2006/02/24(金) 11:28:44

ttp://msdn.microsoft.com/library/ja/default.asp?url=/library/ja/vclib/html/_crt__alloca.asp
>セキュリティに関するメモ Windows XP では、try/catch ブロック内で _alloca を呼び出した場合は、catch ブロックで _resetstkoflw を呼び出す必要があります。

VC限定だけど、こんなへんてこ仕様の非標準関数はあまり使いたくない

0839デフォルトの名無しさん

2006/02/24(金) 11:45:02

べつにallocaなんて使わなくても、内部に配列を抱え込めば済む話じゃ。

0840デフォルトの名無しさん

2006/02/24(金) 11:52:01

まあ「高々N」だからな。

0841デフォルトの名無しさん

2006/02/24(金) 11:54:41

>>838
変な仕様というか、allocaの引数が可変だから、
スタックチェックに引っ掛からないように調整し直す必要があるんだろ?
通常終了時は関数出口辺りで調整するコードを実行するんだろうけど。

0842デフォルトの名無しさん

2006/03/08(水) 19:40:47

STLで環状リストってありますか？
++iteratorでぐるぐる回るやつが理想です。

0843デフォルトの名無しさん

2006/03/08(水) 20:41:51

ないです。

0844デフォルトの名無しさん

2006/03/08(水) 20:45:42

++iteratorの代わりに、
++iterator; if (iterator == ringList.end()) iterator = ringList.begin();するだけだろ。

0845デフォルトの名無しさん

2006/03/08(水) 21:12:04

>>843-844
レスありがとうございます。やはり無いですか。
>>844で示されたようにすればいいんですが、環状リストとして扱っているということを
コード上にも(アルゴリズム的に)反映させたいと思ってたので残念です。

0846デフォルトの名無しさん

2006/03/08(水) 21:20:33

>>845
844の動きをするイテレータを自作すればいいと思うのだが。

0847デフォルトの名無しさん

2006/03/08(水) 21:43:24

>>844みたいなことを内部的にしたいが為だけにiteratorのクラステンプレートを
自作するのは、まぁ、億劫な話だわな。

0848デフォルトの名無しさん

2006/03/08(水) 21:58:09

そこでboost iteratorsですよ。

0849デフォルトの名無しさん

2006/03/08(水) 21:58:51

そんなあなたにBoost.Iterator

0850デフォルトの名無しさん

2006/03/08(水) 22:01:06

つboost::iterator_adaptor

0851デフォルトの名無しさん

2006/03/08(水) 22:04:09

>>848-850
おまえら、合体しる。

0852デフォルトの名無しさん

2006/03/09(木) 01:20:26

>848-850をbindしようと思います

0853デフォルトの名無しさん

2006/03/09(木) 08:18:30

>>845
添字を循環させるってのはどう?
index = (index + 1) % array.size();

0854デフォルトの名無しさん

2006/03/09(木) 08:37:59

>>853
そういうことをするoperator []を持つコンテナを作るってのはどう?

0855デフォルトの名無しさん

2006/03/09(木) 08:41:18

>>854
まあ、言いたいのはそういうことです。
fetch_first, fetch_next, fetch_last で実装してもいいかも。

0856デフォルトの名無しさん

2006/03/09(木) 14:47:51

boost::iterator_adaptor で実装しようと思ったら思いの他難しいな…。

0857デフォルトの名無しさん

2006/03/09(木) 15:51:30

RandomAccessIteratorの要件を満たさないから
そこだけmpl::if_で分岐を入れる必要があるな。

0858デフォルトの名無しさん

2006/03/09(木) 15:59:35

ブーストってなんですか＞＜？

0859デフォルトの名無しさん

2006/03/09(木) 16:22:14

そろそろ "＞＜" を NG ワードに入れてもいい季節かな？

0860デフォルトの名無しさん

2006/03/09(木) 16:25:20

やめてください！＞＜

0861デフォルトの名無しさん

2006/03/09(木) 22:36:15

>>857
いや，ベースとなるイテレータが RandomAccess なら満たすんじゃないですか？

0862デフォルトの名無しさん

2006/03/09(木) 23:12:35

>>834あたり
遅くなりましたが、
ttp://www.tantalon.com/pete/files/gems3update.zip
にある StaticAlloc ってのがそういう感じに使えそうですね。

vector::swap時のアロケータとの整合性とか考えると、
自前でコンテナ書いた方が良いという気もしてきますた。

0863デフォルトの名無しさん

2006/03/09(木) 23:23:23

>>861
うまく順序を定められない。
pとqが異なるとき、[p,q)も[q,p)も空でない区間だから、
p < q かつ q < p である必要がある。

0864861

2006/03/10(金) 00:30:39

>>863
う～ん，これ設計として大別して2つあるんですね．
今，対象とする範囲の大きさを仮に10としたときに，
it と it + 10 が同値である（it == it + 10 が常に true）というあり方と，
it と it + 10 が同値でない (it == it + 10 が常に false) というあり方の2つです．

自分としては後者の設計を想定していて， it と it+10 はイテレータとしては同値ではなく
単に dereference の結果「たまたま」同じ値が返ってくるだけという考え方です．
この立場ではイテレータアダプタは readable だが writable ではない，となります．
こちらの設計ではイテレータアダプタオブジェクトが，現在の場所を指す
ベースイテレータオブジェクトと何らかのオフセット値を同時に保持する必要があります．
（ただし，ベースが RandomAccess なら保持するのはオフセット値だけで良いです）

多分 863 さん的には前者の立場かと思うんですが，前者の場合
全順序性のような RandomAccess 固有の問題に限らず，
一般に std::distance の意味が一意に定まらず，混乱すると思うので
（最小の正の値を返す，といったような何らかの一貫した立場を取ることはできますが）
個人的にはちょっと設計的に微妙な感じはします．

0865デフォルトの名無しさん

2006/03/10(金) 00:54:52

>>864
なるほど、後者の設計を思い付かなかった。
こっちの方がずっと扱いやすそうだ。

0866デフォルトの名無しさん

2006/03/10(金) 08:49:14

基本的なことで質問です
STLって便利？ではなくて使ったほうが良いですか？

0867デフォルトの名無しさん

2006/03/10(金) 09:11:47

C++でSTL使うのはWindowsをマウスで操作するぐらいに自然なことだ。

0868デフォルトの名無しさん

2006/03/10(金) 09:39:06

C++でSTLを使わないのは、裸の女を見てオナニーをするようなものだ。
STLを使うのは、オナニーではなくセックスをするようなものだ。

0869デフォルトの名無しさん

2006/03/10(金) 09:44:14

初心者の君が天才でもないかぎり、どんなに頑張ってもSTLより高速なコードは書けないだろう。

0870デフォルトの名無しさん

2006/03/10(金) 10:16:35

C++はSTLを使ってこそ本領を発揮できる。

0871デフォルトの名無しさん

2006/03/10(金) 10:19:02

>>870
そこまでヨイショするほどのもんでもないと思うが。
でも、STLは使え。>>866

0872デフォルトの名無しさん

2006/03/10(金) 10:26:54

>>867
Windowsをマウスを使わずにキーボードショートカットだけで操作するのは別に非効率とは限らないが、
C++でSTLを使わないのは非効率だ。

>>868
裸の女を見てオナニーをしても不毛ではあるがセックスに伴う責任は回避できる。
しかし、C++でSTLを使うことにセックスに伴うような責任は発生しない。

>>866
まぁ、使ってみろ。いいもんだ。

0873デフォルトの名無しさん

2006/03/10(金) 10:40:29

そうなんですか・・・これから勉強か～～

0874デフォルトの名無しさん

2006/03/10(金) 11:09:03

というか、STLの知識は他の言語でも役立つだろう。
これからどの言語もSTL風のコレクションクラスを持つことになるだろうから。
実際JavaやC#でも…

0875デフォルトの名無しさん

2006/03/10(金) 11:28:25

>>874
javaのあの脳味噌が腐ったようなGenerics実装みてよくそんな希望的観測が抱けるな。

0876デフォルトの名無しさん

2006/03/10(金) 11:37:25

実装? 仕様じゃなく?

0877デフォルトの名無しさん

2006/03/10(金) 11:40:53

>>876
漏れは「仕様」より一つメタな概念としての"Generics"ってのがあって、
C++ の template やら "Java の Generics" ってのはそれの実装だ、
という（脳内で）考えてるので自然に読めますた。

0878デフォルトの名無しさん

2006/03/10(金) 11:46:05

まあ仕様の間違いでしょ。

JavaのGenericsは、特殊化なしの制約付きとしてはそれほど悪くないんじゃない？
コアなC++使いにとっては貧弱に思えるけれども。

0879デフォルトの名無しさん

2006/03/10(金) 12:21:20

JavaのGenericsは切な過ぎる。
特殊化なしの制約なんてもう耐えられない。

0880デフォルトの名無しさん

2006/03/10(金) 12:31:52

特殊化しなくちゃ

0881デフォルトの名無しさん

2006/03/10(金) 12:36:26

JavaのCollectionの内部イタレータというのも切ないな。
実装の隠蔽という面からは、あれも正しいんだろうけども。

STL.NETは公開延期だけど、やっぱりJavaよりになるんだろうな。
特殊化はC++とCLOSくらいしかないし。

0882デフォルトの名無しさん

2006/03/10(金) 13:40:43

え、特殊化ねーの？(;ﾟДﾟ)

0883デフォルトの名無しさん

2006/03/10(金) 15:07:49

C++/CLIはgenericでなく、templateなら特殊化可能だったよ。
genericはnew制約とか余計な思想強制されるんでいらね

0884デフォルトの名無しさん

2006/03/12(日) 04:45:43

STLPortの5.0.2を使ってみたりしてるんだけど、
hash_setがなんか遅いような気がする
気のせい？

0885デフォルトの名無しさん

2006/03/12(日) 11:44:32

VC7のよりは速い

0886デフォルトの名無しさん

2006/03/13(月) 13:54:59

vectorから不連続な複数要素をインデックス指定で一度に効率よく削除するにはどうするのが一番いいんだぜ？

#include <stdio.h>
#include <vector>
#include <algorithm>

template<class T>
bool VectorErase(std::vector<T>& vt, std::vector<unsigned int>& ve)
{
　std::vector<T>::iterator　　　　p1, p1Src, p1Dst, p1End;
　std::vector<unsigned int>::iterator　　p2, p2End;
　unsigned int　i, nMaxElement;

　// 削除するインデックスが配列サイズより大きいかチェック
　nMaxElement = *std::max_element(ve.begin(), ve.end());
　if (vt.size() <= nMaxElement){
　　return false;
　}

　if (ve.size() > 0){
　　p2 = ve.begin();
　　p2End = ve.end() - 1;
　　for (i = 0; p2 != p2End; ++p2, ++i){
　　　// 次の削除要素までコピー
　　　p1 = vt.begin() + *p2;
　　　p1Src = p1 + 1;
　　　p1Dst = p1 - i;
　　　p1End = vt.begin() + *(p2 + 1) - 1;
　　　for (; p1 != p1End; ++p1){
　　　　*p1Dst++ = *p1Src++;
　　　}
　　}

0887デフォルトの名無しさん

2006/03/13(月) 13:55:33

　　// 次の削除要素がなければ、残りはコピーだけ
　　p1 = vt.begin() + *p2;
　　p1Src = p1 + 1;
　　p1Dst = p1 - i;
　　p1End = vt.end() - 1;
　　for (; p1 != p1End; ++p1){
　　　*p1Dst++ = *p1Src++;
　　}

　　// リサイズ
　　vt.resize(vt.size() - ve.size());
　}

　return true;
}

void main()
{
　std::vector<unsigned int>　vecData;　　// 対象データ
　std::vector<unsigned int>　vecErase;　　// 削除インデックス (要昇順ソート、ユニーク)
　unsigned int　　　　i, nMaxData;
　nMaxData = 10;
　vecErase.push_back(0); vecErase.push_back(4); vecErase.push_back(7);　// 削除インデックス作成
　for (i = 0; i < nMaxData; ++i) vecData.push_back(i);　// データ作成
　VectorErase(vecData, vecErase);　// 削除実行
　for (i = 0; i < vecData.size(); ++i) printf("vecData[%u]: %u\n", i, vecData[i]);　// 結果表示
}

0888デフォルトの名無しさん

2006/03/13(月) 14:17:13

どうするのが一番いいんだぜ？って何語だぜ？

0889デフォルトの名無しさん

2006/03/13(月) 14:41:45

>>887
面倒なことせずに、簡単に行こうよ。それでパフォーマンステストしてから効率を考えよう。
#つーか、>886は効率悪そうでw
テンプレート化はしてないけどするにしても簡単でしょ。
static void VectorErase(vector<unsigned> & vecData, unsigned idx)
{
vecData.erase(vecData.begin() + idx);
}
static void VectorErase(vector<unsigned> & vecData, vector<unsigned> const & vecErase)
{
for (vector<unsigned>::const_reverse_iterator it = vecErase.rbegin(); it != vecErase.rend(); ++it) {
VectorErase(vecData, * it);
}
}

0890デフォルトの名無しさん

2006/03/13(月) 15:02:56

なぜvectorから要素を効率よく削除できるのはどうしてだぜ？

0891デフォルトの名無しさん

2006/03/13(月) 15:12:13

>面倒なことせずに、簡単に行こうよ。それでパフォーマンステストしてから効率を考えよう。
汎用の部品は最低限の最適化をしておいても損はないと思う。
とりあえず、>>889はO(n^2)なので問題外じゃないだろうか。

0892デフォルトの名無しさん

2006/03/13(月) 15:25:50

std::remove_ifは？

0893デフォルトの名無しさん

2006/03/13(月) 15:51:35

>>892
std::remove_if()はiteratorが渡されないからインデックス配列を扱う用途には向いてない希ガス。

>>891
同意。しかし、vectorの要素をインデックスで削除する用途はそれほどない希ガス。

>>887
インデックスを作る段階で、std::remove_if()をいきなり実行できないのかな?

0894886@Athlon64 3000+

2006/03/13(月) 20:33:38

nicegay達、レスありがとうだぜ？
簡単に試したところ、条件次第でremove_ifと速度が入れ替わる（500～1000万件
で±数十ミリ秒程度）のですが、平均的に速そうでかつムラがなさそうなので、
データクラスに削除フラグを持たせてremove_ifを使う方向で考えてみます。

0895デフォルトの名無しさん

2006/03/13(月) 20:52:14

>データクラスに削除フラグを持たせて
ほんとにそんな侵入的な方法が必要なのか？
すごく気持ち悪いんだが。

もちろん、おまえが良いというならそれで良いんだけど。

0896デフォルトの名無しさん

2006/03/13(月) 21:37:34

要素がスマートポインタ的な実装の場合、テンポラリvectorに生き残りを
コピーしてvectorごとswapするのが速い悪寒だぜ。

0897デフォルトの名無しさん

2006/03/14(火) 00:35:14

日本語でおｋ

0898デフォルトの名無しさん

2006/03/14(火) 01:18:36

・削除するインデックスのリストはソート済
・削除する要素が存在しないときの最適化はしていない
という条件だとこんな感じ？
まだまだ汎化＆最適化できそうだけど、もういいや。
void VectorEraser( std::vector<int>& target, std::vector<int>& erase)
{
　std::vector<int> result;
　std::vector<int>::iterator tb(target.begin());
　std::vector<int>::iterator ti(target.begin());
　std::vector<int>::iterator te(target.end());
　std::vector<int>::iterator ei(erase.begin());
　std::vector<int>::iterator ee(erase.end());
　while((ti != te)&&(ei != ee)) {
　　if (*ei == std::distance(tb, ti)) {
　　　++ei; ++ti;
　　} else {
　　　result.push_back(*ti);
　　　++ti;
　　}
　}
　result.swap(target);
}

0899デフォルトの名無しさん

2006/03/14(火) 01:23:20

>>894
niceなguyとniceなgayは微妙に違うんだぜ。
両方兼ねている人もいるだろうけど。

0900デフォルトの名無しさん

2006/03/14(火) 06:54:23

>>898
それだとtargetとeraseのサイズに比例した一時領域を食うからアンマリ良くないと思う。
コピーを作るより破壊的にコンテナに直書きしていったほうがコストが抑えれる。

void VectorEraser( std::vector<int>& target,const std::vector<int>& erase)
{
    std::vector<int>::const_iterator ei(erase.begin());
    std::vector<int>::const_iterator ee(erase.end());
    std::vector<int>::iterator di(target.begin());
    std::vector<int>::iterator tb(target.begin());
    std::vector<int>::iterator ti(target.begin());
    std::vector<int>::iterator te(target.end());
    for(;ei != ee;++ei) {
        std::vector<int>::iterator x(tb);std::advance(x,*ei);
        di = std::copy(ti,x,di);
        ti = ++x;
    }
    di = std::copy(ti,te,di);
    target.resize(std::distance(target.begin(),di));
}

0901デフォルトの名無しさん

2006/03/14(火) 11:31:03

>>900
ループの最初の一回を外に出してコピーしないようにすると
より高速になりますね。
最初にif (ei != ee)が要りますが。

0902デフォルトの名無しさん

2006/03/16(木) 18:36:16

質問失礼します。
現在構造体にSTL stringのメンバを複数おいて利用しているのですが、
どうもメモリリークが起きてしまいます。
起きているのはそのメンバに有効な文字列（１バイト以上）が入ったときのみのようです。
入るのはoperater =によってです。
Debug実行の後の出力では
c:\program files\microsoft visual studio .net 2003\vc7\include\crtdbg.h(689) : {68} normal block at 0x00CD2568, 32 bytes long.
と、出力されています。構造体にstringは使用出来ないのでしょうか？
ご教授お願いします。

0903デフォルトの名無しさん

2006/03/16(木) 18:38:55

>>902
レガシーな構造体のつもりで安直なメモリ転送したりメモリコピーをしていなければ大丈夫。

0904902

2006/03/16(木) 18:44:46

memcpy Zeromemory等の関数は使用してないです。
もちろんstring内データ直アクセスも。
構造体内に構造体が３つあってそこにもstringやらintやら混ざってるのが悪いのでしょうか。
･･･そんなわけないですよねぇ･･･。
ちなみにSTLは.NET2003標準のやつです。

0905902

2006/03/16(木) 18:56:06

度々すみません。情報追加です。
構造体を使用しているのはクラスのpublicメンバで、
m_typData.strA = "aaaaaaaaaaaaaaaa";
等としたところでリークしていました。また、上記例から文字が一文字減るとおきませんでした。
その直前までsrAは未初期化の状態です。

0906デフォルトの名無しさん

2006/03/16(木) 19:06:34

>>904
その構造体を free で解放してたりしませんか？

0907902

2006/03/16(木) 19:11:14

>>906
していません。したら落ちます、構造体自体はそのまま
TYPE_DATA typData; の様な使い方をしているので。
string以外のメンバはint DWORD SIZE RECT POINT さらに構造体などですが、
いずれもメモリ操作系の関数は使用しておらず、すべてoperater =や+=等ばかり使用しています。

0908デフォルトの名無しさん

2006/03/16(木) 19:27:56

とりあえず再現性のある最小のコードを貼れ。
話はそれからだ。

0909902

2006/03/16(木) 19:34:37

最小ソースです Win32 Console VC++.NET 2003で作成

// CRTデバッグ
#define _CRTDBG_MAP_ALLOC

// CRTデバッグ
#include "stdlib.h"
#include "crtdbg.h"

#include <string>
using namespace std;
struct TYPE_A
{
string a;
};

void main(void)
{
TYPE_A typData;

typData.a = "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa";

// CRT メモリリーク確認
_CrtDumpMemoryLeaks();
return;
}

0910デフォルトの名無しさん

2006/03/16(木) 19:39:07

>>909
typDataがスコープから抜ける前にリークチェックしてるよ

0911デフォルトの名無しさん

2006/03/16(木) 19:41:20

あと
・mainの戻り値にvoidはやめなさい。
・stdlib.hやcrtdbg.hがなぜ""で囲まれてるのか？

0912デフォルトの名無しさん

2006/03/16(木) 19:41:56

正しくはこうやるみたいですよ。試してませんが。

void main()
{
TYPE_A typeData;
typData.a = "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa";

_CrtSetDbgFlag( _CRTDBG_ALLOC_MEM_DF | _CRTDBG_LEAK_CHECK_DF );
return;
}

0913902

2006/03/16(木) 19:57:38

解決しました。
実際の方ではWinMainの中でクラス変数を宣言し（そのクラスが構造体を持ってるのです）クラスの関数を走らせ終了する
ようなものになっていたのですが、クラスをポインタにしてnew 及び deleteを行えば解決しました。
STLの問題では無く申し訳ありません。同じスコープ内で有効な物に対してはチェックがうまく働かないと知りませんでした。
ご教授ありがとうございました。

0914902

2006/03/16(木) 20:03:39

>>911
前に勤めていた会社の先輩にSTLは<>、その他は""と習ったからです。
違うのでしょうか。
void main(void)に関しても高校時代のポケコンCが･･･
いろいろと間違った知識を使ってきたみたいで恥ずかしいです

>>912
調べて下さってありがとうございます。
試してみたところ_CrtDumpMemoryLeaks無しで終了時にチェックが働く様になりました。

0915デフォルトの名無しさん

2006/03/16(木) 20:16:43

>>913
new, deleteしなくても

int main()
{
　{
　　TYPE_A typeData;
　　typData.a = "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa";
　}
　_CrtSetDbgFlag( _CRTDBG_ALLOC_MEM_DF | _CRTDBG_LEAK_CHECK_DF );
　return 0;
}

ってすればいいんだけどな。

0916デフォルトの名無しさん

2006/03/16(木) 20:22:39

>>914
> 前に勤めていた会社の先輩にSTLは<>、その他は""と習ったからです。
（´Д｀）

0917デフォルトの名無しさん

2006/03/16(木) 20:24:02

>>914
前の会社なら問題ないだろうから、その会社名と先輩とやらの名前を晒せ。
ローカルなインクルード以外は全て<>にするのが常識だ。
#プロジェクトローカルをどっちにするかは悩ましいところだが。

0918デフォルトの名無しさん

2006/03/16(木) 21:41:43

>>914
その先輩はSTLを標準ライブラリ全てを指す言葉として使っているに違いない。

0919デフォルトの名無しさん

2006/03/16(木) 22:20:00

きっとSTLがSTandard Libraryの略だと思ってるんだよ

0920デフォルトの名無しさん

2006/03/16(木) 22:27:15

まぁSTLという区分の曖昧さ・中途半端さにも若干の業はあると思うけれど、
その先輩はそれを言い訳にしちゃいけない領域に居るお馬鹿さんだな。

0921デフォルトの名無しさん

2006/03/17(金) 10:05:08

STL作った人は余程の自信があるんだろうな。
俺のソースは恥ずかしくて見せられない。＞＜

0922デフォルトの名無しさん

2006/03/17(金) 10:35:31

>>921
自信が無くても見せなければならない。

……、それがテンプレートの定め。

0923デフォルトの名無しさん

2006/03/17(金) 10:46:39

ｲﾔﾝ

0924デフォルトの名無しさん

2006/03/17(金) 13:00:47

ベクトルのリザーブってするとどんな利点があるの？

0925デフォルトの名無しさん

2006/03/17(金) 13:09:32

性能的に有利な場合がある
一個ずつpush_backしていくと何度も内部でrealloc©しちゃうけど
reserveしとけばそのサイズを越えるまで無駄なrealloc©をしないことが保証される

reallocによるメモリの断片化の防止とかもあるけど
いちいちメモリ確保&コピーコンストラクタ呼び出しするコストは馬鹿に出来ない

0926デフォルトの名無しさん

2006/03/17(金) 13:10:10

0927デフォルトの名無しさん

2006/03/17(金) 13:35:17

>>925
あり＾＾

0928デフォルトの名無しさん

2006/03/17(金) 13:52:34

>>926
&copyって書けばいいだけのこと。(&copy)

0929デフォルトの名無しさん

2006/03/17(金) 13:53:39

ま、それだけのこと

0930デフォルトの名無しさん

2006/03/17(金) 14:00:34

♥

0931デフォルトの名無しさん

2006/03/17(金) 14:05:42

ああリザーブってキャパシティを保証するだけですか。
もともとキャパシティが必要個数分以上になってれば、リザーブなんか考えずに
ぼんぼこ必要分までプッシュバックしていっておｋ？

0932デフォルトの名無しさん

2006/03/17(金) 14:52:32

＞ああ給油ってのはガソリン入れるだけですか。
＞もともとガソリンが必要な量だけ入っていれば、給油なんか考えずに
＞ぼんぼこ目的地まで走っていっておｋ？

OK。

0933デフォルトの名無しさん

2006/03/17(金) 15:55:03

リザーブしただけでアプリのメモリ使用量は増えますか？

0934デフォルトの名無しさん

2006/03/17(金) 16:06:59

増えるかもしれないし増えないかもしれない。
そもそもreserve()で何もしない処理系もある。

0935デフォルトの名無しさん

2006/03/17(金) 16:09:41

>そもそもreserve()で何もしない処理系もある。
それは規格違反な気がするが。
どの処理系？

0936デフォルトの名無しさん

2006/03/17(金) 16:37:10

934じゃないけど。
Windowsのことかなー
あいつはallocしても、仮想メモリ空間のアドレスに空きがあればOKのフリするし。
実際にメモリをアクセスしに行ってPageエラーをキャッチして本物の仮想メモリを割り当てる
ってことやってるから、そのタイミングでswapファイルが作れなくなってあぼーんとか、ある。

0937デフォルトの名無しさん

2006/03/17(金) 17:40:42

>>936
それは「何もしない」とは大分違うような気がする。

0938デフォルトの名無しさん

2006/03/17(金) 23:26:13

resize()で今より大きい個数指定したら再確保すると思うんですが、
その時ってちゃんとリザーブして確保とか、考えられる限り高速に設計されてますか？

0939デフォルトの名無しさん

2006/03/17(金) 23:28:43

もちろん

0940デフォルトの名無しさん

2006/03/17(金) 23:30:38

じゃあ僕は安心してリサイズすればいいのですね＾＾
ありがとうございました

0941デフォルトの名無しさん

2006/03/17(金) 23:31:51

>>938
複雑度が線形以下で実装されていることが保証されている。
「高速に設計」されているかどうかは知らない。

0942デフォルトの名無しさん

2006/03/17(金) 23:33:51

そもそもreserve()なんて使いません＞＜

0943デフォルトの名無しさん

2006/03/17(金) 23:43:34

>>942
使えよ（必要ならば）。

0944デフォルトの名無しさん

2006/03/18(土) 01:58:19

C++の人達は呑気でイイですね

0945デフォルトの名無しさん

2006/03/18(土) 02:08:55

>>944
そんなわけあるか！
禿げが禿げてんのだってきっとストレスが原因だ！

0946デフォルトの名無しさん

2006/03/18(土) 02:16:58

しかしあれだけC++使える香具師にどんなストレスがあるって言うんだ

0947デフォルトの名無しさん

2006/03/18(土) 02:27:49

禿げが気になって気になってストレスたまるんだと・・・

0948デフォルトの名無しさん

2006/03/18(土) 02:59:51

おまいらが禿禿言うからだろ
言ったやつ謝れよ

0949デフォルトの名無しさん

2006/03/18(土) 04:44:02

ごめ…

0950禿

2006/03/18(土) 05:01:04

ちゃんと謝れ(`_ゝ´)

0951デフォルトの名無しさん

2006/03/18(土) 05:03:37

ごめんなさい＞＜

0952デフォルトの名無しさん

2006/03/18(土) 07:35:58

子曰く、放屁也。

0953デフォルトの名無しさん

2006/03/18(土) 11:47:14

禿げはビオチン不足が原因の可能性がある
サプリで摂れって
ビオチンは、糖尿病や肥満の対策にも有効だぞ
英語の綴りはbiotinだ

0954デフォルトの名無しさん

2006/03/18(土) 12:18:12

>>953 禿はセックスのやり過ぎだと思う。
だれか訊いてきて来んない？本人に。

0955デフォルトの名無しさん

2006/03/18(土) 13:59:12

禿げは
L-システイン
L-メチオニン
亜鉛
が不足している。

0956http://www.vector.co.jp/soft/win95/util/se072729.html

2006/03/18(土) 18:28:18

TextSS　の64bit化おながいします

もしくは64bitにネイティブ対応した置換ソフトないですか？

0957デフォルトの名無しさん

2006/03/18(土) 19:21:36

>>956
スレ違い。マルチ乙。
あと氏ね。

0958デフォルトの名無しさん

2006/03/19(日) 21:02:01

大体マルチする程の内容ですらないしな

0959デフォルトの名無しさん

2006/03/22(水) 09:09:37

VC8でSTLport5.0.2をビルドすると、最後に「パブリックシンボルが
見つかりません」というリンカの警告が一つ出るな。

ま、ライブラリはビルド出来て使えたが、気になる。

0960デフォルトの名無しさん

2006/03/22(水) 09:15:40

ま、気にするな。

0961デフォルトの名無しさん

2006/03/22(水) 09:19:00

>>960
レス㌧クス。ま、5.0.2そのものがVC8 Beta用みたいだから、
VC8の正式版が出てる今日、STLportもVerUPすると期待してる。

0962デフォルトの名無しさん

2006/03/22(水) 10:17:19

ま、少なからず、近いうちに問題解決されるんじゃねぇかな。

0963デフォルトの名無しさん

2006/03/22(水) 17:06:28

おまいら週に何回オナニーしますか？
僕は最近めっきり減りました。

0964デフォルトの名無しさん

2006/03/22(水) 21:25:22

だいたい７回くらいかな。
曜日は火曜と金曜と決めている。

0965デフォルトの名無しさん

2006/03/22(水) 22:39:29

曜日決めてまとめてやるんですか。。。

0966デフォルトの名無しさん

2006/03/22(水) 22:59:37

STLは制限の多い組み込みとかの開発でも使い物になります？

0967デフォルトの名無しさん

2006/03/22(水) 23:01:34

最悪アロケータとか自分でどうにかできるなら

0968デフォルトの名無しさん

2006/03/22(水) 23:04:40

ﾄﾝｸｽ

0969デフォルトの名無しさん

2006/03/22(水) 23:10:13

STLがしっかり実装できるほど、
まともにテンプレートが使える、
組み込み向けのC++コンパイラなんてあるのかな。

0970デフォルトの名無しさん

2006/03/22(水) 23:17:45

組み込み向けってもピンキリだけどな。

ttp://www.toppers.jp/cxx-api.html
こんなもんまであるご時世だし。

0971デフォルトの名無しさん

2006/03/22(水) 23:34:09

コンパイラに組み込み向けも糞もないんじゃないの?
ライブラリならともかく。

0972デフォルトの名無しさん

2006/03/22(水) 23:47:21

EC++とかはもうどうでもいいにせよ、世の中gccとか対応してないどマイナーなアーキテクチャなどいくらでもある

0973デフォルトの名無しさん

2006/03/23(木) 00:34:20

>>966
コンテナはともかく、アルゴリズムとファンクタはとても役に立つ！

0974デフォルトの名無しさん

2006/03/23(木) 02:31:39

>>973
例えば？

0975デフォルトの名無しさん

2006/03/23(木) 02:33:19

>>974
fill とか copy とか transform とか、いくらでもあるだろ。

0976デフォルトの名無しさん

2006/03/23(木) 10:11:49

>>974
equal_range でも sort でも remove_copy_if でも配列に対して使える。
一緒に bind などもどうぞ。

0977デフォルトの名無しさん

2006/03/27(月) 14:01:59

Apache C++ Standard Library
http://incubator.apache.org/stdcxx/
ってどんなもん？みんな使ってる？便利？

0978デフォルトの名無しさん

2006/03/27(月) 15:16:06

まず何でここで訊くのかが解らん

0979デフォルトの名無しさん

2006/03/27(月) 15:19:05

ここが一番適切なような気が駿

0980デフォルトの名無しさん

2006/03/27(月) 16:32:29

>>977
中身はほとんどRogueWaveのままだから、STLportよりは落ちる。
それにslistやhash_mapなど、SGI STL特有の便利なコンテナが無い。
Dinkumwareでさえ採用しているというのに。

0981デフォルトの名無しさん

2006/03/27(月) 16:56:51

ソースの読みやすさは、Apache C++ Standard Library が一番だと思うよ

0982デフォルトの名無しさん

2006/03/27(月) 18:55:16

ああ、それは俺もそう思う。使っちゃいないが。

0983デフォルトの名無しさん

2006/03/28(火) 16:57:58

次ぎスレは
C++相談室に合流ってことで
なしということでよろしく

0984デフォルトの名無しさん

2006/03/28(火) 17:16:10

合流かぁ・・・・C++相談室は時々荒れるからなぁ

0985デフォルトの名無しさん

2006/03/28(火) 18:46:40

え～このままでいいんじゃないの？
無くていいならそのうち落ちるって。

0986デフォルトの名無しさん

2006/03/28(火) 18:49:53

C++ｽﾚの人口から見て、次ｽﾚを建てる必要性はないと思う

0987デフォルトの名無しさん

2006/03/28(火) 19:49:04

毎度要らないという結論になるのに誰かが立ててしまう。
そんなこんなで4スレ目まで来てしまった。

いい加減このスレは終わらせようよ。

0988デフォルトの名無しさん

2006/03/28(火) 19:50:48

まだだ・・・
まだ終わらんよ・・・

0989デフォルトの名無しさん

2006/03/28(火) 20:24:30

>987
一部の人間が勝手に結論してるだけに見えるんだが気のせいかね

0990デフォルトの名無しさん

2006/03/28(火) 20:52:09

[合流するべき理由]
STLは規格により明確にC++である

>>988,989
理由は

0991デフォルトの名無しさん

2006/03/28(火) 21:34:22

またはじまったんかｗ

0992デフォルトの名無しさん

2006/03/28(火) 22:02:52

次ぎスレ
http://pc8.2ch.net/test/read.cgi/tech/1142423595/

0993デフォルトの名無しさん

2006/03/28(火) 22:18:00

バーロ、まだはじまっちゃいねーよ

0994デフォルトの名無しさん

2006/03/29(水) 00:32:51

>>992
GJ!
でも一瞬あせったよ、また立てたのかとね。

0995デフォルトの名無しさん

2006/03/29(水) 05:46:34

後で次スレ立てておくよ。

0996デフォルトの名無しさん

2006/03/29(水) 05:55:55

次スレ
【注意】STLの落とし穴【危険】
http://pc8.2ch.net/test/read.cgi/tech/1104092624/

0997デフォルトの名無しさん

2006/03/29(水) 08:53:54

>>998-100
もし立てたいと思うのなら、
その前に必ず>>992か>>996のスレで提案すること。

>>983-を見れば少なからず次スレを要らないと思っている奴が居るのがわかるはず。

0998デフォルトの名無しさん

2006/03/29(水) 08:57:34

>>996を再利用で、それを使い切ってから次スレでいいだろ。

0999デフォルトの名無しさん

2006/03/29(水) 10:59:22

ああ、それがこのスレの総意だな。

1000デフォルトの名無しさん

2006/03/29(水) 12:15:07

1000なら、STLの呼称廃止

1001１００１

Over 1000Thread

このスレッドは１０００を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。

レス数が1000を超えています。これ以上書き込みはできません。