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

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++標準ライブラリだ。
範囲が明確に決まってるかのように、含まれるだの含まれないだの言うのは時代遅れだぞ。

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

15 ：デフォルトの名無しさん：2005/10/31(月) 08:42:05

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

16 ：デフォルトの名無しさん：2005/10/31(月) 14:17:29

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

17 ：デフォルトの名無しさん：2005/10/31(月) 15:37:05

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

18 ：デフォルトの名無しさん：2005/10/31(月) 16:31:12

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

19 ：デフォルトの名無しさん：2005/10/31(月) 16:41:03

厨w

20 ：デフォルトの名無しさん：2005/10/31(月) 17:02:46

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

21 ：デフォルトの名無しさん：2005/10/31(月) 17:15:23

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

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

22 ：デフォルトの名無しさん：2005/10/31(月) 19:37:16

>>18
巣に帰れ

23 ：デフォルトの名無しさん：2005/10/31(月) 22:03:55

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

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

24 ：デフォルトの名無しさん：2005/10/31(月) 23:08:12

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

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

25 ：デフォルトの名無しさん：2005/10/31(月) 23:14:38

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

26 ：デフォルトの名無しさん：2005/10/31(月) 23:55:14

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

27 ：デフォルトの名無しさん：2005/11/01(火) 00:00:52

>>26 concept_check

28 ：デフォルトの名無しさん：2005/11/01(火) 00:02:43

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

29 ：デフォルトの名無しさん：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
        ]

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

30 ：デフォルトの名無しさん：2005/11/02(水) 23:01:52

listをdequeにしたら?

31 ：デフォルトの名無しさん：2005/11/02(水) 23:04:19

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

32 ：デフォルトの名無しさん：2005/11/02(水) 23:04:33

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

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

33 ：デフォルトの名無しさん：2005/11/02(水) 23:20:53

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

34 ：デフォルトの名無しさん：2005/11/02(水) 23:24:11

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

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

35 ：デフォルトの名無しさん：2005/11/02(水) 23:36:14

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

36 ：デフォルトの名無しさん：2005/11/03(木) 00:09:45

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

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

37 ：36：2005/11/03(木) 00:21:00

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

38 ：デフォルトの名無しさん：2005/11/03(木) 00:26:10

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

39 ：デフォルトの名無しさん：2005/11/03(木) 01:00:26

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

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

40 ：デフォルトの名無しさん：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で１件ずつ回してコピーするしかないのでしょうか?

41 ：デフォルトの名無しさん：2005/11/03(木) 02:47:45

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

42 ：デフォルトの名無しさん：2005/11/03(木) 02:56:51

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

43 ：デフォルトの名無しさん：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の区別はできていると思っています。

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

45 ：29：2005/11/03(木) 04:46:26

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

46 ：デフォルトの名無しさん：2005/11/03(木) 07:29:52

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

だって、ププッwwwwwwwwwww

47 ：デフォルトの名無しさん：2005/11/03(木) 13:43:21

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

48 ：デフォルトの名無しさん：2005/11/03(木) 15:12:47

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

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

49 ：デフォルトの名無しさん：2005/11/03(木) 15:28:09

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

50 ：デフォルトの名無しさん：2005/11/03(木) 15:31:39

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

51 ：デフォルトの名無しさん：2005/11/03(木) 16:19:13

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

52 ：sage：2005/11/03(木) 17:09:42

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

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

53 ：デフォルトの名無しさん：2005/11/03(木) 17:37:53

54 ：デフォルトの名無しさん：2005/11/03(木) 18:40:12

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

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

55 ：デフォルトの名無しさん：2005/11/03(木) 18:42:02

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

56 ：デフォルトの名無しさん：2005/11/03(木) 21:58:04

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

57 ：デフォルトの名無しさん：2005/11/03(木) 23:03:55

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

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

58 ：デフォルトの名無しさん：2005/11/04(金) 00:20:38

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

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

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

59 ：デフォルトの名無しさん：2005/11/04(金) 00:32:18

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

60 ：デフォルトの名無しさん：2005/11/04(金) 01:14:19

for(;;)
while(1)

くらべてみよー

61 ：デフォルトの名無しさん：2005/11/04(金) 01:38:58

漢なら while (true) だ！

62 ：デフォルトの名無しさん：2005/11/04(金) 01:42:07

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

63 ：デフォルトの名無しさん：2005/11/04(金) 01:51:43

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

64 ：デフォルトの名無しさん：2005/11/04(金) 02:57:26

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

65 ：39：2005/11/04(金) 03:43:52

>58
えぇー

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

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

66 ：デフォルトの名無しさん：2005/11/04(金) 04:31:34

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

67 ：>>56=59=63：2005/11/04(金) 04:43:10

>>66
んなこたーない。

68 ：デフォルトの名無しさん：2005/11/04(金) 11:24:55

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

69 ：デフォルトの名無しさん：2005/11/04(金) 12:05:15

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

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

70 ：デフォルトの名無しさん：2005/11/04(金) 12:47:55

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

71 ：デフォルトの名無しさん：2005/11/04(金) 12:50:21

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

72 ：デフォルトの名無しさん：2005/11/04(金) 12:58:24

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

73 ：デフォルトの名無しさん：2005/11/04(金) 13:12:48

>>72
負け犬の遠吠え

74 ：デフォルトの名無しさん：2005/11/04(金) 16:29:00

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

75 ：デフォルトの名無しさん：2005/11/04(金) 16:57:18

並列だろ

76 ：デフォルトの名無しさん：2005/11/04(金) 18:44:04

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

77 ：デフォルトの名無しさん：2005/11/04(金) 18:56:24

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

78 ：デフォルトの名無しさん：2005/11/04(金) 20:47:17

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

79 ：デフォルトの名無しさん：2005/11/04(金) 21:11:06

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

80 ：デフォルトの名無しさん：2005/11/04(金) 21:15:16

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

81 ：デフォルトの名無しさん：2005/11/04(金) 23:25:57

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

82 ：39：2005/11/04(金) 23:59:36

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

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

83 ：デフォルトの名無しさん：2005/11/06(日) 16:56:25

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

84 ：デフォルトの名無しさん：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

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

85 ：デフォルトの名無しさん：2005/11/08(火) 03:39:19

祈る。

86 ：デフォルトの名無しさん：2005/11/08(火) 05:31:28

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

87 ：デフォルトの名無しさん：2005/11/08(火) 08:35:44

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

88 ：デフォルトの名無しさん：2005/11/08(火) 15:20:36

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

89 ：デフォルトの名無しさん：2005/11/08(火) 21:54:42

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

90 ：デフォルトの名無しさん：2005/11/08(火) 22:25:40

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

91 ：デフォルトの名無しさん：2005/11/09(水) 01:02:23

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

92 ：デフォルトの名無しさん：2005/11/09(水) 12:09:00

いるよバカ

93 ：デフォルトの名無しさん：2005/11/09(水) 13:49:09

>>92
>>90

94 ：デフォルトの名無しさん：2005/11/09(水) 21:08:12

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

95 ：デフォルトの名無しさん：2005/11/10(木) 00:04:19

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

96 ：デフォルトの名無しさん：2005/11/10(木) 00:11:19

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

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

97 ：デフォルトの名無しさん：2005/11/10(木) 00:13:01

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

98 ：デフォルトの名無しさん：2005/11/10(木) 00:23:19

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

99 ：デフォルトの名無しさん：2005/11/10(木) 00:35:02

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

100 ：デフォルトの名無しさん：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で....の部分を共有すればいい

101 ：デフォルトの名無しさん：2005/11/10(木) 01:12:01

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

102 ：デフォルトの名無しさん：2005/11/10(木) 02:18:58

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

103 ：98：2005/11/10(木) 02:31:38

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

104 ：デフォルトの名無しさん：2005/11/10(木) 17:22:48

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

105 ：デフォルトの名無しさん：2005/11/10(木) 17:25:16

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

106 ：デフォルトの名無しさん：2005/11/10(木) 17:28:55

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

107 ：デフォルトの名無しさん：2005/11/10(木) 19:30:44

ｷﾓｲ仕様ですね

108 ：デフォルトの名無しさん：2005/11/10(木) 19:43:22

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

109 ：デフォルトの名無しさん：2005/11/10(木) 19:48:28

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

110 ：デフォルトの名無しさん：2005/11/10(木) 20:00:16

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

111 ：デフォルトの名無しさん：2005/11/10(木) 20:02:51

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

112 ：デフォルトの名無しさん：2005/11/10(木) 20:08:07

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

113 ：デフォルトの名無しさん：2005/11/10(木) 20:28:28

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

114 ：デフォルトの名無しさん：2005/11/10(木) 20:39:13

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

115 ：デフォルトの名無しさん：2005/11/11(金) 01:52:17

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

116 ：デフォルトの名無しさん：2005/11/11(金) 10:05:46

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

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

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

117 ：デフォルトの名無しさん：2005/11/11(金) 12:01:15

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

118 ：デフォルトの名無しさん：2005/11/11(金) 12:09:05

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

119 ：デフォルトの名無しさん：2005/11/11(金) 12:51:37

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

120 ：デフォルトの名無しさん：2005/11/11(金) 12:56:32

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

121 ：119=120：2005/11/11(金) 13:00:38

URL間違ってたｽﾏﾇorz

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

122 ：デフォルトの名無しさん：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> のみを
受け付けるようにするにはどうしたらいいのでしょうか？

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

123 ：デフォルトの名無しさん：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;
+}

124 ：デフォルトの名無しさん：2005/11/11(金) 13:58:15

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

125 ：デフォルトの名無しさん：2005/11/12(土) 09:36:14

http://sourceforge.net/projects/stlport

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

126 ：デフォルトの名無しさん：2005/11/12(土) 09:55:16

>>81でがいしゅつ

127 ：デフォルトの名無しさん：2005/11/12(土) 10:00:04

だヵら何？

128 ：デフォルトの名無しさん：2005/11/12(土) 14:15:00

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

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

129 ：デフォルトの名無しさん：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);
}

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

130 ：デフォルトの名無しさん：2005/11/12(土) 16:24:16

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

131 ：デフォルトの名無しさん：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をインクリメントしてもしなくても結果が変わらないのですが
どうなっているんでしょうか？

132 ：デフォルトの名無しさん：2005/11/12(土) 18:13:13

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

133 ：デフォルトの名無しさん：2005/11/12(土) 19:58:59

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

134 ：デフォルトの名無しさん：2005/11/12(土) 20:04:14

>133
std::for_each

135 ：デフォルトの名無しさん：2005/11/12(土) 20:04:41

>>133
copy+ostream_iterator

136 ：133：2005/11/12(土) 20:05:31

さっそくどうも

137 ：デフォルトの名無しさん：2005/11/12(土) 20:16:13

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

138 ：デフォルトの名無しさん：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の場合指定できないということでいいのでしょうか？

139 ：デフォルトの名無しさん：2005/11/12(土) 21:02:51

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

140 ：デフォルトの名無しさん：2005/11/12(土) 21:17:51

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

141 ：デフォルトの名無しさん：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を使用してはならない。

142 ：デフォルトの名無しさん：2005/11/13(日) 15:59:15

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

143 ：デフォルトの名無しさん：2005/11/13(日) 16:00:10

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

144 ：デフォルトの名無しさん：2005/11/13(日) 16:02:26

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

145 ：デフォルトの名無しさん：2005/11/13(日) 18:50:32

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

146 ：デフォルトの名無しさん：2005/11/13(日) 20:24:57

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

147 ：デフォルトの名無しさん：2005/11/13(日) 20:30:20

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

148 ：デフォルトの名無しさん：2005/11/13(日) 20:38:04

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

149 ：デフォルトの名無しさん：2005/11/13(日) 20:39:17

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

150 ：デフォルトの名無しさん：2005/11/13(日) 20:45:21

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

151 ：デフォルトの名無しさん：2005/11/13(日) 20:48:41

じゃあ作ってくれよ

152 ：デフォルトの名無しさん：2005/11/13(日) 20:56:50

>>150
stringはSTLじゃない。

153 ：デフォルトの名無しさん：2005/11/13(日) 21:00:41

なんで？

154 ：デフォルトの名無しさん：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はユーザー定義コピーコンストラクタ、
デストラクタ、コピー代入を持てないから一緒にするのはまずい。

155 ：デフォルトの名無しさん：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がある。

156 ：デフォルトの名無しさん：2005/11/13(日) 21:36:20

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

157 ：デフォルトの名無しさん：2005/11/13(日) 21:44:00

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

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

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

158 ：デフォルトの名無しさん：2005/11/13(日) 21:45:09

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

159 ：デフォルトの名無しさん：2005/11/13(日) 21:49:02

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

160 ：デフォルトの名無しさん：2005/11/13(日) 21:54:27

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

161 ：デフォルトの名無しさん：2005/11/13(日) 22:13:21

>>152-160　>>14

162 ：デフォルトの名無しさん：2005/11/13(日) 22:17:01

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

163 ：デフォルトの名無しさん：2005/11/13(日) 22:21:13

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

164 ：デフォルトの名無しさん：2005/11/13(日) 22:27:20

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

165 ：デフォルトの名無しさん：2005/11/13(日) 22:45:05

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

166 ：デフォルトの名無しさん：2005/11/13(日) 22:51:15

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

167 ：デフォルトの名無しさん：2005/11/13(日) 23:04:39

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

168 ：デフォルトの名無しさん：2005/11/13(日) 23:09:28

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

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

169 ：デフォルトの名無しさん：2005/11/13(日) 23:13:04

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

170 ：デフォルトの名無しさん：2005/11/13(日) 23:17:53

stringにもiteratorあるよ？

171 ：デフォルトの名無しさん：2005/11/13(日) 23:18:43

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

172 ：デフォルトの名無しさん：2005/11/13(日) 23:18:47

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

173 ：デフォルトの名無しさん：2005/11/13(日) 23:19:02

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

174 ：デフォルトの名無しさん：2005/11/13(日) 23:23:15

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

175 ：デフォルトの名無しさん：2005/11/13(日) 23:27:54

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

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

176 ：デフォルトの名無しさん：2005/11/13(日) 23:41:07

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

177 ：デフォルトの名無しさん：2005/11/13(日) 23:42:47

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

178 ：デフォルトの名無しさん：2005/11/13(日) 23:43:26

×>>176
○>>173

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

179 ：デフォルトの名無しさん：2005/11/13(日) 23:44:51

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

180 ：デフォルトの名無しさん：2005/11/13(日) 23:46:57

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

181 ：デフォルトの名無しさん：2005/11/13(日) 23:47:09

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

182 ：デフォルトの名無しさん：2005/11/13(日) 23:47:18

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

183 ：デフォルトの名無しさん：2005/11/13(日) 23:47:41

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

184 ：デフォルトの名無しさん：2005/11/14(月) 00:05:28

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

185 ：175：2005/11/14(月) 00:10:10

いや、おかまいなく。

186 ：デフォルトの名無しさん：2005/11/14(月) 00:18:20

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

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

187 ：デフォルトの名無しさん：2005/11/14(月) 00:55:45

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

188 ：デフォルトの名無しさん：2005/11/14(月) 01:04:30

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

189 ：デフォルトの名無しさん：2005/11/14(月) 01:10:02

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

190 ：デフォルトの名無しさん：2005/11/14(月) 02:40:41

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

191 ：デフォルトの名無しさん：2005/11/14(月) 03:39:45

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

192 ：デフォルトの名無しさん：2005/11/14(月) 03:45:27

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

193 ：デフォルトの名無しさん：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)
みたいなことができればうれしいんだが。

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

194 ：デフォルトの名無しさん：2005/11/14(月) 04:03:04

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

195 ：デフォルトの名無しさん：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;

196 ：デフォルトの名無しさん：2005/11/14(月) 04:27:04

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

197 ：デフォルトの名無しさん：2005/11/14(月) 04:33:03

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

198 ：デフォルトの名無しさん：2005/11/14(月) 04:35:44

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

199 ：デフォルトの名無しさん：2005/11/14(月) 04:37:43

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

200 ：デフォルトの名無しさん：2005/11/14(月) 04:39:40

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

201 ：デフォルトの名無しさん：2005/11/14(月) 04:54:57

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

202 ：デフォルトの名無しさん：2005/11/14(月) 05:16:26

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

203 ：デフォルトの名無しさん：2005/11/14(月) 05:20:57

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

204 ：デフォルトの名無しさん：2005/11/14(月) 05:22:59

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

205 ：デフォルトの名無しさん：2005/11/14(月) 07:31:47

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

206 ：デフォルトの名無しさん：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++のソースを

207 ：デフォルトの名無しさん：2005/11/14(月) 19:32:17

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

>>203で正解

208 ：デフォルトの名無しさん：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に書いてあったはず。
今手元になくて、大まかにしか思い出せないけど。

209 ：デフォルトの名無しさん：2005/11/14(月) 21:32:06

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

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

210 ：デフォルトの名無しさん：2005/11/14(月) 21:35:36

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

211 ：デフォルトの名無しさん：2005/11/15(火) 20:05:54

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

212 ：デフォルトの名無しさん：2005/11/15(火) 20:07:18

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

213 ：デフォルトの名無しさん：2005/11/15(火) 20:37:00

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

214 ：デフォルトの名無しさん：2005/11/15(火) 20:59:09

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

output = 禿禿禿

215 ：デフォルトの名無しさん：2005/11/15(火) 21:04:36

ここ死んでるね。

216 ：デフォルトの名無しさん：2005/11/15(火) 21:06:02

>>214
コンパイルエラー

217 ：デフォルトの名無しさん：2005/11/15(火) 21:16:16

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

218 ：デフォルトの名無しさん：2005/11/15(火) 21:29:49

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

219 ：デフォルトの名無しさん：2005/11/15(火) 21:33:56

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

220 ：デフォルトの名無しさん：2005/11/15(火) 21:36:09

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

221 ：デフォルトの名無しさん：2005/11/15(火) 21:41:11

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

222 ：デフォルトの名無しさん：2005/11/15(火) 21:41:33

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

223 ：デフォルトの名無しさん：2005/11/15(火) 21:46:02

>>220
偽。

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

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

224 ：デフォルトの名無しさん：2005/11/15(火) 21:47:55

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

225 ：デフォルトの名無しさん：2005/11/15(火) 21:49:13

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

>>219
んな無体な。

>>220
詳しく。

226 ：デフォルトの名無しさん：2005/11/15(火) 21:51:53

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

227 ：デフォルトの名無しさん：2005/11/15(火) 22:05:41

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

228 ：デフォルトの名無しさん：2005/11/15(火) 22:08:35

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

229 ：224：2005/11/15(火) 22:22:54

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

