【注意】STLの落とし穴【危険】

1 ：04/12/27 〜 最終レス ：2012/10/27

STL（あるいはboost）を使っていく上で
思わぬ落とし穴、やってはいけない禁じ手などを
晒すためのスレです。暗黙知の解放！

2 ：

vector<auto_ptr>

3 ：

vectorやstringで、.clear()したからといって
メモリも解放されるとは限らない罠。

4 ：

>>2
ん！？危険なの？ちと想像してみよかな・・・

5 ：

>>4
std::sort()などのコピーを伴うアルゴリズムを呼び出した時の事を考えてみろ。
普通ポインタのコピーをしても、ポインタが指しているインスタンスは変化しないという
考えの元に各種アルゴリズムが構築されている。
しかし、std::auto_ptrは、ポインタをコピーするだけで、元のポインタの値は 0 に設定
されてしまう。これにより、複数のポインタから同一のインスタンスを指す事のないように
してあるのがstd::auto_ptrだ。だからこそstd::auto_ptrのスコープを外れた時点で、それ
が指すインスタンスもdeleteできる。
すなわち、コピーコンストラクタと代入演算子のセマンティックスが独自の物で、通常の
ポインタとは全く互換性がない。

6 ：

gcc3以降では、auto_ptrをstlコンテナに入れてるソースは
コンパイルエラーになるようになってるしね。

7 ：

関連？重複？
C言語の見えないバグ、対処法でも語るｽﾚ
http://pc5.2ch.net/test/read.cgi/tech/1064482029/l50

8 ：

>>7
C厨と合流するつもりはない。

9 ：

auto_ptrはほとんど使わないな。
非常に使いにくい。

10 ：

落とし穴つったらアレだろ
コンパイラが対応してないｗｗｗｗｗｗ

11 ：

>>10
STLもまともに機能しない糞コンパイラなぞ捨ててしまえ。

12 ：

糞スレ立てんなよ、バーカ　R＞＞１

13 ：

EffectiveSTLに書いてある以外の落とし穴があるなら
是非知りたいけど

14 ：

>>6
それは、普通でしょう。　auto_ptrはstlのコンテナとは共存できない。
Exceptional C++: Item 37. AUTO_PTR を読みましょう。
ちなみに、auto_ptrをコンテナで使おうとするとエラーが出るのは、Exceptional C++によれば、
auto_ptr's copy constructor and copy assignment operator take references to non-const to
the right-hand-side object. Most implementations of the standard containers' single-element
insert() functions take a reference to const, and hence won't work with auto_ptrs.
とのこと。　boostのshared_ptrは便利だよ。

15 ：

stringの参照渡しではなく、実体渡しってコスト高いのかな・・・
例えば、1000文字程度の文字列が格納されてるstringを関数の引数などで
実体渡しだとか、返却すると高いのかな？
string tail( string a)
{
return a + ":addtail";
}
みたいなコード。
参照渡しって微妙に使いにくいんだよね・・・だから実体渡しにしたいの
だけど。

16 ：

>>15
stringの実装方法による。大抵のstringは文字列そのものを別の領域にもっており、
コピーコンストラクタでコピーされるのは管理領域だけという場合が多い。
それよりも、関数内での演算時にコンストラクタが呼び出され、そちらはまともに内容の
方もコピーするので、間違いなく遅くなるぞ。

17 ：

>>15
それでいいと思う。　最近のコンパイラって結構賢いし、あんまり細かいことは気にしない
方がいい。　stringも大抵はリファレンスカウント方式だから、コピーのコストは低い。
ちなみに、C++ではmake copying cheaperは一つの鉄則。　特に、STLユーザーは。
(Effective STL: Item 3参照)　C++でもJavaみたいにプログラミングするのがいいみたい。
また、Efficent C++ Chapter 4. The Return Value Optimization参照するといい。

18 ：

>>16,17
ほうほう、なるほど。
んじゃ、stringの場合、もう参照渡しにする理由なんてない
気がするなー。
サンクス。

19 ：

>>18
Efficient C++でも読んでみるといいかも。

20 ：

便乗して自分も質問・・・
vector< string > なんかを返却するのは危険だろうか？
例えばの用途としては、ファイル名を列挙するサービスを作ったとして、
その場合、なんらかの形で配列を返しますけど、安全性考えるなら
vectorだとか使いたいところ。それも、返却で。
アセンブリリスト出力させても、いまいち分からないし。
特にSTL内部の謎シンボルにcallだとかjumpされるともう追えない (;-;)

21 ：

>>20
危険でも何でもない。std::vectorのコピーコンストラクタが全部面倒みてくれる。
もちろん参照を返す場合は、ローカル変数の参照を返してはいけない事などは
他のクラスやPODと同じ。

22 ：

逆落とし穴？ってとこかな。有名だけど、一応足跡残しとこうかな。
vector<>ってアドレス的に連続性が保障されてるって、みなさん
知ってました？
例えば、vector< char > tbl;
とあって、tbl.size()==nな場合、
tbl[0]からtbl[n-1]は連続したアドレスであることが保障されてるんだってさ。STLの仕様として。
なので、char*p = &tbl[0] とかやって、その後は *p++ = 0x00 だとかで
アクセスできてしまうと。iteratorを使う必要もないみたい。
でもdequeでは、保障されてるのか、保障されてないのか不明。
明記された文書も見たこと無い。
listあたりだと確実に連続してないので、気にならないけど
dequeは気になるなー。

23 ：

>>危険でも何でもない。std::vectorのコピーコンストラクタが全部面倒みてくれる。
あ、いや、おそらく20はそのコピーコンストラクタのコストを気にしてると
思うんですが。例えば、stringが100個くらいあったとして、それを返却すると
関数出口で発動するコピーコンストラクタがまじでコピーしているのか否か？など。

24 ：

>>22
ISO/IEC14882:2003ではstd::vectorの連続性が保証されてるよ。
§23.2.4の当たり。
std::dequeは保証されてない。

25 ：

ついでに調子こいて。
vector<bool>の時だけは特殊カスタマイズ発動して、ビット操作を意識した
コードが生成されるみたい。ビットセットなんかでメモリかつかつの時は
積極的にvector<bool>を使うといいみたい。

26 ：

>>23
それだったら、std::vectorの実装による、としかいいようがない。
Copy On Writeなら、要素を変更しようとしない限り、管理情報のみを返すかもしれない。
const参照なら戻り値最適化をしてくれる可能性がさらに高まる。

27 ：

vector<bool>は>>25の理由で正常にサイズが取得できないから使うな、と
聴いたことがあるんだけど…
ビットセットはそのままstd::bitsetじゃダメなん？

28 ：

>>25
Effective STL第18項。
std::vector<bool>はコンテナの要件を満たしていない。
それよりもboost::dynamic_bitsetの方がまだましだろ。

29 ：

stringだとか<<だとか使い始めて気になるといえば、
c言語時代のprintf可変調引数って便利だったなと。
%05dで0つめてくれたり。%08xで16進表記してくれたり。
.printf()というか.vsprintf()に相当するユーティってありそうだけど
見たことない。ご存知のかたいますー？

30 ：

boost::format

31 ：

＞const参照なら戻り値最適化をしてくれる可能性がさらに高まる。
あー、そうかそうか。大抵の用途は確かに結果受け取りの
const参照で済むから、これからはこまめにconstつけてこうかな。

32 ：

>>29
そんなに標準の書式マニピュレータを使うのが面倒か。
std::setw()以外は効果がストリームに残ったままになってしまうので元に戻すのが
面倒と言えば面倒だが。
直接フラグをsetf()/unsetf()でいじってもいいしな。

33 ：

結構、みなさんboost使ってるんですね。
自分は使ったこと一度も無い。ものにもよると思うんだけど、
「これないと損するから黙って使え！」というくらい強烈なお奨め
boostモジュールってある？

34 ：

boost::bind、boost::shared_ptr

35 ：

boost::lambda (かなりコンパイラを選ぶ)

36 ：

boost::regex
手軽に正規表現使うにはいい

37 ：

boost::mplは基地外のためのライブラリかも。これで書かれたプログラムを見て
発狂しそうになった。

38 ：

とりあえずスマートポインタを初めとして、
次期標準に入ることが決まってる物は使って損はないと思われ

39 ：

template <int leftShifts_, int rightShifts_>
Int_ convert_(Int_ v) const {
return
boost::mpl::if_c <
(rightShifts_ == leftShifts_),
NoShiftPolicy,
boost::mpl::if_c <
(leftShifts_ > rightShifts_),
LeftShiftPolicy<leftShifts_-rightShifts_>,
RightShiftPolicy<rightShifts_-leftShifts_>
>::type
>::type::shift(v);
}
これ、c++のソースなんですか？
意味不明〜

40 ：

>>次期標準に入ることが決まってる物は使って損はないと思われ
STLくらい標準であれば安心して使えるのだけどねー。
vc++、gccどちらでも同じソースをコンパイルできなければならない仕事を
抱えてるため。
でも次期標準決定してるなら、そろそろ馴れとかねば。

41 ：

>>40
基本的にはSTLと同じ感覚で使えるので（かゆいところに手が届く感じ）
馴れるというより使ってみればすぐ分かるかと。
（spiritやlambdaは別として）
http://boost.sourceforge.net/regression-logs/
コンパイラの対応状況はここで見れば分かりますが、
VC7.1〜とgccならほぼ全て問題ないと思われ

42 ：

>>20
関数で危険なのは、ポインタやレファレンスを返すとき。　特に、関数内部で作られたオブジェクトを
ポインタやレファレンスで返すのは重大な誤り。
この場合のオーバーヘッドが気になるなら、shared_ptrを用いるとよい。　shared_ptrを用いれば
Javaのようにオブジェクトを扱えるのでメモリ管理を気にしなくてよい。　ただし、構文が少し
煩雑になるという欠点を持つ。　*や->演算子を多用するから。
例：
typedef vector<string> VectorString;
typedef shared_ptr<VectorString> RefVectorString;
RefVectorString v(new VectorString());
v->push_back("Hello");
VectorString::iterator it = v->begin();
cout << *it;
RefVectorString f(){
RefVectorString v(new VectorString());
v->push_back("Hello");
return v;
}
RefVectorString v2 = f();
もOK!

43 ：

鬱だ… STL

44 ：

>>42
お前みたいな初心者が出てくると、かえって混乱するから引っ込んでてくれ。

45 ：

>20 >42
基本的にはどこかで作ったvector<string>を「丸ごとコピーして」
値返しするんじゃない？
なので、スタックに積まれたvector<string>でも、戻り値は
「丸ごとコピーした」値なので、ローカルスコープを抜けて
元のvector<string>が削除されても戻り値に影響しないはず。
>26
そんな無茶なRVOあるの？
>33
boost::test
CPPUnitよりセットアップが簡単。ガリガリ手書きする必要あるけどね。

46 ：

المغاربيعلىخالتاريخية
خصصةلمنالرأي كانتص
العاهلالمغربيلموريتانيا،ولكنل

47 ：

>>15
boost-sandboxにあるBoost.Moveとかも見てみたら良いかも知れませんよ．
実体返しと構文一緒で効率は参照渡し並で（ﾟдﾟ）ｳﾏｰみたいな．
"Move"の概念がイマイチ浸透してないのとドキュメントが未整備なために
非常に取っ付きにくいライブラリですけれど．
>45
＞boost::test
bjamのunit-testルールと組み合わせるとbjamと打つだけで
ビルド後即単体テストな感じでさらに（ﾟдﾟ）ｳﾏｰ．

48 ：

>>46
だったら、一辺OCAMLやHaskellかじってみたらジェネリックプログラミング
ってなにかよく理解できるとおもうよ

49 ：

例えばboostのスマートポインタ(shared_ptr)を使うことにした場合、プロジェクト全体で使うように
統一する？
それとも複数箇所から参照されるようなオブジェクトだけにしておく？

50 ：

統一しておかないと、そのうち同一プロジェクト内に複数の
リファレンスカウンティングスマートポインタが蔓延する罠。

51 ：

その場合、生ポインタも禁止？

52 ：

std::getline(std::basic_stringを引数に取るもの)も上限指定できないから、
無茶苦茶行数の長いテキストを読み込ませるなんて攻撃ができる。
なんて話をこの前C++スレで見かけたな。

53 ：

見かけるもなにも有名な話なんで

54 ：

今時basic_stringがCOWなSTLってあるんですか？

55 ：

>>52-53
ぐぐっても見つからない。ほんとに有名な話なのか？

56 ：

>>22
内部の実装はべた配列だ。だからといってメモリのアドレスを取得して（
そもそも iterator がポインタだったする）vector にアクセスするのは間違いだ。
社会に出たらやっていいことと悪いことを見分けなければならない。
内部のメモリポインタを取得して操作したいのなら valarray を使おう。
単純なループをまわすとき iterator を使おうが [] でアクセスしようが、
ポインタを使ったときと同じ速度のコードをはいてくれる。
今時ポインタのほうが速いというのはうそだと思っていいだろう
（もちろんレジスタの割り当てを気にするくらいの限界のチューニングをするときは違うかもしれないが）。
http://www.nantekotta.com/stl.html

57 ：

std::stringの最後は\0とは限らないので、
終端の判別は必ずイテレータが終わりかどうかを調べること。

58 ：

>>56
vector のメモリレイアウトはC言語の組み込み配列と同じだよ。
そんなメンテナンスされてない古い記事引用して何が言いたいの？

59 ：

>>58
社会に出たらやっていいことと悪いことを見分けなければならない。

60 ：

>59
うん、それは当然だと思うよ。で、その言葉にもう一言加えさせてくださいな。
「社会に出たらなぜそれをやって良いか/悪いかを人に納得できるように説明できなければならない」

61 ：

>>57
イテレータ使ってループ回しておきながら 0 で終端判定ってのは中途半端な間違いだな。
そんな間違いする奴は string の要素に 0 が入ってたりしても嵌るんだろうな。

62 ：

>>59
だったら>>56を間違いであると見分けることができないとな。

63 ：

付けたしだけど、私もiteratorでアクセスできる場面でポインタを使うことにはもちろん反対ですよ。
CのAPIとデータをやりとりする際の一時バッファとして利用する場合などでは
ポインタによるアクセスは（vectorが空でなければ）安全で有用だという主張です。

64 ：

ところで
＞内部のメモリポインタを取得して操作したいのなら valarray を使おう。
これってOKだっけ？valarray自体カビの生えた前時代の遺物なので
どうでもいいっちゃどうでもいいんだけど

65 ：

Cに渡すときはポインタと個数を渡すから
ベクタが空でも、個数も0なんで
結局安全なケースがほとんどだと思うが

66 ：

>>65
C/C++使うんなら未定義動作に気をつける覚悟を持たなくちゃ。

67 ：

普通定義してあるって・・・

68 ：

>>67 未定義動作が何のことか知ってて言ってるのか？

69 ：

>>68
うん。で、何が言いたいの？
まぁどうせ急に絡みたくなっただけなんだろうけど。

70 ：

>>66はCの配列とvectorを比較しているわけではなく、
配列の先頭ポインタと個数を渡すというインターフェース自体が
危険だと言いたいのだろう。

71 ：

>>69
ベクタが空な時はポインタ取っちゃダメ。

72 ：

>>70
ちがうよ。なんでそうなる？

73 ：

vectorが空の場合にしても、
Cの配列との比較にもvalarrayとの比較にもなってないから、
一体何を言いたいのだろうと考えた結果の結論でした。
失礼。
まだ>56の話かと思ってました。

74 ：

void hoge(int n, int* ptr) {
　int i;
　for(i = 0; i < n; ++i) {
　　hogehoge(ptr[n]);
　}
}
みたいな、Cルーチンに、
　hoge( &vect[0], vect.size() );
とかやると、本当にvectが空のときだけは動作が未定義なの？
そういう無駄なチェックを要求するう糞ったれな仕様は、やめてほしいんだが

75 ：

hogeがそういう実装なら、nが0の場合はptrはアクセスされないんだから
未定義な訳がない気がするが
一般には、そういう「Cルーチン」の実装によるとしかいえないだろう

76 ：

ちなみに、引数逆でしたな、すまん

77 ：

俺が言いたいのは、Cルーチンのほうじゃなくて
vectorが空のときに、&vect[0]の動作が未定義かどうかってこと
ごみの値でいいから、とにかくポインタを返してさえくれる仕様ならば
何も文句は無い

78 ：

>>74-77
vect.empty() ならば vect[0] の時点で未定義動作。
23.1.1/12 で a[n] は *(a.begin() + n) と定義されている。
23.1/7 により、 a.empty() のとき a.begin() == a.end() であり、
この値はコンテナに対する "past-the-end" と呼ばれる値になる。
24.1/5 により "past-the-end" は "dereferencable" ではない。
24.1.1/2 の票にイテレータ a に対する *a の事前条件として
a が "dereferencable" であることが挙げられている。
（ちなみに、 a が "dereferencable" であることは a + n を定義するための事前条件でもある。）
事前条件を満たさないことになるので、未定義動作となる。
（最後１行だけ、規格中に明らかな記述を見つけられなかった。17.4.3.7かな？）
ttp://www.kuzbass.ru/docs/isocpp/lib-containers.html#lib.sequence.reqmts
ttp://www.kuzbass.ru/docs/isocpp/lib-iterators.html#lib.iterator.requirements

79 ：

>>74-77
http://pc2.2ch.net/tech/kako/1037/10377/1037795348.html
ここの 603-

80 ：

どうやら、そうらしいな
まったくプログラム経験のろくに無い奴が作ったとしか思えん糞ったれな仕様だ
空の時には「未定義のポインタ値」を返すbegin_ptr()とかでもあればともかく
大体STLってのは、馬鹿丸出しの仕様が多い
vector<int> v;
vector<int>::const_itetator it;
　中略
copy(it, v.end(), dest);
こんなあたり前のコードが通らねえから、const_castがいるときた
const_iteratorを返す、cbegin(), cend()ぐらい用意しとけっての

81 ：

>>80
名前は c_str() に倣って c_ptr() とかして
空のときはヌルでも返すことにするとよかったかもしれんな。
あと const_cast は要らんだろう、といちおう突っ込んでおく。

82 ：

vector<int>::const_iterator v_end = v.end();
copy(it, v_end, dest);
とかやれば、要らんけど
やらんと、it は const_iterator で、v.end()はinteratorだから
templateでどっちの型を採用したらいいかわからんといって怒られる

83 ：

つーかこの場合はconst_iteratorの存在理由こそ問題

84 ：

const_iteratorは俺も嫌い
const_iterator ci = v.begin();
iterator i = const_cast< const_iterator >( ci );
これが出来る出来ないよりも、やって良い行為なのか
悪い行為なのかわかりづらい。
全てのiteratorでconst_castのオーバーロード関数を
用意してくれてると良かった。
つーか誰かSTLに詳しい人作ってYO！！STLport用でいいカエラ！