230 ：デフォルトの名無しさん：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なので、地雷があったりするのかもしれんが。

231 ：デフォルトの名無しさん：2005/11/16(水) 00:43:06

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

232 ：デフォルトの名無しさん：2005/11/16(水) 01:19:30

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

233 ：デフォルトの名無しさん：2005/11/16(水) 01:23:44

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

234 ：デフォルトの名無しさん：2005/11/16(水) 04:30:42

下手の考え休むに似たり

235 ：デフォルトの名無しさん：2005/11/16(水) 06:59:04

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

236 ：デフォルトの名無しさん：2005/11/16(水) 19:10:29

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

237 ：デフォルトの名無しさん：2005/11/16(水) 20:08:17

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

238 ：デフォルトの名無しさん：2005/11/16(水) 20:57:45

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

239 ：デフォルトの名無しさん：2005/11/16(水) 21:30:49

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

240 ：デフォルトの名無しさん：2005/11/16(水) 21:37:14

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

241 ：デフォルトの名無しさん：2005/11/16(水) 23:26:45

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

242 ：デフォルトの名無しさん：2005/11/16(水) 23:34:35

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

243 ：デフォルトの名無しさん：2005/11/17(木) 02:39:52

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

244 ：デフォルトの名無しさん：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.

245 ：デフォルトの名無しさん：2005/11/17(木) 20:50:43

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

246 ：デフォルトの名無しさん：2005/11/17(木) 20:55:06

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

247 ：デフォルトの名無しさん：2005/11/17(木) 20:55:41

お断りします

248 ：デフォルトの名無しさん：2005/11/17(木) 20:56:58

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

249 ：デフォルトの名無しさん：2005/11/17(木) 20:57:13

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

250 ：デフォルトの名無しさん：2005/11/17(木) 21:04:00

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

251 ：デフォルトの名無しさん：2005/11/17(木) 21:07:25

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

252 ：デフォルトの名無しさん：2005/11/18(金) 00:31:36

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

253 ：デフォルトの名無しさん：2005/11/18(金) 01:24:47

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

254 ：デフォルトの名無しさん：2005/11/18(金) 07:50:40

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

255 ：デフォルトの名無しさん：2005/11/18(金) 09:30:07

要するに馬鹿と。

256 ：デフォルトの名無しさん：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になっていくといいんだけど…

257 ：デフォルトの名無しさん：2005/11/18(金) 10:05:50

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

258 ：デフォルトの名無しさん：2005/11/18(金) 15:24:37

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

259 ：デフォルトの名無しさん：2005/11/18(金) 17:31:41

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

260 ：デフォルトの名無しさん：2005/11/18(金) 18:10:53

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

261 ：デフォルトの名無しさん：2005/11/18(金) 18:38:33

うすらとんかち

262 ：デフォルトの名無しさん：2005/11/18(金) 19:42:33

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

263 ：デフォルトの名無しさん：2005/11/18(金) 19:57:45

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

264 ：デフォルトの名無しさん：2005/11/18(金) 21:51:31

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

265 ：デフォルトの名無しさん：2005/11/18(金) 21:57:47

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

266 ：デフォルトの名無しさん：2005/11/19(土) 01:32:10

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

267 ：デフォルトの名無しさん：2005/11/19(土) 09:12:26

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

268 ：デフォルトの名無しさん：2005/11/19(土) 11:41:11

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

269 ：デフォルトの名無しさん：2005/11/19(土) 12:19:53

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

270 ：デフォルトの名無しさん：2005/11/19(土) 12:30:44

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

271 ：デフォルトの名無しさん：2005/11/19(土) 12:33:14

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

272 ：デフォルトの名無しさん：2005/11/19(土) 13:04:21

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

273 ：デフォルトの名無しさん：2005/11/19(土) 13:06:36

>>268
C使っときなさい。

274 ：デフォルトの名無しさん：2005/11/19(土) 13:13:13

まぁ、stlのvectorは無駄が多いのは周知の事実なわけだがな

275 ：デフォルトの名無しさん：2005/11/19(土) 13:23:22

無駄が多いのはおまいの設計が悪いだけ

276 ：デフォルトの名無しさん：2005/11/19(土) 13:35:05

低能はvbでも使っとけ

277 ：デフォルトの名無しさん：2005/11/19(土) 13:45:37

vectorを使ったとしても、プログラマはリソースの明示削除手続きから解放されるだけであり、
無駄が出ないように工夫する義務はプログラマにある。

278 ：デフォルトの名無しさん：2005/11/19(土) 13:55:40

まだvb馬鹿にしてる奴がいるのか、さすがstl厨

279 ：デフォルトの名無しさん：2005/11/19(土) 14:10:26

VBは所詮VB

280 ：デフォルトの名無しさん：2005/11/19(土) 16:07:53

STLとSTOってどっちがつおいの？

281 ：デフォルトの名無しさん：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;
};

282 ：デフォルトの名無しさん：2005/11/19(土) 16:18:04

>>280
答えはキミの中にあります

283 ：デフォルトの名無しさん：2005/11/19(土) 17:17:07

コピーコンストラクタがいやなら shared_ptr 使うか、
vector<hoge* > ってすべきだな。
あとインスタンス化のたびに競合おこしたりとかいうのもあるし、
初期化~終了までファイルロックする類のクラス作ったりすると。

284 ：デフォルトの名無しさん：2005/11/19(土) 19:30:38

boost::ptr_vectorでもよい。

285 ：デフォルトの名無しさん：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みたいな形で、スコープを抜けるときに呼び出す関数を
積んでおくことができると理想なのですが

286 ：デフォルトの名無しさん：2005/11/21(月) 17:56:11

boost::move_ptrやshared_ptrみたいに削除子を指定するのはﾀﾞﾒ？

287 ：デフォルトの名無しさん：2005/11/21(月) 18:10:35

>>286
サンキュー！そのものズバリが見つかったーよ
http://boost.cppll.jp/HEAD/libs/smart_ptr/sp_techniques.html#on_block_exit

以前、どこかのWebでスコープを抜けるときにコードを実行できるようなことを読んだ覚えがあって、
「スコープ終了処理指定」とかいろいろぐぐっても、なかなか見つけられなかったけど、
削除子で検索したら一発でした

288 ：デフォルトの名無しさん：2005/11/21(月) 18:59:33

その手のテクニックなら ScopeGuard も候補になるかな．

289 ：デフォルトの名無しさん：2005/11/21(月) 21:01:19

>>285
FinallyCloseHandle hFile = CreateFile(...);ではだめなのか？

290 ：デフォルトの名無しさん：2005/11/22(火) 00:49:20

>>288
さんくす！ScopeGuardも調べてみた

http://www.kmonos.net/alang/klx/
ここに実装例があったけど、ようは終了処理の関数と引数の参照を入れとくのね
勉強になります

>>289
あ、newじゃなくても良いですね
287に書いていますが、以前、どこかのwebでこの方法を見たとき
おぼろげにテンプレートを使って実現していたような覚えがあったので、
こんな風な書き方になってました

291 ：デフォルトの名無しさん：2005/11/22(火) 12:22:58

（数値地図から）200×200の数の行列？を読み込まし、iと、i＋1と、j、　j＋１で四点をとり、その４点の一番大きい値から小さい方へいくプログラムがつくれません
参照できるサイトありますか？わかる人いますか？ヒントください＞＜
もう三ヶ月悩んでます、助けて
馬鹿な為ほんとプログラムわからないんです

292 ：デフォルトの名無しさん：2005/11/22(火) 12:31:21

>>291
マルチ死ね

293 ：デフォルトの名無しさん：2005/11/22(火) 20:16:26

指定した条件に合致したインスタンスを指すイテレータを返す関数を作るときは
その返却値となるイテレータにNULLを使っていいんでしょうか？

294 ：デフォルトの名無しさん：2005/11/22(火) 20:25:50

>>293
つ[std::find_if()]

295 ：デフォルトの名無しさん：2005/11/22(火) 20:29:51

普通はendが返るんじゃね？

296 ：デフォルトの名無しさん：2005/11/22(火) 20:30:05

>>293
NULLはポインタにしかない。

297 ：デフォルトの名無しさん：2005/11/22(火) 21:53:50

>>294
うあ、そんな便利なものが…。
使ってみます。ありがとうございました。

>>295
>>296
なるほど。
std::find_if()してきて、それがend()かでエラー判定するんですね。
ありがとうございました。

298 ：294：2005/11/22(火) 23:17:49

<algorithm>や<numeric>はその手のロジックの宝庫だからね。
この辺に慣れるとちょっとした集計なんかがループを書かずにできる。

299 ：デフォルトの名無しさん：2005/11/24(木) 00:24:57

ちと古いネタにレスします
C++は一週間ぐらい前に始めたばかりなのでよくわかってないかもしれないけど、その辺はフォローよろしくです。
>>267
FILE * からfstreamを生成する場合、FILE*のクローズの責任（というよりFILE*の所有者）は誰になるのでしょう？
古いVCだとFILE*からfstream作った時は明示的にclose()呼ぶようにとか書いてあったような気がするんだけど、これじゃあまり使い道が・・・
自分で作ったfstream(Widefilename版)だとFILE *から作ってもデストラクタでクローズしてしまいます。
fstream(_wfopen(...))みたいな使い方を想定してます。

300 ：267：2005/11/24(木) 07:48:28

>>299
すまん。
たまたま耳にしただけであって，そこまで詳しいところは読んでいない。
でも俺が作るとしたら後者の方式（fstreamが所有権を持ちデストラクタでクローズする）にするな。

301 ：デフォルトの名無しさん：2005/11/24(木) 08:35:29

gcc拡張のstdio_filebuf, stdio_sync_filebufは、closeなし。
cin, cout, cerrのfilebuf先は、main()出た後のstdin, stdout, stderrのclose任せ。

302 ：デフォルトの名無しさん：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というテキストファイルが出来た。
なぜだろうね？

303 ：デフォルトの名無しさん：2005/11/24(木) 18:46:50

>>302
ios::binaryってフラグは、CR+LFのようなOS依存コードをcookedではなくて
rawで書け、って意味。

std::ostream_operator<int>←って指定してるじゃん。これじゃあ　<< で
出力したのと全く同じ。

バイナリで書きたければwrite()を使いなせえ。

304 ：デフォルトの名無しさん：2005/11/24(木) 18:50:17

あ、put()でもいいよ。

305 ：デフォルトの名無しさん：2005/11/24(木) 18:53:43

どうしてもアルゴリズムでバイナリを出力したければ、ユーザー定義の
バイナリ出力反復子を作るか、<<を多重定義し、バイナリ出力
専用のクラスを作り、for_eachで渡すか、だなあ。

306 ：302：2005/11/24(木) 19:23:10

詳しくありがとう。

307 ：デフォルトの名無しさん：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));
}

308 ：デフォルトの名無しさん：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));
}

309 ：デフォルトの名無しさん：2005/11/25(金) 07:26:24

私は、fstream系をデバッグトレース出力にしか使わないなぁ。
とりあえずトレースしたいときは、色んな構造体に対して<<演算子がオーバライドされてると、便利だ。
でも、一般のファイルを読み書きする時は専らcstdioを使う。
皆さんはどう？

310 ：デフォルトの名無しさん：2005/11/25(金) 08:30:44

cstdio を使う理由なんて、互換性以外に何があるんだ。
使いわけたりしねぇよ…。

311 ：デフォルトの名無しさん：2005/11/25(金) 09:14:02

fstreamって何でこうもまあ低速なの？

312 ：デフォルトの名無しさん：2005/11/25(金) 09:58:43

>>310
iostream・fstreamはファイルサイズが無駄に大きくなる。
ちょっとしたコンソールアプリには、iostreamは大げさすぎる実装だ。

313 ：デフォルトの名無しさん：2005/11/25(金) 10:31:01

今時数十KB増えるくらい蚊に刺されたようなもんじゃん。

314 ：デフォルトの名無しさん：2005/11/25(金) 10:55:12

>>312
それなら C 使えば？

315 ：デフォルトの名無しさん：2005/11/25(金) 12:38:37

また莫迦が STL ｽﾚで stream の話してるよ…

316 ：デフォルトの名無しさん：2005/11/25(金) 12:45:01

>>315
過去ログと空気は読む物ってことだわな

317 ：デフォルトの名無しさん：2005/11/25(金) 12:55:52

まぁSTLという言葉の定義に持ち込む>>315のほうが馬鹿だけどね。

318 ：デフォルトの名無しさん：2005/11/25(金) 13:07:39

>>307-308
便乗で申し訳ないが、basic_ostream< wchar_t > への対応版も希望

319 ：デフォルトの名無しさん：2005/11/26(土) 10:46:08

http://dl.njfiw.gov.cn/books/C/

320 ：315：2005/11/29(火) 16:18:06

>>316-317
初代ｽﾚから居るが。
時々思い出したように粘着しているだけだ。

321 ：デフォルトの名無しさん：2005/11/29(火) 19:07:08

>>320
？　お前はまさにそこをイジられてるんだが、何をわざわざ説明してるんだ？

322 ：デフォルトの名無しさん：2005/11/29(火) 22:18:12

>>318
亀レスだが、コンストラクタを変換関数の代わりに使っているので、
OutBin(wchar_t)と、intとwchar_tを受け取った場合のフラグでも
増設して、operator<<の動作を切り替えればいいやん。

323 ：デフォルトの名無しさん：2005/11/30(水) 19:03:24

vector とかよりももっと複雑な、
一般のグラフ構造のリンク関係を持ったアイテム集合を
うまく扱うためのコンテナクラスライブラリってありませんか？

324 ：デフォルトの名無しさん：2005/11/30(水) 19:03:55

コンテナクラスライブラリってあんまり使わないみたいなんで
テンプレートクラスライブラリって言い換えます。

325 ：デフォルトの名無しさん：2005/11/30(水) 19:09:37

クラステンプレートであってテンプレートクラスではない。
STLには存在しないがboost::graphというものは存在する。

326 ：デフォルトの名無しさん：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();
}
};

327 ：デフォルトの名無しさん：2005/11/30(水) 22:00:53

>>326
typename std::map<KEY, VAL>::iterator...

328 ：デフォルトの名無しさん：2005/11/30(水) 22:09:59

>>327
ありがとうございます。
どうしてtypenameをつけるとコンパイル通るんですか？

329 ：デフォルトの名無しさん：2005/11/30(水) 22:20:14

>>328
http://www.fides.dti.ne.jp/~oka-t/cpplab-template-4.html

330 ：デフォルトの名無しさん：2005/11/30(水) 23:11:44

>>329
停滞してるな

331 ：デフォルトの名無しさん：2005/11/30(水) 23:12:31

逃した魚は大きいぞ

332 ：デフォルトの名無しさん：2005/11/30(水) 23:59:56

>329
そこを読んで思ったんだが、
typedefの時にtypenameを書かないと通らないコンパイラってあるの？
typedefの引数？は型名に決まっているんだから必要ないように思えるだが。

333 ：デフォルトの名無しさん：2005/12/01(木) 00:14:14

>>332
そうやって勝手に標準規格をねじ曲げたのがVC7.1だろう。
VC7.1だけ使ってると、typenameが必要だって事が学習しにくい。

334 ：デフォルトの名無しさん：2005/12/02(金) 01:38:49

7.1はわりとtypenameについて忠実じゃなかったっけ？
6が酷かったのは覚えているが。

335 ：デフォルトの名無しさん：2005/12/02(金) 02:07:50

いや全然

336 ：デフォルトの名無しさん：2005/12/02(金) 02:12:05

そうか気のせいだったか。

337 ：デフォルトの名無しさん：2005/12/04(日) 20:17:12

>>333
typenameなんていらないじゃん。未熟なコンパイラを救うためだけのもんだろ。

338 ：デフォルトの名無しさん：2005/12/04(日) 20:21:40

>>337
typename は未熟な C++ 言語仕様を救うためのもんだよ。
コンパイラベンダがどうこうするもんじゃない。

339 ：デフォルトの名無しさん：2005/12/04(日) 20:30:15

即ち禿がC++に毛を生やす努力をすればtypenameはいらない。

340 ：デフォルトの名無しさん：2005/12/04(日) 22:16:07

お前らいつもいつも禿禿って…いい加減にしろよ？

341 ：デフォルトの名無しさん：2005/12/04(日) 22:42:49

あ、びょーん先生こんにちは。
今日も落ち武者ヘアー似合ってますよ。

342 ：デフォルトの名無しさん：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と出ます。

343 ：デフォルトの名無しさん：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().

344 ：デフォルトの名無しさん：2005/12/05(月) 22:55:11

事前条件として !ivec.empty() に注意ね

345 ：デフォルトの名無しさん：2005/12/07(水) 19:20:03

Boostを使わずにSTLのみで、スマートにcsvファイルを読み込めたりする？

346 ：デフォルトの名無しさん：2005/12/07(水) 19:27:03

>>345
RFC4180を見る限り、スマートにってのは無理みたいだね。

347 ：デフォルトの名無しさん：2005/12/07(水) 19:33:15

>>346 そんな RFC があったのか・・・

348 ：デフォルトの名無しさん：2005/12/07(水) 20:00:03

たしか超最近出来たRFCだろそれ

349 ：デフォルトの名無しさん：2005/12/07(水) 20:56:06

>>346
そんなのあったのか

つかC/C++でCSVファイルを読むのはクソだるいんだよな
書くのは楽なんだが。

350 ：デフォルトの名無しさん：2005/12/07(水) 21:18:00

Java だと楽なの？CSVファイル読むの。
いや、俺、Javaほとんど使ったことないから。

351 ：デフォルトの名無しさん：2005/12/07(水) 21:43:47

CSVつってもExcel仕様のCSVとか色々あるんじゃないの。
引用符の処理や複数行のセルとかどうすんだとか。

352 ：346：2005/12/07(水) 22:26:19

>>347-349
今年10月にできてる

353 ：デフォルトの名無しさん：2005/12/08(木) 00:43:10

ttp://www005.upp.so-net.ne.jp/episteme/html/stlprog/_02.html#making_iterator
ここの雛形を使ってイテレータを作ってみようと思ったんですが、

'iterator' : 定義されていない基本クラスが宣言されています
となってしまいます。
#include <iterator>
の他にする事があるんでしょうか？

354 ：デフォルトの名無しさん：2005/12/08(木) 00:57:48

名前空間じゃね?

355 ：デフォルトの名無しさん：2005/12/08(木) 01:06:30

>>354
using namespace std;
または
std::iterator
としたらすんなり通りました。
ありがとうございました。

356 ：デフォルトの名無しさん：2005/12/08(木) 01:18:01

RFCってのは4月にチェックするものだと言うすり込みがあるのでしらんかった。