85 ：

>>84
> iterator i = const_cast< const_iterator >( ci );
これ、何がしたいの？
> const_castのオーバーロード関数
これも意味がわからん。

86 ：

>>85
const_cast< iterator >( ci );
これの間違い。
＞> const_castのオーバーロード関数
＞これも意味がわからん。
これこれ。
template< typename T0, typename T1 >
T1 const_cast( T0 );
template< >
std::set::iterator const_cast< std::set::const_iterator, std::set::iterator >( std::set::const_iterator i ){ ...}
これが全コンテナにあったら便利じゃん。

87 ：

間違った、C++の仕様に合わせるとこうか。うぜー
template< typename T >
T const_cast( std::set::const_iterator i );
template< >
std::set::iterator const_cast< std::set::iterator >( std::set::const_iterator i ){ ...}

88 ：

>>86-87
それがあると何がうれしいの？

89 ：

iteratorをmutableメンバ変数として持たなければならない時とか

90 ：

>>89
mutable iterator って宣言すればいいだけじゃない？
const_cast の出番がわからん。

91 ：

>>90
class test
{
std::list<int> c;
mutable std::list<int>::iterator i;
void constant_method() const
{
i= c.begin(); // ERROR
i= const_cast< std::list<int>* >(&c)->begin(); // OK
}
void nonconstant_method()
{
i= c.begin(); // OK
}
};

92 ：

>>91
それは普通の const_cast だろ。>>86-87 で言われてるものとは違うようだが。

93 ：

>>92
説明不足ですまんね。
>>86-87があれば>>91みたいな方法とらずに
いいなーみたいな。それだけ。
まあ、あったらイイナ♪(マイメロふう)程度のもの
なんで真に必要な場面はそうないんじゃない？

94 ：

こういうのがあればいいんだろ
template <class InputIterator1, class InputIterator 2, class OutputIterator>
void copy(InputIterator1 first, Inputiterator2 last, OutputIterator out);
>>86-87みたいなのは、あってもいいけど
紛らわしいから名前を変えた方がいいよね。
const_cast とはやってることが全然違うし。
const_iterator_cast とかなんとか。

95 ：

そういうのがあると、beginとendの型が全く違っててもパラメタがマッチするから
バグの原因だよなあ
結局解決策は、iteratorの種類ごとにcopyの多重定義ぐらいしかなさげ

96 ：

>>95
std::iterator_traits + boost::enable_if
あたりを使えばなんとなるっしょ。
どのくらい制限すればいいかは、議論の余地が大有りだろうけど。

97 ：

>>95
>そういうのがあると、beginとendの型が全く違っててもパラメタがマッチするから
インスタンス化で弾かれるだろ。
俺は>>94が正解だと思う。
http://www.boost.org/libs/iterator/doc/new-iter-concepts.html
で提案されてるInteroperableIteratorってのもそのためのものだよな？

98 ：

インスタンス化による拒否だと実装の深い部分で弾かれるのが若干嫌なので
interoperable iterator + enable_if(もしくはconcept check)というのが最良ですかね．
後，最近iterator, const_iterator間のinteroperability以外に
iterationの情報をiteratorの型にエンコードしてコンパイル時にalgorithmをアンロールする
とか，それと普通のiteratorによるループを融合しようという趣旨の話もちらほらあるので
(Fusionとか最近David Abrahamsがやっているヤツとか)
その関連でも>>94の形が今後ちらほら出てくるかも知れないです．

99 ：