357 ：デフォルトの名無しさん：2005/12/08(木) 01:23:57

さすがにそれはどうかとｗ
確かに俺も毎年4月は確認するけどさｗｗｗ

358 ：デフォルトの名無しさん：2005/12/08(木) 01:51:41

>>350
Javaは標準ライブラリに、StringTokenizer があるから、
少なくとも、C++標準だけでやるよりは楽。

359 ：デフォルトの名無しさん：2005/12/08(木) 01:53:16

>>358
StringTokenizerはCSVのパーシングにおいては何の役にも立たないと思うぞ

360 ：デフォルトの名無しさん：2005/12/08(木) 01:55:19

そうなの？
まぁ、でもRegexあるけど。

361 ：デフォルトの名無しさん：2005/12/08(木) 01:56:38

>>360
人に聞く前に>>346にせっかく挙がってるRFC嫁よ

362 ：デフォルトの名無しさん：2005/12/08(木) 02:25:12

a","b""bb","ccc CRLF
ﾋﾄﾞｽ

でもBNFがあったのですぐ解った

363 ：デフォルトの名無しさん：2005/12/08(木) 06:39:02

CSVが難しいのは、ハウス規格がたくさんあるからで、
>>358 >>359 >>360の言っているような問題じゃない。

>>362
Shift_JISだと、あのBNFじゃ駄目だけどね。

364 ：デフォルトの名無しさん：2005/12/08(木) 11:47:10

あー、RFCだから仕方ないけどCrLf限定になってるし2バイト文字が通らない。
これもまた実態に合わないのか。

365 ：デフォルトの名無しさん：2005/12/08(木) 12:02:30

Category: Informational

366 ：デフォルトの名無しさん：2005/12/08(木) 13:55:59

CSVなんかはPerlで読んじゃうな
前処理させとくだけでもずいぶん楽だし

367 ：デフォルトの名無しさん：2005/12/08(木) 20:25:06

>>366
正しいと思う。
CSVファイル読込が全体に占める消費時間は微々たる物になるケースがほとんどだし。

368 ：デフォルトの名無しさん：2005/12/09(金) 04:06:12

RFC 書いた人、実体分かって書いてるのかな。

369 ：デフォルトの名無しさん：2005/12/09(金) 12:23:24

Boost.Spirit フレームワークで、簡単お手軽CSVパーサを作れば
かなりイイ感じだが、>>345 は、「Boost を使わず」といってるし…

370 ：デフォルトの名無しさん：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.

とある。別に制限するものではないと思うけど。

371 ：デフォルトの名無しさん：2005/12/09(金) 13:42:54

>>370
> 別に制限するものではないと思うけど。

このメディアタイプではCR LFのみだよ。
曖昧にしたら駄目じゃん。いまさらRFCにする意味が半減。

ローカルシステムはCRのみやLFのみかもしれないから、
実装する奴は気をつけろって事。

世間では色々乱れてるから、このメディアタイプ定義で
(インターネット上での)データ交換の規準ができた。

372 ：デフォルトの名無しさん：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

373 ：デフォルトの名無しさん：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 *>());
}

エラーが一杯出る…

374 ：デフォルトの名無しさん：2005/12/14(水) 11:31:29

mylist.sort()

list に std::sort は使えないんじゃ

375 ：デフォルトの名無しさん：2005/12/14(水) 11:34:55

>>373
list.sort();

376 ：デフォルトの名無しさん：2005/12/14(水) 11:37:23

>>373
もうちと付け足す。std::sort()は、random access iteratorを要求している。
しかし、std::list::iteratorは、bidirectional iterator なので、コンパイルが
通らない。

それでは使い勝手が悪いので、std::list::sort()が用意されている。こちらは
マージソートが歴史的な理由から採用されており、bidirectional iterator
でも動くようになっている。

377 ：373：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だかららしい。
ついでに解決策を参考にして、何とかソート出来た！

378 ：デフォルトの名無しさん：2005/12/14(水) 14:06:07

>>376
ついでに補足しておく。
C++標準において、「std::list<>::sort()がStableソートであり、等価な要素の
相対的な位置関係が保たれること」が、保証されている。
で、歴史的な理由により、ほぼ全ての実装でマージソートが採用されている。
(が、その保証はない)

379 ：デフォルトの名無しさん：2005/12/14(水) 19:51:00

επιστημη ←こいつ調子に乗ってるな
何様だよ

380 ：デフォルトの名無しさん：2005/12/14(水) 19:55:23

こんなところで吠えてないで本人に直接言えよ

381 ：デフォルトの名無しさん：2005/12/14(水) 21:58:36

標準化メンバーの1人だっけ?

382 ：デフォルトの名無しさん：2005/12/14(水) 23:28:12

そだよ、標準ライブラリの一部も彼を含めた日本の標準化委員会の案

383 ：デフォルトの名無しさん：2005/12/14(水) 23:53:13

>>379
過疎スレにいってらっしゃい。

επιστημηってウザくね？
http://pc8.2ch.net/test/read.cgi/tech/1091350633/

384 ：デフォルトの名無しさん：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;
}

385 ：デフォルトの名無しさん：2005/12/15(木) 23:25:25

そこで呼び出されてるわけじゃない。
関数のアドレスを渡してるだけ。

386 ：デフォルトの名無しさん：2005/12/15(木) 23:26:58

>>384
そもそも呼び出されてすらないし。find_ifに関数渡してるだけでしょ。
find_ifの中の人がiteratorを実引数にしてiscommaを呼び出すってだけの話。

387 ：デフォルトの名無しさん：2005/12/15(木) 23:27:40

Oppsかぶったかぶった。

388 ：デフォルトの名無しさん：2005/12/15(木) 23:51:56

>>385-386
ものすごく納得いきました。ありがとうございます。

389 ：デフォルトの名無しさん：2005/12/16(金) 02:58:10

>>388 は qsort とか使ったことなかったのかな・・

390 ：デフォルトの名無しさん：2005/12/16(金) 06:00:51

皆が皆CからC++へ行くわけじゃないからね。

391 ：デフォルトの名無しさん：2005/12/16(金) 06:34:27

qsortはCの関数だがな

392 ：デフォルトの名無しさん：2005/12/16(金) 07:00:16

話がかみ合ってない悪寒

393 ：デフォルトの名無しさん：2005/12/16(金) 08:10:52

>>385
> 関数のアドレスを渡してるだけ。

関数オブジェクトを渡しています。

394 ：デフォルトの名無しさん：2005/12/16(金) 08:12:50

>>393
馬鹿ですか？関数と関数オブジェクトの見分け方ぐらい
付けられるようになっとけ。

395 ：デフォルトの名無しさん：2005/12/16(金) 11:09:08

>>387
オップス?
もしかして：Oops!

396 ：デフォルトの名無しさん：2005/12/16(金) 14:31:25

↓>>393の必死な言い訳

397 ：デフォルトの名無しさん：2005/12/16(金) 16:22:37

関数⊂関数オブジェクト

398 ：デフォルトの名無しさん：2005/12/16(金) 16:25:37

もう少しこう、うっかり騙されそうなネタで頼む

399 ：デフォルトの名無しさん：2005/12/16(金) 16:43:58

↓素直に自分の無能を認める>>393

400 ：デフォルトの名無しさん：2005/12/16(金) 17:07:28

俺が悪かった

401 ：デフォルトの名無しさん：2005/12/16(金) 17:12:16

いや俺のほうが悪い

402 ：デフォルトの名無しさん：2005/12/16(金) 17:51:26

私のために争わないで！

403 ：デフォルトの名無しさん：2005/12/16(金) 18:21:45

もうこれ以上

404 ：デフォルトの名無しさん：2005/12/16(金) 18:55:58

君のまわりに不幸の存在を俺は認めない

405 ：デフォルトの名無しさん：2005/12/16(金) 20:07:19

>>389
10月中旬ごろ標準Cの勉強を始めて
11月下旬に標準C++へ、MFCを使って電卓を作って、WinSockでechoサーバをみようみマネでつくり
昨日、初めてSTLの勉強を始めて・・・何故か本の真ん中からはじめたので右も左もわからず・・・・

って感じです。今までネットワークエンジニアとして修行していたのでプログラミングは、つぅあっパリですｗ

406 ：デフォルトの名無しさん：2005/12/16(金) 23:47:13

最初から読もうぜ。結構なんとかなってしまうけど、基本も大事だしね。

407 ：デフォルトの名無しさん：2005/12/17(土) 00:43:22

>>406
STLにも勉強する順番があるんですか？

408 ：デフォルトの名無しさん：2005/12/17(土) 00:55:26

>>407
私は>>406ではありませんが。勉強に順序はありません。でも、
一般的にはstd::vector<>が最初に紹介されていませんかね？

409 ：デフォルトの名無しさん：2005/12/17(土) 00:59:32

>>407
俺は>>406じゃないけど、STLを基本概念から全部理解しようと
したら大変だぜ。本が何冊も出ている。

よく使うコンテナやアルゴリズム、関数オブジェクトの使い方あたり
から少しずつ入って行けば楽なのではないかと思う。

410 ：デフォルトの名無しさん：2005/12/17(土) 01:22:06

vector → list → iterator → algorithm → functional → その他

くらいでいいんじゃね？

411 ：デフォルトの名無しさん：2005/12/17(土) 02:25:01

>>410
ご教授、ありがとうございます。
時間があればそのようなことをしたいと思います。

412 ：デフォルトの名無しさん：2005/12/17(土) 02:36:29

>>411
vector→list→map→algorithm→functional→[boost]

413 ：デフォルトの名無しさん：2005/12/17(土) 03:26:07

最初からLoki

414 ：デフォルトの名無しさん：2005/12/17(土) 03:48:00

>>412
はいはい。じゃーそれで

415 ：デフォルトの名無しさん：2005/12/17(土) 07:17:05

Vector → 窓の杜

416 ：デフォルトの名無しさん：2005/12/17(土) 09:35:09

Vector→Quaternion→Matrix

417 ：デフォルトの名無しさん：2005/12/17(土) 10:16:04

テンソルは？

418 ：デフォルトの名無しさん：2005/12/17(土) 10:41:51

>>414
わかればよろしい。

419 ：デフォルトの名無しさん：2005/12/17(土) 10:54:53

Scalar → Vector → Tensor

はいはい、テンソルテンソル。

420 ：デフォルトの名無しさん：2005/12/17(土) 11:04:45

>>419 わかればよろしい

421 ：デフォルトの名無しさん：2005/12/17(土) 11:08:09

>>419
わかればよろしい。

422 ：デフォルトの名無しさん：2005/12/17(土) 11:10:04

はいはい、すごいね、テンソルテンソル

423 ：デフォルトの名無しさん：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が最初のコンテナとして適当ではないかと。

424 ：デフォルトの名無しさん：2005/12/17(土) 13:02:54

私は実務で使いながらだったから
vector → iterator → algorithm
の順に入ったな。
Cの経験が充分あるなら、取り敢えず可変長配列としてのvectorを見てから
それを一通り使い倒して他にいくと言う意味で悪くないと思う。
#例えばvectorのoperator[]に馴れてそこで留まる香具師にはどうせalgorithmなんて使いこなせないわけだし。

425 ：デフォルトの名無しさん：2005/12/17(土) 13:54:13

>>424
そえは業務でalgorithmを使っていないって事ですか？

426 ：デフォルトの名無しさん：2005/12/17(土) 14:02:05

ヘタレがvector使うとバグの温床になる
listとか使った方がまだまし

427 ：デフォルトの名無しさん：2005/12/17(土) 14:14:24

>>426
なんで？逆じゃないの？

428 ：デフォルトの名無しさん：2005/12/17(土) 14:23:39

vectorやstringは、今となっては設計が5年は古いよな。
algorithmを使えば済むものが、内部メソッドになってしまっている。

429 ：デフォルトの名無しさん：2005/12/17(土) 14:31:45

>428
stringはともかくvectorにそれ当てはまる？

430 ：デフォルトの名無しさん：2005/12/17(土) 15:18:02

>>428
あんた、実はあんまりSTLを知らないね。

std::algorithmを適用できないイテレータを持つコンテナに最適な
アルゴリズムを用意したのが、大抵の内部メソッドだ。

それから、std::stringは、STLには大抵入れない。random access iterator
を使えるので、適用できるアルゴリズムが多いのは確かだが、
用途が主に文字列の操作なので、Cのstring.hに対応する関数を
内部で持っただけ。

431 ：デフォルトの名無しさん：2005/12/17(土) 15:36:34

>>430
stringの後半の主張はどうかと思うぞ。
STL以前からあるクラスで、今やオールドタイプだ。

432 ：デフォルトの名無しさん：2005/12/17(土) 15:50:32

std::stringにバイナリを入れられるのは知ってるけど、果たして
std::stringの内部メソッドがそれに適したような格好になってるかな？

433 ：デフォルトの名無しさん：2005/12/17(土) 18:51:43

>>432
何がいいたいかよくわからん。

434 ：デフォルトの名無しさん：2005/12/17(土) 19:23:27

>>432
typedef basic_string<char> string; ですから、charなんなんでもありです。
ただしc_str()は'\0'が途中にあるとまずいですが。

>>430
SGIのSTLにstring入ってるぞ。

435 ：デフォルトの名無しさん：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);

436 ：デフォルトの名無しさん：2005/12/17(土) 20:02:02

>>435
まずくないのには同意だが、そういうとき普通はc_strじゃなくdataを使うだろ。

437 ：デフォルトの名無しさん：2005/12/17(土) 20:15:33

>>436
data()は今の議論のテーマではない。
終端に確実にヌルが付加されるc_str()を使わずdata()を用いる利点など一切ない。

438 ：デフォルトの名無しさん：2005/12/17(土) 20:18:49

>>437
fwriteに渡すのに終端文字がいちいち付加される意味ないのでc_str()なんか使う意味ないだろ

439 ：デフォルトの名無しさん：2005/12/17(土) 20:19:39

何故?

実装によっては、capacity() != size() の時、
c_str()はdata()より重い処理になるよ。

>>435のようにsize()と使うならdata()ってのが定石だと思う。

440 ：デフォルトの名無しさん：2005/12/17(土) 20:20:10

>>439は、>>437へのレス

441 ：デフォルトの名無しさん：2005/12/17(土) 20:26:47

>>438
仕様変更に対する事前策を用意しておくことを無意味とは、大胆発言だな。

ヌル終端文字列を前提とした既存のC関数に渡すとき、
バッファオーバランの可能性を軽減することができる。
この点においてstring::c_str()は、string::data()やstringstream::str()より安全性に優れている。

ヌル終端保証されたc_str()と保証されないdata()。
一方で、c_str()とdata()が同じ挙動をするSTLも存在する。
どちらを使うべきかは一目瞭然だろう。

442 ：デフォルトの名無しさん：2005/12/17(土) 20:28:22

>>439
サンプルとなる、ソースと開発環境を書け。

443 ：デフォルトの名無しさん：2005/12/17(土) 20:32:35

>>441
バイナリデータブロックを扱っているところをnul文字終端に仕様変更する準備をしておくなんて
普通じゃないな

444 ：デフォルトの名無しさん：2005/12/17(土) 20:35:43

>>443
Unicode文字列をバイナリデータとして扱っている場合などはそうでもない。
何をもって普通というのかその人の経験量だろうけど。

445 ：デフォルトの名無しさん：2005/12/17(土) 20:38:55

１．c_str()は'\0'が途中にあるとまずい
２．size()とともに用いればまずくない
３．そういうときはc_strじゃなくdataを使う
４．ヌル終端文字列を前提とした既存のC関数に渡すときc_str()のほうが安全
５．1に戻る

446 ：デフォルトの名無しさん：2005/12/17(土) 20:40:22

>>439の実証コードはまだですか？
>>439の正しさが確認されないことには、
議論が進まないのでなるべく早目にお願いします。

447 ：デフォルトの名無しさん：2005/12/17(土) 20:44:06

>>445
多分、３．は必要ないから、無限ループには陥らない。

448 ：デフォルトの名無しさん：2005/12/17(土) 20:55:04

結論としては、nul終端が必要ない時はdata()を使え。ただし義務ではない。

449 ：デフォルトの名無しさん：2005/12/17(土) 20:59:41

data()を使う合理性が確認できない。という限定された結論しか出ていない。
c_str()に対するdata()のパフォーマンス優位性も一切確認されていない。

全ては信者の脳内にしか存在しない。

450 ：デフォルトの名無しさん：2005/12/17(土) 21:07:02

逆にc_str()の方が安全である実装はあるのか?
俺の知っている実装は全て、data()とc_str()は同じものを返すよ。
data()の時も実は'\0'で終端されているという…

451 ：デフォルトの名無しさん：2005/12/17(土) 21:13:43

>>450
size() == 0の時少し振る舞いが違うぞ。
まあ多くの実装で返ってくるものは同じだが(w

452 ：デフォルトの名無しさん：2005/12/17(土) 21:14:32

c_str()のdata()に対する優位性
・ヌル終端保証
・"c_str"というキーワードが他であまり使われないので、文字列検索が"data"に比べて簡単

data()のc_str()に対する優位性
・不明

453 ：デフォルトの名無しさん：2005/12/17(土) 21:15:15

VC++7.1はdata()がc_str()を呼んで、c_str()が_Myptr()を呼んでるよ。

454 ：デフォルトの名無しさん：2005/12/17(土) 21:17:31

>>441
そこでstringstream::str()を引き合いに出してくる理由がわからない。

455 ：デフォルトの名無しさん：2005/12/17(土) 21:19:15

data()のc_str()に対する優位性
・ソース内にc_str()と混在させることにより難読性を高めて、他のプログラマがコピペしにくくする著作権保護効果。

456 ：デフォルトの名無しさん：2005/12/17(土) 21:23:13

>>454
己の経験不足を報告するスレじゃないはずだぞ。

457 ：デフォルトの名無しさん：2005/12/17(土) 21:32:22

stringstream::str()はstd::stringを返すのだからss.str().c_str()という手段はないのか？

458 ：デフォルトの名無しさん：2005/12/17(土) 21:33:10

>>452
> data()のc_str()に対する優位性

Cスタイルの文字列を必要としている局面でないことが明確。

459 ：デフォルトの名無しさん：2005/12/17(土) 21:44:24

問題があるのは、stringstream::str()じゃなくてstrstream::str()だった。スマソ。

460 ：デフォルトの名無しさん：2005/12/18(日) 00:07:21

STL使うとどうなるの？

461 ：デフォルトの名無しさん：2005/12/18(日) 00:12:32

>>460
一気に実行ファイルサイズが10倍になります。

462 ：デフォルトの名無しさん：2005/12/18(日) 00:14:24

>>460
別世界が開ける。

463 ：デフォルトの名無しさん：2005/12/18(日) 00:48:02

>>461
環境によるだろ。
俺はBorland-C++5.6.2に -D_RTLDLL オプションを指定して、極力
ランタイムを使用するようにして使っているが、例えばstd::vectorを
使っても使わない時と比べ10Kほどしか増えない。

464 ：デフォルトの名無しさん：2005/12/18(日) 00:57:46

>>461,463
はいはい、他スレのテンプレわろすわろす

465 ：デフォルトの名無しさん：2005/12/18(日) 00:57:49

すげえ。ダイナミックリンクしといてファイルサイズが増えないとかいってるよ。この人。

466 ：デフォルトの名無しさん：2005/12/18(日) 01:03:05

懐かしいなｗ

467 ：not 463：2005/12/18(日) 01:03:25

そりゃそうでしょ。
「実行ファイルのサイズが１０倍になる」を受けてるレスだから。

468 ：デフォルトの名無しさん：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

469 ：デフォルトの名無しさん：2005/12/18(日) 01:30:19

>>468
ﾜﾛｽｗｗｗｗｗ

470 ：デフォルトの名無しさん：2005/12/18(日) 01:36:26

懐かしさと共にﾜﾛｽｗｗｗｗ

471 ：デフォルトの名無しさん：2005/12/18(日) 01:45:39

自作自演乙

472 ：デフォルトの名無しさん：2005/12/18(日) 02:03:26

>>471 がどれを自作自演と言いたいのか判らない。

473 ：デフォルトの名無しさん：2005/12/18(日) 05:32:51

だってこのスレに書き込んでるの俺一人しかいないしｗ

474 ：デフォルトの名無しさん：2005/12/18(日) 07:27:07

いつも思うのだが、>>463は正しいことを書いてる。
あの時点で注目されているのはテンプレートのコード生成に伴うサイズ増量であって、
Cランタイムがどのようにリンクされようがテンプレートと何の関係もない。
むしろ動的リンクの方がテンプレートによる増量がわかりやすいかもしれない。

475 ：デフォルトの名無しさん：2005/12/18(日) 07:31:10

　　　　　　　　　　　i::::::::/'"￣￣ヾi
　　　　　　　　　　　|:::::::|　,,,,,_　 ,,,,,,|
　　　　　　　　　　　|r-==（　｡);（　｡)
　　　　　　　　　　　(　ヽ　　:::__)..:: }
　　　　 ,＿＿__／ヽ　　ー==　;　ほほう　それでそれで？
　　　　 r'"ヽ　　 t､　　＼＿＿_ !
　　　　/ ､､i　　　ヽ＿＿,,/
　　　 /　ヽﾉ　　j　,　　　j　|ヽ　
　　　 |⌒`'､__ /　/　　　/r　 |
　　　 {　　　　￣''ｰ-､,,_,ﾍ＾　|
　　　　ゝ-,,,＿＿＿＿_）--､j
　　　 /　　＼__　　　　　　/
　　　|　　　　"'ｰ‐‐---''

476 ：デフォルトの名無しさん：2005/12/18(日) 07:48:26

std::string使ってないなあ
MBSやsurrogateやらの対応が甘そうだったので自前で作った

477 ：デフォルトの名無しさん：2005/12/18(日) 08:06:26

std::stringから継承するという選択肢は無視かね。
MBS対応メソッドを追加すればすむだけなのに。

478 ：デフォルトの名無しさん：2005/12/18(日) 09:40:48

std::stringから派生するのはやめた方が……。
非仮想デストラクタだし、スライスも怖いし……。

479 ：デフォルトの名無しさん：2005/12/18(日) 10:03:16

>>478
非仮想デストラクタの心配は杞憂。

別のスコープで作られた派生クラスインスタンスを
基底クラスのポインタで破棄すべき状況が、
果たして文字列クラスで起こりうるかどうか考えよう。
ポインタを使いたくないからクラス化しているのに本末転倒な状況だ。

また、STLのコンテナやアルゴリズムがテンプレートを用いており、
継承をあえて使っていない理由についても考えよう。

ところで、「スライス」とは何？

480 ：デフォルトの名無しさん：2005/12/18(日) 11:36:17

>>479
基底クラスへのスライシングだろ。
非仮想デストラクタの場合と心配してるところの根は同じだと思う。

481 ：デフォルトの名無しさん：2005/12/18(日) 11:40:33

>>479
> ポインタを使いたくないからクラス化しているのに本末転倒な状況だ。

そんなあほな。

482 ：デフォルトの名無しさん：2005/12/18(日) 11:58:05

>>480
スライスが動詞でスライシングが動名詞だということだけはわかりました。本当にありがとうございました。

>>481
そういうもんですか？
自分でバッファを確保・解放するなら、
文字列クラスじゃなくて生のchar*でいい気がするけど、どうでしょうか。
暗黙のうちに解放されるコンテナの場合、>>479が触れているとおりテンプレートだし。
だめ？

483 ：デフォルトの名無しさん：2005/12/18(日) 12:40:10

スライシングすらわからんのなら出直してこい

484 ：デフォルトの名無しさん：2005/12/18(日) 12:46:34

>>476
std::wstringは？

>>477
char_traitsの自作は？

485 ：デフォルトの名無しさん：2005/12/18(日) 14:40:45

オススメはbasic_string<unsigned char>でUTF-8

いや、マジで。

486 ：デフォルトの名無しさん：2005/12/18(日) 14:55:54

1文字進めるとかは？

487 ：デフォルトの名無しさん：2005/12/18(日) 15:01:58

>>484
>std::wstringは？
ワイド文字列の罠
ttp://hw001.gate01.com/eggplant/tcf/cpp/wchar_t_trap.html

488 ：デフォルトの名無しさん：2005/12/18(日) 15:34:13

Windows上で多言語対応が必要ないなら16bit化SJISをwstringにつっこむのが最強。

489 ：デフォルトの名無しさん：2005/12/18(日) 18:40:23

>>488
それAPIやライブラリ関数呼び出しの度にchar*またはwchar_t*に
変換せなあかんのか
最悪じゃん

490 ：デフォルトの名無しさん：2005/12/18(日) 19:28:16

>>488
UTF-16をwstringに格納することに比べどんな利点があるのか？

491 ：デフォルトの名無しさん：2005/12/18(日) 21:56:36

1文字進めるのが簡単

492 ：デフォルトの名無しさん：2005/12/18(日) 22:04:08

そして2文字戻す。

493 ：デフォルトの名無しさん：2005/12/18(日) 22:51:03

三歩進んで二歩下がる

494 ：デフォルトの名無しさん：2005/12/19(月) 09:49:59

>>479
> また、STLのコンテナやアルゴリズムがテンプレートを用いており、
> 継承をあえて使っていない理由についても考えよう。

(ﾟДﾟ)ﾊｧ?
テンプレート関係ないやん

495 ：デフォルトの名無しさん：2005/12/19(月) 10:12:46

496 ：デフォルトの名無しさん：2005/12/19(月) 11:18:52

497 ：デフォルトの名無しさん：2005/12/20(火) 21:18:46

498 ：デフォルトの名無しさん：2005/12/20(火) 21:37:00

499 ：デフォルトの名無しさん：2005/12/20(火) 22:42:51

500 ：デフォルトの名無しさん：2005/12/20(火) 23:23:51

よくわからん流れだが
５００は頂いとくよ

501 ：デフォルトの名無しさん：2005/12/20(火) 23:26:28

ショック！自作ゲームでわざわざタスクシステムを自前リストで作ってたけど、
STL使ったら直ぐに出来上がった。
今まで食わず嫌いしてて損したよﾏﾏﾝ。

502 ：デフォルトの名無しさん：2005/12/20(火) 23:47:06

まあまあ、苦労は一回はいいんでないかい。一回だけね。

503 ：デフォルトの名無しさん：2005/12/20(火) 23:59:43

ゲームのタスクシステムに向いてるのってsetとlistどっちでしょうか？

504 ：デフォルトの名無しさん：2005/12/21(水) 00:08:58

普通は組み合わせることになるんじゃないの？

mapのlistとか、vectorのmapとか。
setはあんまり出番なさそうだけど。

505 ：デフォルトの名無しさん：2005/12/21(水) 00:10:53

priority_queueだと思うが。

506 ：501：2005/12/21(水) 00:16:04

俺はlistで作ってみた。で、タスクは一定のメモリを使い回すのが利点なので、動的メモリ確保開放しないように作りたい。
で、結局push_frontでダミーを一定量確保したら一旦clearするようにタスクのファクトリを作ってみた。

push_back等で一定量確保した後で、eraseやclearを使った後は、前に確保した領域は使い回されている保障はあるのかな。
誰か詳細ｷﾎﾞﾝ。

507 ：デフォルトの名無しさん：2005/12/21(水) 00:18:58

そういう場合のためにアロケータがあるんだけどな。

508 ：501：2005/12/21(水) 00:21:48

>>507
なるほど偉い便利だな。これで心置きなく作れる。
ｻﾝｸｽ。

509 ：デフォルトの名無しさん：2005/12/21(水) 00:31:08

>506
そういうのはvectorだけじゃね？
reserve()があるのはvectorだけだし。

510 ：デフォルトの名無しさん：2005/12/21(水) 01:18:42

するとvectorのarg2に自前のアロケータテンプレート指定して作れって事ですかね。
安心できると思ったけど結構めんどいね。

511 ：デフォルトの名無しさん：2005/12/21(水) 01:34:11

>510
reserve()はアロケータの呼び出し自体を抑えて、動的メモリの再確保回数を減らす方法。
listで似たような事をしたければ自前アロケータの内部で似たようなことをするように作れ、と言うこと。

512 ：デフォルトの名無しさん：2005/12/21(水) 04:40:22

boost::poolをコンテナの第三引数に入れて、ベンチマークを取ったり
した。ケースバイケースだけど、こちらの方がわずかに速くなる場合がある。

逆に遅くなる事もある。環境や用途にも大きく左右されると思うので、
各自実験してみて欲しいが、なかなか面白いる

513 ：デフォルトの名無しさん：2005/12/21(水) 05:02:50

＞面白いる
いらん

514 ：デフォルトの名無しさん：2005/12/21(水) 05:11:03

かなタイプで、「。」を「る」に打ち間違えただけじゃないかー
そんなに責めるなよーorz

515 ：デフォルトの名無しさん：2005/12/21(水) 07:04:20

>>510
作らないでもいろいろある。

516 ：デフォルトの名無しさん：2005/12/21(水) 13:55:28

>>515
それを聞きたいいる

517 ：デフォルトの名無しさん：2005/12/21(水) 15:08:20

STLを学ぼうとして最初に思い込みが原因か疑問符がついたので質問させてください。
string型なのですが、char型配列→string型はもちろんできます。
逆も「読み取り専用」なら str.c_str(); で出来たのですが、string型に直接値を入れるのはできないのでしょうか。（設計思想的にできないのかなと思ってます）

例えば
strcpy(str.hoge(), "こんにちは");
なんて真似です。
作ってるアプリケーションでGetOpenFileNameを使っているのですが、
一旦char配列にファイルパスを受け取らせ、その後pathを保存しておくためのstring型に変換するべきなのでしょうか。

518 ：デフォルトの名無しさん：2005/12/21(水) 16:37:52

よくわからないけど、
std::string hoge;
hoge = "こんにちは"
ならできるよ？

519 ：デフォルトの名無しさん：2005/12/21(水) 16:44:07

お返事ありがとうございます。

それは = 代入演算子が使われているからですよね。
それではなく
sprintf(str.c_str(), "%d", 5);
などが出来ないかなと思いまして。

↑これ自体はやっちゃいけないらしいですけど、他でこの想定にかなう方法はあるのかなと。
Win32APIなどでは、char*を引数で渡して中身を入れてもらうAPIも多くあるので…。

520 ：デフォルトの名無しさん：2005/12/21(水) 16:48:31

要はstrcpy()とかsprintf()とかfgets()のような振る舞いをする関数で使いたいと言うことだろ。
ポインタを渡してそこに書いてくれるような。

521 ：520：2005/12/21(水) 16:49:51

がーん、リロードすべきだったw

で、WinAPIを使いたいだけならCStringという妥協でも委員でないの?

522 ：デフォルトの名無しさん：2005/12/21(水) 17:41:27

STLのstringはそういう扱いはできないということですね。
ありがとうございました。

523 ：デフォルトの名無しさん：2005/12/21(水) 18:08:18

stdio系使わずにstringstream使え

524 ：デフォルトの名無しさん：2005/12/21(水) 18:42:47

sprintf -> stringstream
fgets -> getline

とか、代替のものがあるので、それを使うのが一番じゃないかな。

525 ：デフォルトの名無しさん：2005/12/21(水) 18:59:21

>523>524
WinAPIで使いたい、って書いてあるやん。

526 ：デフォルトの名無しさん：2005/12/21(水) 20:03:24

std::string strprintf(const char *fmt, ...)
みたいな関数をでっち上げればいい。

527 ：デフォルトの名無しさん：2005/12/21(水) 20:27:50

んなことやるぐらいならboost::formatで。

528 ：デフォルトの名無しさん：2005/12/21(水) 20:29:26

boostは使いたくない

529 ：デフォルトの名無しさん：2005/12/21(水) 21:17:49

>>528　その心は？

530 ：デフォルトの名無しさん：2005/12/21(水) 21:21:00

>>519
WinAPI相手ならstd::vector<TCHAR>で我慢してくれ。

531 ：デフォルトの名無しさん：2005/12/21(水) 21:46:12

>>529サイズがでかくなるから

532 ：デフォルトの名無しさん：2005/12/21(水) 21:50:43

環境によるだろ。
俺は（略）

533 ：デフォルトの名無しさん：2005/12/21(水) 21:57:57

すげえ。ダイナm(略)

534 ：デフォルトの名無しさん：2005/12/21(水) 23:27:46

#include <stdafx.h>

後(略)

535 ：デフォルトの名無しさん：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<>もメモリ上の連続性を仮定するようになるのかよ。

536 ：http://pc8.2ch.net/test/read.cgi/tech/1133007604/470：2005/12/22(木) 02:30:13

>>535
恥ずかしいから貼らないでくれorz

537 ：デフォルトの名無しさん：2005/12/22(木) 02:39:38

std::string hage="ﾋﾞｬｰﾈ";
hage[0] = 'ｳ';

いまでもこれならできたりする。

538 ：デフォルトの名無しさん：2005/12/22(木) 02:53:20

うむふ

539 ：デフォルトの名無しさん：2005/12/22(木) 10:17:18

>>535
いやっほーう！

540 ：デフォルトの名無しさん：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().

か。

541 ：デフォルトの名無しさん：2005/12/23(金) 00:19:34

つ http://tricklib.com/cxx/dagger/xstring.h

std::string location;
sprintf(capture_string(&location), "<%s>#%d", __FILE__, __LINE__);

542 ：デフォルトの名無しさん：2005/12/23(金) 05:38:16

>>541 突然なんだ？

543 ：デフォルトの名無しさん：2005/12/23(金) 14:25:28

>>542

ちょっとタイミング外したけど、>>519 に対してのﾚｽ。

544 ：デフォルトの名無しさん：2005/12/23(金) 18:14:09

dequeがサイズ拡大時に確保するメモリブロックのサイズって大体どれくらいなのでしょうか？

545 ：デフォルトの名無しさん：2005/12/23(金) 18:17:10

処理系による。

546 ：デフォルトの名無しさん：2005/12/25(日) 01:50:59

STLportっていつの間にURL変わったんだ？
ver5.0 出てるなんて知らなかった(////)

547 ：デフォルトの名無しさん：2005/12/25(日) 16:14:29

setとmultisetってどういう風に使い分ければいいんでしょうか？

548 ：デフォルトの名無しさん：2005/12/25(日) 16:15:32

>>547
使えばすぐにわかる。

549 ：デフォルトの名無しさん：2005/12/25(日) 22:00:03

setは集合。つまり重複要素を許さない。
multisetってのは集合ではなく、重複要素を許す。

550 ：デフォルトの名無しさん：2005/12/26(月) 11:31:17

>>549
普通「集合」は重複を許すと思うが。
すくなくとも数学ではそうだ。

551 ：デフォルトの名無しさん：2005/12/26(月) 12:02:11

>>550
よくわからん。
数学では
{1} = {1,1}
じゃないか？

552 ：デフォルトの名無しさん：2005/12/26(月) 12:04:06

数学では普通両者を区別するよ
高校数学までではこんなこと気にしないと思うけどね

553 ：デフォルトの名無しさん：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}.

554 ：デフォルトの名無しさん：2005/12/26(月) 12:10:04

ZFは普通じゃないのか。
外延性公理
∀a∀b[a=b⇔∀x(x∈a⇔x∈b)]

555 ：デフォルトの名無しさん：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度ずつ呼ばれてくれるのを期待しているのですが…。

556 ：555：2005/12/26(月) 14:16:32

補足です。
＞list.push_back(deque<int>());
＞
＞とすると、deque<int>のデストラクタが2回呼ばれてしまう気がします。
引数で作られた無名なくラスのデストラクタと、
アプリケーションの最後でlistが解放される際のデストラクタで計2回ということです。

557 ：デフォルトの名無しさん：2005/12/26(月) 14:19:42

>>556
コンストラクタが二回、デストラクタが二回走るだけで、
問題はない。

>deque<CHoge> > list;
>list.push_back(CHoge());

これも、CHogeのデフォルトコンストラクタ・コピーコンストラクタ・デストラクタが正しく定義されていれば
問題ないはず。

558 ：デフォルトの名無しさん：2005/12/26(月) 14:25:53

>>557
ありがとうございます。
なるほど。

しかしCHogeはポインタをメンバー変数として所持し、デストラクタでdeleteするようにつくられています。
auto_ptrを使うとよさそうですが、そうするとアップキャストできなくなるのが(CHoge内ポインタの役割上)問題です。

自前で参照カウントを作るか、素直にポインターで実装するべきでしょうか。
deque<CHoge*>
insertやpop, pushするたびに自前でdeleteすることになりますが…。
アドバイスいただければ幸いです。

ところでSTLには、実体を伸び縮みさせられるコンテナはないのでしょうか？
dequeはどうも実体を伸び縮みさせるのには向かないような…。

559 ：デフォルトの名無しさん：2005/12/26(月) 14:32:02

vector< vector<char> > を使って、
可変長構造体にキャストして使うことは可能。

ただ、実体自体を伸び縮みさせるのではなく、
そういうのをポインタで保持するのが普通だと思う。

560 ：デフォルトの名無しさん：2005/12/26(月) 14:35:06

なるほど。
vectorで実体を必要な分確保しておいて、それをdequeにあてはめるわけですね。
しかしvectorは配列が2の乗数を超えるように増えた場合に配列を作り直しますから、コンストラクタとデストラクタがふいなことで呼び出されてしまいそうです。

素直にポインタでやってみようと思います。
ありがとうございました。

しかし>>558でinsertやpop, pushするたびに～って書いてありますが
どう考えてもpopの時しかdeleteは呼びませんね。お恥ずかしい。

561 ：デフォルトの名無しさん：2005/12/26(月) 17:25:44

ポインタのコンテナで自前deleteがいやなら、スマートポインタのコンテナにすればいいじゃない。

ポインタをメンバー持ってるなら、ちゃんとコピー操作に手をいれておけよ。
禁止だけなら3行で済むし。

562 ：デフォルトの名無しさん：2005/12/26(月) 18:05:09

auto_ptrはコンテナの要素にすることが禁止されていなかったか？

563 ：デフォルトの名無しさん：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 --
今日は善い日だ、便が出る

こんなヤツ

564 ：デフォルトの名無しさん：2005/12/26(月) 18:08:16

>>562
boost::shared_ptr

565 ：デフォルトの名無しさん：2005/12/26(月) 18:09:43

>>563
stringstream

566 ：565：2005/12/26(月) 18:10:18

と、ちょっと用途が違うみたい。スマン忘れて

567 ：デフォルトの名無しさん：2005/12/26(月) 18:11:09

>>563
バインドはできないけど、std::ostringstreamからstr()でstd::stringを取り出せる。

568 ：デフォルトの名無しさん：2005/12/26(月) 18:20:12

>>564
うお、shared_ptrだったら大丈夫なのか。正直知らんかった。

コンテナが縮む時に、破棄された分の要素についてデストラクタが呼ばれるのって仕様上確定しているのかね？
確定していないからauto_ptr(とかshared_ptr)はダメなんだと思っていたんだが。

569 ：デフォルトの名無しさん：2005/12/26(月) 18:27:39

>コンテナが縮む時に、破棄された分の要素についてデストラクタが呼ばれるのって仕様上確定しているのかね？
当り前だ。それが保証されてなかったらそもそもコンテナがまともにつかえない。

auto_ptrがコンテナに入れられないのはコピーセマンティクスが破壊的だから。

570 ：デフォルトの名無しさん：2005/12/26(月) 18:29:38

>>565, >>567
ありがとうございます。
バインドできないのかー。
残念。

571 ：デフォルトの名無しさん：2005/12/26(月) 19:03:09

boostならpointer_containerもありますよっと。

572 ：デフォルトの名無しさん：2005/12/26(月) 23:54:01

vectorがA構造体の配列で
Aはメンバにid,dateを持っていて
例えばidが2を持つ一番初めの要素を検索するにはどのようにコーディングしたらよろしいのでしょうか

ご教授お願いします

573 ：デフォルトの名無しさん：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));

574 ：デフォルトの名無しさん：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で調べてみるとよろし。

575 ：デフォルトの名無しさん：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);

576 ：デフォルトの名無しさん：2005/12/27(火) 00:32:06

a_vector.begin() + rand() % a_vector.size(); // ←多分これが2

577 ：デフォルトの名無しさん：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);

578 ：577：2005/12/27(火) 00:42:25

あ、getterの定義いらね
std::vector<A>::iterator itr = std::find_if(vect.begin(),vect.end(),bind(&A::id,_1)==2);

579 ：572：2005/12/28(水) 01:18:49

とりあえず573で出来ました
これは前に書いた出力のやつに似ているので自分にあっているっぽいです

boostも便利らしいですが色々ややこしく…な感じです
STLも殆ど分かっていないですし手をつけるのもどうかなと思うところもあります

(しかしどうしてこのような結果が得られるのか今ひとつ分からん
も少し格闘してきます

580 ：デフォルトの名無しさん：2005/12/28(水) 10:40:22

>>579
>575と>574が理解できれば>573はその中間と言うか、汎用型じゃん。

581 ：デフォルトの名無しさん：2005/12/28(水) 11:38:41

>>580
ハイハイ。知ったか君。

582 ：575=580：2005/12/28(水) 11:53:17

>>581
何か?
#今改めて>575を見たらoperator==になってない……_/￣|○

583 ：デフォルトの名無しさん：2005/12/28(水) 22:14:09

vector<char>からcharの配列を取り出すのはわかるのですが(&vector.front())、
list<char>からの取り出し方法が分かりません。
リスト構造なのでループで回さないと無理なのかとも思うのですが、良い方法が
あればご教授お願いします。

584 ：デフォルトの名無しさん：2005/12/28(水) 22:17:05

>>583
empty() の時は front() 呼び出しちゃだめだから気をつけて。
vector 以外のコンテナからC言語の組み込み配列を得るには
コピーして作るしかない。

585 ：デフォルトの名無しさん：2005/12/28(水) 23:05:23

>>583
ループを回す代わりにイテレータで。
std::list<char> ls;
// ……。
std::vector<char> v(ls.begin(), ls.end());
場合によってはstd::stringのほうが良いかもしれない。

586 ：デフォルトの名無しさん：2005/12/28(水) 23:53:40

えっと Windows で STLPort 4.6.2 を使っているんだけど、StlPort って
スレッドセーフってことでいいのでしょうか？

マルチスレッドなプログラム書いてて、再現が難しい（リリースモードのみ）
バグがあって原因を追究しているんだけど、スタックトレースを
とったら、stlport の _alloc.c で落ちたみたいなんですが・・・

587 ：デフォルトの名無しさん：2005/12/29(木) 00:01:47

メモリリークの類がalloc.cで落ちるのはよくある話。

588 ：デフォルトの名無しさん：2005/12/29(木) 00:32:40

>>584-585
ありがとうございました。

589 ：デフォルトの名無しさん：2005/12/31(土) 16:33:11

簡単で標準的なスマポを標準テンプレートライブラりーで
教えてくださいって、既にテンプレートを貼ってあったら
ごめんなさい。

ちなみに、紅白の大鳥はスマップです。←見ねーよ
戦後６０年を見るね。0：00英霊たちに合唱・・・亞ボーン

590 ：デフォルトの名無しさん：2005/12/31(土) 16:37:40

…(;ﾟДﾟ)

591 ：デフォルトの名無しさん：2005/12/31(土) 17:38:49

>>589 斬新だな。

592 ：デフォルトの名無しさん：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;}
};

593 ：デフォルトの名無しさん：2005/12/31(土) 18:32:16

>>592
コンパイルがどう見ても通らないソースなんだが。
何を言いたいんだ？

594 ：デフォルトの名無しさん：2005/12/31(土) 18:44:22

年の瀬に湧くと話題の馬鹿でしょう。

595 ：デフォルトの名無しさん：2005/12/31(土) 19:31:46

>>592
http://www.borland.co.jp/qanda/lang/l0003025.html
＞コンパイルがどう見ても通らないソースなんだが。
＞何を言いたいんだ？
某のコンパイラは通らないか、ソースが間違っているのですか。
ついでにＶＣ６　ＶＣ２００５での問題点も指摘してください。

596 ：デフォルトの名無しさん：2005/12/31(土) 19:44:43

だから elete って何よ。

597 ：　：2005/12/31(土) 19:46:17

ひょードル強いな！

598 ：デフォルトの名無しさん：2005/12/31(土) 19:48:47

もう、寝ていいよ　
（596だから elete って何よ）

599 ：デフォルトの名無しさん：2006/01/03(火) 22:23:13

それはねー、エリート宣言さ～

600 ：デフォルトの名無しさん：2006/01/04(水) 16:29:26

６００

601 ：デフォルトの名無しさん：2006/01/06(金) 18:29:58

std::numeric_limits<double> のメンバ関数を使って、
ある double 型の変数に格納されているのが
NaN かどうかを判定するってことは可能ですか？

つまり C99 における isnan() のようなものが
STL にも用意されているのでしょうか??

602 ：デフォルトの名無しさん：2006/01/06(金) 18:37:44

こんなん見つけた
http://www.kouno.jp/home/c_faq/c14.html#9

603 ：デフォルトの名無しさん：2006/01/06(金) 18:43:23

結局 isnan() を使うしかないのか・・・
gcc だと C99 準拠だから isnan() がつかえるけど、
Visual C++ だと C99 準拠じゃないから isnan() がないんだよな。
でもよく見たら _isnan() があった。

とはいえ、nan() も処理系によって有ったり無かったりなんで、
std::numeric_limits<double>.quiet_NaN() のほうがいいかも
と思ったんだけど、結局 STL もそこまでは面倒見てくれないのか。

604 ：デフォルトの名無しさん：2006/01/08(日) 14:50:10

MinGWへのSTLport5.0.1のインストールやっとうまく行った・・・・
今までおかしかった原因は、-mthreadsをコマンドラインに与えてないせいでした。

STLportがマルチスレッドでビルドされるのは知ってたけど、4.6.2までは-mthreads
が不要だったので、はまってました。

この勢いでVC7.1にも入れよう。VC8.0もいじらないといけないし、大変だ。

605 ：デフォルトの名無しさん：2006/01/09(月) 15:02:07

std::vector<T> や std::list<T> に
T や T の派生クラスを混在して保持するように
したいのですが、可能でしょうか？

606 ：デフォルトの名無しさん：2006/01/09(月) 15:08:31

ポインタ若しくはスマートポインタを格納することは可能

607 ：デフォルトの名無しさん：2006/01/09(月) 15:13:50

std::auto_ptr ？
とおもったけど、これは色々文献を読んでみると
STLのコンテナの要素とすることは禁止されているみたいですね。
内部の実装がどうなってるのかは知らないけど。

格納したいクラスへのポインタをメンバに持つ
ラッパークラスでも作ろうかとおもったけど、
もしかして boost::shared_ptr で行けたりします？
って、ためしてみようっと。

608 ：デフォルトの名無しさん：2006/01/09(月) 15:17:13

>>607
>もしかして boost::shared_ptr で行けたりします？
はい

609 ：605=607：2006/01/09(月) 15:25:21

ふむ、うまくいったようです。
ありがとうございました。

610 ：デフォルトの名無しさん：2006/01/09(月) 15:49:29

boost を使っていいなら、 ptr_vector とかもあるよ。

611 ：605=607：2006/01/09(月) 16:13:01

げ、なんか便利そうなモノが他にもあるんですか。
boost は普段正規表現ライブラリくらいしか使わないんで、
boost の全貌を把握してないんですよ。
boost:ptr_vector もどんなもんか勉強してきます。

612 ：デフォルトの名無しさん：2006/01/09(月) 21:52:05

std::vector とかって operator[] では
std::out_of_range 例外が発生しないんですね。
at() なら発生するのに。

613 ：デフォルトの名無しさん：2006/01/09(月) 22:08:35

>>612
at() は範囲チェックをする分パフォーマンスが落ちるから、
範囲外へのアクセスを行う可能性がある時のみ使う感じで使い分けたりする。

614 ：デフォルトの名無しさん：2006/01/13(金) 01:51:05

mapで一度登録した値を変更したい場合一度削除しないと変更できませんか？

615 ：デフォルトの名無しさん：2006/01/13(金) 01:58:46

m[key] = value;

616 ：デフォルトの名無しさん：2006/01/13(金) 01:59:02

>>614
できます

617 ：デフォルトの名無しさん：2006/01/13(金) 02:11:38

どうもありがとうございます

618 ：デフォルトの名無しさん：2006/01/13(金) 17:43:32

stringとwstringの相互変換なtemplate又は、関数ってあります？
やっぱ、
MultiByteToWideCharとか使って変換しないと駄目？

619 ：デフォルトの名無しさん：2006/01/13(金) 18:41:13

お前が変換したいように変換しろ。

620 ：デフォルトの名無しさん：2006/01/13(金) 21:30:21

>>618
wstringつーかwchar_tのエンコーディングは標準でコレと定められているわけじゃない
（まあそれを言ったらcharだってそうだけどな。EBCDICとかあるし、結局何だって
つっこめる）
だから、実際に自分がどーゆーエンコーディングを用いているかに応じて、
変換も行わなければならない。「常に正しい方法」は存在しない、ということだ。

621 ：デフォルトの名無しさん：2006/01/13(金) 21:50:18

ISO C++的にはcodecvtクラスだろ。
関連クラス: locale, facets, codecvt_byname

622 ：デフォルトの名無しさん：2006/01/15(日) 03:12:03

>618
ここの一番下のサンプルでも見るといい。
ttp://hw001.gate01.com/eggplant/tcf/cpp/wchar_t_trap.html

623 ：本田：2006/01/15(日) 17:58:26

>>586
> えっと Windows で STLPort 4.6.2 を使っているんだけど、StlPort って
> スレッドセーフってことでいいのでしょうか？

BCB6は、マルチスレッド対応と非対応を選択できるようだけど。

624 ：デフォルトの名無しさん：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が起動します。

　この辺の仕組みが分かりません。よろしくご教授下さい．
　板違いでしたら申し訳ありません。

625 ：デフォルトの名無しさん：2006/01/17(火) 20:38:59

>>624
全くスレ違い。Win板だと思う。

626 ：デフォルトの名無しさん：2006/01/17(火) 20:59:07

>>625
すいませんでした。

627 ：デフォルトの名無しさん：2006/01/18(水) 21:22:52

vector<char>にcharの配列を一気に代入したいです。
forループでpush_backするより効率がいい方法はありますか？

628 ：デフォルトの名無しさん：2006/01/18(水) 21:28:20

char buf[]="aiueo";
vector<char> hoge(&buf[0],&buf[0] + sizeof(buf)/sizof(buf[0]));

629 ：デフォルトの名無しさん：2006/01/18(水) 21:48:17

これでもいける
char buf[] = "hello";
std::vector<char> v;
v.assign(buf, buf + strlen(buf));

てか、stringをなぜ使わないのか。
参照カウントが気になる？

630 ：デフォルトの名無しさん：2006/01/18(水) 22:33:49

string って参照カウンタ持ってるのか。
独自のGCを使ってるってこと？

631 ：デフォルトの名無しさん：2006/01/18(水) 23:04:10

>>630
参照カウンタを使うかどうかは実装次第。
ただしメモリ確保自体にはテンプレート引数で指定されたアロケータ
（std::stringではstd::allocator<char>）が使われる。

632 ：デフォルトの名無しさん：2006/01/18(水) 23:06:35

>>630
そういう実装が流行ってた時代もあった。
でも今は全部コピーする実装が主流。
どちらにせよ実装依存

633 ：デフォルトの名無しさん：2006/01/18(水) 23:29:54

参照カウンタ方式stringが廃れた理由は何？

634 ：デフォルトの名無しさん：2006/01/18(水) 23:32:35

>>633
たとえばスレッド安全のためということがある。

635 ：デフォルトの名無しさん：2006/01/19(木) 03:09:19

>>628
>629で充分。つーか、それだとナル文字の分も追加されるぞ。

636 ：628：2006/01/19(木) 04:23:05

ありがとうございました。

637 ：デフォルトの名無しさん：2006/01/26(木) 10:27:02

インテルのコンパイラヘルプに、exportのキーワード。
まさか、対応してる？

638 ：デフォルトの名無しさん：2006/01/26(木) 10:30:40

でも、メンバテンプレートがない？

639 ：デフォルトの名無しさん：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 でうれしくなれる例を教えて！

　　　　　　　　　　　　　　　　　　　　　
　　　　　　　　　　　　　　　　ﾊ_ﾊ　　
　　　　　　　　　　　　　　　('(ﾟ∀ﾟ∩　教えて！
　　　　　　　　　　　　　　　　ヽ　　〈　
　　　　　　　　　　　　　　　　　ヽヽ_)

640 ：デフォルトの名無しさん：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);
のように書けば実装は別で定義されていることになってリンク時に結合される
これによってヘッダに大量の実装をおく必要が無くなってコンパイル時間の短縮等が期待できる。

641 ：デフォルトの名無しさん：2006/01/26(木) 11:45:37

まぁコンパイル時間の短縮ってもプリコンパイルヘッダに比べるとどうなんだかな。

642 ：638：2006/01/26(木) 11:50:25

すみません。自己解決しました。テンプレートの解釈があいまいになるところが
あったせいで、VC7でよくて、intelはだめだったというだけでした。

643 ：デフォルトの名無しさん：2006/01/26(木) 11:58:10

>>640
thx。

おもわず、だまされました。

644 ：デフォルトの名無しさん：2006/01/26(木) 17:55:52

std::vector に格納できるのは shared_ptr ですよね？

645 ：デフォルトの名無しさん：2006/01/26(木) 18:05:31

ほぼなんでも格納できます

646 ：デフォルトの名無しさん：2006/01/26(木) 18:17:20

>>645 ちょ、まっ、wwww
std::auto_ptr とかヤバス

647 ：デフォルトの名無しさん：2006/01/26(木) 19:00:36

>645
コピーできないものを「ほぼ」の除外対象にするのは如何なものかと思います。

648 ：デフォルトの名無しさん：2006/01/26(木) 21:53:10

まったく問題ないと思います。

649 ：デフォルトの名無しさん：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 を使ってもコンパイル時間は短縮されないだろう、とのこと。

650 ：デフォルトの名無しさん：2006/01/26(木) 23:27:55

別のコンパイル単位で、
同じ文脈でインスタンス化される場合、
exportでやる流儀なら、一度で済むだろ。

651 ：デフォルトの名無しさん：2006/01/26(木) 23:50:18

>>649
加えて，ビルドツールが export による翻訳単位を超えた依存関係を
識別できなければならない，とか
たとえ無名名前空間で定義された export を指定されていない
テンプレートだとしても他の export されたテンプレート経由で名前が他の
翻訳単位に暴露されるなど，プログラムの挙動が非常に予測しにくくなる，とか
従来の
「～～テンプレートからインスタンス化された～～テンプレートからインスタンス化（以下略」
という楽しいコンパイルエラーメッセージに加えて
「～～翻訳単位からインスタンス化された～～翻訳単位からインスタンス化（以下略」
というさらに楽しいエラーメッセージが付加される，とか色々楽しいことが満載です．
マクロの名前を翻訳単位によって切れるのが，現状 export による
明らかな恩恵だと結論されていますけれど，これも本質的には
別次元の問題（C99 のスコープ付きマクロ）として解決されるべき問題ですし

"Exceptional C++ Style" に，20ページも使って
「現状，いかに export に期待できないか」が， Java の全言語仕様の実装に
2人年かかったのに対して export 「だけ」の実装に3人年かかった，
とかいう話なんかと一緒に恐ろしく詳細に載ってます．

652 ：651：2006/01/27(金) 00:04:54

649 に挙げられた記事と "Exceptional C++ Style" の
内容はほとんど同じものでした．すいません．

653 ：デフォルトの名無しさん：2006/01/27(金) 07:57:01

>650
その高速化は export を使わない場合でも可能だ、というのが記事の趣旨。
もちろん、#include してることで実装の読み込み自体は常に発生するけど、コードの生成までは必要ない。
Comeau compiler は export の場合と、#include の場合の両方でその高速化が可能って書いてあるけど
使ってないから本当かどうかは知らない。

654 ：デフォルトの名無しさん：2006/01/27(金) 08:59:24

>>653
> コードの生成までは必要ない。

一応生成しとかないと。(あるいはソースを保存しとくか)
g++だとweak symbolで生成している。

655 ：デフォルトの名無しさん：2006/01/27(金) 10:35:58

icc なんかで翻訳単位を超えたインライン化なんかも実装されてるわけで、
本質的に便利なことがあれば export も実装も普及するんでしょうね。

656 ：デフォルトの名無しさん：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?

657 ：デフォルトの名無しさん：2006/01/28(土) 20:15:07

>>656
その物体オブジェクトに
ID持たせるとかすればいいんじゃね？
アドレスを使うというのはどうも・・・

オブジェクトの拡張ができないなら
map<id, object>とか
vectorとかlistの要素をpair<id, object>にするとか

658 ：デフォルトの名無しさん：2006/01/28(土) 20:16:25

>>656
記録しておきたい要素のインデックスをvectorで保持すればいいジャマイカ
それを添え字に使って位置と大きさとやらにアクセスすればよい。
何のためのvectorだよぅ

659 ：デフォルトの名無しさん：2006/01/28(土) 20:18:42

>>658
それじゃ要素の追加、削除でindexがかわるからまずいんじゃ？

660 ：デフォルトの名無しさん：2006/01/28(土) 20:24:04

>>656
list,set,mapのイテレータが無効になる条件は、
自分自身のイテレータを削除したときのみなので大丈夫と思う。

661 ：デフォルトの名無しさん：2006/01/28(土) 20:31:05

>>659
アドレスが変わるってそのことか。
てっきり要素数が変わった時にガバッと取り直すことかと思ったよ。

662 ：デフォルトの名無しさん：2006/01/28(土) 20:41:56

削除はどのくらいの頻度で起きるのかね。
頻度高いならvectorは得じゃないよね。位置詰めのcopyが起きるから。

663 ：656：2006/01/28(土) 21:38:49

>>657-662
ありがとうございます。
削除も結構な頻度でおこるんで、
とりあえず物体の情報をlistに格納して、衝突判定はそのイテレータを使う方法でやってみます。

664 ：デフォルトの名無しさん：2006/01/28(土) 22:10:49

そうね、listで書いてみて、ボトルネックが見つかれば、
自作も含めて、他のコンテナ考えた方がいいだろうね。
とりあえずコンテナの形態にべたべたに依存しないコード書いといて。

665 ：デフォルトの名無しさん：2006/01/29(日) 05:19:19

コンテナからある条件を満たす要素だけを集めた
新しいコンテナを作るのって一発でできないんですか？

666 ：デフォルトの名無しさん：2006/01/29(日) 05:30:57

>>665 「一発で」の意味がわからん。

667 ：デフォルトの名無しさん：2006/01/29(日) 05:43:34

>>665
たぶん、STLの範囲内でやるなら
remove_copy_if + back_inserter + 適当な述語関数

......どうでも良いけど、STLにcopy_ifが無いのは何故だろう。

668 ：デフォルトの名無しさん：2006/01/29(日) 05:52:19

>>667
入れ忘れちゃった。てへっ♥ by禿

669 ：667：2006/01/29(日) 06:02:25

>>668
を読んでいくら禿でも、そんなことないだろうとプログラミング言語C++を読んでみたら
------------------------------------------------------
残念なことに、copy_ifはどうしたわけか標準ライブラリが
提供するアルゴリズムセットから抜け落ちてしまった(私の過失である)
---------------------------------------------------------
　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　by 禿
　プログラミング言語C++第三版 P610より

やっぱ禿のせいか
ｳﾜｧｧｧｧｧｧヽ(`Д´)ﾉｧｧｧｧｧｧﾝ!