void foo(const string& cstr) {
　string str = cstr;
　・・・
　copy(str.begin(), cstr.end(), dest);
こんなエラーが検出できなくなるのが、ちと気になる。

100 ：

>>99
現状でも↓がコンパイルエラーにならないんで、何が悪くなるとも思わん。
copy(a.end(), b.end(), dest)

101 ：

copy(a.begin(), b.end(), dest)

102 ：

>>80-82
copy(it, vector<int>::const_iterator(v.end()), dest);はどう？ちょっと長ったらしいけど。

103 ：

>>80
> const_iteratorを返す、cbegin(), cend()ぐらい用意しとけっての
これだろ?
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1865.pdf
&v[0]は未定義の方がいいと思う。

104 ：

boost::shared_ptrのget() を無効にしたいのだけど
なにかいい方法あります。

105 ：

>>104
boostの中の人を恐喝して、get()を取り消させる。

106 ：

あっそ

107 ：

>>102
copy(boost::const_begin(v), boost::const_end(v), dest);

108 ：

で、結局、お前らにとってboostって何よ？

109 ：

事実上の標準。

110 ：

ちゅうか、次期標準採用が見込まれるライブラリだろ。
ま、永遠の次期標準ってのも珍しくない業界だけどな。

111 ：

次期標準なら、俺は標準になってから使う。

112 ：

俺は標準化されていない今でも使う。
実際俺にとっては有ると便利ではなく、無いと不便と化している。

113 ：

もはやC++とはboostのことだよ。
MPLのソースなんてどうみてもコンパイラの実装の一部

114 ：

MPLてなに？

115 ：

だめだこりゃ

116 ：

STLが標準じゃないの？

117 ：

>>116
そうだよ。

118 ：

いやつまりＳＴＬがあるんだからいらねーじゃんって話

119 ：

>>118
STLとBoostは排他的な存在ではないです。
BoostにはたしかにSTLの補完的なものもありますが、
そうでないものもかなり多いです。

120 ：

排他的も何もboostって、stlなしで動くとは到底思えんが

121 ：

Boostがなきゃ、最近の言語に作業効率で負けるよ。

122 ：

>>118
C++使ったことないだろ？

123 ：

http://pc8.2ch.net/test/read.cgi/tech/1130680264/
から誘導されてきたんですが、
このスレタイだと質問とかしずらい。

124 ：

>>123
C++相談室 part48
http://pc8.2ch.net/test/read.cgi/tech/1142423595/l50
【初心者歓迎】C/C++室 Ver.25【環境依存OK】
http://pc8.2ch.net/test/read.cgi/tech/1140963340/l50

125 ：

とりえあず、↓の避難所としてこのスレを使い、
使いきったところで相談室 5を立てることが前スレの総意として決定されました。
【C++】STL（Standard Template Library）相談室 4
http://pc8.2ch.net/test/read.cgi/tech/1130680264/

126 ：

>>125 いや、次要らないから。

127 ：

いや、次要るから。

128 ：

[要らない理由]
STLは規格により明確にC++である
C++相談室と分けるほどトラフィックもない（ってか閑散としてる）
もし分けるとなるとC++相談室では「C++からSTLを除いたもの」を主な話題とすることになるが
「C++からSTLを除いたもの」でそんなに話題あるかい？
>>127
要る理由は？

129 ：

それを言い出すとBOOSTスレもいらなくならない？

130 ：

>>129
規格

131 ：

C++相談室であつかうSTLは純粋な文法のみ
STLスレではコンパイラやライブラリによる
実装依存なものまで含んだディープな話題
てなかんじだと私は思っていました。

132 ：

>>131
>コンパイラやライブラリによる実装依存なものまで含んだディープな話題
のスレの名に「STL相談室」はないだろうw

133 ：

STL相談室が出来た経緯
【C++】STL（Standard Template Library）相談室
http://pc5.2ch.net/test/read.cgi/tech/1095583235/
よりコピペ

8 名前：デフォルトの名無しさん ：04/09/19 20:32:58
STLはSTLで分けてほしい。
でないとBoostまで一体化になってしまう。

9 名前：デフォルトの名無しさん ：04/09/20 05:21:12
個人的には、STLだけでも分厚い本がかけるぐらい広大なものだから、STL専用スレがあってもいいとおもうよ。

10 名前：デフォルトの名無しさん ：04/09/20 08:25:11
でもtemplateスレは他のC++スレより書き込み少なめだからそこでSTLも済ませてもいいと思うけど。

11 名前：デフォルトの名無しさん ：04/09/20 12:11:52
STLもBoostもtemplateの応用例の一部に過ぎないから。
そんなものがtemplateスレを埋めたら
PerlスレをCGIの話で埋めるようなもの。

134 ：

>>128
もし必要とされてないならスレは1000まで埋まらないっつの
半年でスレ1個埋まるんだからこの板ならまあまあのスピードだ
決して閑散としてた訳じゃないと思うが？
というか必死になってるのは君1人か、多くて君ともう1人だろ？

135 ：

>>134
同意。ぜんぜん閑散としてない。
なぜそんなに必死にまとめようとしているのかわからん。

136 ：

ヒルズ脳

137 ：

ヒルズにいるとまとめようとしたくなるん？

138 ：

>>135
>>132

139 ：

C++相談室とC++凖標準ライブラリってカテゴライズする案があったかな

140 ：

>>134,135
閑散としてないのはたぶんC++相談室でSTLの話もされてるからだと思う．

141 ：

今までうまくいっているものを変える必要はない。

142 ：

>>141
だったらSTLスレも要らないということになるぞ。

143 ：

だったらお前の存在も要らないということになるぞ。

144 ：

>>142
それはあなたの思いこみだ

145 ：

つか廃止はともかくSTLスレっつう名前はなんとかしない？
おまいらC++相談室でSTLの話題が出ようものならスレ違ってんで
STLスレの方に誘導できるのか？
STLスレって名前を単に存続させたいやつはやってみろよ

146 ：

なんなら俺がやってもいいよ

147 ：

また立ったわけだが。
【C++】STL（Standard Template Library）相談室 5
http://pc8.2ch.net/test/read.cgi/tech/1143608073/l50

148 ：

>>147
アッー！！

149 ：

STL使って落とし穴作れるんですか？

150 ：

ＳＴＬってさ、ちびまるこの花輪くんが、ＯＴＬってしてるみたいだよな

151 ：

>>145
STLなどという意味のない単語そのものの廃止を提案する。

152 ：

>>151 じゃ、以後 OTL で。

153 ：

俺専用テンプレートライブラリ

154 ：

Rー ツール リスト

155 ：

オブジェクトテンプレートライブラリ？

156 ：

http://otl.sourceforge.net/

157 ：

age

158 ：

パソコン買いたい人にココ紹介します。
http://www.excite.co.jp/search.gw?search=%83%5E%83P%83I%83l%81@%8D%C5%8B%AD&target=combined&look=excite_jp&Language=

159 ：

age

160 ：

【C++】STL（Standard Template Library）相談室 5
http://pc8.2ch.net/test/read.cgi/tech/1143608073/l50
これの次スレとして使ったらどうかという話があったので、とりあえずURLを張っておく。

161 ：

すでに次スレが建てられている。

162 ：

おお知らなかった。

163 ：

ho

164 ：

age

165 ：

valarrayのresizeって
vectorのそれと挙動が違うのな。
valarrayはSTLじゃないし、文句は言えないんだけど
これにはやられたよ。
皆さんは知ってました？

166 ：

知らないで使うなんてありえないな。

167 ：

最近のゆとりは
使う前にざっと実装覗いてみる程度もしねーのか…

168 ：

「昔のゆとり」という括りがあるのか？

169 ：

「昔のゆとり」は、スレが立った日時も直前のレスの日付も無視して
沈んでるスレに能書きたれて悦に入るらしいよ。

170 ：

ゆとりどうしなんだからみんななかよくしろよー

171 ：

ゆとり〜　ゆとり〜
お〜れ〜もぉぉ　ゆとり〜

172 ：

ゆとりゆとりって煽ってるやつて、ゆとり教育が昭和何年から始ったか知らないで言ってるんだろうな。
もしくはすごいおっさんか。

173 ：

円周率三桁教育受けた世代の事をそれの一つ前の世代が馬鹿にする意味で言ってるんだと思ってた

174 ：

受験戦争時代より後を、一般的にゆとりと言われてるんだろう。

175 ：

ゆとり教育世代でしょ

176 ：

エロゲー世代じゃね？

177 ：

>>145
本屋さんでは、書名にSTLを含めたものも有るし、「ああ、入門書の次の段階の話で
Boostの手前のレベル辺りを話題にすればいいんだな。」と分かり易いし、
ステパノフに敬意を表したいから、伝統ある用語"STL"を残したいな。

178 ：

ちょっとお聞きしたいのだが
typedef struct tagTestData {
int num;
std::queue<int> que
} TestData
とかやって
TestData *ptr = malloc(sizeof(UserData))
ptr->que.push(1)
とやると，プログラムが落ちるのだが，これってnewじゃないと
だめ？
STLってコンストラクタとか使ってるの？
すごい馬鹿な質問でごめん

179 ：

>>178
その前に、TestData *ptr = malloc(sizeof(UserData))ってことはエラーになるわけだが。
つーか、TestDataかUserDataかどっちなのかと。

180 ：

>>178
使ってる

181 ：

queのコンストラクタ呼び出しが行われておらんな

182 ：

C++でmalloc使っちゃ駄目だろ

183 ：

>>182
typedef struct tagTestData {
なんて書き出してるあたり、
>>178はCでそれなりに経験積んだC++移行中の人なのではないかな。
>>178
C++でmallocは禁じ手だよ。
むしろ存在を忘れてしまっても構わない。

184 ：

C++でもmalloc使ってるおれが来ましたよ

185 ：

どうやって管理すんのさ。間違ってfreeしたらあぼんしないか？
ひょっとしたらハンガリアン？
nwepほげほげ
mlcpほげほげ
あ、これなら徹底すればいけるかもしれないｗ

186 ：

コンストラクタ呼ばれないから駄目絶対

187 ：

そんなにダメだったなんてしらなんだ(((( ;ﾟДﾟ))))

188 ：

>>186
メモリ空間だけ確保しておいて、ナカミはAPIが格納するオブジェクトかも……
あ、ちゃんとカプセル化すればいいのか

189 ：

TestData *ptr = (TestData *)operator new(sizeof(TestData));
new (ptr) TestData();

190 ：

素直にnewできない〜
勇気を私にください〜

191 ：

184じゃないけど、バイナリファイルを読み込むときに new char [] は不自然かと思い、malloc() を使ってる。
テキストファイルのときは new char []。

192 ：

>>191
STLあるんだからfstream使えば？

193 ：

mallocつこてるやつはSTL（テンプレートとクラスの固まりだが）とクラスにmemsetもしてないだろうな

194 ：

>>191
だから、そういう目的のためにoperator newがあるんだろうに。
mallocとの違いは、不足時に例外を出すかどうかだけだよ。実質的に。
STLのvectorの実装でも、内部ではoperator newでブロック確保して使ってる。
(古いものに備えて)malloc使ってるのももちろんあるけど。

195 ：

>>191
んなもんスタックのバッファに確保するかvector<>使えよ
んなところでいちいちmalloc()やnewなんぞ使うな
明示的なdeleteやfreeは恥だと思え

196 ：

>>183
> Cでそれなりに経験積んだC++移行中の人
おれには、Cの教科書でC++のコーディングしてるプログラミング初級者にしか見えない。
>>179も書いているけど、”UserData”がなんなのか分からないと、
質問の意図がどこにあるのかすら分からない。

197 ：

>>194
なるほど。次回からそうする。
>>192,195
型を char とか unsigned char とかにするのが気に入らないと言っているのだが、読み取ってはくれなかった？

198 ：

　　typedef unsigned char byte;
としておけば済むことじゃないの？

199 ：

#include <boost/cstdint.hpp>
using boost::uint8_t;

200 ：

>>195
つまりallocaを使えば万事解決と

201 ：

>>200
標準から外れるという問題が発生。

202 ：

allocaは遅い

203 ：

Mr.malloc よりは速くね？

204 ：

>>203
マリックﾜﾛﾀ

205 ：

>>172
> ゆとりゆとりって煽ってるやつて、ゆとり教育が昭和何年から始ったか知らないで言ってるんだろうな。
> もしくはすごいおっさんか。
>
団塊世代とは中高年の総称である。
○ or ×？

206 ：

>>205
ゆとり教育とは戦後教育のすべててある
教育勅語で教育を受けていない香具師をゆとりという

207 ：

まぁ教育勅語で育った世代が少年だった頃は、
強盗強姦殺人、いずれも今の少年の数倍やらかしてたんだけどね。
多少のゆとりはあったほうがいいな。

208 ：

戦後教育ならＧＨＱ教育と呼ぶべきかも
ゆとりはむしろ極左系の影響を受けてる印象がある

209 ：

まあ、どっちにしても愚民化政策という点で一致してる罠

210 ：

一般的には受験戦争時代より後の、土曜日が授業じゃなくなった
辺りを指すようだな。

211 ：

今の学生は土曜昼下がりのワクワクっぷりを味わえないのか。

212 ：

半ドンも死語だしな。

213 ：

ゆとりっつっても８０年代前半くらいまでの生まれは
受験競争が異様に加熱してた時代で育ってんだよなぁ
子供が勉強漬けになってるって、しょっちゅうマスコミが取り上げてた

214 ：

いまの子供も勉強漬けですよ
学校で教えないから塾に郁子が増えるんだって
で政府の発表の方は学校ベースだから
それをマスコミュが真に受けて増幅してるだけ

215 ：

stlやboostは使わなくなった。ソースが汚くなるわ、デバッグは面倒だわ。
まぁ、納品で永遠におさらばの時だけ使ってるｗｗｗ

216 ：

あー、漏れも納品で永遠におさらばの時だけstlもboostも使わずに済ませるよ。

217 ：

stlやboostの代わりに作られたであろう車輪のことを思うとゾッとするわ。

218 ：

コンテナまで自作か。おそろしく効率悪いことしてるんだな。

219 ：

lambdaとかsplitとか使っていればそりゃ汚くなるわ。

220 ：

C++ってJavaより良いですが、下内容に関しては、STLがニアミスしてる気ガス
＞Java が使いにくいのは静的だからではない
＞ttp://d.hatena.ne.jp/kwatch/20080305/1204743236
＞世の Java 屋はこのコードを見ても、何も疑問に感じないそうだ。ありえん。

221 ：

>>220
C++0x では、そこの var に対応する auto が入ることになった。

222 ：

それが本質的な解決かどうかはともかく、一応C++0xでは、
コンテナに初期化子{a, b, c}が使えるようになり、
自動変数には型推論が使えるようになるはず。

223 ：

autoって何だかBASICの再来みたいで嫌だな

224 ：

>>220
アクセサが気に入らねーならクラスにすんなと。
全部publicにして直さわりだと、後で内部構造変えたりできねーじゃん。何のためのprivateメンバなんだと。
まあ、こんなこと無いだろうけど3次元ベクトルをクラス内部で直交座標系で保持してたのを
内部処理の都合で極座標で保持するように変更するとかさ。
アクセス関数経由してたら、内部を変えてもクラス外部からは従来通り、直交座標で値の設定ができるわけでよ。

225 ：

単に長ったらしいコードが嫌と言っているようにしか見えない。
例えば、C# 3.0の自動プロパティでは、
public int Hoge {get; set;}という風に書ける。こういうのがいいと言っているのでは？
224のように変更する必要が出てきたら、従来の書き方に変えればいい。

226 ：

>>224
あんなアクセサ作る奴は内部構造変えたらそれに合わせてアクセサも追加したり
しかねない。

227 ：

>>225
そもそもクラスの発想は再利用だろ(俺自身は全然再利用できてねーけど)。
クラスを作る人間と使う人間が別々の場合を想定して作るべきじゃん。
使う人間に内部構造を意識させたら負けでしょ。

228 ：

setterはアンチパターンだから
ダメなコードは書きにくくするという点でJavaは正しい

229 ：

自動プロパティはJavaにも導入すべきだと思うけど、C++には導入しないでほしいな
リファクタリング支援環境に乏しい言語だとかえって足枷になる

230 ：

STLって何がめんどーなんだろうかと思ったんだが、
バッファリングやってくれないからクラスっぽくないんだよね。
クラスっぽくないから、メソッド足し難い。

231 ：

誰か翻訳してくれ。

232 ：

クラスっぽくない＝継承せずにそのまま使うことが前提になっている（普通の利用者については）
かな？
バッファリングやってくれない、のほうは分からん。
頭痛が痛いのかもしれない。

233 ：

継承しなけりゃクラスじゃないってのはそりゃ違うけどな。
Facade パターンみたいに継承しない使い方も定番の使い方だ。

234 ：

>>230
STLにメソッド足し難いってどういう意味？
例えばvectorに追加機能が欲しいけどメンバ関数が追加できないって言いたいのか？
そういう場合はランダムアクセスイテレータに適用可能なアルゴリズムを書けばおｋ。
それはvector以外のコンテナにも利用可能な汎用メソッドとなる。

235 ：

>>234
というSTLのやり方に230が慣れていないだけだと思う。

236 ：

派生クラスじゃなくてコンテナアダプタを作る方法もあるな

237 ：

for_eachの実装を見て、あまりの単純さにびっくりしたとかよくあることだし

238 ：

ほとんど普通のwhileループに見えるからな。
その分イテレータとファンクタが頑張ってるんだが。

239 ：

> バッファリングやってくれない、のほうは分からん。
> 頭痛が痛いのかもしれない。
やべえじわじわ来た

240 ：

ふつーにメンバ関数足したいじゃん。
だって、そうでないと理解してくれない利用者もいるわけだし。
ｲﾃﾚｰﾀﾝのことを知らない人も居るんだおｗ

241 ：

vectorのpush_backと[]演算子しか使ってない俺にはiteratorなんぞ不要

242 ：

>>241
甘いな、そこまで言うならpush_back()ではなくコンストラクタでサイズを決めてしまえw

243 ：

それだったら尚のことグローバル関数を追加すればいいと思ってしまう。

244 ：

＞尚のこと
で、
何で、
＞グローバル関数
グローバルという最悪解がでるんだよ。
がいきち？

245 ：

>>244
単なる誤爆じゃないのか? いくらなんでもそんな素っ頓狂なこと、気が違っていたってしないだろ。

246 ：

なんか興奮気味のお馬鹿さんが来たね

247 ：

>>244
俺はvectorを継承してメンバ関数を追加するより
vectorを引数に取るグローバル関数を追加するほうがまだマシだと思っている。
五十歩百歩とか言うなら、そりゃそのとおりだ。

248 ：

>>247
五十歩百歩じゃねーよ。
クラスにメソッド足すのはふつー。
グローバル関数サイアク。

249 ：

>>248
vector限定ではなくなるけど、<algorithm>の関数群はサイアクなのか？

250 ：

>>249
ライブラリとして存在する関数と、
今からコードを足すのに関数しかできん、というのとは比較しているものが違う。
池沼、R。

251 ：

>>250
ライブラリは別ですか。
じゃあ話は変わるけど、Effecitve C++の2版19項あるいは3版23項で、
メンバ関数よりも非メンバ関数が勧められていることはどう思う？

252 ：

開発にはC言語よりはC++なだけで、
C++の推奨に純粋に従っていく気はさらさらありません。
開発するもののデザインを正しくしたいだけ。
STLも開発者の要望になびくべき。

253 ：

アホの要望になびいてもしょうがないかも。

254 ：

＞グローバル関数を追加すればいいと思ってしまう。
　↑
アホ

255 ：

>>252
お前とC++で正しいデザインの方向性が違うように思える。
（俺じゃなくてC++なのは、俺とC++もまた方向性が違うと感じるときがあるから）
>>253
アホの要望でもそれが多数派なら従うべきだね。

256 ：

自分は多数派と思い込んでるあたりがアホ。

257 ：

　↑
完全誤読のアホ。

258 ：

> 完全誤読
そんな四字熟語はありません。

259 ：

>>258
漢字が四つ並べばすべて四字熟語だと思っていませんか?
# 「完全誤読」が妥当かどうかは兎も角。

260 ：

>>259
思っていませんよ。

261 ：

では何故、いきなり>258のようなことを言い出したのですか?

262 ：

>>261
話題そらし乙

263 ：

>>261
「では」ではなく「だから」ですね。
もし私が「漢字が4つ並べばすべて四字熟語だと思っている」のなら、
「漢字が4つ並んでいるのに四字熟語ではない」という事態は私の考える世界にはあり得ないはずであり、
「完全誤読」の4文字を見た瞬間、私はそれを「そういう四字熟語」だと思ったはずですが、
私は「そんな四字熟語は存在しない」と言っているわけです。
つまり、漢字が4つ並べばすべて四字熟語だとは思っていないから出てきたものに対して、
あなたは（あなたですよね？）「漢字が四つ並べばすべて四字熟語だと思っていませんか?」と問うたわけです。
完全無駄……じゃなくて、完全に無駄な質問ですね。

264 ：

噛み付くことに意味を見出しているんだから
当人には無駄ではなくて君にだけ無駄なんだ

265 ：

残念でした。
257以降にはレスしません。
つまり、264の言葉は264にしか該当しませんｗ

266 ：

＞257以降にはレスしません。
257より後にはレスしていません、でした。

267 ：

>>261 は「何故そのような当たり前の指摘をするのか」を問うているように見えるんですが
もしその通りなら >>263 は答えになっていませんし、随分間抜けな印象ですね。

268 ：

＞完全無駄……じゃなくて、完全に無駄な質問ですね。
なら、
＞常考……じゃなくて、常識で考えて
とか、
＞がいしゅつ・・・じゃなくて、既出ですね。
とでもいうのか？
ｳｻﾞｳｻﾞ。

269 ：

ぐち0x18　〜日本語が通じない〜
http://pc11.2ch.net/test/read.cgi/prog/1200889547/l50

270 ：

>>268
「完全無駄」っていうのが、常考やがいしゅつのような「用語」なら、お前の言ってることも一理ある。
でもこの場合、単に日本語がおかしいだけだから、馬鹿にされてもしょうがない。
さらに言うと、お前のその的外れな切り返しも、「完全無駄」と同じくらい馬鹿にされてもしょうがない。ばーかｗ

271 ：

＞常考やがいしゅつのような
これらだって、出た瞬間は、
＞単に日本語がおかしいだけだから
だったんだお。
おまいが全てを仕切るな、消えろ。

272 ：

ばーかw
ワロタ

273 ：

272=完全馬鹿

274 ：

>>271
どっちも出た瞬間は馬鹿にされまくってたじゃん。そして今回も馬鹿にされている。
噛み付きたかったら、「完全誤読」が充分に流行って、「今さら2ch語にマジ突っ込みかよ！」
って言える空気がこの言葉に関して醸成されてからにしてちょーだい。間抜けなヒステリーは勘弁。
あと、たぶんお前、「仕切る」の意味をどっかで勘違いしてるぞ。
自分の意見をいくら言っても、正しい日本語をいくら紹介しても、それは仕切るとは言わない。
全体の流れ等を統制するために、他人の意見をさえぎったり、無理矢理な話題転換を強制するのが
「仕切り」で、それはお前がいま「消えろ」という言葉でやったことだ。
要するにお前が仕切ってるわけ。間抜けなヒステリーは勘弁。

275 ：

次の次あたりで、どう言い返していいかわからなくなって
シャボン玉のように壊れて消えると予想。

276 ：

あきれて、華麗にスルーｗ

277 ：

vectorなどのコンテナを継承して
新しいコンテナを作ったことがあるけど
いちいち数あるコンストラクタを再定義しなければならなかったのが
きつかったな。ここら辺がC#とか新しい言語でも同じなんかな？

278 ：

STL のコンテナは仮想デストラクタ持ってないから public 継承は危険だな。
protected/private 継承ならマシではあるが。
まあそれはおいといて、コンストラクタはどうしようもないと思う。

279 ：

vectorを継承したところで
新コンテナの実装にvector使っているだけで大部分の関数が再定義ってことになるから、
単に包含でよくね？
新コンテナとvectorに親子関係もたせる必要性って多分ないでしょ。

280 ：

まあ、メソッド追加したかった、ってことはあると思うけどね。

281 ：

STLコンテナとかイテレータとかって、直接つかうんじゃなくて
もうすこし高レベルのクラスを実装するのに使うのが正しいんじゃないのかと。
部品を作る部品、みたいな。

282 ：

俺が作ったのは、selectionというvectorをpublic継承したクラスで
単純に、配列の中で、現在選択されている要素を示す機能を追加したものだった。
(ドロップダウンリストで使うようなイメージ)
これを実現する為だけに、vectorの殆どのメソッドを再定義しなければなかった。
継承というアプローチが間違っていたんだろうか。

283 ：

>>279が、そのものずばり言っていたか。
正直すRかるかった

284 ：

意見かぶるけど、自分ならよっぽどの場合じゃなけゃvectorなどの普通手を入れない部品は継承しないな。包含にする。
継承するならリスコフの置換原則を守ってるかチェックした方がよいかと。

285 ：

>>278
protected/private 継承でもvectorのデストラクタは呼ばれないから関係ないのでは？

286 ：

っていうか仮想デストラクタ持ってないクラスは
暗黙的に継承禁止ってことなんだね・・。早く言ってよ。
class Derived : public Base
{
virtual ~Derived(){ Base::~Base();}
};
でも、継承する場合でも、とりあえずこうしておけばOKなのかなぁ？

287 ：

>>285
仮想デストラクタがないことの問題は、アップキャストされた状態でdeleteされたときに、
正しいデストラクタが呼ばれないこと。
逆にデストラクタが呼ばれるときにインスタンスの正しい型が判っていれば、
例え仮想でなくてもきちんとデストラクタは呼ばれる。
これに関するprotected/private継承の利点は、クラスの外で自由にアップキャストできないので、
デストラクタが正しく呼ばれない心配が大きく緩和されるということ。
>>286
だからそれも無意味。

288 ：

>>286
色々と全ての点で駄目すぎる。
まず、Derivedのデストラクタが呼ばれるときは、
自動的にBaseのデストラクタも呼び出されるから明示的にベースクラスのデストラクタを呼ぶ必要はない。
また、Baseクラスが仮想デストラクタでないならDerivedクラスで仮想デストラクタを定義しても意味はない。
(Derivedクラスからさらに継承する場合でdelete時にBaseクラスを介さないときを除く)
ちなみに仮想デストラクタがない=継承禁止ではない。
多くの場合、public仮想デストラクタかprotected 非仮想デストラクタが継承を認める場合の書き方。
前者はdelete時にもBaseクラスを使う場合、後者はdelete時にはDerivedクラスを使う場合に使う。

289 ：

実験的にVectorの要素のクラスの
コピーコンストラクタとデストラクタで
動作ログ吐き出すようにしてみたら
異常にコピー＆破棄繰り返しててワロス

290 ：

>>289
前もってreserveすればある程度は抑えられるかもしれない。

291 ：

>>285
>逆にデストラクタが呼ばれるときにインスタンスの正しい型が判っていれば、
>例え仮想でなくてもきちんとデストラクタは呼ばれる。
ごめん。そのとおりだった。ここを勘違いしていた。それと、呼ばれないのはvectorのデストラクタではなく、
派生クラスのデストラクタの間違いだった。
>>288
なるほど。後者のケースは知らなかったので勉強になった。デストラクタをprotectedにしておけば
Baseをdeleteできないから非仮想デストラクタでいいわけね。でもあえて非仮想にする必要はある？
仮想にしておけばいい気がするんだけど。まさか仮想関数ポインタの4バイト節約じゃないよね？

292 ：

仮想関数呼び出しのオーバーヘッドが許容できない場合など。

293 ：

あまりないと思うけどなあ。そんなクリティカルなら継承自体使えない気が。
まあvirtualにする必要がなければしないにこしたことはないね。

294 ：

よく考えればdeleteはしなくてもBaseクラスにアップキャストしてポリモーフィズムすることは可能なわけで、
その場合は仮想関数呼び出しになるな。
まあ　仮想デストラクタがない=継承禁止ではない。　という例として勉強になった。
今までは継承元クラスのデストラクタは必ず仮想でなければいけないと思っていたから。

295 ：

C++ Coding Standardsだとstd::unary_functionやstd::binary_functionに
protectedな非仮想のデストラクタを持たせるべきだったと取り上げている。
あとはCRTPのように、継承はするけど仮想関数を全く使わない場合にも
protected非仮想デストラクタの出番だと思う。

296 ：

unary_functionとbinary_functionにデストラクタ欲しいね。

297 ：

C++ Coding Standards　を　読んだ。一回読んだけど頭に入ってなかったな。
新たな発見だったのは、非仮想publicデストラクタでdeleteした場合の動作は未定義だそうだ。

298 ：

派生クラス突っ込んでるのに delete した場合、じゃないの？

299 ：

そう。流れ的に省略した。

300 ：

すみません、アプリでメモリリークが起きてるっぽいんですが、
クラス変数にvectorの実態宣言があってinsertやった場合も、
クラスが破棄されたらvectorは自動でメモリ解放してくれますよね？
まさか明示的にresize(0)する必要は無いですよね？
（逆にvectorがポインタ宣言だったら、そのポインタの指す実態をdeleteする必要があるだけですよね？）

301 ：

>>300
そのvectorに何を入れてるの？
オブジェクトを入れてるのならいいけど、オブジェクトへのポインタを入れてるのだったら自分で中身を消さないとダメだよ。

302 ：

そしてそういう時には boost::ptr_vector が使える

303 ：

実態宣言？

304 ：

お前を嫁にもらう前に逝っておきたいことgirl

305 ：

かなりきびしい話もするが 俺の本音を聴いてOK

306 ：

俺より先に寝てはいけnight

307 ：

さだようく？

308 ：

俺より後に起きてもいけnine

309 ：

めしは上手くつくlay

310 ：

dequeの良さに今頃気づきました

311 ：

いつも綺麗でin low

312 ：

dequeる範囲で

313 ：

かまわないcolor

314 ：

俺のせいで流れが・・・
忘れてくrail nut

315 ：

She got more deck in night at corny

316 ：

Cation marmoreal

317 ：

おまえら何をstring

318 ：

Has not niter caught on.

319 ：

流れ分断してすまない。
193>>
struct Test
{
vector<int> aaa;
vector<string> bbb;
int ccc;
};
Test test;
memset(&test,0,sizeof(Test));
ってSTLつきの構造体をmemsetやったら危険ですか？

320 ：

>>319
ったり前。
Test test;　　　　　　　　　　　　　　　　// メンバ aaa と bbb のコンストラクタが呼び出される
memset(&test,0,sizeof(Test));　　　 // ぶっ壊される

321 ：

memsetは要はドーザーで更地にするようなもんだからな。
PODはただの区画で、C++クラスは家付き不動産て感じか。

322 ：

すると、vtblつきのクラスは動産だな。

323 ：

増築可能に作った不動産じゃね？

324 ：

レスサンクス。
vtblつきのクラスはともかく、
C言語な構造体のvectorは問題ないと思ってmemsetしてた。
一見問題なく動くから困る。今から直します。

325 ：

処理系で違うだろうけど、vectorの初期値が全部0(NULL)のもあるかもな。

326 ：

しかし初期値0の場合でも、値入れてからmemsetしちゃったらメモリリークするからな

327 ：

>>324
そもそもstringはあんたの言う「C言語な構造体」には該当しないと思うのだが。

328 ：

>>327
あいまいな表現で申し訳ない。
aaaのmemsetはセーフだけど
bbbは不味いだろという指摘を期待して質問してしまいました。
「C言語な構造体」というのはPOD型構造体のつもり。
専門用語の厳密な知識が足りないので、あいまいな表現を選択しました。
（aaaをPOD型構造体にしておけばより良かったか）

329 ：

>>328
vector<int>もvector<string>もPODではない。
ゆえにTestもPODにならない。

330 ：

>>329
了解。
C++の仕様をまともに読んだことがなかったから、読んでみるよ。
図書館で『C++ランゲージ クイックリファレンス』借りてきた。

331 ：

おれは>>319見たとたんに悲鳴を上げるな

332 ：

もう memset(), memcpy() 見ただけで妖気アンテナが立つぜ。

333 ：

俺は、なんというか、久しぶりに清々しい気分になっちったな〜

334 ：

>>330
あれはいい参考になるからいつも手元においてる。
ただ、リファレンスのはずなのに、たまにコーディングスタイルに属する問題がさらっと並んで書かれてたりするから注意が必要だけどな。

335 ：

参考までに、
なんで>>319が、vector<int>をPODだと思ってたのかを知りたいな。

336 ：

>>334
おお。しっかり参考にしようと思います。
>>335
一言で言えば無知。
便利そうなものはろくに勉強せずすぐ使ってしまうのがあるかな。
（最初にvector使ったときは便利さに衝撃を受けた）
PODの概念は319の書き込む前後にネットで調べるまで知らなかったです。
vector<int> aaa;
aaa.clear();
size_t size=sizeof(aaa);//20
size=aaa.size();//0（ちなみに）
今思えば、
一度でもこういうコードを試して見れば
memsetが危険かどうか判断できたな。
VC++2005で上記のaaaをウォッチすると
aaa [0]()
このように出るから、int以外でメモリ取ってるイメージが湧かなかった。
よってmemsetもOKかなという判断をしたのだろう。

337 ：

すれ汚しすまん。
ついでに、フローだとこんな感じかな。
こういう後輩がいたらしっかり指導してやってください。
動くプログラムを書けるようになる
↓
変数は必ず初期化するようにしなさいと言われる
↓
memsetの存在を知る（まとめて初期化できるからこれは便利）
↓
STLを使ってみる（これは便利！）
↓
STLとmemsetの併用が何か怪しい気がした
↓
質問して悲鳴をあげられた←いまここ

338 ：

>>337
>STLとmemsetの併用が何か怪しい気がした
いいセンスしてるじゃん！がんがれ〜

339 ：

std::fillかstd::fill_nを使ってmemsetは禁止するのが良い。
それで大体困らないし。

340 ：

なるほど
コンパイラにエラーを吐かせるようにするわけか

341 ：

vector<POD> v で memset(&v[0], …)って気持悪いとかそういうこと以外に実害あったっけ?

342 ：

v.size()が0の時があるので気をつける。

343 ：

>>341
POD にポインタや不動小数点数が入ってると意味を成さない。 vector 関係ないな。

344 ：

>>339-340
memset多用のおかげで見逃されてるよね、std::fill

345 ：

std::fill ってちゃんと memset 並に最適化されるのん？

346 ：

組み込み型に対して memset に dispatch する実装もありますけれど，
ユーザ定義の POD に対してそれができる実装は見たことない

347 ：

それは見識が狭いだけかと。

348 ：

ispodって最近のgccやvcにはあるんだっけ？

349 ：

VC++は2005から持っている。
ただ、2005も2008もstd::fillでは使われていない。
ただの特殊化で(signed/unsigned) charだけmemsetを呼ぶ実装になっている。

350 ：

>>347
ｋｗｓｋ

351 ：

>>349
それは勿体無いね

352 ：

なあ？
素人質問でもうしわけないんだけどさ
中でnewやってるクラス(MyClass)を
vector <MyClass> mMy;
ってやってpush_backとかresizeすると
newしたものってバグる？
つまり、何を気にしているかというと
push_backやresizeをしたときにクラス１回破棄して作り直してね？
ってことナンすけど・・・

353 ：

STLのコンテナに載せる要件に、コピーコンストラクタが必要、というのがありますが
当然、コンパイラが自動的に作るコピーコンストラクタがどんな動作をするかには言及しませんね。

354 ：

>>353
>STLのコンテナに載せる要件に、コピーコンストラクタが必要、というのがありますが
マジですか？
んじゃ基本的には
vector <MyClass*> mMy;
みたいにしないといけないの？
コピーコンストラクタがない場合

355 ：

デフォルトコンストラクタでnewしてコピーコンストラクタで適切にケアして無いのが異常。
そんなクラスを収容できるようにはコンテナはできてないということ。

356 ：

>>355
え？コピーコンストラクタを実装するのって暗に当たり前だって言ってる？
悪いけど俺にそんな認識はないなぁ・・・つか無かったなぁ
エラーもでないし
はぁ・・・わかりにく・・・これだからテンプレートって使わない人多いんだろうなぁ・・・
ってちょっと思った

357 ：

>>356
「中でnewやってるクラス」という言葉の意味が、常識的に解釈できる通りの意味だとすると、
これはテンプレートとは全然関係の無い話だよ。
むしろC++の基礎知識に属するというか、マジな話、君は致命的な欠陥のあるクラスを
作りまくってることになるよ・・・。

358 ：

>>357
マジで？
中でnewってのは
MyClassのメンバ変数にこんなのがあったとして
　int *mUnko;
MyClassクラスのどっかで
　mUnko = new int[256];
とかやってるってことだよ
これをやってるクラス(MyClass)をvectorでpush_backとかresizeをやると
newで確保した内容が吹き飛んでしまう
って現象
俺はこれ知らんかったなぁ・・・
コピーコンストラクタが定義されてないクラス全部欠陥品ってこと？

359 ：

メンバに生ポインタ持つなら
自前の代入演算子とコピーコンストラクタは必須だろう
それ以外の場合はケースバイケースかな
メンバの全てについて、コピーコンストラクタ・代入演算子の呼び出しを考慮してあるなら
デフォルトのでいい
面倒ならとりあえずprivateにしてみるのがよい
class Hoge
{
private:
　Hoge(const Hoge&);
　Hoge& operator=(const Hoge&);
　//・・・
};
コンパイルしてエラーが出たら実装。
g++を使っているなら -Weffc++ というマゾっぽいオプションもある。素人にはお勧めできない。

360 ：

>>359
面倒臭すぎる
つか、絶対に知らない奴多いと思うんだよね
この現象
vector <MyClass*> mMy;
もうクラスをvectorするときはポインタだけに絞ろう

361 ：

・・・寒気がしてきたZE

362 ：

> vector <MyClass*> mMy;
中に入っているMyClass*をdeleteし忘れるんですね、わかります

363 ：

>>356
まぁテンプレートやSTL以前にC++そのものがわかりにくいってことだ。
とりあえずEffective C++ / Effective STL読んどけ。
>>352みたいなことに自分で気づけたのなら筋はいいと思うな。

364 ：

vector < shared_ptr<MyClass> > mMy;
これなら安全ちゃう？

365 ：

「現象」として捉えるんですね
すごく遠目からみるんですね
「中でnewするクラス」の人は
さすがです

366 ：

そもそも、newしていることに疑問を持たない方がおかしい。

367 ：

本人は最後まで「vectorに格納する場合に生じる現象」として捉えていたけど、
MyClass hoge, fuga;
hoge = fuga;
だけでも、なんか素敵なことが起きかねないよな、現状のスキルだと。

368 ：

MyClass hogehoge();
fugafuga()
{
　MyClass a = hoeghoge();
}
最適化によって落ちたり落ちなかったりするんですね

369 ：

ここにいる奴ら、std::auto_ptrをコンテナに入れてはいけない
理由を理解してなさそう

370 ：

バカな理屈で周りがバカばっかに見える、二次成長期におなじみの例の病気では。

371 ：

>>359
今の現場のコーディング規約と同じだー。
> コピーを考慮しないクラスでは、
> コピーコンストラクタと代入演算子をprivateにすること
ってのがあるよ。

372 ：

厨二病か

373 ：

クラス内部でnew/deleteをするクラスはコピーコンストラクタと
代入演算子は必須だろうが

374 ：

>>356
> え？コピーコンストラクタを実装するのって暗に当たり前だって言ってる？
常識というか、普通に気づくんじゃないかね。自前でコピーコンストラクタ書く時に
「あれ?こんなこと自動ではやってくれないよな?」ってのに気づけば。だから
>>359
> 面倒ならとりあえずprivateにしてみるのがよい
とか
>>371
> コピーを考慮しないクラスでは、
> コピーコンストラクタと代入演算子をprivateにすること
とかだし、google のコーディング規約でも↓みたいなマクロが用意されてるわけだ。
// A macro to disallow the copy constructor and operator= functions
// This should be used in the private: declarations for a class
#define DISALLOW_COPY_AND_ASSIGN(TypeName) \
  TypeName(const TypeName&); \
  void operator=(const TypeName&)
class Foo {
 public:
  Foo(int f);
  ~Foo();
 private:
  DISALLOW_COPY_AND_ASSIGN(Foo);
};

375 ：

>>364
> vector < shared_ptr<MyClass> > mMy;
> これなら安全ちゃう？
shared_ptr<> はオーバヘッドが馬鹿にならないからなぁ。

376 ：

boost::noncopyable

377 ：

なんでもshared_ptrにつっこめば解決すると思うな。
自分でコピーコンストラクタと代入演算子を定義して
ptr_vector当たりを使うのが正道だ。

378 ：

>>377
ptr_vector使うならコピーコンストラクタいらないんじゃ…

379 ：

これ、vectorテンプレートを作った奴の評価としてはNGだろ？
現状そうなってるから仕方ないってのは受け入れた上での評価だけど
だってこんな仕様にしたらMyClassを変更するたびに
MyClassの仕様として正しい正しくないの他に
MyClassを使用している箇所を片っ端から探して
newを使用していいかどうか確かめなきゃいけないってことだろ？
最悪じゃね？
カプセル化が完全に死んでるじゃん

380 ：

>>379
何度も言われているが、これは vector じゃなくて C++ 一般の話。

381 ：

>>380
どうして？

382 ：

>>381 >367-368

383 ：

>>380
俺はそうは思わないな
vectorの仕様によっては助かるように細工することもできるわけだし
使用者がvectorの内部まで知らないと使えないってのはやっぱりわかりにくいと思うよ
っていうかコピーコンストラクタの用意されて無いクラスを
vectorにぶち込んだ時点でエラーでもいいと思うけどね

384 ：

newが使ってあるクラスでコピーコンストラクタが
実装してあることをチェックしてからしかvectorには突っ込めないとか使い難いな

385 ：

>>383
> vectorの仕様によっては助かるように細工することもできるわけだし
どうやって？
コピーコンストラクタの用意されてないクラスをエラーにすると、 C の構造体が
vector に入れられない。それは面倒だ。

386 ：

ところでmallocだとどうなんの？
アドレスだけコピーしてくれてセーフ？
なんてことはないか

387 ：

>>385
クラスがきたときだけptr_vector仕様にする

388 ：

>>385
クラスはクラス用のvectorを作って
vectorにクラスを入れるとエラーでもよかったけどね
なにも全部ひっくるめてvectorとかする意味わからないな
そのせいでわかりにくくなるならクラスはクラス用のvectorみたいなのを使う
って決めてあったほうがよかった
と俺は思う
（今のvectorを変えろとかそういう意見じゃなくて今後そういうテンプレート的なものがあったときに
そういうふうに作るようにしたほうがいいんじゃねぇの？ってことな）

389 ：

>>387
生半可な知識でくだらないこと書きなさんな。C++のclassはstructとはprivateかpublicかの違いしかない。

390 ：

>>388
あんたが一人でその、「クラス専用ベクタ」とやらを作って使えばいいだろ。

391 ：

>>389
現状、明らかに使いにくいしわかりにくいのに
そこの改善より
俺が馬鹿で終了？
意味不明
じゃ、仮に中でnewしてても死なないvectorがあったら
現状のvectorとどっち使うの？お前

392 ：

>>387-388
vector に入れたときだけ大丈夫で >367-368 はやっぱりダメとか、ありえんだろ。

393 ：

>>392
それはやってみるか中みないとわからんと思うな
ちなみに>>367ってエラーでなかったっけ？

394 ：

中で死なないvectorの為に(それ以外の理由の方が大きいが)
代入とは別に移動(move)という処理を標準化しようという動きはあったろ。
いつになるか分からんけど

395 ：

>>391
> 仮に中でnewしてても死なないvectorがあったら
listでよくね?
listって確か要素を追加・削除しても、関係ない要素のコピーは起きないよな?
あとC++0xにemplaceが入れば満足か?

396 ：

>>394
C++0x の move な。一応次の標準に入る予定。
ただ、その場合もコピーと同様に、クラス側で「移動」用の定義を与えないと働かない。
標準ライブラリ内のクラスが move に対応するんで、自動的に大丈夫になる
ケースもあるだろうけど。

397 ：

>>393 妄想ベースでしゃべるな。

398 ：

つーかこんな挙動、絶対わかんねーって。マジクソだな。

399 ：

要は、危険なクラスをコンテナだけが安全に使えても意味がないということなんだが。
何でそんな簡単なことも判らないでこのスレにいるんだ?

400 ：

>>399
えー意味わからん
危険なクラスってコピーコンストラクタがないクラスを言ってるの？

401 ：

すべてのクラスをvectorに突っ込んでも大丈夫なように作るなんてありえんわ
面倒臭すぎる
職場の超百得ナイフクラスをサポートできへん

402 ：

>>400
必要なコピーコンストラクタを欠いているクラスが危険だと言っている。

403 ：

いや、要件を満たしていないのに使えてしまうのが危険なんだよ。

404 ：

>>402
？
意味分からん
>要は、危険なクラスをコンテナだけが安全に使えても意味がないということなんだが。
この発言だと
vectorにつっこんだときのことを言ってるんじゃなくて
MyClassが危険なクラスって言いたいんだよね？
でも
>必要なコピーコンストラクタを欠いているクラスが危険だと言っている。
こんなこというからさっぱりわからないよ
何が言いたいの？
>>403
俺もそう思うな
望ましい状態は２つあって使えないような作りか、使えるような作りかだと思うんだよね

405 ：

>>404
vector につっこめないクラスは単体の代入やコピーでも同様の問題を起こすということ。
このようなクラスを安全に代入やコピーをするには、コピーコンストラクタや代入演算子の
定義が必要。そして、それらを定義すれば vector に入れても問題なくなる。

406 ：

>>404 >367-368

407 ：

>>404
安全側に倒したいんなら new するポインタの保持に生ポインタを使わないことだ。
int の配列を持つなら vector<int> を使えばいい。

408 ：

でもvectorだと生ポの6倍程度のメモリを使うんだぜ？

409 ：

自分で管理できない馬鹿には少ないコストだろ。

410 ：

>>408
6倍はないだろ。どんなコンパイラでどうやって測った？

411 ：

>>410
VC9でsizeof(std::vector<int>)で30が返ったんだが。
(20だったかも)

412 ：

>>411
10個突っ込んでも、300とか200にはならんと思うけど。
size() * sizeof(int) + Nbyteがせいぜいでない？

413 ：

>>411
4バイトアラインのはずだから、20だろうな。それにしても >412 の言うとおり、
int を256個も入れりゃ気にならんだろ。

414 ：

>>403
きっと0xならMyClassはCopyConstractableでないしAssignableでもないから
std::vectorに入れられないってエラーになる。

415 ：

CopyConstructible

416 ：

>>414
デフォルトの定義で動いちゃうから、無理でしょ。

417 ：

>>412-413
もちろんvector1つくらいの管理変数サイズを気にしたりはしない。
vector<vector>みたいな状況が怖いわけで。
大量に使うクラスで、生ポで済むのにvector組み込む場合ね。
vectorよりはshared_ptr使った方がいくらかマシか？

418 ：

>>417
そんなにリソースをキツキツで使いたいならコピーコンストラクタと代入演算子ぐらい
さくっと定義して使えよ。
安全性と効率のトレードオフだ。 C++ ではデフォルトで効率を取るのが言語の方針ってこと。

419 ：

>>417
コピーコンストラクタとか定義しないいけないのが嫌だから生ポインタじゃ済まないんだろ。
おとなしく vector 使っとけ。

420 ：

いやだからvectorよりshared_ptrのほうが(ry
あるいはもっと向いてるポインタ格納クラスがあればな

421 ：

>>417
> vector<vector>みたいな状況
おれなら、その状況では管理サイズよりpush_back時の時間の方が気になるけど。
管理サイズが気にならないわけではないよ？
たとえかも知れんけど、listにしとかね？

422 ：

dequeをですね

423 ：

窓から投げ捨ててですね

424 ：

最初にvectorにポインタ入れてクソ仕様と騒いでたヤツはバカだが、
STLコンテナがmoveするべきところをcopyで済ましてるのは、確かに
今となってはまずい設計だったよな。
移動用のファンクタを渡せるようにするなどの対応をするべきだった。

425 ：

>>424
そういう問題ではない。普通に代入とか、関数に渡すために仮引数に
書いてコピーコンストラクタが呼び出される事実はSTLとは全く関係が
ないにも関わらず同じ問題を引き起こす。

426 ：

>>425
いや、コピーコンストラクタが不備だったりコピー禁止にし忘れてるクラスの問題の
話ではなく、vectorが再配置にコピー動作を行ってることによって発生する
オーバーヘッドを指摘してるんだよ。
ポインタで配列を保持するようなクラスだと、再配置のときまでコピー動作じゃまずいだろと。

427 ：

よくわからんけどrealloc()とかの関数を見習った
歴史的経緯があるんじゃないだろうか？

428 ：

寝ぼけてたようなので補足
＞ポインタで配列を保持するようなクラスだと
ポインタで配列を保持してるのを、vectorに入れ替えたクラスだと、
再配置のたびvectorの中身までコピーされてオーバーヘッドが大きい。

429 ：

まぁ、そういう場合は再配置が起き難いように事前に確保しておくからあんまり困らないね。
再配置による中身のコピーのオーバヘッドが気になるくらいなら、真面目にデータ構造見直すし。

430 ：

うんまぁそういう解決方法もあるけど、移動用の
ファンクタなりなんなり設定できると便利だよね。
可変長なデータ読み込む場合とか、最後まで読んで
みないと要素数が分からない場合もあるんだし。

431 ：

>>430
しつこいな。
自分で作れやカス

432 ：

作るとか作らないとかそういう話じゃないだろ…

433 ：

きっと0xならなんとかしてくれるんだよね？

434 ：

>>433
するわけない。

435 ：

boostにでも提案突撃して来い

436 ：

あれ？ 0x の話ならここで move が出てくる場面じゃ？

437 ：

長文だが結局あまり実がないので適当にスルーよろ。
現行範囲内で考えるなら swap をできる限り利用する、みたいな
感じになるのかね。
ってことからちょっと考えてみた。
いくつかのアルゴリズムについては swap あるいは iter_swap で
挙動が定義されている。
が、g++ 3.4.4 の libstdc++ の実装では iter_swap は swap を
呼び出さず、また、アルゴリズムで swap と iter_swap を意識して
使い分けているようには見えない。
もちろん swap と(iterator 経由の)iter_swap で結果が異なる
なんてのは論外だけど、swap については独自の型についても
特殊化を提供しよう、みたいな事が言われるが、iter_swap まで
特殊化を提供はしないわけで(っていうか事実上無理)。
結果として、CopyConstructible と Assignable から想定される
swap の一般的な実装 T t(a); a = b; b = t; よりも効率的な swap
を持つ型に対する場合で、かつ、アルゴリズムの実装が iter_swap を
用いる場合には効率が落ちるケースがある、ということになりそう？
って、長々書いてきたけど、
ttp://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#187
に既にあったわ。
ということで、0x になると iter_swap が swap で定義されるので上記
問題はなし、ってことのよう。

438 ：

>>437
"move" とか "move semantics" とか 「右辺値参照」 ("rvalue reference") あたりの
単語で検索していろいろあさってもらえれば恐らく期待しているものが引っかかるかと．
ちなみに swap を使う場合， swap 先 (移動する先) のオブジェクトを
あらかじめ構築していないといけないので，そういうオブジェクトを構築する
汎用の構文 (とその挙動) も規定しないといけないです．

439 ：

>438
うん。だからあえて「現行範囲内で」。
で、n2738 見ると、vector の insert が軒並み requires MoveAssignable<T> になってるんで
(resize は insert と erase で定義されるから resize とかも) 424 辺りが望む挙動を期待していいってことでOK?

440 ：

追記。
vector 全体が requires MoveConstructible<T> になってる。

441 ：

LWG187 は iter_swap の元々の動機付けだった， proxy を
どうするのかの問題についての立ち位置が分からないですね，これ．
move は現行の範囲内でやるならおっしゃるとおり
swap でやるのが良いとは思いますけれど
(Boost の sand-box にあるエミュレーションもそういう形態を取ってましたし)
ただ，現行でやるのは本当に面倒だと思いますよ．
N2738 というか， move の proposal の動機付けの1つに，
当然コンテナ内のバッファ再配置があったわけで，
424さんとかの望むことそのものはできないとさすがにまずいかと．
後，あまり関係ないですけれど， N2738 を読む限り，要素型に対する
CopyAssignable の要求は必要な箇所のみに完全に絞られるようになりますね．

442 ：

>N2738 というか， move の proposal の動機付けの1つに，
>当然コンテナ内のバッファ再配置があったわけで，
これっすね。
ttp://www.open-std.org/jtc1/sc22/wg21/docs/papers/2002/n1377.htm#vector%20Example
# 適当に拾い読みしてて薄っぺらいのがばればれ。
proxy については良く分からないですが、LWG742 辺りが関係してますか？
ttp://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#742

443 ：

肛門をいじりすぎたせいでSTL。

444 ：

>>442
proxy を用いる iterator (iter_swap が本来問題にしていた状況) に関しては，
その LWG742 がそのまま該当すると思います．仮に LWG742 の proposal が通るならば，
iter_swap に関しては swap への単純な委譲 (LWG187 の proposal の通り) で良いかと．
ただ，そこでも指摘されていますけれど， LWG742 のやり方は swap が
template 定義内で unqualified call されることを前提としているわけで，
そうすると異なる2つの型に対する swap の呼び出しによって，
異なる2つの associated namespace の swap の定義が ADL によって
visible になるような状況があるのがまずいだろうな，とは思いますけれど．

445 ：

日本語でおｋ

446 ：

なんか出来損ないの翻訳を読んでいるようだ

447 ：

無理やり変換しないで訳がわからない単語が残してあるところは
性能がいいのか悪いのか判断しかねるな

448 ：

ぶっちゃけこんな会話になっちゃうところがもうユーザビリティ最悪だよな
このテンプレート

449 ：

そろそろどこかのブログに
「444は僕です」
と書かれる頃かな

450 ：

基本的にstl関連使うと
解読不能なほど長いunko.unko.unko.unko.・・・住所はなんとかならんのか
日本の埼玉県鴻巣市吹上３丁目１の４の３の○○マンション３０６号・・・みたいなｗ
もうわかったよｗ長いよｗ
絶望的にセンスねぇよｗ
いくら時代が進んだからってエディタの横幅一杯まで攻めてる理由ないってｗ

451 ：

っstlfilt

452 ：

concept

453 ：

>>451-452
んで、問題を解決しようとすると
そういう新ワードが出てきてますますわからなくなるんだよなｗ
そのクラス（テンプレート？）わかる奴一体世のプログラマに何人いんだよって話ですよ

454 ：

STLfilt一回使ってみろよ
マジ感激すっから
Perlをインストールする必要があるけど

455 ：

せめて、コンパイラのエラーメッセージとかで
デフォルトテンプレート引数を使用している部分は(スイッチで)省略できるとかなら
もうすこし読みやすくなるんだろうけどね。
あと、typedefしてる部分とかも。
ただの引数の型の部分でstd::basic_string<char, std::char_traits<char>, std::allocator<char> > とか。
まあ書く側としてhoge<hage,hige>::iteratorとかになっちゃうのは
typedefくらいしかどうしようもないけど。

456 ：

>>455
日本語でおｋ

457 ：

>>453
ついていけないなら、むりせずやめてもいいんだよ？

458 ：

>>457
もうわかりやすさとか除外して
ひたすら言語の「できること」探しがはじまったら
言語の存在意義が不明になってしまうで
言語ってのは昔から制限をかけることで進化してきたもんなんだぜ
アセンブラのが色んなことできるぜ型縛りもなんにもないしね
人にわかりやすく、誰でも読めるように、
たくさんの人が簡単に理解できるように
これを忘れた時点でもう何をやっても自己満足でしかない

459 ：

よう分からんけどC++使わない方がいいよ、きっと

460 ：

>>459
言語に機能を求めるならアセンブラのがいいよってことだよ
馬鹿だからわかんないかｗ

461 ：

うんそうだね。俺もアセンブラ使うよ

462 ：

また自分の馬鹿さ加減を棚にあげてSTLのせいにするアホウが一人

463 ：

Lispは自己満足ですか？

464 ：

vector ってデストラクタが vertual じゃないけど
継承するなってこと？

465 ：

間違えた virtual

466 ：

>>465
基本的に標準ライブラリのクラスはどれも継承するな。
していいのはstreambufくらい。

467 ：

exceptionは継承してもいいんじゃない？

468 ：

俺みたいな初心者にはこれは落とし穴だね

469 ：

うん、俺言い過ぎたな。 コンテナクラスは継承するなぐらいに言っておけばよかった。

470 ：

どんまい。

471 ：

std::unary_functionとかあるしね

472 ：

STLportのbasic_string::assign(const CharT*, size_type)って
lengthチェックしてるからデータがヌル終端でないと死ぬんだな…
デバッグ版のみだけど。

473 ：

デストラクタがvirtualじゃないvectorを継承すると
どういう落とし穴にはまるんですか？

474 ：

>>473
アフォですか？
デストｒラクターが呼ばれないと
メモリの開放がされないのでリークして
オーｖバーフローするくらい気付け

475 ：

#include <iostream>
class Base {
public:
~Base() { std::cout << "~Base" << std::endl; }
};
class Derived: public Base {
public:
~Derived() { std::cout << "~Derived" << std::endl; }
};
int main() {
Base * p = new Derived;
delete p;
return EXIT_SUCCESS;
}

476 ：

Base が vector だよね？
じゃあさ、こうは？
#include <iostream>
class Base {
public:
~Base() { std::cout << "~Base" << std::endl; }
};
class A {
public:
virtual ~A() { std::cout << "~A" << std::endl; }
};
class Derived: public Base, public A {
public:
virtual ~Derived() { std::cout << "~Derived" << std::endl; }
};
int main() {
A* p = new Derived;
delete p;
return EXIT_SUCCESS;
}

477 ：

>>473-476
未定義動作。結果がどうなるか知りたければ試してみるしかないし、
やってみても何も起こらないかもしれないし、いつも同じ結果になるとも限らない。

478 ：

まさか

479 ：

>>473
別に vector に限った事じゃねぇだろに。
Effective C++ 読むなり
「デストラクタ virtual」でググるなりしろ。
>>474
もちつけ。つか、ちゃんと理解してる？

480 ：

オーバーフローはしないと思う

481 ：

474はつまらない釣りでしょ

482 ：

参考文献
C++ Coding Standards 第35項「基本クラスとして設計されていないクラスからは継承しない」
派生クラスのオブジェクトに対して基本クラスの非virtualなデストラクターを呼ぶと未定義動作。

483 ：

>>477
いやいや476の例は問題ないだろ。
もちろん、それで問題を防げるわけではないから
やっちゃ駄目という結論に変わりはないが。

484 ：

いつまでこのつまんない話続けるつもり？

485 ：

>>484
ほほう、貴方が面白い話題を提供してくれるわけか

486 ：

つまらない話ですいませんでした

487 ：

>>483
ほんとだ。ごめん。ありがとう。

488 ：

STL標準講座って本を読んだら
rbegin()は末尾を返すって書いてあった。
嘘だった。
すごい落とし穴にはまった。

489 ：

>>488
末尾だと思うけどねぇ。end()と同じじゃないけど。

490 ：

remove()は要素を削除するって書いてあった
嘘だった
size()取ったらremove()前と後で変わってないよ

491 ：

>>498
もっとよく調べないからだ

492 ：

STL標準講座よりSGI(not 草加)のリファレンスマニュアルを読めばいいと思うよ
remove:
ttp://www.sgi.com/tech/stl/remove.html

493 ：

今えぴたんのサイト見てきたけど、rbegin(), rend()の説明が間違っているようだね。
ttp://www005.upp.so-net.ne.jp/episteme/html/stlprog/container.html

494 ：

end()は最後の要素のひとつ後、従って、*end()は実行時エラー。
Exceptional C++ にもそう書いてある。
一方、rbegin()は最後の要素、だから、*rbegin()は最後の要素を返す。
STL標準講座はその辺ごっちゃだよね。
範囲をあらわす言葉が統一されないだけ。
初心者向けの本だから、最後の要素がひとつくらいcopyされなかったりしても
気にするなよ

495 ：

>>493
エピス！てめぇｗ
なんちって

496 ：

誰でも間違いぐらいあるさ
　人間だもの
　　　みつを

497 ：

エピの本は買わない
これ常識

498 ：

えぴタンのが間違ってるとして、rend()って何が返るって言えばいいのかな。
先頭の直前を指すイテレータ？

499 ：

逆方向に考えて、末尾の次。

500 ：

逆方向の末尾は順方向の先頭？

501 ：

そりゃそうだ。

502 ：

もちろんrend()を逆参照すると未定義の動作

503 ：

size()が1以上なら、begin()[0]とrend()[-1]は同じ。

504 ：

それは保証されてない。

505 ：

知ったかは去ればーか

506 ：

[ begin, end )
[ rbegin, rend )
なわけだけど、
そもそもこの半分開いた範囲の話すら出てこないのがSTL標準講座。
begin から end に向かって到達可能であることが推定されることも説明されてない。
何より、Visual C++ ver.6 で動作確認という
まったく標準 C++ に準拠していない実装依存なコードが満載。

507 ：

仕様とか無知なくせにふと思ったんだが、STLってスレッドセーフ？
今は一応クリティカルセクション作って保護してあるが、ｲﾗﾅｲなら面倒だからはずしたい・・・

508 ：

C++の規格としては今のところ何も決まっていないから、
自分の使っている奴の説明書読め。

509 ：

>>508 そうかありがとう。

510 ：

あーSTL使うとC#より遅くなる。
辛いねー

511 ：

んなこたーない。使い方が悪いんだろ。
コード貼ってもらえるといいんだが。

512 ：

_SECURE_SCL

513 ：

きっとDebugビルドになっているとかで最適化していないのだろ。

514 ：

いろんな意味で使い方を間違っていれば、C#より遅くなっても不思議ではないと思うけどな。
不必要にコピーを連発しているとか、インライン化が阻害される書き方をしているとか。

515 ：

漏れは>>510はきっとポインタじゃなくて実体を格納させて
コピーコンストラクタが走り回ってると見るけど、
>>514以外に考えられる原因ってある？

516 ：

どうでもいい。エスパースレでやれ。

517 ：

いや簡単なソースを書いてみろよ。
C#の方が大抵はやいんだよ。


俺は気がついた時、正直死ぬほど驚いた。

518 ：

>>517
「簡単なソース」をさ晒してみてくれよ。

519 ：

>>518
バイナリリードでフロートを三時限配列に代入。
アレイつかったプラプラはシャープの倍以上かかる。
試してミソ。

520 ：

どうせvectorの領域再確保が発生してるだけでしょ

521 ：

バイナリリードってどうせoperator>>を使ったんだろ
fread()使ってみろよ絶対にC++の方が早いから
それからC#にはシリアライズ機能が標準装備されているから
比較するならC++もboost使って比較しろ

522 ：

C#の方がデフォルトで楽に速度が出るってことでいいかな。
fread？それCじゃん。C++と比較するならstreamじゃないと。

523 ：

C++でもread()つかってストリームバッファ入力すると速いと思うぞ

524 ：

比較するならプログラム出して検証可能にしてくれ
このままだと >>519 がアホチンなことをしてる可能性が否定できない
（というか、そうとしか思えない）

525 ：

>C#の方がデフォルトで楽に速度が出るってことでいいかな。
その認識でいいと思う
しかし、必要とあらばそこだけCやアセンブリで書いて
手軽に最適化ができるというのもC++の強みかと

526 ：

つまりC++/CLI最強と。

527 ：

ストリームの読み書きの速度で言語の速度を比較するスレはここですか？

528 ：

そう読み違えている人がいるスレならここですよ。

529 ：

なら、速度を欲する目的にiostreamやC#という選択をする人が居るスレがここですね。

530 ：

いや、初心者にありがちな「C++ではstdioは使うべきではない」と考える人のスレです。
それと、write()やReadFileのようなシステムコールを直接呼び出す方が速くなると
勘違いしている初心者のスレでもあります。
「とにかくアセンブラにすれば速い」と思ってそうな気配のある人もいるかもしれません。

531 ：

話はガラッと変わるが、
C#もLINQ登場で一気に魅力的になった。ラムダ式もC++0xより先行しているし。

532 ：

でも一番短かく書けるラムダ式ってboost::lambdaなんだよなぁ…
短さだけが正義じゃないけどさ

533 ：

コンパイル時間の長さもboost::lambdaが一番だな

534 ：

C++はさすがに古いから他言語に乗り換えたくもあるけど、
用途的に無理だからなあ

535 ：

ネイティブコンパイルしてくれて
GC によるストップザワールドのない言語となると
C/C++ くらいしか選択肢ないしな。

536 ：

>>532
bindなんかが必要になったら一巻の終わりだよ。
そうならない限りは本当にいいんだけどね。

537 ：

bindバカにすんなてめぇ

538 ：

バカはバカだろ

539 ：

バインドはバカじゃないよ。単にラムダから短さを失わせるだけで。
特にメンバへのアクセスが嫌だね。

540 ：

意味もない機能でデブな言語になってやったぜ！

541 ：

unko.resize(unko.size()+1);
unko[unko.size()-1] = new Unko();
unko[unko.size()-1].init(chinko,manko・・・);
return unko[unko.size()-1];
これなんとかなんないの？

542 ：

Unko *p = new Unko();
p->init();
unko.push_back(p);
return p;

543 ：

>>542
大してかわんないじゃん

544 ：

そもそもどうしたいのかが分からん。

545 ：

>>541と>>542が大して変わらなく見える、ってのは
センスが無いって事だと思うな。

546 ：

たしかに>>541の方がunkoだらけだね

547 ：

std::auto_ptr<Unko> ap(new Unko);
ap->init(...);
unko.push_back(ap.get());
return ap.release();

548 ：

>>547
いや、だからよ
そういうブロックみたいな塊自体を無くしたいわけよ
push_backがインデックスを返してくれるだけでよかったのにと思ってる

549 ：

なんか、あんまり実用的ではないなぁー。

550 ：

>>549
そうなんだよ
push_backがインデックス返すだけじゃ駄目だなｗ
こんな感じの処理のおかげで結局管理クラス(〜Manage)とか作ったりしねぇ？
上では初期化処理ちょっと省略して書いたけど結局newやinitが失敗したりしたときの
処理まで書くとあんまりvectorやlistに恩恵感じなくなる

551 ：

>>550
何を問題としてるかよくわからんが、とりあえず vector や list を使わなければ
解決する問題ではないだろ。
もしかして ptr_vector が欲しいってだけか？

552 ：

何故Unkoにinitがあるのかもわからん
コンストラクタで初期化するだろ普通
unko.push_back(new Unko(...));
return unko.back();

553 ：

>>552 それ、 push_back() で bad_alloc したら Unko が漏れる。

554 ：

>>553
ホントだよ
だだ漏れだよ
括約筋の切れたｱﾅﾙとなにも変わらない

555 ：

reserveで予約しておけば
push_backではbad_allocが出ないことが保証されてるけどな。

556 ：

当然スマートポインタのコンテナだよな？
所有権管理してない生ポインタのコンテナとかありえないよね？

557 ：

unko.reserve(unko.size()+1);
return *(unko.insert(unko.end(), new Unko(...)));
これでFAかな。

558 ：

なんか俺、大腸な気がしてきた。

559 ：

>>552
困るよ
再初期化効かないじゃん

560 ：

ほんとうは、Unko漏れる 言いたかっただけちゃうんかと

561 ：

Rのさいずもうひとつよやくして、RのはしにあたらしいRをいれてかえす。

562 ：

>>559
initが要らないなんて言っていないよ。
コンストラクタが内部でinitを呼べればいいと言う話。

563 ：

コーラック飲んどけって話か

564 ：

やだよコンストラクタで、大量の初期処理なんて。
キメの細かいエラー処理ができねーじゃん。

565 ：

まあ具体性のない話を長々としても
どうせ解決するわけがないわな。

566 ：

next_permutationって重複してる値があったらうまく並び替えてくれないんだな

567 ：

質問があります。
たとえば、Windows APIとSTLの組み合わせとして、
以下のソース、※１、※２はＯＫなんでしょうか？
ダメ出しと回避策があればお願いします。
（エラー判定など詳細部分は省略）
　 HANDLE hFile;
　 DWORD dwCnt;
　 DWORD dwSize;
　 std::deque<BYTE> d;
　 std::vector<BYTE> v;
　 hFile = ::CreateFile(省略...);
　 dwSize = ::GetFileSize(hFile, NULL);
　 d.resize(dwSize);
　 v.resize(dwSize);
　 ::SetFilePointer(hFile, 0, NULL, FILE_BEGIN);
　 ::ReadFile(hFile, &d[0] , dwSize, &dwCnt, NULL); 　 // ※１
　 ::SetFilePointer(hFile, 0, NULL, FILE_BEGIN);
　 ::ReadFile(hFile, &v[0] , dwSize, &dwCnt, NULL);　 // ※２
　 ::CloseHandle(hFile);

568 ：

規格によって、連続した論理番地に要素が格納されることが要求される
標準コンテナは vector の方だけ。
なんだけど、そういうことが訊きたかったのかな。
もう少し質問が簡で要を得てるといいんだけど。

569 ：

>>568
dequeにこだわる訳ではないですが、
やっぱろdequeを使うべきではない？
実は、シリアル通信でReadFileを使った例があり
以降の電文解析がdequeだったので、
ReadFileがdequeでいければいいなぁなどなど・・・

570 ：

1. vector(または配列), deque 間の変換負荷は許容する
2. deque を使った既存コードの利用を諦める
どれかを受け入れるしかないんでないの

571 ：

>>570
了解！
検討してみます

572 ：

ソースがあって、pop_front/push_frontを使っていなければ、
そのコード、vectorに変えても使えるのでは、と思う。

573 ：

新規質問です：
今までvectorﾓﾝﾘｰで開発してました。
vectorをqueueに差し替えようと思うのですが、
ｲﾃﾚｰﾀﾝでしかアクセスできなくなるんですよね？
vector<MY_REC> items;
int i = items[index].MY_MEMBER;
とか書けなくなるわけですか？
どう書き直せば良いのか教えて下さいorz

574 ：

＞vectorをqueueに差し替えようと思うのですが、
vectorに近いdequeのが良いみたいですね。

575 ：

dequeってリニアアドレスじゃないけど、
dequer<MY_REC> items;
int i = items[index].MY_MEMBER;
って書けるんでしたっけ？

576 ：

>>575
書ける
operator[]があるから

577 ：

�dｸｽ
C++の演算子のオーバーロードってこういう風に使われてるんですね。
自分では使ったこと無いけど。
逆にポインタ取って[]で書くとアウトなんですね。

578 ：

std::dequeはリニアである保証がないからな

579 ：

C言語で書いてた時は、memsetとか使いまくりでリニアって重要でしたが、
C++になってからクラスってmemsetできないし（特にstring）、
リニアの重要性って無くなりましたよね。

580 ：

C++0xを待て

581 ：

>C++0x
kwsk
リニアのメモリ２つのせいで、
Out of Memoryエラーが発生してて、
vectorｲﾔﾝな気分。

582 ：

std::stringがリニアである事が保証される予定
std::ropeはだめだが

583 ：

>>579
そんなこといって組んでると、javaより遅いプログラムになるぞ。
つーか、もうなってるんだけどな！

584 ：

ちょっと便利なアセンブラにちょっと便利な機能付け加えた言語用の
ちょっと便利なライブラリって事を忘れちゃダメだよな

585 ：

しかし、8割はJavaより遅くても問題ない罠（要出典）

586 ：

>std::stringがリニアである事が保証される予定
stringが構造体のメンバだったりしたらリニアって無理な希ガス？
>std::ropeはだめだが
はつみみです。今ググってみましたが長い文字列ですか。

587 ：

>>586
>stringが構造体のメンバだったりしたらリニアって無理な希ガス？
違うvectorと同等にするって意味
std::ropeは非標準だがstd::stringよりカット＆ペーストに向いている

588 ：

あっそーなんだ。
stringの中の人はvectorだと思い込んでいた。
>InfoQ: C++とJavaのレガシーについて語るのは時期尚早か？
>ttp://www.infoq.com/jp/news/2009/04/C-Plus-Plus-Java-Legacy
ﾁﾞｬｳﾞｧの負けｗ

589 ：

vector<MY_REC> items;
で、
items.erase(&.items[1]);
とかしてたんだけど、
vectorをdequeにしたら、うわ、コンパイルエラー。
eraseの引数はｲﾃﾚｰﾀﾝなんでつよね。
記述間違ってない希ガスるんだけど。

590 ：

引数はイテレータなんだから、イテレータを渡そうよ。&items[1] はイテレータではない。
vectorならそれで動くこともあるだろうけど。

591 ：

そうか、自分ﾍﾞｸﾀﾀﾝばっかり使ってたから、
items[?]でイテレーターになると思い込んでいた。
イテレーターの書き方が分からないorz

592 ：

　↑
名前590は589の間違いゴメソ

593 ：

begin() とか end() とかでイテレータを取得できる。イテレータに ++ を作用させれば前に進む。
イテレータが具体的にどんな型なのかは、利用者は知らなくて良い。
（実際にはただのポインタであることもある。）
イレテータの型は vector<MY_REC>::iterator などの名前でtypedefされてるので、必要ならこれを使う。

594 ：

�dｸｽ
items.erase(items.begin + 1);
でコンパイル通りました。
念のため確認したいのは。
dequeはvectorみたく、
・勝手に順番は変わらない。
・items.begin + X　→　X番目の要素を表す
であってますよね？

595 ：

＞items.erase(items.begin + 1);
ごめんなさい、
items.erase(items.begin() + 1);
でしたorz

596 ：

最後の連投です、すみません。
vectorの要素のアドレスをイテレーターとして使うのは、どうなんでしょう？
a) 意識して使うなら記述的にＯＫ
b) アドレス使わず素直にイテレーター使えば？
c) イテレーターに比べて間違ってコンパイル通る場合があるので、アドレス使うのやめるべき
d) vectorから別に差し替え難いのでやめるべき
e) その他