670 ：デフォルトの名無しさん：2006/01/29(日) 09:41:20

まあ、logical_not使えばいいし。

671 ：デフォルトの名無しさん：2006/01/29(日) 10:24:19

_ifなんてついてる時点で設計ミスだから禿は正しい
filter_iterator使え

672 ：デフォルトの名無しさん：2006/01/29(日) 10:31:49

今禿って言う香具師ちょっと来い( ﾟДﾟ)

673 ：デフォルトの名無しさん：2006/01/29(日) 10:55:35

はげって誰のこと？
画像はってよ。

674 ：デフォルトの名無しさん：2006/01/29(日) 11:53:09

http://public.research.att.com/~bs/homepage.html

remove_copyも名前がおかしい。

675 ：デフォルトの名無しさん：2006/01/29(日) 11:54:21

あれえ？前は椅子に座って机に足かけてる画像だったような気がするけど。
ハゲのくせに足なげえとしか思ってたけど。

676 ：デフォルトの名無しさん：2006/01/29(日) 12:05:45

名前はAdaでMusser&Stepanovが書いた頃の流儀だな。
removeじゃなくてDeleteだが。Copy_Ifはこの頃からない。

677 ：デフォルトの名無しさん：2006/01/29(日) 12:15:54

ホントだ。写真変わってるね。
ﾊｹﾞのくせに生意気