597 ：

あってる。OK。

598 ：

>>596
まあ、b)c)かな。たぶん、環境によってはvectorでも>>589は通らないことがあると思うよ。

599 ：

なぜvectorだと通るんだろう
ポインタからイテレータに変換されたりするのかな?

600 ：

>>599
イテレータの実態(実装)が単なるポインタであることがある。

601 ：

なるほど thx

602 ：

何だか回答が頂けて嬉しい。最後の最後の連投です。
（ポインタ→イレテーター化は直せる数でしたので直すつもり）
vectorとdequeの違いに興味が出てきました。
vectorってresizeしてサイズを大きくした場合、
リニアアドレスが取れない場合、
勝手に先頭ポインタ（と亀の子式に残り全部）変わっちゃう場合があるんですよね？
（サイズが大きい場合、アプリ固まるんだろうか）
それに対してdequeの場合、リニアじゃない分、
要素のポインタは安定して同じ場所に居てくれるのでしょうか？
多分、上記両方とも実装依存なんでしょうけど。
ただ、STLの場合、実装依存でありながら、この操作は短時間で終わる事、
みたいな実装指定に近い規定だった記憶があるのですが。（ネットつまみ食いの知識ｗｗｗ）

603 ：

>>602
実装依存じゃないよ。規格にイテレータの扱いも書いてある。
deque は vector よりも厳しい。
例えば、挿入操作は再配置の有無に限らず、
すべてのイテレータと参照を無効にする。
つまりアドレスが変わる。
そもそも reserve すらないし。

604 ：

>実装依存じゃないよ。規格にイテレータの扱いも書いてある。
あっ、そうなんですか。メモメモ
>挿入操作は再配置の有無に限らず、 すべてのイテレータと参照を無効にする。
この文章が知りたかったんです、有難うございます。STLらしい厳格な文章ですね。
STL知らない人にSTLの考え方とか注意点を伝えるとき、
ｲﾃﾚｰﾀﾝとこの１文を言っとけば大きな間違いは無くせる気がします。

605 ：

23.2.1.3
dequeは末尾か先頭で挿入される限り、全ての反復子が無効になるが参照は無効にならない。
この特性はdequeを使う主要な理由に成り得る。

606 ：

ちょｗ

607 ：

throw NullPointerException

608 ：

catch(NullPointerException e) {
Ga();
}

609 ：

void Ga()
{
throw NullPointerException();
}

610 ：

なるほど、STLって危険なんだねGaｸﾌﾞﾙ

611 ：

>>610
STL無しに同等の機能を作るコストを考えてみるといいよ
もっと危険でgkbrなコードが生成されると思われる

612 ：

ハサミも使いようだしなぁ

613 ：

これってイテレータ無効化される？
vector<int> v;
transform(v.begin(),v.end(),back_inserter(v),bind1st(plus<int>(),1));