678 ：デフォルトの名無しさん：2006/01/29(日) 12:25:27

このおっさんの名前見るたびに、
インリンの顔が浮かぶ。
なんかＭ字ビターンに似てねぇ？

679 ：デフォルトの名無しさん：2006/01/29(日) 13:30:48

ｵﾏｲﾗ本人がいないからって言いたい放題だなｗ

680 ：デフォルトの名無しさん：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;
}

681 ：デフォルトの名無しさん：2006/01/29(日) 14:01:16

>>679
俺は本人の前でも言えるよ。日本語でなら。

682 ：デフォルトの名無しさん：2006/01/29(日) 14:03:11

>>679
俺も本人の前でも言えるよ。エスペラント語なら。

683 ：デフォルトの名無しさん：2006/01/29(日) 14:06:06

ﾋﾞﾔｰｿって言語学者だしエスペラント知ってそうだな

684 ：デフォルトの名無しさん：2006/01/29(日) 14:23:36

だったら禿がこのスレ見たら泣くな
日本語も分かりそうだしｗ

685 ：デフォルトの名無しさん：2006/01/29(日) 16:08:10

は・・い、いえビョ～～ン先生ごめんなさい。
私たちが間違ってました。

686 ：デフォルトの名無しさん：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)))

687 ：デフォルトの名無しさん：2006/01/29(日) 20:49:19

何この平和なスレ。

688 ：デフォルトの名無しさん：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))

689 ：デフォルトの名無しさん：2006/01/30(月) 23:46:56

あ～るはげた～ひる～さがり～♪

690 ：デフォルトの名無しさん：2006/01/31(火) 00:06:11

か～つら～につづ～くみち～♪

691 ：デフォルトの名無しさん：2006/01/31(火) 01:37:40

めーがーねーがーごーとーごーとー♪

692 ：デフォルトの名無しさん：2006/01/31(火) 12:11:59

func(float a[])
という関数に
vector<float> x;
を引数に渡したくて、
func(&(x[0]))
とやっているんだけど、うまくキャストができません。
どうすればいいでしょうか？ご教授よろしくお願いいたしますm(__)m

693 ：デフォルトの名無しさん：2006/01/31(火) 12:24:00

>>692
すまん、普通にそれで通るんだがコンパイラ何よ？

#include<vector>
void func(float a[]){}
int main(){
std::vector<float>x;
func(&(x[0]));
}

694 ：デフォルトの名無しさん：2006/01/31(火) 12:35:35

>>693
すまん、おれのミスだった。まちがって、
int main(){
std::vector<float>x;
func(x);
}
とやっていた。
いずれにしろバグが取れて助かりました。
どうもありがとう！

695 ：デフォルトの名無しさん：2006/01/31(火) 13:18:55

それバグじゃない

696 ：デフォルトの名無しさん：2006/01/31(火) 21:45:01

694の頭にバグがあったということだろう。

697 ：デフォルトの名無しさん：2006/01/31(火) 23:30:35

スキンヘッド推奨

698 ：デフォルトの名無しさん：2006/02/01(水) 05:53:56

サイドは残さなきゃダメだろ

699 ：デフォルトの名無しさん：2006/02/06(月) 16:43:38

std::vector<T> にて、T はデフォルトコンストラクタ
T::T() を持たなければダメなんでしょうか？？？？
たしかに T::T() を必要とするメソッドは有るよな。
初期化されないブツが投入されるのがイヤな時には、
とりあえず T::T() の中で何か throw するようにしておく？
でもそれだと実行時にしか検出されない･･･

って、書いてて気づいたんだけど、もしかして
T::T() を宣言だけしておいて定義しなければ
リンク時に気づくかも。

700 ：デフォルトの名無しさん：2006/02/06(月) 16:50:32

そんなに気になるならデフォルトコンストラクタをprivateにすればいいやん（;´Д｀）

701 ：デフォルトの名無しさん：2006/02/06(月) 17:05:05

>>700 ΣΣ（ﾟдﾟlll）ｶﾞｶﾞｰﾝ
そ、そうだった・・・・

702 ：デフォルトの名無しさん：2006/02/06(月) 17:11:54

>>699
>初期化されないブツが投入されるのがイヤな時には、
ってことはそのTは自前のコンストラクタを持ってるわけでしょ
ってことはT::T()が勝手に定義されることはないので
何もしなくてもコンパイルエラーになるよ

703 ：デフォルトの名無しさん：2006/02/06(月) 17:19:35

>>702 うん、で、そういうクラスを std::vector<T> に
格納しようとしたら、std::vector<T> のコンストラクタの
一つが T のデフォルトコンストラクタを要求するので
エラーになります。 private にしても同じく。

でも実際にはそのコンストラクタは呼ばれないので、
宣言だけして定義はしなくてもリンク可能です。
実際に使われてるか否か（コードが生成されているか否か）
に関わり無く、テンプレートの関数はとりあえず
実体が生成されるものとして構文と識別子のチェックが行われるようです。

704 ：デフォルトの名無しさん：2006/02/06(月) 17:20:12

って、それは C++99 が要求している事なのか、
たまたま VC++ 2005 の実装がそうなのか分かりません。

705 ：デフォルトの名無しさん：2006/02/06(月) 17:27:22

JIS X3014ではコンテナの要素の要件に定められていることは、
コピーコンストラクト可能であることと代入可能であることだけだった。
（デフォルトコンストラクト可能である必要はないと）

706 ：デフォルトの名無しさん：2006/02/06(月) 17:30:26

>>703
VCで試そうとしたけどエラーが出ない......
エラーの出る最小のソース希望

707 ：ごめん：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 。
正直、スマンカッタ

708 ：デフォルトの名無しさん：2006/02/06(月) 21:59:19

>>704
C++は98。

709 ：デフォルトの名無しさん：2006/02/06(月) 22:00:44

>>708
つ2003

710 ：デフォルトの名無しさん：2006/02/06(月) 22:04:28

禿共のがんばり次第によっては06

711 ：デフォルトの名無しさん：2006/02/06(月) 22:13:51

>>710
禿曰く09

712 ：デフォルトの名無しさん：2006/02/06(月) 22:17:47

おのれ禿・・・
そんなに待てぬ

713 ：デフォルトの名無しさん：2006/02/06(月) 22:29:30

禿禿いうな禿

714 ：デフォルトの名無しさん：2006/02/06(月) 22:31:23

禿せめて08年中ぐらいにはお願いします。
そうすれば00年代にはそこそこ対応したコンパイラが出るかもしれません。

715 ：デフォルトの名無しさん：2006/02/07(火) 06:18:41

禿さんの禿って今も進行してるんですか？

716 ：デフォルトの名無しさん：2006/02/07(火) 07:14:10

>>715
まだ完全には実装されていない。
というか、写真によってちょっとずつちがうから、
そこはベンダー依存ではないか。

717 ：デフォルトの名無しさん：2006/02/07(火) 07:48:57

10年に出すと言うのも男の勇気ですぜ，禿の兄貴。

718 ：デフォルトの名無しさん：2006/02/07(火) 11:12:23

確か最速で x=9 ってヒゲが言ってた。
標準化のプロセスに時間がかかるらしいから、
禿やヒゲががんばっても多分早くはならない。

719 ：デフォルトの名無しさん：2006/02/07(火) 11:19:31

まあ無理に急いで糞言語になるか、標準化遅れて処理系がNEEEEEEになるかはトレードオフだしなぁ

720 ：デフォルトの名無しさん：2006/02/07(火) 11:29:31

どこがC++0xなんだよ
C++1xじゃねえか
禿だか髭だかフサフサだかしらねーけどとっととしやがれ

721 ：デフォルトの名無しさん：2006/02/07(火) 11:45:21

C++0x0a

722 ：デフォルトの名無しさん：2006/02/07(火) 20:19:28

クラスのポインタ配列のvectorを作成し、
foo.push_back(new CFoo()); とやると無論コンストラクタが呼ばれますが
foo.erase(foo.begin()); 等とした際に
CFooのデストラクタが呼ばれないのは、こういう物だと思うしか無いのでしょうか？
foo[0].~CFoo(); みたいな事をeraseする度にやるのは何かおかしい感じがします

723 ：デフォルトの名無しさん：2006/02/07(火) 20:26:15

>>722
スマートポインタ

724 ：デフォルトの名無しさん：2006/02/07(火) 20:32:37

>>722
eraseする前にデストラクタではなくdeleteを呼べ。
それでは面倒だから>>723。
或いはboost::ptr_vector。

725 ：デフォルトの名無しさん：2006/02/07(火) 20:33:52

deleteされるわけじゃないからね、リークするだけ
boost::shared_ptrとかptr_vectorとかあるけど

726 ：デフォルトの名無しさん：2006/02/07(火) 20:36:09

>>723-725
一応、こういうモノなんですね…、ありがとうございます
ptr_vector ていうのがぱっと見便利そうなので試してみます。
とても参考になります。

727 ：デフォルトの名無しさん：2006/02/08(水) 00:27:35

>>722,726
もう納得したみたいだが

CFoo* p = new CFoo();
foo.push_back(p);
foo.erase(foo.begin());

で、勝手にdeleteされた方が
おかしい感じがするだろ

728 ：デフォルトの名無しさん：2006/02/08(水) 09:39:50

boost::ptr_vector と
std::vector<boost::shared_ptr> と
どっちがおすすめ？
っていうか本質的な違いある？

729 ：デフォルトの名無しさん：2006/02/08(水) 10:53:13

>>728
>どっちがおすすめ？
ケースバイケース

>っていうか本質的な違いある？
要素が生ポインタかスマートポインタか。

730 ：デフォルトの名無しさん：2006/02/08(水) 10:58:31

>>729 そうか、 boost::ptr_vector は中身が生ポインタか。
だったら std::vector< std::auto_ptr > とおなじようなもんか？
と思ったけど、後者はやっちゃだめなんだよな。
とりあえず boost::ptr_vector のヘッダファイルでも読んでみます。

731 ：デフォルトの名無しさん：2006/02/08(水) 21:55:40

>>730
ptr_vectorは、ただ単にデストラクタで全要素をdeleteするだけだろ。
auto_ptrとは何の関係もない。

732 ：デフォルトの名無しさん：2006/02/08(水) 23:20:20

要素が削除されたときにdeleteされるから、概念的に各要素がauto_ptrと言えなくも無い。
所有権の移動が無いからboost::scoped_ptrの方が適当だが。

733 ：デフォルトの名無しさん：2006/02/09(木) 08:17:21

(ﾟДﾟ)ﾊｧ?

734 ：デフォルトの名無しさん：2006/02/09(木) 09:28:44

ゆとり世代か

735 ：デフォルトの名無しさん：2006/02/09(木) 10:47:39

732はきわめて妥当なこと書いてると思うが……

736 ：デフォルトの名無しさん：2006/02/09(木) 19:14:45

>735
同意。

737 ：デフォルトの名無しさん：2006/02/09(木) 20:00:25

概念的という言葉を使えば、その記述が妥当であるかのように錯覚する。

しかし、プログラマの目の前にあるものは、
あいまいな「概念」などではなく、具体的で厳密なものだ。

プラットホーム、コンパイラ、ライブラリへの依存を無視した「概念」という言葉は、
プログラマに何の解決ももたらさない。時に誤解さえ与えかねない。

738 ：デフォルトの名無しさん：2006/02/09(木) 22:09:49

概念は心の拠り所。

739 ：デフォルトの名無しさん：2006/02/10(金) 00:22:32

>>737
お空に消えてなくなるタバコの煙みたいなレスですね。

740 ：デフォルトの名無しさん：2006/02/11(土) 14:39:46

先月末にApacheの(元はRogue Waveの)STLが出てるけど、これ既出？
http://incubator.apache.org/stdcxx/download.html の一番下

741 ：デフォルトの名無しさん：2006/02/12(日) 14:20:46

>>740

DL してみたんですけど、 VC6 へのインストール方法がわかりませんでした。。。

742 ：デフォルトの名無しさん：2006/02/20(月) 06:46:37

vectorを配列のように使った場合、配列と比較してパフォーマンスは落ちますか？

743 ：デフォルトの名無しさん：2006/02/20(月) 06:47:16

自分で計れカス

744 ：デフォルトの名無しさん：2006/02/20(月) 07:15:19

実装にもよるが素人が書いた場合、むしろ速くなる場合が多いのでvectorが利用できるなら利用することをすすめる

745 ：デフォルトの名無しさん：2006/02/20(月) 10:08:16

>>742 パフォーマンスに一番影響が出そうなところは
at() と operator[] のどちらを使うかってところかなぁ。
俺はもんげ～速度に厳しいときだけ operator[] 使ってる。

746 ：デフォルトの名無しさん：2006/02/20(月) 11:06:31

未だにat()を使ったことがない。

747 ：デフォルトの名無しさん：2006/02/20(月) 11:18:38

>>746 とりあえず安全のために
速度にうるさくないところでは
at() を使ってる。冷害出してくれるし。

748 ：デフォルトの名無しさん：2006/02/20(月) 11:20:28

あー漏れも同じだ
とりあえずat使って例外が飛んでこなかったらホットしてる

749 ：デフォルトの名無しさん：2006/02/20(月) 11:54:43

ホットで藤井隆を思い出した

750 ：デフォルトの名無しさん：2006/02/20(月) 13:04:53