614 ：

再配置が起これば無効化されるし、
そもそも無限ループ。

615 ：

あ、無限ループはしてるのはわかるけど
無効化されるのかが気になったので
再配置、ってのは、vectorのcapacityの拡張が起こるかっていうこと？
だとするとこの例は必ず無効化されるわけか

616 ：

関数の引数にvectorの参照を渡して
内部でサイズが変わるような処理したらマズイと
どっかで読んだような気がするのですが心当たり有りませんか？
void somefunc(vector<string>& data)
{
data.push_back("hoge");
}
本なら大抵揃ってるので書籍名とページ数だけでも構いません…。
よろしくお願いいたします。

617 ：

>>616
そのコードは全く問題ない。つーか参照渡して中身をいじれなくてどうするんだよ。
おまいが勘違いしてるのはイテレータのことじゃないか？

618 ：

どうもそのようで。
手元でも普通に動いてたんですが、
アレ、ホントにこれでも良かったかな？と
疑心暗鬼になってました。
レスありがとうございました。

619 ：

自動焼人 ★　＝　自動保守 ◆KAWORUKOFI　＝　自動保守#K9K?_D[L
名言集　その４
『俺の経歴カックイイだろ？』
http://yutori7.2ch.net/test/read.cgi/news4vip/1249830540/　ID:PVAf+dux0　＝　自動焼人 ★
> 984 ：以下、名無しにかわりましてVIPがお送りします [sage] ：2009/08/10(月) 00:11:14.95 ID:PVAf+dux0
> 俺の簡単な年表（笑）
> 高二秋：自前のパソコンゲット
> 高三春：コテハンとしてデビュー、指揮官見習い
> 高三秋：指揮官デビュー
> 大一：新しい武器の開発や、突撃で数々の戦歴を残す
> 大二春：規制系キャップ取得、第一線から退く
> 大二夏：ネットでのゲーム作成プロジェクト始動
> 大二秋：政治系オフに参加
> 大二冬：最後の突撃、華々しく散る
> 大三春：政治系活動を本格始動
> 大三夏：三度目の選挙へ
>
> おまえらは、後を継ぐなよｗ
----------------------------------------------
この自動焼人 ★メールマガジンの配信停止をご希望される方は
http://qb5.2ch.net/test/read.cgi/sec2chd/1250169591/
にて自動焼人 ★までご連絡ください

620 ：

http://cpplover.blogspot.com/2009/08/bjarne-stroustrupconcept_14.html

621 ：

とあるC配列を使っていたコードをvectorに置き換えたんだが・・・
なんかエラーになると思って調べたら、
（以下簡略化したサンプル）
int ar[10];
int idx;
idx = 5;
idx[ar] = 50;
となってた→arを要素10個のvectorに置き換えたらエラー。
idx[ar] = 50;
なんて書き方ができることを初めて知った・・・

622 ：

char c = 3["Hello"]; とか余裕〜

623 ：

やられた
p+c-1==v.size()-1のとき
copy(v.begin()+p-1,v.begin()+p+c-1,u.begin());　//実行時エラー。p+cの時点でオーバーラン
copy(v.begin()+p-1,v.begin()+p-1+c,u.begin()); //OK
copy(v.begin()+p-1,v.begin()+(p+c-1),u.begin());　//OK

624 ：

v.end() + 1

625 ：

std::listから取得したiteratorって、それが指している先の要素が削除された時以外は
常に同じ要素を指し続けてくれますか？
std::vectorとかはころころ変わりますよね

626 ：

>>625 それで合ってる。

627 ：

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

628 ：

vector<T>　イテレータ無効化の罠
で辛酸をなめると、他のコンテナでもビクビクするよな
俺だけかもしれんが

629 ：

vectorはコピーしまくりになるから
要素の変更がある用途には向かない
っつーかvector禁止でも良いくらい

630 ：

>>628
イテレータでビクビクすることはないが、
生ポインタがあちこちに渡されてるのを見ると不安になる。

631 ：

>>629
使い分けのできないバカのためにメモリ連続が保証されたコンテナを捨てる必要はない。

632 ：

馬鹿を基準にしちゃうと何一つ安全・確実なものは存在しなくなるからねえ。
フェイルセーフにも限度というものがある。

633 ：

コンテナの特性なんて最初に全部暗記しておくものだろう
と思ったけど要点を細大漏らさず書いてある比較表、一覧ってないのかな。
Effective STLも留意点の全てが載ってるわけじゃないし。

634 ：

>>633
なんか半年くらい前かな？
STL系でぐぐると一番にヒットしてたサイト。ヒットしなくなったよね
潰れたのかな
あそこが一番わかりやすくて良かったんだが

635 ：

sumi氏のページのことなら、潰したらしい
ついでにboost.cppllも潰れねえかなぁ

636 ：

>>633
覚える必要なんて無いよ。
必要になってから探せばいい。
目の前の問題に必要なコンテナの特性を理解する能力を磨くのが先。
暗記自慢を増やしても仕方ない。

637 ：

そんな数ないんだし、使い方はともかく、特性くらいは覚えておいて損はないよ

638 ：

>>633
STLの仕様書を読めばいいのだ。
コンテナが満たすべき仕様がすべて書いてある。
逆に言えば、書かれていないいかなる仕様も保障されていない。
ちゅか、それがまさにEffective STLに書かれていることなわけだ。

639 ：

C++エキスパートだけがC++を必要とするわけじゃない。

640 ：

エキスパートになりたい人は全部読む。
そうじゃない人は必要なとこだけ読めばいい。

641 ：

C++エキスパートになると頭が禿げます

642 ：

自分が書いてるコードがどう動くかくらい知っといてね

643 ：

メンバにstringを追加したクラスをresize(mycls.size()+1)で増やすとプログラムが落ちるんですけど
これってやったらダメですか？
それとも別のどっかが悪いのでしょうか？

644 ：

本当にstd::string::resize()を呼んだときに落ちるなら、おそらくメモリ確保に失敗してる
mycls.size()の値は確認した？

645 ：

resizeを実行するインスタンスが何なのか、
myclsが何なのか、どこで実行されているのか、全く分からない
もっと具体的に書いてくれ

646 ：

auto_ptrを使ってみた
意外と使えるじゃんこれ
なんでみんな避けてるの？

647 ：

コンテナにつっこめないから

648 ：

コンテナに突っ込めないっていうかそれは副作用であって
そもそも二つ以上のポインタから参照出来ないっていうのが欠陥

649 ：

auto_ptr<Hoge> p(new Hoge());
としたあと
Hoge *q = p;
して
Hoge * をコンテナに入れれば良いんでね？

650 ：

>>649
何の意味があるんだ？
pの寿命が尽きるとコンテナの中身が勝手に消されるぞ。

651 ：

コンテナを使い終わってからpの寿命が消えればいいんだろ

652 ：

>>646
別にみんなが避けてるわけじゃない
多くの人はその特性を理解して適切に使ってると思う
ただ、コピーコンストラクタや代入演算子の挙動が異質だったり
色々と仕様の変遷があったり、VCの古いバージョンが不完全だったりしたので
使用に際していくつかの注意点があった
その注意点を理解出来なかったり、理解するのが面倒な人たちが避けてるだけだと思う

653 ：

auto_ptrが必要なのはreleaseが要るときだけ

654 ：

>>644-645
レスありがとうございます
リビルドすることで落ちなくはなったんですけど
たしかこれってダメでしたね
完全に忘れていました
このスレの
>>352-から続く話を読んで思い出しました
ああ、長い時間が無駄に・・・

655 ：

やっちまいました・・・
>>352と同じ間違いをプログラム全域にわたってやっちまいました・・・orz

656 ：

vector -> decue

657 ：

念のため確認しておくけど「間違い」は
「コピーコンストラクタ、代入演算子、デストラクタを適切に定義していなかった」
であって、「resize() を呼んでしまった」じゃないよね？

658 ：

どうやって適切に定義するの？

659 ：

確保、コピー、破棄

660 ：

つーか、コピー操作をするクラスにコピーコンストラクタや代入演算子が必要かどうか判断つかない人がいることが怖い。

661 ：

>>660
うっかりvectorを使うとすべて必要になるからな
vectorツッコミ禁止コードを入れておけば問題ない

662 ：

>>661
vectorだけじゃないだろ。
dequeでもポインタじゃなくてオブジェクトを突っ込んだらコピーが発生する。

663 ：

コピコン禁止コードってあったじゃん
望月ボウヨウ先生の入門書に書いてあった

664 ：

ちがう
柴田望洋先生だｗ

665 ：

privateにコピーコンストラクタや代入演算子を入れる知恵があれば、コピーできないクラスをコピーなんてしないでしょ。

666 ：

さよならvector <MyClass> mMy;ですね

667 ：

急にスレ伸びてるけどなんかあったの？

668 ：

>>667
>>654が殉職しただけだ
気にすることはない

669 ：

こんにちわvector <MyClass *> mMy;ですね

670 ：

visual C++ 2010を使っていて、stlportの設定中で困っています。
詳しい方がいましたら教えていただきたいです。
STLportをビルド・インストールする際に、
configure msvc8でやると2008みたいでコマンドが通りません。
何を入力したらよいでしょうか？

671 ：

STL固有の問題じゃないんだがこのコードが通らねぇ
std::set<void(Class::*)(int)> methods;
methods.insert(&Class::Method);
原因は、メンバー関数は==と!=以外の比較ができないから。
これ欠陥じゃね？

672 ：

>>671
メンバ関数へのポインタに限らず、普通関数へのポインタなんかコンテナに入れないだろ

673 ：

>>672
それが必要だったりするんだよ。
こういうのを作ってたんだがな。
BroadCaster<void(Event&)> mouse_down;
Controler ctrl;
Event e;
mouse_down.Attach(Delegate<void(Event&)>(&ctrl,&Controler::NextClick); //リスナー登録
mouse_down(e); //すべてのリスナーにイベント発行
これの内部でsetを使ってる。でDelegateを一意に識別するためには、
どうしてもメンバー関数を内部で比較する必要があるんだよ。
まぁ、この例が特異だとしても、イベントリスナーをsetに突っ込むなんてよくやりそうな事じゃ
ないか?

674 ：

>>673
だとすればメンバ関数が==と!=しか使えないのはC++の仕様であって、バグではない
ましてやstd::setの責任でもない
設計ミスとしか言いようがないな

675 ：

>>673
お前はメンバ関数へのポインタを基礎からやり直せ

676 ：

>>674
じゃ、コンテナに突っ込む必要がある時君ならどうする？
関数をコンテナから除去するときvectorに突っ込んで全部なめて削除するのか？
それがC++の仕様だからと言って。

677 ：

>>676
だからコンテナに突っ込む事そのものが間違いだと言っているんだ
std::auto_ptrをコンテナに突っ込むのが間違いなのと同じだ

678 ：

>>675
　理屈は解ってんだよ。実行するまで本当の関数が特定できないから、
メンバー関数のポインターは普通のポインターじゃない。それは解ってる。
　しかし、一度なんらかの関数が代入が代入されると言うことは一意に関数を
識別できるってことではある。現に、関数ポインターを(long**)(&mp):として
とりだしてやれば一意の値を取り出すことも可能なんだ。だから、本来言語仕様で
制限するような事じゃないはずだろ。

679 ：

>>678
だったらここでいくら吠えても無駄だよ
C++標準化委員会に言いな
基本的には仕様書に従え
ここではこれしか言えん

680 ：

>>678
メンバ関数へのポインタじゃなくて、メンバに別のint型のプライオリティフラグでも持って、
それで叙述関数か何か書いてsetに叩き込めばいいだろう
いくらでも回避策はあるはずだ
頭の固いやっちゃな

681 ：

>>680
具体的にどうやんの？頭固いから解んないわ。

682 ：

>>673みたいな例だったら、似たようなことをやっているはずのBoost.Signals2のソースに、参考になるとこないかなあ？

683 ：

>>681
例えば生成パターンにクラスを生成させて、フラグにはそれで連番振るの
それでソートさせるとかすりゃいいじゃん

684 ：

>>673
こんな感じのことがしたいのかな
http://codepad.org/NmSmtfaY
signal使おうとしたらcodepadは通らないな
ライブラリが必要だからかな

685 ：

==と!=ができるのだから、常に固定値を返す最悪なハッシュ関数と共にunordered_setに突っ込むという手も考えられる。
やりたくはないけど。

686 ：

>>682
>>673の例は結局メンバー関数の関数部をポインターに変換して計算してるから
いまさら別にいいんだけどね。
stlコンテナを使ったときの汎用的な方法が知りたいよ。

687 ：

Boost.Flyweightに放り込むのはどう？
同じオブジェクトは同じポインタを指すので、ポインタの大小比較が可能になる。
と思ったが、こいつ結局ハッシュ関数を必要とするので、>>685と同じようなもんだった。
http://www.kmonos.net/alang/boost/classes/flyweight.html

688 ：

>>684
うおっバリバリのboostプログラミング
見た目C#みたいだな

689 ：

>>671
こういうこと？
http://codepad.org/jfJhVYwX

690 ：

>>689
それlとrそのもののアドレス比較してて、何を入れようと結果変わらず、
意味なくね？

691 ：

こうか
ttp://codepad.org/g26T90wp

692 ：

>>691
汚ねーテクニック使ってるなおい
移植性ないだろ

693 ：

ないよ

694 ：

>>691は苦し紛れなりに頑張ってるのではｗ
一意の識別子をkeyに持ってvalueに関数を保持しているのなら見た事あるよ
vectorに保持するのを否定してるみたいだけど、
そんなに速度差が出るほど大量にコールバックを格納するのかな

695 ：

ポインタ同士の等値以外の比較は未定義じゃなかったかな。
あとreinterpret_cast使え。

696 ：

同じ配列に属さないアドレス同士の比較結果は不定、か。

697 ：

intptr_t があるじゃん。
もう大抵の処理系で使えるんじゃないの？
template<> struct std::less<void(Class::*)(int)> : public std::binary_function <void(Class::*)(int), void(Class::*)(int), bool> {
 bool operator()( void(Class::*_Left)(int) , void(Class::*_Right)(int) ) const
 { return *reinterpret_cast<intptr_t*>(&_Left) < *reinterpret_cast<intptr_t*>(&_Right); }
};

不定といったって、実行時に変化するわけじゃないでしょ。
大小関係が実行時に一定なら、この用途には充分。
一定じゃない実装も考えうるけど。

698 ：

まあでも、普通のポインタなら、p == qなら、(intptr_t)p == (intptr_t)qも保証されているので、
心配なら、整数に変換してから比較する比較子を作ってもいいし、
整数に変換した値をハッシュ値にしてunordered_setに入れるのなら、なんの心配も要らないはず。
メンバへのポインタだとそんな保証はあったっけ？

699 ：

>>697
メンバ関数へのポインタはintptr_tと同じ大きさとは限らない。
仮想関数なんかに対処しないといけないため。
少なくともsizeofで見ないとダメだよ。
g++ (x86 32ビット)だとintptr_tの倍の8バイト、
VC++ (x86 32ビット)もコンパイルオプションやその他状況次第で4から最大16バイトになる。

700 ：

intptr_t 及び void * は
データ型へのポインタについてしか、相互変換での安全性は保証されていない。
メンバ関数に限らず、通常の関数ポインタもダメ。

701 ：

汎用的な関数ポインタコンテナはID変換式にするしかないのか

702 ：

だからお前ら規格で保証されてない事を無理にしようとすんなって

703 ：

メンバ関数ポインタの中身をバイト比較って、保証外だよねえやっぱ。
ttp://codepad.org/puCA18lB

704 ：

>>703
というより、そもそも、どうしてそれが保証されると思うのかが聞きたいw

705 ：

ところで>>680のいうint型のプライオリティフラグを持たせる方法とやらはどうやるのかね？

706 ：

質問よろしいでしょうか
std::fstreamを使ってバイナリデータを読み込もうとしています。
データは、いくつもの構造体をそのままダンプしたデータとなっており
----
fstrm.exceptions(std::fstream::badbit | std::fstream::failbit);
fstrm.open("hoeg.dat", (std::ios::in | std::ios::binary));
fstream.read(&hogeStruct, sizeof(hogeStruct));
fstream.read(&fooStruct, sizeof(fooStruct));
----
こんな感じで次々構造体にreadしていこうと思いました。
ここで困ったのですが、どうも「readした結果、ぴったりファイル終末まで達したら」failでExceptionが投げられるようなのです。
期待していたのは「readなりで、ファイルサイズをオーバーして読もうとしたら」例外。
という挙動なのですが、こちらはfstreamに存在しないのでしょうか？
eofのExceptionも「ぴったりファイル終末まで達したら」投げられてしまうようでして…。

707 ：

>>706
すいません、こちら私の勘違いが原因でした。
ぴったし＋1バイト以上読むとeofbitのExceptionおよびfailbitのExceptionが発生しました。
こちらのテストコードミスです。すいませんでした

708 ：

boo-----

709 ：

tes

710 ：

最近寂しいのでageますよ

711 ：

streamの例外はbadbitだけ立てると使いやすいよね

712 ：

failbit も立てとかないと中途半端じゃないか？

713 ：

確かにstd::iostreamは例外で処理すると綺麗に書けるな

714 ：

理由が解らんでもないんだが、std::mapにconstでoperator[]アクセス出来ないのは
微妙だよなぁ。constで呼び出されたときに未格納のキーを渡されたら例外出せばいいだろうに。

715 ：

>>714 http://www.google.co.jp/search?q=std%3A%3Amap+at

716 ：

そもそもキーが無い時に勝手に要素追加するという仕様がイケてない

717 ：

だよね

718 ：

とはいっても、組込み屋としては例外吐かれても困る。
end() の参照を返すわけにもいくまい。
コンパイルエラーにしてくれる現状がベスト。
だいたいその程度なら自分でユーティリティ作ればいいだろう。

719 ：

>>718
組み込み屋はなんで例外吐かれると困るの？
どのみち map 使ってたら bad_alloc 飛んでくるんじゃね？

720 ：

組み込みコンパイラは例外対応が不十分（というかハード的に無理）なんてザラでは

721 ：

>>719
処理速度やメモリ消費を考慮して例外を使用しない設定でビルドするよ。
STL コンテナを使うときには例外出さない自作アロケータ使うよ。

722 ：

>>721
処理速度？
例外使っても throw 〜 catch 以外は遅くなるところ無いんじゃないの？
むしろ戻り値でエラーチェックしないぶん速くなることもあるみたいだし。
メモリ消費っていうのはコードサイズのことかな？
RAM の消費は数 KB ってとこだよね？

723 ：

スタックオブジェクト廃棄のためにtry-catch文を書いたのと同じコードが生成される事はよくある。

724 ：

>>723
それはあたりまえ。
でも try で処理速度が問題になることは（最近のコンパイラでは）ほぼ無い。
VC6 とか Mingw 3.x.x あたりでは try （およびローカルオブジェクト）ごとに
コードが追加されてえらいことになってたみたいだけど。

725 ：

>>722
> 例外使っても throw 〜 catch 以外は遅くなるところ無いんじゃないの？
throw 〜 catch 使わないなら例外自体使わなくてもいいでしょ。
メモリはコードサイズとテーブルのサイズ。
実行時に消費するメモリがどのくらいかはちょっと見当がつかない（かなり少ないんじゃないか）。

726 ：

>>725
>> 例外使っても throw 〜 catch 以外は遅くなるところ無いんじゃないの？
> throw 〜 catch 使わないなら例外自体使わなくてもいいでしょ。
throw 〜 catch をまったく使わないんじゃなくて、 throw 〜 catch が
遅くなるだけならかまわない（異常系の速度を気にしないところでしか
使わない）ってことでしょ。
map の例で言えば、 at() と find()+if とを見つからない場合の速度要求に
応じて使い分けるってことになるね。
なので >>721 のように「例外を使用しない設定でビルド」する理由に
処理速度を挙げるのはおかしいんじゃないの？って話。

727 ：

>>726
例外ランタイムをリンクするだけで処理速度にペナルティがあるなんて話をしたつもりはないよ。

728 ：

mapのvalue_typeはどうしてconst keyだけなの？
キーと値のペアを一時変数でごにょごにょいじって再格納したいときとか、
value_typeを集めたvectorを作りたい時とか困るじゃん！
今は苦肉の策で
typedef std::pair<hoge, hoge> mutable_value_type;
mutable_value_type pair(hogeMap.begin()->first, hogeMap.begin()->second);
とかしてるけど面倒すぎるよ！何か良い方法ないの？

729 ：

>>728
挿入時と検索時の速度を保証するため
もしconstじゃなかったら挿入の度に木を再構築しなければならず、ものすごく遅くなる

730 ：

>>728
規格で規定はされてないけど普通木構造で実装するので key の値を変えられると最悪木全体の再構築が必要になる。
key なり pair<key,value> なりにコピーしてから変更すれば？そのコードはちょい遠回りじゃね？

731 ：

>>728
std::pair<hoge, hoge> hogecopy( *hogeMap.begin() );
std::pair<const hoge, hoge> & hogeref( *hogeMap.begin() );
ていうか、なんで pair にするの？
key を変更して再格納するなら key, value のそれぞれの一時変数を作るのが平明でしょ。
value を編集したり、集めたりするなら、イテレータのままで問題ない。

732 ：

もしかして型名を書くのが面倒臭いという話だろうか
typedef map< ..., ... > mt;
typedef pair<
　remove_const< mt::value_type::first_type >::type,
　mt::value_type::second_type
> mpt;
確かにあんまりｲｹてない気がする

733 ：

boost様の力でどうにかならないんすか？

734 ：

>732
さしあたって mt::value_type::first_type は mt::key_type、mt::value_type::second_type は mt::mapped_type でいける。

735 ：

map使うときpairも必須なんだから、mt:pairを何で用意してないの？って話じゃね

736 ：

vectorへの要素追加と削除時に要素に対して任意の処理を実行したくて、
継承したクラスを作ったんだが、
.erase(std::remove())の記法で削除される要素は、
eraseに来る時点で該当要素のオブジェクトが初期化されてしまっていた。
(具体的には、shared_ptr要素の指す先がnullになっていた)
なにか他に良い方法はないだろうか？

737 ：

継承しないで手作業で呼び出しクラスを書く

738 ：

sortかstable_sortしてfindしてeraseする

739 ：

そうか、ごめん完全に頭がやられてる。
removeeraseの使用を禁止して、
代わりにfinderaseベースの削除コードを
使用するよう規定すればいいのか。
>>737-738
ありがとう。
sortする理由は、removeだと詰めて空いた分の要素が初期化されちゃうけど、
sortなら初期化されずに同値が隣接するだけになるからってことで合ってるかな？

740 ：

削除したいかどうかを基準に比較するファンクタを使ってソートすれば
remove同様前後に分かれるだろ

741 ：

>>736
そのクラスで書き込み可能なイテレータや参照を公開している限り、
任意の処理を漏れなく実行することは無理でしょう。

742 ：

アロケータという手もあるけど面倒だな

743 ：

そもそもコンテナって継承していいんだっけ

744 ：

>>743
継承しても、 new で得たポインタをアップキャストしたまま delete しない限りは問題ない。

745 ：

vector<int> v;
v.reserve(1000);
for(int i=0; i<1000; ++i) v[i]=i;
とした後に、
vector<int>::iterator it;
for(it=v.begin(); it!=v.end(); ++it) cout<< *it <<endl;
としてもうまくいきません。v.end()がv[1000]の次を指していないため
ですが、v.end()を設定する方法ってあるんでしょうか？
それとも、reserveとiteratorは相性が悪いのでしょうか？

746 ：

v[i]=i を v.push_back(i) にかえる

747 ：

確かreserve()は領域を予約するだけで
アクセス可能になるわけではないと思いますが

748 ：

>>746
そうなんですが･･･　push_backでは時間がかかります。
>>747
実際、reserveしてみると、普通にV[i]=iのアクセスが可能です。
｢いや、そう見えるだけであって実際には･･･の話かもしれないけど
(C++では意外なメカニズムに驚くことが多すぎて、自信ないです)。

749 ：

いや、そう見えるだけであって実際には範囲外アクセス

750 ：

>>748
[i]が単なるポインタアクセスになってるからできてしまっているが、
reserveしただけの段階だとsize()の値とかend()の返す位置とかpush/pop_back()
など全部変化しないから、色々困るだろう。
[i]で初期値を入れるなら、reserveじゃなくてresizeを使うといいよ。

751 ：

>>748
あとreserveしたサイズ内でのpush_backならメモリの拡張処理は発生しないと
思うので、時間もかからないんじゃないの。
(どの環境なのか分からないので断言はできないが)

752 ：

>>748
そう、難しく考えなくとも
vector<int> v(1000);
で済む話でした。ただ、intを格納するのなら問題ないですが、
自作のオブジェクト、それも引数付きのオブジェクトを格納
するときはreserveが必要なわけで。で
しかし、iteratorは使えないわけで。

>>749 - >>751
嘘。

753 ：

>>745
reserve()じゃなくてresize()だろう
ちゃんと規格票か本読め

754 ：

std::vector<int> vec;
vec.reserve(5);
for( int i = 0; i < 5; ++i ) vec[i] = i;
↓codepad の g++ でabortした
> /usr/local/lib/gcc/i686-pc-linux-gnu/4.1.2/../../../../include/c++/4.1.2/debug/vector:192:
> error: attempt to subscript container with out-of-bounds index 0, but
> container only holds 0 elements.
たまたま上手く動いているように見えるだけで
reserveしただけの要素に直接アクセスするのはやはり避けるべきでしょう

755 ：

>>752
reserve() + push_back() でいいだろ。
確かに最終的な要素数が決まっている状況で size() を 1 ずつ増やしていくのは無駄だけど、
自作のオブジェクトならその部分の負荷の割合も下がるだろうし。

756 ：

reserve()というのはメモリの再割り当てを指定した要素数になるまで起きないように
防止するだけの働きであり、実際に空のコンテナを用意するわけではない
だから未定義の動作＝鼻から悪魔
メモリの再割り当てが起きると時間が掛かるしイテレータ・ポインタ・参照が無効に
なるのでそれを回避したい時に使うがそれ以上の意味はない
詳しくはEffective STL P65を見よう

757 ：

あ、size()を超えたコンテナへのアクセスとかイテレータの逆参照などが鼻から悪魔ね

758 ：

>>749->>751
ごめん。俺の間違いだったかもしれん。
>>756
Effective STL P65、ちょっと前に読んだことあるけど、言ってる
ことが俺にはよくわからなかった。空のコンテナを確保しておか
ないと、メモリの再割り当てを防止できないと思うけど。
>>754
そうかもしれない。
>>755
確かに。でも、gcc4.4.2 + SGI STL ? では reserve()を使わずに
vector<int> v;
for(itr=0; itr<itrmax; ++itr) {
for(i=0; i<N; ++i) v1.push_back(i);
v1.clear();
}
とやった方が圧倒的に速かった。STLの実装にもよるがreserve()を使う
ご利益がわからない。iteratorの無効化は防げるだろうけど。

759 ：

v1→ｖ

760 ：

ごめん。また間違えた。gcc4.4.2 → gcc4.4.1
>>755
比較するベンチマークのプログラムが間違ってた。やはり、
reserve() + push_back()の方が速かった。
(1) reserve()関数で領域確保しても、push_back()で要素を格納していく。
(2) いきなり、[]演算子を使って要素の代入を行うのは危険
ってとこか。しかし、v.reserve(N)を呼び出した時点でv.size()、v.end()
を使えるようにすることはreserve()関数内で可能だと思うが、そうしない
のはなぜだろう？

761 ：

だからresize()というメンバがあるんだって。
調べろよ

762 ：

一応書くとreserveはメモリの割り当てのみで
コンストラクタが呼ばれない＝オブジェクトが初期化されない。
resizeは初期化される＝アクセスしても安全。

763 ：

resize()はメモリの再割り当てで時間がかかるし、イテレータ
が無効になるだろが。知らんくせに横から口出すな。カス！

764 ：

きみ向いてないよ

765 ：

こんな過疎スレで釣りするヤツの気が知れない

766 ：

>>763 それは reserve() も同じだよ。

767 ：

コンストラクタが呼ばれないということは
当然デストラクタも呼ばれないわけで
もはやオブジェクト指向どころの話ではなく
charのブロックをnewして直接弄ってるのとあまり変わらない気がするｗ

768 ：

>>763
馬鹿かお前は
Effective STLを100回読んでから書き込め

769 ：

C++関連のスレ荒らしてるいつものアホだから、構っちゃダメ

770 ：

100冊買ったけど1回も読んでないわ。カス！

771 ：

>>768
こういう奴に限って、全然わかっとらんｗ

772 ：

>>771
まだ噛みついてんのか
余程悔しかったらしいなｗ

773 ：

いいや、全然。
馬鹿か

774 ：

なんだ自分の書いてる事のおかしさにも気づけない馬鹿だったか

775 ：

ID出てないのにくさいって凄い

776 ：

うざい。どうでもいい。

777 ：

STLの本はどれも退屈で刺激がすくない -> non stimulate

778 ：

すげえな。ここまで頭悪いと笑えるわ。

779 ：

殆ど自演だからね

780 ：

しょうもない奴等ばかりｗ

781 ：

たとえそこが肥溜めでも首を突っ込まずにはいられない

782 ：

落とし穴スレだけに

783 ：

std::vector<double> Prob(N+1);
あqwせdrふじこlp；←適当な処理
Prob[N] = std::accumulate(Prob.begin(), Prob.end()-1, 0);
N番目の要素にN-1番目までの要素の和を求めて、
結果が１になるのを確認したかったのですが、Prob[N]に0が代入されました
だれか何か御教示ください。

784 ：

なんでend()の結果を1引いているの?

785 ：

Pr[0],Pr[1],Pr[2],...Pr[N-1],Pr[N]
↑Pr.begin() ↑Pr.end()
となると思ったので、イテレータから-1しました.

786 ：

ずれた。…orz
やりたいことは、
Prob[0]からProb[N-1]までの要素の和を求めて、
Prob[N]に合計を代入したかったんです。

787 ：

>>783
合計が 0 だったんだろ。 1 になるというのならその根拠がわかるように書いてくれないと。

788 ：

あqwせdrふじこlp；←適当な処理
は、乱数を割り当てて、その規格化定数で割るといった処理をしているので、
合計は１かそれに近い値になります。
実際に各要素を出力させても、[0,1)の範囲で値が入っているため
合計が０になることはありえません。
STLでは、引数にvectorをとる関数の返り値を、
その引数に代入させてはいけないのか疑問に思ったので
質問させて頂きました

789 ：

Prob.end()-1がまずいんじゃないの？
std::advance(Prob.end(), -1)に置き換えたらどうなる？

790 ：

std::accumulateの第三引数を 0 から 0. にしろ

791 ：

0て書くとintと判断されるつまり>>790ってこと(ドットがあると浮動小数点数になる)
デバッガで追えば簡単に分かることだからちゃんとデバッグしよう

792 ：

Prob[N] = std::accumulate<double>(Prob.begin(), Prob.end()-1, 0);
ではどうかな？

793 ：

>>792
累算する値の型はテンプレート第２引数だから、そうはいかない。
・・・それでいけるようにしたほうがよかったんだろうな。設計ミスっぽい。

794 ：

accumulateの引数の型は、いかにも落とし穴っぽい。
スレの趣旨にぴったりだな。

795 ：

>>789
合計値は変わりませんでした。
random-access iteratorの演算子に、-が含まれているので
リテラルとして,Pr.end()-1はあっている気がします.
>>790,791
ありがとうございます。期待する値を得ることができました
今度からデバッガかけます

796 ：

§26.4.1 Accumulate
1 Effects: Computes its result by initializing the accumulator acc with the initial value init and then modifies
it with acc = acc + *i or acc = binary_op(acc, *i) for every iterator i in the range
[first, last) in order.262)
2 Requires: T must meet the requirements of CopyConstructible (20.1.3) and Assignable (23.1) types.
binary_op shall not cause side effects.
マジだorz
>acc = acc + *i or acc = binary_op(acc, *i) for every iterator i in the range
つまりaccの型がintだといくらdoubleを足しても小数点以下は切り捨てか