漏れはfor_eachを使うからat()もoperator[]も使わんがな。

751 ：デフォルトの名無しさん：2006/02/20(月) 21:13:31

STL
ST
S
ST
SLL

752 ：デフォルトの名無しさん：2006/02/20(月) 22:08:02

at は安全だっつって使っておきながら catch してない人が居たなあ……。

753 ：デフォルトの名無しさん：2006/02/20(月) 22:49:12

>>752
投げられる例外すべてを catch する必要は無い。

754 ：デフォルトの名無しさん：2006/02/21(火) 12:42:04

>>752
コケてくれるという事は、検出出来ている、という事です。
安全ですね

755 ：デフォルトの名無しさん：2006/02/21(火) 12:59:15

「こけてくれる=安全」といえばこんな思い出が。
学生時代、あるプロジェクトにバイトで火消し投入された。
バイトを投入するあたり、相当DQNな会社だったわけだが、
まぁ投入される方としては時給もよかったしラッキーって感じ。

で、いつまで経っても原因不明のバグが出たりでなかったりで
リリースできん、って言う物だったんだけど、社内で共通に
使ってるライブラリみて唖然とした。すげぇ臭い物に蓋な
プログラム。例えば年齢を引数に取るコードで、負の値が
与えられたら勝手に0と見なす、みたいなことやってる。
で、漏れが assert 入れたら、お前のせいでバグが増えたってしばかれた。

756 ：デフォルトの名無しさん：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;
};

757 ：デフォルトの名無しさん：2006/02/21(火) 15:03:53

class a{
...
};
static std::map<int,int> a::b; ← static メンバは外部定義しないとダメポ

758 ：デフォルトの名無しさん：2006/02/21(火) 15:09:38

>>757 宣言もしてないのにそんなこと出来るの？

759 ：デフォルトの名無しさん：2006/02/21(火) 15:34:47

その質問はよくわからんな

760 ：デフォルトの名無しさん：2006/02/21(火) 15:36:11

僕がSTLより高速なコードを書ける日来ますか？

761 ：デフォルトの名無しさん：2006/02/21(火) 15:36:34

来ません。

762 ：デフォルトの名無しさん：2006/02/21(火) 15:49:21

>>756
何その糞コンパイラ。

763 ：760：2006/02/21(火) 16:03:57

>>761
ありがとうございました。
それが分かっただけでも大満足です＾＾

764 ：デフォルトの名無しさん：2006/02/21(火) 16:54:05

>>757
以下のようにしたらエラーが出なくなりました。
ありがとうございます。

#include <MAP>

class a {
public:
　　static std::map<int,int> b;
};

std::map<int,int> a::b;

765 ：デフォルトの名無しさん：2006/02/21(火) 17:19:24

>>762
そのレスは意味が分からん

766 ：デフォルトの名無しさん：2006/02/21(火) 17:53:27

>>755
続きは？

767 ：デフォルトの名無しさん：2006/02/21(火) 18:36:01

>>766
確かにちょっと気になるな

ワッフルワッフル

768 ：デフォルトの名無しさん：2006/02/21(火) 18:52:03

それはつまり、どういうイヤらしいしばかれ方をしたか
詳細を書けということだな

ワッフルワッフル

769 ：デフォルトの名無しさん：2006/02/21(火) 22:58:38

キャッチしなくていいってのは、例外安全無視ってこと？

770 ：デフォルトの名無しさん：2006/02/21(火) 23:02:21

>>769
関係ない。「例外安全」の意味わかってんのか？

771 ：デフォルトの名無しさん：2006/02/22(水) 07:02:16

>>769
キャッチ漏れがあっても最後に確実に検出できるのがいいとこでそ。

772 ：デフォルトの名無しさん：2006/02/22(水) 07:10:09

関数内でエラーを拾った場合に、メンバ変数なり引数変数なりを
関数呼び出し前の状態に戻しておいて、処理が呼ばれなかったことにしつつ
例外を投げるのが例外安全だっけ？

773 ：デフォルトの名無しさん：2006/02/22(水) 07:32:38

>>772
それは例外安全性のレベルが与える保証のうち、強い保証というもの。

774 ：デフォルトの名無しさん：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にあることくらいは理解した方がいい。

英語苦手でも、簡単な英語で書かれているから、翻訳ソフト併用で問題なく読めるはず。

775 ：デフォルトの名無しさん：2006/02/22(水) 08:44:20

Deep C++にも例外の記事があったような気がしたがどうだっけ？

776 ：デフォルトの名無しさん：2006/02/22(水) 08:47:35

手元に「Exceptional C++ (訳本)」があるので、
例外中立と例外安全のところ読み返しときます。

777 ：デフォルトの名無しさん：2006/02/22(水) 08:47:42

>>775
あれは連載の途中で間違いの訂正が入っていたりするんで
途中だけ読むようなことは危険。
通して読めば、例外への誤解～理解を追えるので有益。

778 ：デフォルトの名無しさん：2006/02/22(水) 09:03:16

例外中立も例外安全も知らずに
例外を使っていたオレ。

779 ：デフォルトの名無しさん：2006/02/22(水) 09:35:50

Schmidtってちょっととぼけたところあるからな。
筆量はすごいんだが。

780 ：デフォルトの名無しさん：2006/02/22(水) 09:39:44

>>752はやっぱり変な気がする。
最終的に例外キャッチしない場所だったら、at使うよりも、
デバッグ版のSTL使うとか、assert入れるとか、デバッグ版とリリース版で[]とatを切り替えるとか
するのが筋でなかろうか。
まぁ速度気にしないならどうでもいいけど。

781 ：デフォルトの名無しさん：2006/02/22(水) 09:56:15

>>780
最終的に例外をキャッチしない場合でも範囲オーバー時の動作が違うわけで。
operator[]() で範囲オーバーしたら未定義動作。
at() で範囲オーバーしたら terminate() 。
環境によってはこれだけで十分な理由になり得る。

782 ：デフォルトの名無しさん：2006/02/22(水) 14:49:38

あー確かに。「誤動作即再起動」なプログラムには充分意味があるよ。
U/I持ってたらそうはいかないんだろうけど。

783 ：デフォルトの名無しさん：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

784 ：デフォルトの名無しさん：2006/02/22(水) 18:11:01

aのsortに合わせてbの要素も入れ替える様、sortを修正しろ。

a,bが小さいなら、class x { double a; int seq; } でseqに順番入れてソート、
bをseqみながら入れ替え。

785 ：デフォルトの名無しさん：2006/02/22(水) 18:19:03

>>783
boost::zip_iterator + a だけを見る比較
でいけるんじゃね？

786 ：783：2006/02/22(水) 18:25:56

レスどうもありがとうございます。
STL の sort をどこかに copy して修正すればいいのでしょうか？
STLの改造は今までやった事がないので、よく分からないのですが、
sort 命令に相当する source をSTLの中から探し出して、
それを改造し、自前で修正し、新たなソースファイルに
するということでしょうか？それともsort 文だけ
再定義する方法があるのでしょうか？

787 ：783：2006/02/22(水) 18:28:37

786は784へのレスです。
>>785
そんなのがあるのですか！boost::zip_iterator というのは
使ったことがなかったのですが、ぜひ勉強してみます。
やはりSTL だけでスマートにやるのは難しいでしょうか？

788 ：デフォルトの名無しさん：2006/02/22(水) 18:36:48

>>786
sortを修正すると言うより、sortに渡す関数オブジェクトを作れと言うことだろう。

789 ：デフォルトの名無しさん：2006/02/22(水) 19:32:27

関数オブジェクトによるソートといえば、
VC6のstd::list::sort()は欠陥で有名だよな。
std::sort()は大丈夫だけど。

790 ：デフォルトの名無しさん：2006/02/22(水) 19:47:39

xをsortしてから、a,bに全要素コピーし直す…
空間的にも時間的にも無駄が多いが

sortを自分で書くしかないか？
std::sortをコピペしてきて
swapの部分だけ二重にするとか

この2通りしか思いつかない

791 ：デフォルトの名無しさん：2006/02/22(水) 19:55:17

aのソート結果を使ってコピーする関数オブジェクトを作ってbからbNewにコピーしたら?

792 ：783：2006/02/22(水) 19:55:36

>>788
レスありがとうございます。
790さんが言われるように swap 自体を書き換えないといけない
ような気もするのですが、いかがでしょうか？

793 ：783：2006/02/22(水) 20:25:16

>>791
すみません、関数オブジェクトを使い慣れていない初心者でして、
考えてみたのですがよく分かりませんでした。具体的に
どのようにすればよろしいでしょうか？

794 ：デフォルトの名無しさん：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をすべてコピーする

795 ：デフォルトの名無しさん：2006/02/22(水) 20:55:42

>>789
VC6はそういうの苦手なの有名じゃん

796 ：デフォルトの名無しさん：2006/02/22(水) 21:01:24

std::sort(pair_iterator(a.begin(), b.begin()), pair_iterator(a.end(), b.end()));

で、両方のイテレータを操作してくれるような
イテレータアダプタ pair_iterator を作ればいいんじゃね？

797 ：デフォルトの名無しさん：2006/02/22(水) 21:18:41

>>796
それはsort側で両方の要素を同時にswapできるのか？
iteratorの指す先は単一の要素の気がするが

798 ：797：2006/02/22(水) 21:26:45

std::swapを特殊化すればできるかもしれないが、
前スレ
http://pc8.2ch.net/test/read.cgi/tech/1116559700/
の議論によれば、
std::sortがstd::swapを使用する保証はないらしい

799 ：デフォルトの名無しさん：2006/02/22(水) 21:36:20

>>795
苦手て(w

800 ：デフォルトの名無しさん：2006/02/22(水) 22:08:43

>>799
んじゃ正確に

ダメぽ

801 ：783：2006/02/22(水) 22:50:23

>>798
なるほど、そうですか。。。
>>794 の方法や、>>784 の class x { double a; int seq; } の方法で
地道にやる事にします。sizeof(double) > sizeof(int)なので、転送する
バイト数が少ない int seq の方法が有利かも。
いろいろとどうもありがとうございましたm(__)m ＞皆様

802 ：デフォルトの名無しさん：2006/02/22(水) 23:10:09

配列インデックスの配列 vector<size_t> c を作って、
比較関数に a[c[i]] < a[c[j]] のようなものを渡して sort() 。
あとは出来上がった c に従って a, b を並べればいい。
ダメかな？

803 ：デフォルトの名無しさん：2006/02/22(水) 23:13:40

index table (permutation) から実際の配列をソートしなおす
アルゴリズムって結構面倒だったような

804 ：デフォルトの名無しさん：2006/02/22(水) 23:15:46

最適化は後からやればいいんだよ

805 ：デフォルトの名無しさん：2006/02/22(水) 23:24:38

>>803
テンポラリ使えば簡単。

806 ：783：2006/02/22(水) 23:34:43

>>802 >>805 そうですね。この方法がベターな気がします。
どうもありがとうございました。

>>803 あくまでも tmp を使わない方針で、index table から配列を
ソートしなおすアリゴリズムを実装する位なら、最初から自前で
直接 sort する関数を作ってしまう方がよさそう(w

807 ：デフォルトの名無しさん：2006/02/23(木) 02:01:07

車輪の再発明をして、STLとのパフォーマンス差に愕然としないと、
一流のプログラマにはなれませんよね？

808 ：デフォルトの名無しさん：2006/02/23(木) 02:09:05

>>807 先にソースを読んで悟ることができる人もいるだろう。

809 ：デフォルトの名無しさん：2006/02/23(木) 02:12:13

プログラムを書くのも大事だけど、人のソースを読むのもかなり大事なんだよな
能力を高める秘訣については俺も知りたいもんだけど

810 ：デフォルトの名無しさん：2006/02/23(木) 08:09:54

人は、「vectorなんて初心者向けだろｗ」とタカをくくって、後で間違いに気づく。

811 ：デフォルトの名無しさん：2006/02/23(木) 09:56:52

真の初心者にはstd::map<long, T>を使わせるべき。

812 ：デフォルトの名無しさん：2006/02/23(木) 10:45:02

再発明した車輪の改良をして、STLとのパフォーマンス差に優越感を抱いた後で
例外安全とか柔軟性の差に愕然としないと一流のプログラマにはなれません

813 ：デフォルトの名無しさん：2006/02/23(木) 10:48:28

初めて出会った時からSTLにどっぷり依存してるから、
STL使わないという人を本気で不思議に思う。

814 ：デフォルトの名無しさん：2006/02/23(木) 11:03:33

初期の漏れ
　どうでも良いところをstl任せにできるから、
　重要な部分のチューニングに時間取れてｳﾏｰ!

今の漏れ
　パフォーマンスはどうでも良いのでstlで出来ることは非効率でも全てstl任せ。
　その分上位構造として複雑なアルゴリズムで難しい処理が実装できてｳﾏｰ!

特定の処理の実行速度だけ見ると昔の漏れの方が優秀・・・

815 ：デフォルトの名無しさん：2006/02/23(木) 11:09:10

STLは、フレームワークでもあるから、
自前特定領域チューニングコンテナを作る時にも設計の手間が大幅に省ける。
ステファノフ万歳

816 ：デフォルトの名無しさん：2006/02/23(木) 11:29:14

>>814
STL使用コードを低レベルなバッファアクセス並みに高速化できないのは、単に君が努力不足だから。

実体コンテナを使うだけでなく、その各要素へのアドレスvectorを利用すれば、
いくらでも低レベルなバッファアクセス並みの速度にできる。

817 ：デフォルトの名無しさん：2006/02/23(木) 11:38:55

sort()がswap()所以で遅いというなら、ポインタ配列に入れてCライブラリのqsort()すればいいだけ。
STLだと遅くなるとか言ってる奴は馬鹿丸出し。

818 ：デフォルトの名無しさん：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

819 ：デフォルトの名無しさん：2006/02/23(木) 11:44:47

boost 使えばいいのか・・・

820 ：デフォルトの名無しさん：2006/02/23(木) 11:54:29

>>818
＞vector< int > hoge(); hoge.reserve(N); だと効率悪いし・・・

は？vectorのせいじゃなくて、動的メモリを確保するタイミングが悪いだけだろ。
STLコンテナ使用をやめてallocやnewで記述したとしても同じことだ。
設計の段階から見直すことが先だろう。
同じバッファが再利用できないか、つまりは、スコープの見直し。

821 ：デフォルトの名無しさん：2006/02/23(木) 11:57:33

boost::ptr_container ?
早くこれにもシリアライザを用意して欲しいな。
まぁシリアライザだけ自分で書いてもいいけど。

822 ：デフォルトの名無しさん：2006/02/23(木) 11:57:38

>>818
Nが固定ならvector(size_type n)を使おうよ…

823 ：デフォルトの名無しさん：2006/02/23(木) 12:03:27

>>820
再利用できないとき、
あるいはしたくないときにはどうすればよいのか教えてください。

特にマルチスレッドのプログラム（やスレッドセーフなライブラリ）の場合
なかなかそう都合よくは行かないことも多くて。

824 ：デフォルトの名無しさん：2006/02/23(木) 12:05:41

>>822
それだと最初からサイズNじゃない？
>vector< int > hoge(); hoge.reserve(N);
と意味が違うような・・・

というか(スレ違いだけど) boost::array<int, N> hoge; で解決。

825 ：デフォルトの名無しさん：2006/02/23(木) 12:08:14

>>824
あ、やっぱりboost::array は完全固定サイズだから、
「高々Nの可変長」ってのとは違うような・・・

寝ます。

826 ：デフォルトの名無しさん：2006/02/23(木) 12:09:01

>>824
何言っているか理解不能。
お題をちゃんと示せよ。

827 ：デフォルトの名無しさん：2006/02/23(木) 12:12:29

＞なかなかそう都合よくは行かないことも多くて

多いか？
不可能であると頑なに決め付ける根拠が希薄なわけだが。

828 ：デフォルトの名無しさん：2006/02/23(木) 12:22:23

「高々N」は「上限がN」ということなので、上限固定として扱って問題ないと思うが、
「高々N」とはどういう意味で使っているのか?

829 ：デフォルトの名無しさん：2006/02/23(木) 13:28:16

もう面倒だからvalarray使えや

830 ：デフォルトの名無しさん：2006/02/23(木) 13:34:15

多分capacityが不変でsizeが可変なvector風コンテナのことを言ってるんだと思う。

831 ：デフォルトの名無しさん：2006/02/23(木) 13:57:40

だったらvectorでいいような。

832 ：デフォルトの名無しさん：2006/02/23(木) 13:59:10

いや、vectorだとスタックに取れない。

833 ：デフォルトの名無しさん：2006/02/23(木) 14:01:50

上限はそうだけど、なるべくメモリ消費したくないのでは？

834 ：デフォルトの名無しさん：2006/02/23(木) 18:56:02

自分でスタックに確保するアロケータを作ってそいつをstd::vectorに渡せばいけるのでは？
と思ったが、標準のコンテナに渡せるアロケータの要件を守れなさそうな気がする。

835 ：デフォルトの名無しさん：2006/02/23(木) 19:20:58

そこで、std::basic_string<Hoge>。
VC8だと。16バイトまではstackに確保してくれる実装になってた。

836 ：デフォルトの名無しさん：2006/02/23(木) 19:48:35

>>835
basic_stringは制約が・・・

837 ：デフォルトの名無しさん：2006/02/23(木) 23:58:27

>>834
allocate()でalloca()使ったからといって問題になることはないよ。

838 ：デフォルトの名無しさん：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限定だけど、こんなへんてこ仕様の非標準関数はあまり使いたくない

839 ：デフォルトの名無しさん：2006/02/24(金) 11:45:02

べつにallocaなんて使わなくても、内部に配列を抱え込めば済む話じゃ。

840 ：デフォルトの名無しさん：2006/02/24(金) 11:52:01

まあ「高々N」だからな。

841 ：デフォルトの名無しさん：2006/02/24(金) 11:54:41

>>838
変な仕様というか、allocaの引数が可変だから、
スタックチェックに引っ掛からないように調整し直す必要があるんだろ?
通常終了時は関数出口辺りで調整するコードを実行するんだろうけど。

842 ：デフォルトの名無しさん：2006/03/08(水) 19:40:47

STLで環状リストってありますか？
++iteratorでぐるぐる回るやつが理想です。

843 ：デフォルトの名無しさん：2006/03/08(水) 20:41:51

ないです。

844 ：デフォルトの名無しさん：2006/03/08(水) 20:45:42

++iteratorの代わりに、
++iterator; if (iterator == ringList.end()) iterator = ringList.begin();するだけだろ。

845 ：デフォルトの名無しさん：2006/03/08(水) 21:12:04

>>843-844
レスありがとうございます。やはり無いですか。
>>844で示されたようにすればいいんですが、環状リストとして扱っているということを
コード上にも(アルゴリズム的に)反映させたいと思ってたので残念です。

846 ：デフォルトの名無しさん：2006/03/08(水) 21:20:33

>>845
844の動きをするイテレータを自作すればいいと思うのだが。

847 ：デフォルトの名無しさん：2006/03/08(水) 21:43:24

>>844みたいなことを内部的にしたいが為だけにiteratorのクラステンプレートを
自作するのは、まぁ、億劫な話だわな。

848 ：デフォルトの名無しさん：2006/03/08(水) 21:58:09

そこでboost iteratorsですよ。

849 ：デフォルトの名無しさん：2006/03/08(水) 21:58:51

そんなあなたにBoost.Iterator

850 ：デフォルトの名無しさん：2006/03/08(水) 22:01:06

つboost::iterator_adaptor

851 ：デフォルトの名無しさん：2006/03/08(水) 22:04:09

>>848-850
おまえら、合体しる。

852 ：デフォルトの名無しさん：2006/03/09(木) 01:20:26

>848-850をbindしようと思います

853 ：デフォルトの名無しさん：2006/03/09(木) 08:18:30

>>845
添字を循環させるってのはどう?
index = (index + 1) % array.size();

854 ：デフォルトの名無しさん：2006/03/09(木) 08:37:59

>>853
そういうことをするoperator []を持つコンテナを作るってのはどう?

855 ：デフォルトの名無しさん：2006/03/09(木) 08:41:18

>>854
まあ、言いたいのはそういうことです。
fetch_first, fetch_next, fetch_last で実装してもいいかも。

856 ：デフォルトの名無しさん：2006/03/09(木) 14:47:51

boost::iterator_adaptor で実装しようと思ったら思いの他難しいな…。

857 ：デフォルトの名無しさん：2006/03/09(木) 15:51:30

RandomAccessIteratorの要件を満たさないから
そこだけmpl::if_で分岐を入れる必要があるな。

858 ：デフォルトの名無しさん：2006/03/09(木) 15:59:35

ブーストってなんですか＞＜？

859 ：デフォルトの名無しさん：2006/03/09(木) 16:22:14

そろそろ "＞＜" を NG ワードに入れてもいい季節かな？

860 ：デフォルトの名無しさん：2006/03/09(木) 16:25:20

やめてください！＞＜

861 ：デフォルトの名無しさん：2006/03/09(木) 22:36:15

>>857
いや，ベースとなるイテレータが RandomAccess なら満たすんじゃないですか？

862 ：デフォルトの名無しさん：2006/03/09(木) 23:12:35

>>834あたり
遅くなりましたが、
ttp://www.tantalon.com/pete/files/gems3update.zip
にある StaticAlloc ってのがそういう感じに使えそうですね。

vector::swap時のアロケータとの整合性とか考えると、
自前でコンテナ書いた方が良いという気もしてきますた。

863 ：デフォルトの名無しさん：2006/03/09(木) 23:23:23

>>861
うまく順序を定められない。
pとqが異なるとき、[p,q)も[q,p)も空でない区間だから、
p < q かつ q < p である必要がある。

864 ：861：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 の意味が一意に定まらず，混乱すると思うので
（最小の正の値を返す，といったような何らかの一貫した立場を取ることはできますが）
個人的にはちょっと設計的に微妙な感じはします．

865 ：デフォルトの名無しさん：2006/03/10(金) 00:54:52

>>864
なるほど、後者の設計を思い付かなかった。
こっちの方がずっと扱いやすそうだ。

866 ：デフォルトの名無しさん：2006/03/10(金) 08:49:14

基本的なことで質問です
STLって便利？ではなくて使ったほうが良いですか？

867 ：デフォルトの名無しさん：2006/03/10(金) 09:11:47

C++でSTL使うのはWindowsをマウスで操作するぐらいに自然なことだ。

868 ：デフォルトの名無しさん：2006/03/10(金) 09:39:06

C++でSTLを使わないのは、裸の女を見てオナニーをするようなものだ。
STLを使うのは、オナニーではなくセックスをするようなものだ。

869 ：デフォルトの名無しさん：2006/03/10(金) 09:44:14

初心者の君が天才でもないかぎり、どんなに頑張ってもSTLより高速なコードは書けないだろう。

870 ：デフォルトの名無しさん：2006/03/10(金) 10:16:35

C++はSTLを使ってこそ本領を発揮できる。

871 ：デフォルトの名無しさん：2006/03/10(金) 10:19:02

>>870
そこまでヨイショするほどのもんでもないと思うが。
でも、STLは使え。>>866

872 ：デフォルトの名無しさん：2006/03/10(金) 10:26:54

>>867
Windowsをマウスを使わずにキーボードショートカットだけで操作するのは別に非効率とは限らないが、
C++でSTLを使わないのは非効率だ。

>>868
裸の女を見てオナニーをしても不毛ではあるがセックスに伴う責任は回避できる。
しかし、C++でSTLを使うことにセックスに伴うような責任は発生しない。

>>866
まぁ、使ってみろ。いいもんだ。

873 ：デフォルトの名無しさん：2006/03/10(金) 10:40:29

そうなんですか・・・これから勉強か～～

874 ：デフォルトの名無しさん：2006/03/10(金) 11:09:03

というか、STLの知識は他の言語でも役立つだろう。
これからどの言語もSTL風のコレクションクラスを持つことになるだろうから。
実際JavaやC#でも…

875 ：デフォルトの名無しさん：2006/03/10(金) 11:28:25

>>874
javaのあの脳味噌が腐ったようなGenerics実装みてよくそんな希望的観測が抱けるな。

876 ：デフォルトの名無しさん：2006/03/10(金) 11:37:25

実装? 仕様じゃなく?

877 ：デフォルトの名無しさん：2006/03/10(金) 11:40:53

>>876
漏れは「仕様」より一つメタな概念としての"Generics"ってのがあって、
C++ の template やら "Java の Generics" ってのはそれの実装だ、
という（脳内で）考えてるので自然に読めますた。

878 ：デフォルトの名無しさん：2006/03/10(金) 11:46:05

まあ仕様の間違いでしょ。

JavaのGenericsは、特殊化なしの制約付きとしてはそれほど悪くないんじゃない？
コアなC++使いにとっては貧弱に思えるけれども。

879 ：デフォルトの名無しさん：2006/03/10(金) 12:21:20

JavaのGenericsは切な過ぎる。
特殊化なしの制約なんてもう耐えられない。

880 ：デフォルトの名無しさん：2006/03/10(金) 12:31:52

特殊化しなくちゃ

881 ：デフォルトの名無しさん：2006/03/10(金) 12:36:26

JavaのCollectionの内部イタレータというのも切ないな。
実装の隠蔽という面からは、あれも正しいんだろうけども。

STL.NETは公開延期だけど、やっぱりJavaよりになるんだろうな。
特殊化はC++とCLOSくらいしかないし。

882 ：デフォルトの名無しさん：2006/03/10(金) 13:40:43

え、特殊化ねーの？(;ﾟДﾟ)

883 ：デフォルトの名無しさん：2006/03/10(金) 15:07:49

C++/CLIはgenericでなく、templateなら特殊化可能だったよ。
genericはnew制約とか余計な思想強制されるんでいらね

884 ：デフォルトの名無しさん：2006/03/12(日) 04:45:43

STLPortの5.0.2を使ってみたりしてるんだけど、
hash_setがなんか遅いような気がする
気のせい？

885 ：デフォルトの名無しさん：2006/03/12(日) 11:44:32

VC7のよりは速い

886 ：デフォルトの名無しさん：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++;
　　　}
　　}