797 ：

ほんと、糞みたいなコードありがたがってどういうつもりやらｗ

メイヤーなんて、そりゃプログラミングはわかるかもしれないが、
論理的な思考というか、説明能力が欠如
そんなのをありがたがっている黄色い猿どもってｗ

798 ：

額に｢馬鹿｣の字が見事にｗ

799 ：

連投するぐらいなら一回でまとめようや
それとも一つにまとめるよりばらけさせて二倍臭いとかそんなつもり？

800 ：

>>796を解決する方法が一つ見つかった
面倒だけど
std::accumulateの宣言は
template <class InputIterator, class T>
T accumulate (InputIterator first, InputIterator last, T init);
だから
int main()
{
std::vector<double> vd;

for (int i = 0; i < 10; i++)
vd.push_back(i);
double sum = std::accumulate<std::vector<double>::iterator, double>(vd.begin(), vd.end(), 0);

std::cout << sum << std::endl;
}
こういう書き方なら末尾の 0 を double と見なしてくれる

801 ：

std::accumulate(v.begin(), v.end(), static_cast<double>(0));
std::accumulate(v.begin(), v.end(), double());
型名を明示したかったらこうすればいいだけのことだろ
ばかばかしい

802 ：

>>801
それはわかっている
Generic Template Programmingを読んだらaccumulateの宣言が載っていたので
それでやろうと思っただけ
template引数の使い方も知っておかないとまずい場合もあるだろ
俺だったらこうするね
std::accumulate(v.begin(), v.end(), 0.0);

803 ：

それより何をそんなに怒っているんだ？
>ばかばかしい

804 ：

怒られてると思うなら精神科による診断をお奨めします

805 ：

この程度で怒る方がおかしいと思う

806 ：

>>805 がまだわかっていないようなのでもういちどいいます
怒られてると思うなら精神科による診断をお奨めします

807 ：

ばかばかしい

808 ：

http://xfs.jp/XdIjk

809 ：

>>806
理由は？理由も書かずにいきなり「精神科に行け」とは失礼過ぎませんか？
あなたの方がおかしい可能性も十分にあるでしょう
だから理由を聞かせて下さい

810 ：

>>805
この程度で怒られる事もあるんですよ
「ばかばかしい」という言葉は強い意味ですよ
もしそう思っても書かないで、あなたの腹の中で思ってて下さい
書くと誤解を招きます

811 ：

だいいち「ばかばかしい」という言葉が余計
自分の非を差し置いて人に「精神科に行け」とはずいぶんな言いがかりですね

812 ：

Standard Template ばかばかしい

813 ：

>>812
STLがばかばかしいんじゃなくてお前の頭が馬鹿なだけだろｊｋ

814 ：

あとは、こことか
http://studiokingyo.fc2web.com/

815 ：

ばかばかしい

816 ：

ばかばかしいならこのスレに来なきゃいいのに
マゾですか？

817 ：

mapってさ。iteratorがpair返すじゃん。
うんでさ、大抵のalgorithmってfirst、secondに引っかかるじゃん。
みんなどうしてんの？
わざわざpair用に噛ませるfunctorとか作ってんの？

818 ：

>>817
こういう話か？だからC++1xはlambda式が使えるようになってるわけよ
こういう面倒な事をしなくても済むように
struct Pred : public std::unary_function<std::pair<const std::string, int>, bool> {
std::string str;
public:
explicit Pred(const std::string& s) : str(s) {}
result_type operator()(argument_type& pos) const {
return str == pos.first;
}
};
int main()
{
std::map<std::string, int> si;

si["abc"] = 1;
si["def"] = 2;
si["ghi"] = 3;
std::map<std::string, int>::const_iterator pos = std::find_if(si.begin(), si.end(), Pred("def"));
std::cout << pos->second << std::endl;
}

819 ：

そうそうそういう感じ。
ラムダはともかく、なんでC++03の時点でライブラリのサポートが無いのかわからん。

820 ：

>>818
それをlambda式を使って書くとどうなるの？

821 ：

>>820
int main()
{
std::map<const std::string, int> si;

si["abc"] = 1;
si["def"] = 2;
si["ghi"] = 3;
std::map<const std::string, int>::const_iterator pos = std::find_if(si.begin(), si.end(), [&](std::pair<const std::string, int> pos) { return pos.first == "def"; });
std::cout << pos->second << std::endl;
}
どや、無茶苦茶シンプルになるやろ

822 ：

>>819
え？サポートされてるでしょ
単に関数オブジェクトを勉強すればすぐに理解出来る
ただ unary_function とか binary_function の必要性は関数アダプタを
勉強するまで分からないだろうが

823 ：

>>821
短くなるけど、[&]ってセンス悪過ぎない？

824 ：

>>823
俺もC++1xのlambda式はあまりにも見た目が汚いと思うんだが、FDISで誰も
代替案を出せないんだと
多分このまま決まるな
VS2010もg++もこのlambda式が使えるし

825 ：

inline, inline& がいいと思ったんだけどな。
個別にキャプチャするにはやっぱり囲わないとダメか。

826 ：

STLのヘッダの中を覗いたら、吐き気がしたわ
こんなもん考えたやつ、頭オカシイんでねーの？

827 ：

>>826
それは甘い
boostのソース見て見ろよ
完全に発狂していると思えるぞ

828 ：

物によるがboostの方がマクロ乱舞のライブラリよりは大分ましだろ。

829 ：

( ﾟДﾟ)ﾊｧ?

830 ：

>>828はboostの自演

831 ：

vimのquick fixでコンパイルして、エラー箇所としてboostのヘッダファイルに
バッファが飛んだとき、将来の職業としてプログラマだけにはなってたまるかって思ったよ

832 ：

>>826-827
あれぐらいで頭オカシイ、完全に発狂って言うようじゃ
C++プログラマ(C++を使えるといえない)とは言えない

833 ：

>>828
boostだってマクロ乱舞だぜ

834 ：

テンプレートを活用しようとすると
少なからずマクロの力必要だし
たぷるとかマクロなしでひとつひとつ作ってたら死んじゃう

835 ：

>>832
ほう、ではお前さんはboostを超える物を何か書いて発表したかね？

836 ：

>>834
可変長引数テンプレートの代替くらいじゃん
workaround以外でマクロの出番なんて普通にC++使ってればそれほどない
少なくとも日常的に使うほどではまずない

837 ：

boost使うのはともかく、書くのは日常じゃないしな。

838 ：

ところで、おまえらはboostぐらいのレベルのライブラリを作れる？

839 ：

近いうちに俺のコードがマージされそう。

840 ：

つ boost::progress_display

841 ：

boost::progress_timerはちょっとしたベンチマークに便利だな
QueryPerformanceCounter()を使った簡単なクラスを組んであるけど
これよりもっと手軽だ

842 ：

Rubyバカにしてる子ってさ
変数に＄ついてる言語触ってるって事だよね
いちいちSHIFT＋４キーおして ＄ 打ちまくってる感触はどう？
ゴミ

843 ：

通報済み

844 ：

なにこれ

845 ：

>>842Perlの事ならおれに言え！ｼｭﾎﾞｰ!!

846 ：

しかし、変数の前に常に $ をつけるのも、悪いことじゃないと思うんだ。
というのも、結局、どこかの流派の人たちはクラス名の前にかならず C をつけたり、
データメンバのまえに m_ をくっつけたりするからだ…。
クラス名は先頭が大文字ならそれでいいのに。

847 ：

変数名に$をつける言語なんかBASICくらいしか使ったこと無い
文字列のプレフィックスだよな

848 ：

Rubyはメンバ変数に@を付けるね

849 ：

C++も頭かお尻に m_ とか _m を付けるハンガリアン記法が便利

850 ：

>>847
BASIC は suffix だろ、しっかりしてくれ。

851 ：

perlも$付けるよ

852 ：

$安いよね

853 ：

＞std::vector<Point> Points;
＞Ponit *pPt = Points.insert(Points.end(), Point());
このとき、pPtが参照しているメンバーは何番目のメンバーか把握できるのでしょうか？
orz

854 ：

vectorだから、pPt - &Points[0]で足りるんじゃねーの

855 ：

>>854
vectorの返すイテレータはポインタとは限らないぞ

856 ：

そんなことは百も承知。だからbegin()を使っていない。

857 ：

Points.size() - 1

858 ：

>>855
で、質問をちゃんと読んでから、偉そうにコメントしてくれ。

859 ：

>>857
馬鹿か？
Points.size() - 2
だろ

860 ：

おまいらが喜ぶレス付けてやったんだよ。
ありがたく思え。

861 ：

end() は要素じゃないんじゃない？

862 ：

つ [�d]
C言語的な解決策はあったわけですね。その手段でやるしかないですね。
逆にｲﾃﾚｰﾀﾝを経由した書き方で、853を書き替えたらどうなるんでしょう。
でもｲﾃﾚｰﾀﾝだと、何番目のメンバーとか取れないのか。。。
何だかSTLって悩みますね。

863 ：

end() は要素じゃないんじゃないんじゃないんじゃない？

864 ：

＞end() は要素じゃないんじゃない？
＞end() は要素じゃないんじゃないんじゃないんじゃない？
どっちですか（＞＜）
何年もこの書き方なんですが、今さら違ってると言われたらｶﾞｸﾌﾞﾙｗ

865 ：

STL関係ないわ
スレ違いもいいとこ

866 ：

>>859
何で-2ですか？

867 ：

end()が要素だったらend()の前にinsertしたら最後の要素じゃなくなるよね

868 ：

つ[distance()]

869 ：

本当ですか？>>867

870 ：

>>868
ﾍﾞｸﾀﾝのｲﾃﾚｰﾀﾝって、ポインタで良かったんでしたっけ？
だとすると、
＞std::vector<Point> Points;
＞Ponit *pPt = Points.insert(Points.end(), Point());
＞int iIndex = distance(pPt - &Points[0]):
ですか？

871 ：

経験則でおｋ、とは思いませんが、
＞std::vector<Point> Points;
＞Ponit *pPt = Points.insert(Points.end(), Point());
＞int iIndex
のとき、
＞iIndex = Points.size() - 1;
＞iIndex = distance(Points.begin(), pPt);
の両方とも、上手く動作するっぽいですorz

872 ：

>>869
end()
文法:
  iterator end();
end() 関数はベクタの末尾を指す イテレータ を返す。
 ベクタの最終要素にアクセスするは、イテレータをデクリメントする必要があることに注意。
関連項:
begin()

873 ：

つまりどういうことです？

874 ：

size() == 3のとき。
■←begin()
■
■
□←end()

875 ：

size() == 3のとき。
■←begin()
■
■←back()
□←end()

876 ：

>επιστημηです。
>
>--- "[cppll:9733] Re: std::vector の要素の連続性" ---
>
>>2000年08月に vcpp mlで、「規格上は中身をどう実装しようが勝手なんで、
>>std::basic_stringを用いる手もアリかも」という話がありました。
>
>規格上は中身をどう実装しようが勝手なんで、
>std::basic_stringの要素が連続してる保証が…
># 実質上おっけーですけど^^;
>
>ま、欲しいバッファがconstでいいなら basic_string::data() 呼べば。

877 ：

http://ml.tietew.jp/cppll/cppll/thread_articles/9693

878 ：

1要素insertするたびに全要素分の配列再allocateされて
全要素コピーされてたでござるの巻

879 ：

>>859
しかし、じっさいに動作させると、
＞Points.size() - 1
で上手くいくのですが？

880 ：

＞Ponit *pPt = Points.insert(Points.end(), Point());
これって、インサートしたものが末尾になっているような気がするのですが、
間違いですか？

881 ：

>>879 じゃぁそれでいいじゃないか。このスレにもバカはいるさ。
>>880 自分で確かめられるだろ。

882 ：

back から insert ですね
わかります

883 ：

vectorのメモリ管理って：
struct Rec {
　std::vector<Rec> InArray;
};
std::vector<Rec> OutArray;
のとき、
OutArray.clear();
ってやっても、
InArrayがクリアしてなかったから、メモリリークになった、
なんてことは無いですよね？

884 ：

ありますよ

885 ：

え”ー、そうなんですか？
InArray.clear();
してから、
OutArray.clear();
しろ、
ということですか？

886 ：

>>876
コイツ前から思ってたけどマジで日本語書かないよな
C++やりすぎるとこうなるらしい

887 ：

お前ほどじゃない

888 ：

>>883-884 ねーよ

889 ：

コンパイルできないからリークもしないよな

890 ：

こんな過疎スレにまで来てるのか

891 ：

＞>>2000年08月に
まずこの08月ってのがいきなりうざい
＞>>2000年08月に vcpp mlで、「規格上は中身をどう実装しようが勝手なんで、
＞>規格上は中身をどう実装しようが勝手なんで、
「規格上」は？　　はぁ？？？？？「規格では」とか言えばいいのに
しかも何で二回いってんの
しかもその後
＞># 実質上おっけーですけど^^;
また「○○上」って単語がでてきた　最後の顔文字なんでつけたの？　ねえなんで「＾＾；」←この顔文字をつけたの？　この顔文字つける意味あった？ネェなんで顔文字つけたのー？
ほんのわずかな文章で　規格上　規格上　実質上　って3回も変な単語でてきたよコイツ
次、
＞>std::basic_stringの要素が連続してる保証が…
はぁ？？？
最後まで喋れよ
＞>ま、欲しいバッファがconstでいいなら basic_string::data() 呼べば。
、ま、ま、ま、ま、ま「、ま」じゃねーよ何もまとまってないし、　呼べば。　でまた文章とまってる
はぁ？？？
なにこれ、
最後まで発音できないの？
＞>std::basic_stringの要素が連続してる保証が…
＞>ま、欲しいバッファがconstでいいなら basic_string::data() 呼べば。
いい加減にしろ
謝れ
俺が言いたいのはそれだけ

892 ：

呼べばなんだよ
保証がなんだよ

ふざけんな

893 ：

まずお前が and でも or でもないものを and とか or とかいうのをやめてから言え。

894 ：

何の話や？

895 ：

そんなカッカすんなよ
uyも大してかわんないからさ

896 ：

>>883
「わかりました。」「まかせてください。」
↓　数時間後
「は？こんなもん作れって言ってない」

ゴミ

897 ：

std::swap_ranges アルゴリズム

898 ：

一時オブジェクト嫌いや( ｀д´) ｹｯ!

899 ：

>>898
C++11はいいぞー
ムーブコンストラクタがどんなに便利か
そしてSTLもかなり速くなっている

900 ：

C++11とSTLが速くなってるってどういう関係が？

901 ：

ムーブコンストラクタが効いてるんじゃない？

902 ：

>>899
898です。
現場がまだそれ(C++11)に対応して無いから仕方無いんだけどね。
愚痴ってしまった。

903 ：

どう考えてもC++03の
一時オブジェクトを作る→それをコピー→一時オブジェクトを破棄
って無駄だろうが
C++11では出来る場所では
一時オブジェクトを作る→即そのポインタもしくは参照を変数に代入
というわけで無駄がないし速くなる

904 ：

>>903
> 一時オブジェクトを作る→即そのポインタもしくは参照を変数に代入
とても正しく理解できているようには読めんな。

905 ：

Senior Developer がメチャクチャ怪しい
http://blogs.msdn.com/b/vcblog/archive/2012/06/15/10320846.aspx

906 ：

＞std::vector<Point2D> Points;
＞Point2D *pP = Points.insert(Points.end(), Point2D());
某系のコンパイラでは通るのですが、gccでコンパイルエラーです。
この書き方って間違ってますか？

907 ：

＞-build-desktop-Qt_4_8_1__Qt-4_8_1__Release/../../TPolygon.h:72: エラー: cannot convert '__gnu_cxx::__normal_iterator<Point2D*, std::vector<Point2D, std::allocator<Point2D> > >' to 'Point2D*' in initialization

908 ：

class Point2D {
public:
void print() const {
std::cout << "Point2D" << std::endl;
}
};
int main()
{
std::vector<Point2D> Points;
std::vector<Point2D>::iterator pP = Points.insert(Points.end(), Point2D());
pP->print();
Point2D* pP2 = &*pP;
pP2->print();
}

909 ：

つ [お礼] >>908

910 ：

度々すみません。
つまり、gccではﾍﾞｸﾀﾝで、
「ﾎﾟｲﾝﾀ→ｲﾃﾚｰﾀﾝ」はキャストＯＫ、
「ｲﾃﾚｰﾀﾝ→ﾎﾟｲﾝﾀ」はキャストＮＧ、
ということでしょうか？
「ｲﾃﾚｰﾀﾝ→ﾎﾟｲﾝﾀ」はどう書けるのでしょう？

911 ：

>>910
pointer = &* iterator;

912 ：

ケツにぶち込むなら
pointer = &Points[Points.size() - 1];

913 ：

つ orz
なるほど、ｲﾃﾚｰﾀﾝから一旦実体化してさらにアドレス取るんでつね。
盲点というか、それならコンパイルエラー起きようがないです。

914 ：

イテレータから取ったポインタを++とかやりそうで危ういな

915 ：

それはﾍﾞｸﾀﾝ限定なら無問題では？
ﾎﾟｲﾝﾀﾝを保持するとダメなだけで。
ってSTLの最大の欠点は、何が危ないか難しい事ですよね。

916 ：

ポインタの vector にしてると
また色々ミスが出てくる

917 ：

>>916
ああ再配置か
いつ起きるか分からないから怖いな
まあだいたい起きる時の指針はあるけど

918 ：2012/10/27

ooﾀﾝ