887 ：デフォルトの名無しさん：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]);　// 結果表示
}

888 ：デフォルトの名無しさん：2006/03/13(月) 14:17:13

どうするのが一番いいんだぜ？って何語だぜ？

889 ：デフォルトの名無しさん：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);
}
}

890 ：デフォルトの名無しさん：2006/03/13(月) 15:02:56

なぜvectorから要素を効率よく削除できるのはどうしてだぜ？

891 ：デフォルトの名無しさん：2006/03/13(月) 15:12:13

>面倒なことせずに、簡単に行こうよ。それでパフォーマンステストしてから効率を考えよう。
汎用の部品は最低限の最適化をしておいても損はないと思う。
とりあえず、>>889はO(n^2)なので問題外じゃないだろうか。

892 ：デフォルトの名無しさん：2006/03/13(月) 15:25:50

std::remove_ifは？

893 ：デフォルトの名無しさん：2006/03/13(月) 15:51:35

>>892
std::remove_if()はiteratorが渡されないからインデックス配列を扱う用途には向いてない希ガス。

>>891
同意。しかし、vectorの要素をインデックスで削除する用途はそれほどない希ガス。

>>887
インデックスを作る段階で、std::remove_if()をいきなり実行できないのかな?

894 ：886@Athlon64 3000+：2006/03/13(月) 20:33:38

nicegay達、レスありがとうだぜ？
簡単に試したところ、条件次第でremove_ifと速度が入れ替わる（500～1000万件
で±数十ミリ秒程度）のですが、平均的に速そうでかつムラがなさそうなので、
データクラスに削除フラグを持たせてremove_ifを使う方向で考えてみます。

895 ：デフォルトの名無しさん：2006/03/13(月) 20:52:14

>データクラスに削除フラグを持たせて
ほんとにそんな侵入的な方法が必要なのか？
すごく気持ち悪いんだが。

もちろん、おまえが良いというならそれで良いんだけど。

896 ：デフォルトの名無しさん：2006/03/13(月) 21:37:34

要素がスマートポインタ的な実装の場合、テンポラリvectorに生き残りを
コピーしてvectorごとswapするのが速い悪寒だぜ。

897 ：デフォルトの名無しさん：2006/03/14(火) 00:35:14

日本語でおｋ

898 ：デフォルトの名無しさん：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);
}

899 ：デフォルトの名無しさん：2006/03/14(火) 01:23:20

>>894
niceなguyとniceなgayは微妙に違うんだぜ。
両方兼ねている人もいるだろうけど。

900 ：デフォルトの名無しさん：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));
}

901 ：デフォルトの名無しさん：2006/03/14(火) 11:31:03

>>900
ループの最初の一回を外に出してコピーしないようにすると
より高速になりますね。
最初にif (ei != ee)が要りますが。

902 ：デフォルトの名無しさん：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は使用出来ないのでしょうか？
ご教授お願いします。

903 ：デフォルトの名無しさん：2006/03/16(木) 18:38:55

>>902
レガシーな構造体のつもりで安直なメモリ転送したりメモリコピーをしていなければ大丈夫。

904 ：902：2006/03/16(木) 18:44:46

memcpy Zeromemory等の関数は使用してないです。
もちろんstring内データ直アクセスも。
構造体内に構造体が３つあってそこにもstringやらintやら混ざってるのが悪いのでしょうか。
･･･そんなわけないですよねぇ･･･。
ちなみにSTLは.NET2003標準のやつです。

905 ：902：2006/03/16(木) 18:56:06

度々すみません。情報追加です。
構造体を使用しているのはクラスのpublicメンバで、
m_typData.strA = "aaaaaaaaaaaaaaaa";
等としたところでリークしていました。また、上記例から文字が一文字減るとおきませんでした。
その直前までsrAは未初期化の状態です。

906 ：デフォルトの名無しさん：2006/03/16(木) 19:06:34

>>904
その構造体を free で解放してたりしませんか？

907 ：902：2006/03/16(木) 19:11:14

>>906
していません。したら落ちます、構造体自体はそのまま
TYPE_DATA typData; の様な使い方をしているので。
string以外のメンバはint DWORD SIZE RECT POINT さらに構造体などですが、
いずれもメモリ操作系の関数は使用しておらず、すべてoperater =や+=等ばかり使用しています。

908 ：デフォルトの名無しさん：2006/03/16(木) 19:27:56

とりあえず再現性のある最小のコードを貼れ。
話はそれからだ。

909 ：902：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;
}

910 ：デフォルトの名無しさん：2006/03/16(木) 19:39:07

>>909
typDataがスコープから抜ける前にリークチェックしてるよ

911 ：デフォルトの名無しさん：2006/03/16(木) 19:41:20

あと
・mainの戻り値にvoidはやめなさい。
・stdlib.hやcrtdbg.hがなぜ""で囲まれてるのか？

912 ：デフォルトの名無しさん：2006/03/16(木) 19:41:56

正しくはこうやるみたいですよ。試してませんが。

void main()
{
TYPE_A typeData;
typData.a = "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa";

_CrtSetDbgFlag( _CRTDBG_ALLOC_MEM_DF | _CRTDBG_LEAK_CHECK_DF );
return;
}

913 ：902：2006/03/16(木) 19:57:38

解決しました。
実際の方ではWinMainの中でクラス変数を宣言し（そのクラスが構造体を持ってるのです）クラスの関数を走らせ終了する
ようなものになっていたのですが、クラスをポインタにしてnew 及び deleteを行えば解決しました。
STLの問題では無く申し訳ありません。同じスコープ内で有効な物に対してはチェックがうまく働かないと知りませんでした。
ご教授ありがとうございました。

914 ：902：2006/03/16(木) 20:03:39

>>911
前に勤めていた会社の先輩にSTLは<>、その他は""と習ったからです。
違うのでしょうか。
void main(void)に関しても高校時代のポケコンCが･･･
いろいろと間違った知識を使ってきたみたいで恥ずかしいです

>>912
調べて下さってありがとうございます。
試してみたところ_CrtDumpMemoryLeaks無しで終了時にチェックが働く様になりました。

915 ：デフォルトの名無しさん：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;
}

ってすればいいんだけどな。

916 ：デフォルトの名無しさん：2006/03/16(木) 20:22:39

>>914
> 前に勤めていた会社の先輩にSTLは<>、その他は""と習ったからです。
（´Д｀）

917 ：デフォルトの名無しさん：2006/03/16(木) 20:24:02

>>914
前の会社なら問題ないだろうから、その会社名と先輩とやらの名前を晒せ。
ローカルなインクルード以外は全て<>にするのが常識だ。
#プロジェクトローカルをどっちにするかは悩ましいところだが。

918 ：デフォルトの名無しさん：2006/03/16(木) 21:41:43

>>914
その先輩はSTLを標準ライブラリ全てを指す言葉として使っているに違いない。

919 ：デフォルトの名無しさん：2006/03/16(木) 22:20:00

きっとSTLがSTandard Libraryの略だと思ってるんだよ

920 ：デフォルトの名無しさん：2006/03/16(木) 22:27:15

まぁSTLという区分の曖昧さ・中途半端さにも若干の業はあると思うけれど、
その先輩はそれを言い訳にしちゃいけない領域に居るお馬鹿さんだな。

921 ：デフォルトの名無しさん：2006/03/17(金) 10:05:08

STL作った人は余程の自信があるんだろうな。
俺のソースは恥ずかしくて見せられない。＞＜

922 ：デフォルトの名無しさん：2006/03/17(金) 10:35:31

>>921
自信が無くても見せなければならない。

……、それがテンプレートの定め。

923 ：デフォルトの名無しさん：2006/03/17(金) 10:46:39

ｲﾔﾝ

924 ：デフォルトの名無しさん：2006/03/17(金) 13:00:47

ベクトルのリザーブってするとどんな利点があるの？

925 ：デフォルトの名無しさん：2006/03/17(金) 13:09:32

性能的に有利な場合がある
一個ずつpush_backしていくと何度も内部でrealloc©しちゃうけど
reserveしとけばそのサイズを越えるまで無駄なrealloc©をしないことが保証される

reallocによるメモリの断片化の防止とかもあるけど
いちいちメモリ確保&コピーコンストラクタ呼び出しするコストは馬鹿に出来ない

926 ：デフォルトの名無しさん：2006/03/17(金) 13:10:10

927 ：デフォルトの名無しさん：2006/03/17(金) 13:35:17

>>925
あり＾＾

928 ：デフォルトの名無しさん：2006/03/17(金) 13:52:34

>>926
&copyって書けばいいだけのこと。(&copy)

929 ：デフォルトの名無しさん：2006/03/17(金) 13:53:39

ま、それだけのこと

930 ：デフォルトの名無しさん：2006/03/17(金) 14:00:34

♥

931 ：デフォルトの名無しさん：2006/03/17(金) 14:05:42

ああリザーブってキャパシティを保証するだけですか。
もともとキャパシティが必要個数分以上になってれば、リザーブなんか考えずに
ぼんぼこ必要分までプッシュバックしていっておｋ？

932 ：デフォルトの名無しさん：2006/03/17(金) 14:52:32

＞ああ給油ってのはガソリン入れるだけですか。
＞もともとガソリンが必要な量だけ入っていれば、給油なんか考えずに
＞ぼんぼこ目的地まで走っていっておｋ？

OK。

933 ：デフォルトの名無しさん：2006/03/17(金) 15:55:03

リザーブしただけでアプリのメモリ使用量は増えますか？

934 ：デフォルトの名無しさん：2006/03/17(金) 16:06:59

増えるかもしれないし増えないかもしれない。
そもそもreserve()で何もしない処理系もある。

935 ：デフォルトの名無しさん：2006/03/17(金) 16:09:41

>そもそもreserve()で何もしない処理系もある。
それは規格違反な気がするが。
どの処理系？

936 ：デフォルトの名無しさん：2006/03/17(金) 16:37:10

934じゃないけど。
Windowsのことかなー
あいつはallocしても、仮想メモリ空間のアドレスに空きがあればOKのフリするし。
実際にメモリをアクセスしに行ってPageエラーをキャッチして本物の仮想メモリを割り当てる
ってことやってるから、そのタイミングでswapファイルが作れなくなってあぼーんとか、ある。

937 ：デフォルトの名無しさん：2006/03/17(金) 17:40:42

>>936
それは「何もしない」とは大分違うような気がする。

938 ：デフォルトの名無しさん：2006/03/17(金) 23:26:13

resize()で今より大きい個数指定したら再確保すると思うんですが、
その時ってちゃんとリザーブして確保とか、考えられる限り高速に設計されてますか？

939 ：デフォルトの名無しさん：2006/03/17(金) 23:28:43

もちろん

940 ：デフォルトの名無しさん：2006/03/17(金) 23:30:38

じゃあ僕は安心してリサイズすればいいのですね＾＾
ありがとうございました

941 ：デフォルトの名無しさん：2006/03/17(金) 23:31:51

>>938
複雑度が線形以下で実装されていることが保証されている。
「高速に設計」されているかどうかは知らない。

942 ：デフォルトの名無しさん：2006/03/17(金) 23:33:51

そもそもreserve()なんて使いません＞＜