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

1 ：858：2007/12/24(月) 03:41:59

C++標準ライブラリの一つ、STLについて。

前スレ
【C++】STL（Standard Template Library）相談室 7
http://pc11.2ch.net/test/read.cgi/tech/1185986999/

過去ログ・リンク・書籍紹介は >>2 以降

2 ：858：2007/12/24(月) 03:42:34

【C++】STL（Standard Template Library）相談室 6
http://pc11.2ch.net/test/read.cgi/tech/1160821240/
【C++】STL（Standard Template Library）相談室 5
http://pc8.2ch.net/test/read.cgi/tech/1143608073/
【C++】STL（Standard Template Library）相談室 ;4
http://pc8.2ch.net/test/read.cgi/tech/1130680264/
【C++】STL（Standard Template Library）相談室 3
http://pc8.2ch.net/test/read.cgi/tech/1116559700/
【C++】STL（Standard Template Library）相談室 2
http://pc8.2ch.net/test/read.cgi/tech/1104898734/
【C++】STL（Standard Template Library）相談室
http://pc5.2ch.net/test/read.cgi/tech/1095583235/

3 ：858：2007/12/24(月) 03:43:17

リンク切れとか見てないぞ

入門ページなど

・入門
http://www.jah.ne.jp/~naoyuki/Writings/STL.html
・入門,一覧,使い方
http://www5c.biglobe.ne.jp/~ecb/cpp/07_01.html
・メソッド一覧
http://www.wakhok.ac.jp/~sumi/stl/
・サンプルプログラム集
http://www.s34.co.jp/cpptechdoc/reference/stl_samples/
・TIPS集
http://www.nantekotta.com/stl.html
・メルマガ
http://www.kab-studio.biz/Programing/STLiostream/
・解説
http://ja.wikipedia.org/wiki/Standard_Template_Library
http://www-ise2.ise.eng.osaka-u.ac.jp/~iwanaga/programming/stl/about_stl.html

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

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

4 ：858：2007/12/24(月) 03:43:53

書籍紹介

STL標準講座―標準テンプレートライブラリを利用したC++プログラミング
http://www.amazon.co.jp/gp/product/4881357786/

STL―標準テンプレートライブラリによるC++プログラミング第2版
http://www.amazon.co.jp/gp/product/4894714329/

標準C++:STLの基礎知識
http://www.amazon.co.jp/gp/product/4756138047/

標準講座C++―基礎からSTLを利用したプログラミングまで
http://www.amazon.co.jp/gp/product/4881357050/

STLによるコンポーネントデザイン
http://www.amazon.co.jp/gp/product/475613422X/

Effective STL―STLを効果的に使いこなす50の鉄則
http://www.amazon.co.jp/gp/product/4894714108/

5 ：858：2007/12/24(月) 03:44:36

関連スレ

C++相談室 part59
http://pc11.2ch.net/test/read.cgi/tech/1192866305/

Boostを語れゴラァ part5
http://pc11.2ch.net/test/read.cgi/tech/1192662575/

C++0x 2
http://pc11.2ch.net/test/read.cgi/tech/1191842951/

6 ：デフォルトの名無しさん：2007/12/24(月) 12:31:41

>>6
スレ立て乙

7 ：デフォルトの名無しさん：2007/12/24(月) 13:43:05

>>1
すれたて乙。　新しいすれでも>>858名乗るのか？

8 ：デフォルトの名無しさん：2007/12/24(月) 16:19:16

std::pair のインスタンスから first および second を
取り出すファンクタは std の下に用意されていますか？

boost::tuples::get<0> みたいなやつを探しています．
自分で定義してもいいんですが，標準的な方法が
用意されているのであればそちらに従いたいと思います．

9 ：デフォルトの名無しさん：2007/12/24(月) 16:32:24

>8
確か標準には無い。
g++だと、#include <ext/functional> して、
__gnu_cxx::select1stとかselect2ndが使える。

10 ：デフォルトの名無しさん：2007/12/24(月) 18:36:58

mem_funのメンバ変数版とかないの？

11 ：デフォルトの名無しさん：2007/12/24(月) 18:43:24

boost::mem_fn

12 ：デフォルトの名無しさん：2007/12/24(月) 19:15:22

ベクタコンテナを初期化子で初期化する場合
vector<int> vec;
Foo::Foo() : vec()
{}
こうしてるんだけど、間違ってない？

13 ：デフォルトの名無しさん：2007/12/24(月) 19:37:34

間違ってはいないけど、要素数0で初期化なら何もしなくてもいい。

14 ：デフォルトの名無しさん：2007/12/24(月) 19:55:05

>>13
サンクス
そこが聞きたかったんだけど、vectorは初期化しなくても使えるのは知ってたけど
どのタイミングで、初期化を行ってるの？
vector型のインスタンスが作成される、手前で初期化をにやってると想像するんだけど

15 ：デフォルトの名無しさん：2007/12/24(月) 19:56:07

コンストラクタが呼ばれるだけですが

16 ：デフォルトの名無しさん：2007/12/24(月) 20:08:36

>>15
なるほど、コンストラクタが呼ばれたら、そこで初期化が行われる仕組みになってるんだ
納得ｼﾏｽﾀ

17 ：デフォルトの名無しさん：2007/12/24(月) 20:12:08

どんだけ～

18 ：デフォルトの名無しさん：2007/12/24(月) 23:47:24

コンストラクタは何の為にあると思ってたんだろう

19 ：デフォルトの名無しさん：2007/12/25(火) 00:08:39

>>17
気持ち悪いです。自殺してください。

20 ：デフォルトの名無しさん：2007/12/25(火) 00:12:46

件のvectorのコンストラクタで質問なんですが、
vectorのオブジェクトを生成するとメモリ割当て子を一つ生成してさらに割当て子を2回コピーしてるようなんですが、
なんでvectorは合計で３つも割当て子のオブジェクトを用意してるんですか？

21 ：デフォルトの名無しさん：2007/12/25(火) 00:16:25

その挙動はコンパイラの実装次第だから何ともいえない。

22 ：デフォルトの名無しさん：2007/12/25(火) 00:16:54

先頭ポインタ、末尾ポインタ、メモリ確保領域の末尾ポインタの３つ。

23 ：デフォルトの名無しさん：2007/12/25(火) 00:19:35

割当て子ってアロケーターの事だと思った。

24 ：20：2007/12/25(火) 00:31:57

レスありがとうございます。
もう一度コードを読見直してみます。

25 ：デフォルトの名無しさん：2007/12/25(火) 00:59:29

見直すってvectorの実装をか？勉強のためなら止めはしないが・・・
その実装がどの環境でも同じかどうかなんて保障はないぞ。
別にお前さんは何も間違っているわけでもなく、そういうものだと理解するんだ。

26 ：デフォルトの名無しさん：2007/12/25(火) 07:45:18

20の場合では、コンストラクタの既定引数の実引数として1つ作られ、
そこから仮引数へのコピー、そこからvectorのメンバ変数へのコピーで2回だろうな。

27 ：デフォルトの名無しさん：2007/12/28(金) 03:26:47

vector<int> vec;
～
vecに対する処理(入れたり、出したり）
～
if( !vec.empty() )
　　erase( remove( vec.begin(), vec.end()) );
コンテナの要素が空でない場合、要素を全削除する関数ですが、これをtemplateに
してもらえませんか、宜しくオナガイシマス

28 ：デフォルトの名無しさん：2007/12/28(金) 03:39:03

>>27
erase() とか remove() とかの使い方がおかしくてよくわからんけど、
それは無条件で全削除する、つまり vec.clear() と何が違うの？

template にすると言われても何をテンプレート引数にするのか決めないと
どうにでもできてしまうよ。 template<int N> ... とか。

29 ：デフォルトの名無しさん：2007/12/28(金) 03:44:46

>>28
サンクスです
vecの型が
vector<double> vecであってもvector<string> vecでも
削除できるようにしたいのですが？

30 ：デフォルトの名無しさん：2007/12/28(金) 03:47:17

ごめんなさい
erase( remove( vec.begin(), vec.end()), 削除したい特定の要素 );
でした

31 ：デフォルトの名無しさん：2007/12/28(金) 03:58:36

>>29-30
情報小出しの兆候が見られて嫌な感じだな。
いくらかわかったけど、細かい仕様がわからないから何ともできない。
たとえば関数テンプレートにしたいんなら関数の戻り値や引数がわからない。

とりあえず自分で書いた奴みせて。

32 ：デフォルトの名無しさん：2007/12/28(金) 05:00:55

>>29-30
こうですかわかりません

template<typename T>
void erase_it(vector<T>& vec, const T& value)
{
　　vec.erase( remove(vec.begin(), vec.end(), value), vec.end() );
}

33 ：デフォルトの名無しさん：2007/12/28(金) 06:49:01

まだ続々と新情報が出てくるだろうから
しばらく適当にイジってたほうがいいと思うよ

34 ：デフォルトの名無しさん：2007/12/28(金) 18:45:34

>>27です
夕べは眠くて、質問を書き間違えました
>>コンテナの要素が空でない場合、要素を全削除する関数ですが、
これが間違いで
vector型のコンテナで、特定の要素を削除できる汎用的な（Template）の書き方が
教えて欲しかったのです
ですので、32さんありがとう

35 ：デフォルトの名無しさん：2007/12/28(金) 19:12:02

27です、32さんに教えてもらって、Templateの書き方が何となく分かってきた
気がします、連投で申し訳ないけど
コンテナの空チェックで
vector<int> vec;
if(!vec.empty())
　vec.clear();
～空で無い場合の処理

この様な書き方をすると思うのですが、Templateにした場合
この書き方は間違っていますか？
template<typename T>
void empty_it(vector<T>& vec)
{
　　if(!vec.empty())
　　　　vec.clear();
}

36 ：デフォルトの名無しさん：2007/12/28(金) 19:13:18

つーか、vec.clear()だけで充分ですが。

37 ：デフォルトの名無しさん：2007/12/28(金) 19:14:22

>>36
空のコンテナを
vec.clear()すると
アクセスバイオレーションになりませんか？

38 ：デフォルトの名無しさん：2007/12/28(金) 19:16:56

なんでそんなことになると思うの？

39 ：デフォルトの名無しさん：2007/12/28(金) 19:19:50

以前、空のコンテナをclear()したら、そうなった気がしたんですが
今手元に、コンパイラが無いんで確認できないんですが、
勘違いだったのかなぁ・・・

40 ：デフォルトの名無しさん：2007/12/28(金) 19:23:39

>>39
メモリ破壊でもしてたんだろ

41 ：デフォルトの名無しさん：2007/12/28(金) 19:27:46

>>40ってことは、空のコンテナをclear()しても、問題は無いってことですか？
やはり>>35の処理は不要ってこと？

42 ：デフォルトの名無しさん：2007/12/28(金) 19:30:51

>>41
問題ない。不要。

43 ：デフォルトの名無しさん：2007/12/28(金) 19:33:07

>>42了解したよ
ありがとう、幾ら簡単な例ができても、何の役にも立たなくては、意味無いからね

44 ：デフォルトの名無しさん：2007/12/28(金) 21:04:40

解決した途端、敬語が消えてどっかの審査員みたいな目線になるのは
GoFでいうとなにパターンですか？

45 ：デフォルトの名無しさん：2007/12/28(金) 21:08:14

pimpl

46 ：デフォルトの名無しさん：2007/12/29(土) 01:06:28

Observer

47 ：デフォルトの名無しさん：2007/12/29(土) 01:46:38

vector::insert()で、
insert(先頭位置, 挿入数, 挿入する物)
insert(先頭位置, 挿入する物.begin(), 挿入する物.end())
というバリエーションがあるみたいなのですが、どういうバリエーションがあるかは
どうやって知るのでしょうか？manページとかがあるのでしょうか？

48 ：デフォルトの名無しさん：2007/12/29(土) 01:56:47

>>47
こことかどう？
http://www.wakhok.ac.jp/~sumi/stl/

49 ：デフォルトの名無しさん：2007/12/29(土) 02:07:58

>>48
ありがとうございます！

50 ：デフォルトの名無しさん：2007/12/29(土) 02:18:00

俺が今仕事で使ってる環境にはstdc++のmanが入ってるな。
ただ所々間違ってるんだけどw
std::mapのerase(iterator position)がpositionの次のiteratorを返すって書いてあったりする。

51 ：デフォルトの名無しさん：2007/12/29(土) 11:30:15

そういや >>47 のようなことを思っていた時期もあったけど，
いまや IntelliSense に頼りっきりになってしまった．

そろそろ趣味グラマで Linux 上でのプログラミングも
しようかと思うんだけど，Emacs でそういう補完とか
やろうと思うとどんな *.el 入れれば便利なんだったっけ？

52 ：デフォルトの名無しさん：2007/12/29(土) 13:46:27

俺はここ使ってる
http://www.scl.kyoto-u.ac.jp/scl/appli/appli_manual/SUNWspro/WS6U2/ja/manuals/stdlib/stdref/classref.htm

53 ：デフォルトの名無しさん：2007/12/30(日) 16:28:45

Linuxとかならglobalかな
emacsには標準でついてる

54 ：デフォルトの名無しさん：2007/12/30(日) 22:31:50

typedef struct ST_TABLE {
int num;
int headdate;
int taildate;
ST_TABLE( ) : num(0), headdate(0), taildate(0){}
}ST_TABLE;

このような、構造体を持つvector型のコンテナから、for_eachを用いて
headdateの最大値を求める、Templateの作り方を教えてもらえませんか

vector<ST_TABLE> containerIndex

containerIndexには、要素が入っていることと仮定して

for_each( containerIndex.begin(), containerIndex.end(), &head );

template<class T>
int head(const vector<ST_TABLE>::iterator T& t) {

ここまでは分かるのですが（間違っているかもしれない。。。。多分間違ってるでしょうorz）

55 ：デフォルトの名無しさん：2007/12/30(日) 22:35:56

間違ってます。3引数のstd::max_elementを使いましょう。

56 ：デフォルトの名無しさん：2007/12/30(日) 22:41:54

これでは、エラーが沢山出てしまうのですが...
for_each( containerIndex.begin(), containerIndex.end(), head );
template<class T>
int head(const vector<ST_TABLE>::iterator T& t) {
　return max_element t->headdate;
　t++;
}

57 ：デフォルトの名無しさん：2007/12/30(日) 22:49:26

max_element(v.begin(), v.end());

58 ：デフォルトの名無しさん：2007/12/30(日) 22:50:08

>>57 ミスった。スルーしてくれ

59 ：デフォルトの名無しさん：2007/12/30(日) 22:59:05

>>56だけど
できちゃったけど、オーバーロード使って、でできちゃったww
templateでは、できないものかなorz

60 ：デフォルトの名無しさん：2007/12/31(月) 00:54:29

templateで、の意味がいまいち不明だけど、max_element(begin, end, comp)使えって。

61 ：デフォルトの名無しさん：2007/12/31(月) 10:52:36

vector<int> v, w;
があったときにvからwへcopy_ifするとき、wの要素の方が少ないとクラッシュするのですが、
そういうときにもwを拡張しながらcopyするにはどうすればいいですか
たとえば

copy (v.begin(), v.end(), w. begin(), even());

解決方法としてはv.size()であらかじめw.reserveしておくといいのですが、
vは巨大な配列でwは小さいので余計な領域を予約しまくるのが気持ち悪いです

62 ：デフォルトの名無しさん：2007/12/31(月) 11:10:29

自己解決しました。

copy (v.begin(), v.end(), back_inserter(w), even());

ありがとうございませんでした。

63 ：デフォルトの名無しさん：2007/12/31(月) 11:40:20

それだと不必要に非効率になるかも。
w.reserve(w.size() + v.size()) で必要な分のサイズを確保してから、
w.insert(w.begin() + w.size(), v.begin(), v.end()) とやったほうが、
多分（←重要。真相は調べるべき）効率が良い。

64 ：デフォルトの名無しさん：2007/12/31(月) 12:12:24

reserveするだけじゃ実行時エラーになるかも

65 ：デフォルトの名無しさん：2007/12/31(月) 12:36:44

vector<int> vec1
vector<int> vec2
vector<int> vec3に

vec1の要素1,2,3,4,5,6,7,8,9,10
vec2の要素4,5,6
とします、vec1とvec2をマージして、重複値を持たないように
vec3の要素1,2,3,4,5,6,7,8,9,10
としたいのですが、↓これだと
merge( vec1.begin(), vec1.end(), vec2.begin(), vec2.end(), back_inserter ( vec3 );
unique( vec3.begin(), vec3.end() );
vec3の要素1,2,3,4,5,6,7,8,9,10,4,5,6
となってしまいます
どうしたらいいですか？

66 ：デフォルトの名無しさん：2007/12/31(月) 12:47:23

uniqueって、remove_ifなんかと同等のインターフェースで、
vec.erase( remove_if( vec.begin(), vec.end(), cond), vec.end() );
みたいな構成にしないとだめ、じゃなかったっけ。

67 ：デフォルトの名無しさん：2007/12/31(月) 15:49:19

STLじゃないけど

#include <cassert>
#include <pstade/oven/equals.hpp>
#include <pstade/oven/uniqued.hpp>
#include <pstade/oven/merged.hpp>
#include <pstade/oven/initial_values.hpp>
#include <vector>

int main() {
  using namespace::pstade::oven;
  using namespace std;
  vector<int> A = initial_values(1,2,3,4,5,6,7,8,9,10);
  vector<int> B = initial_values(4,5,6);
  assert( equals(A,A|merged(B)|uniqued) );
}

こんな感じでいちいちeraseだの使わずに書きたい気分

68 ：デフォルトの名無しさん：2007/12/31(月) 16:45:30

>>65だけど
あのぉーすみませんが、pstadeってなんっすか？
boostライブラリィの一種？

69 ：デフォルトの名無しさん：2007/12/31(月) 17:19:44

p_stadeさんの作ったC++ライブラリ

70 ：デフォルトの名無しさん：2007/12/31(月) 17:37:06

かなりマニアティックなものなんですか？
解答が無かったんで、今自力でtemplate作ったけど、速度がでねぇ～
参ってるんだよね、コンテナ二つがそれぞれ500件と5000件で先の要件を満たす
ようにすると、PCが1,2秒固まるんだよね
p_stadeさんの作ったC++ライブラリって速度速いの？

template < typename ForwardIterator >
ForwardIterator to_unique( ForwardIterator lhs, ForwardIterator rhs )
{
　　ForwardIterator result = lhs;
　　for( ForwardIterator it = lhs; it != rhs; ++it ){
　　　　if( std::find( lhs, result, *it ) == result ){
　　　　　　*result++ = *it;
　　　　}
　　}
　　resulturn result;
}

71 ：デフォルトの名無しさん：2007/12/31(月) 18:38:00

sort→unique→eraseじゃないの。これが遅いからどうにかしたいって話か？

72 ：デフォルトの名無しさん：2007/12/31(月) 18:54:26

>>70は
>>65の件

73 ：デフォルトの名無しさん：2007/12/31(月) 20:01:07

俺の環境(athlon64 3000+,gcc4.1.2,linux2.6 x86)ではstlのを1とするとovenは10、>>70のは40ぐらいの時間だった
libstdc++でのuniqueの実装はadjacent_findで先頭部分で既にuniqueになってるものを飛ばし
あとはuniqueになっている部分の末尾と比較しながら
uniqueであるなら末尾の次にコピー、そうでないなら無視といった具合に
イテレータが進んでいくだけってシンプルなものだったから、それと比較したらまぁそんなもんかとはおもうけど
2.3秒かかるってのはstd::vectorのreserve()をせずにどんどん突っ込んだとかそういう要因の方がでかそう

74 ：デフォルトの名無しさん：2008/01/01(火) 18:56:28

p_stade（笑）

75 ：デフォルトの名無しさん：2008/01/02(水) 03:41:11

>>70
>解答が無かったんで、今自力でtemplate作ったけど、速度がでねぇ～
for文の中でfindしてりゃそりゃ遅いだろうよw
ハッシュつかえば一発じゃん。

76 ：デフォルトの名無しさん：2008/01/02(水) 10:38:22

「ハッシュ」て、ハッシュドビーフのハッシュですか？

77 ：デフォルトの名無しさん：2008/01/02(水) 10:46:25

はい

78 ：デフォルトの名無しさん：2008/01/02(水) 12:04:26

ハッシュド、即ちハッシュキーに変換されたビーフ。

79 ：デフォルトの名無しさん：2008/01/02(水) 12:53:45

お前の話はつまらん

80 ：デフォルトの名無しさん：2008/01/02(水) 14:21:50

>>76
つまらん話のおかげでシチューを
火にかけっぱだったのを思い出した。
マジ感謝。

# 正月2日からレトルトってのもアレだが。

81 ：デフォルトの名無しさん：2008/01/02(水) 21:35:31

>>80
レトルトかよ！
時間とれる時くらいまともな料理しろって。(実は喰い物作るのって上手なスレッド処理みたいで面白いのだ)

82 ：デフォルトの名無しさん：2008/01/02(水) 23:21:32

>>81
分かるw
コンロが複数あると加熱で複数スレッドとか、火入れてる間に別の一品の下ごしらえとか。
慣れてくると俺OSがマルチスレッドに最適化されてくるのが分かる。

83 ：デフォルトの名無しさん：2008/01/02(水) 23:53:15

生活板か料理板か喪男板かダム河川板でやれ

84 ：デフォルトの名無しさん：2008/01/03(木) 03:33:58

ダム河川板とのつながりを理解できない俺は負け組み。

85 ：デフォルトの名無しさん：2008/01/03(木) 05:22:00

>>84がデッドロックしてるお…

86 ：デフォルトの名無しさん：2008/01/03(木) 08:54:14

定数を返すファンクタってありませんか？
って自分で書くのは簡単ですが，
標準があればそれを使おうと思います．

87 ：デフォルトの名無しさん：2008/01/03(木) 09:50:18

>>86
質問の意味がわかりません。

88 ：デフォルトの名無しさん：2008/01/03(木) 11:07:20

http://www.zvon.org/other/haskell/Outputprelude/const_f.html
的なやつのことだったら、自作しないと標準の範囲では存在しないはず。
それ以前にid関数もなかったはずだ。

boostは知らんので当該スレで聞いてくれ。

89 ：デフォルトの名無しさん：2008/01/03(木) 20:01:01

メイヤーズ先生の本を読んで、STLとマルチスレッドって相性悪いと言うか、
結局、期待通りの動作は、実装依存で全てのSTLの振舞いが保障されてないみたいなことが書いてあったな
STLを駆使した、マルチスレッドプログラミングって、かなり精通しないと難しそうな印象を持った

90 ：デフォルトの名無しさん：2008/01/03(木) 21:33:28

C++0x でスレッド関係のライブラリが標準で入るようになれば
改善されると期待してるんだけど，無理かなぁ．

91 ：デフォルトの名無しさん：2008/01/03(木) 22:09:54

>>89
その本ではどう動く事を期待してたの？

92 ：デフォルトの名無しさん：2008/01/03(木) 22:36:22

>>その本ではどう動く事を期待してたの？
Effective STL本に書いてあるのは
STLのコンテナでマルチスレッドをサポートする基準、ようするに、実装から
最大限望めることは
★複数の読み取りが安全である
★異なるコンテナへの複数の書き込みは安全である
以上で全てと書いてあるよ、ただし。「望むこと」はできるが、常に実現できるとは
限らないことに注意しなければなっらない。こうした内容を保障する実装もあり、保障しない実装もある。
とのことです、漏れ自身、STLを使ってない、マルチスレッドの実装をリファクタリング∩改造したことはあるけど、
STL∩マルチスレッドの経験ないからあんまり良く分かんないけど、なんか考えても難しそうな希ガスる。

93 ：デフォルトの名無しさん：2008/01/03(木) 22:40:27

>STLとマルチスレッドって相性悪いと言うか
うわさではよく聞くんだけどさ・・。具体的にこの場合に絶対におかしくなる
ってコードとどのSTL実装かを知ってる人っているのかな？
いまどきのLinuxとかWinでは問題ないとか勝手に思ってるんだけどさ。。

94 ：デフォルトの名無しさん：2008/01/03(木) 22:43:54

続き。以前にSolarisのSTLでクラス変数をがんばってpthread_lockで
囲ってる実装を見て、なんかあぶなそうだなあと思った記憶はある。

95 ：デフォルトの名無しさん：2008/01/03(木) 22:44:08

libstdc++については、"XXX MT"でgrep してみるといくつか既知のバグがあることがわかるよ。
文字列の参照カウントまわりとか。詳しくはbugzillaをどうぞ。

96 ：デフォルトの名無しさん：2008/01/03(木) 22:55:23

>>93
>>いまどきのLinuxとかWinでは問題ないとか勝手に思ってるんだけどさ。。
その本にも、同じようなことが書いてある
マルチスレッドプログラムの作成は難しく、STLの実装が最初から完全な
スレッドセーフであればと願うプログラマーは多いと
また、後先逆になったけど
>>具体的にこの場合に絶対におかしくなる
>>ってコードとどのSTL実装かを知ってる人っているのかな？
具体的なミューテックスを、行う際の完璧な（著者いわく）Lock方法が載ってるよ

97 ：デフォルトの名無しさん：2008/01/03(木) 22:59:59

後、STL以外のマルチスレッドの実装方法は難しいので、それに関しては
ビョーン本と、自分の書いた（メイヤーズ先生）MoreEffective C++を
読めとも書いてある

98 ：デフォルトの名無しさん：2008/01/04(金) 00:14:41

std::stringとかがCOWな実装ならロックしててもまずいよね場合があるよね。

99 ：デフォルトの名無しさん：2008/01/04(金) 00:16:52

そうだね。詳しくはMore Exceptional C++嫁という感じかな。
翻訳されてないけど。

100 ：デフォルトの名無しさん：2008/01/06(日) 20:55:32

>>86はどうなった？

101 ：デフォルトの名無しさん：2008/01/06(日) 21:10:40

日本語でおｋとなった

102 ：デフォルトの名無しさん：2008/01/06(日) 22:58:34

これだから関数型言語のひとつも使えない連中は以下略

103 ：デフォルトの名無しさん：2008/01/07(月) 02:04:14

>>86 >>100
Boost.Lambdaのconstantは望むものと違う？

104 ：デフォルトの名無しさん：2008/01/10(木) 23:19:46

105 ：デフォルトの名無しさん：2008/01/11(金) 13:33:47

106 ：デフォルトの名無しさん：2008/01/11(金) 14:01:47

初歩的な質問で申し訳ないのですが
class sample{
public:
vector<int> vector_int;
list<double> list_double;
～省略～
}
というようなクラスをnew演算子で動的に生成した場合、delete演算子で解放
する際にはメンバのvectorやlistのメモリも解放されるのでしょうか。

ご教授お願いします

107 ：デフォルトの名無しさん：2008/01/11(金) 14:11:45

>>106
される．
安心して使いたまえ．

108 ：デフォルトの名無しさん：2008/01/11(金) 14:18:33

>>107
ご教授ありがとうございます。

また質問で恐縮なのですが関連して、メンバを
vector<int> *p_vector_int
とし、コンストラクタ内で動的にメモリ確保したとすると、この場合はデストラクタ内
で解放するように定義しとかなければいけないのでしょうか？

109 ：別人：2008/01/11(金) 14:42:35

>>108
そのとおり、でも
sample a;
sample b = a;//もしくはsample b(a);
これでデストラクタが呼ばれると同じポインタを複数回deleteしたりする未定義動作になるから注意してね。

110 ：デフォルトの名無しさん：2008/01/11(金) 14:49:55

>>108
コンテナをnewするなんて糞みたいなことはやめたまえ。

111 ：デフォルトの名無しさん：2008/01/11(金) 15:00:28

>>109
>>110
ありがとうございます。

確かにコンテナをnewで確保するっていうのも変な話かも知れないです。　
動的なメモリ確保・解放っていうのがintやdoubleといったような基本的な
型でしか情報が見つからなかったので、クラスや可変長配列の場合どうなるのか、
モヤモヤしていたんですが、すっきりしました。ありがどうございました。

112 ：デフォルトの名無しさん：2008/01/11(金) 15:05:27

>>108
解放忘れが気になるなら，
std::auto_ptr を使うといいよ．

113 ：デフォルトの名無しさん：2008/01/11(金) 15:06:50

>>112
調べてみます。ありがとうございます

114 ：デフォルトの名無しさん：2008/01/11(金) 15:08:25

auto_ptrなんて落とし穴満載の使いづらいのを進めるなよ。

115 ：デフォルトの名無しさん：2008/01/11(金) 15:10:54

>>114
そこらへんは、自分で判断しますので大丈夫ですよ・・・きっとｗ

116 ：デフォルトの名無しさん：2008/01/11(金) 15:19:07

>>108
boost::shared_ptr (or boost::scoped_ptr)

boost::shared_ptr<std::vector<int> > sp_vector_int;

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

>>111
動的確保する為のコンテナを、動的確保なんて「例」だとしても阿呆過ぎる。

118 ：デフォルトの名無しさん：2008/01/11(金) 15:30:23

大量に複数のコンテナを用意する場合、コンテナのメンバ変数に
メモリが圧迫されることがあるので、newするケースもあると思うがなぁ。

119 ：デフォルトの名無しさん：2008/01/11(金) 15:34:45

Container<Container<Type> >

120 ：デフォルトの名無しさん：2008/01/11(金) 15:49:21

>>114
だって，boost のビルドからしろって勧めるのも気が引けるじゃないか．

121 ：デフォルトの名無しさん：2008/01/11(金) 16:03:12

>>120
いや、なるべくbestの回答をするのが親切だと思う。

122 ：デフォルトの名無しさん：2008/01/11(金) 16:07:43

boost::shared_ptrはboostの他のライブラリに依存しない設計方針らしい

123 ：デフォルトの名無しさん：2008/01/11(金) 16:13:54

ビルドが必要なのは実装依存のコンポーネントだな。
thread関連とかasio（まだ無いが）とか。
shared_ptrなんぞバイナリー落としてインストールするだけだ。

124 ：デフォルトの名無しさん：2008/01/11(金) 17:24:46

>>123
それを言うならヘッダファイルジャマイカ？

125 ：デフォルトの名無しさん：2008/01/11(金) 18:09:22

C++相談室どこいった？

126 ：デフォルトの名無しさん：2008/01/11(金) 18:15:35

落ちた

127 ：デフォルトの名無しさん：2008/01/11(金) 18:23:18

996レスくらいだっけ? ぎりぎりで落ちたよね。

128 ：デフォルトの名無しさん：2008/01/11(金) 18:31:41

イテレータって何ですか？

129 ：デフォルトの名無しさん：2008/01/11(金) 19:03:45

>>124
ヘッダもだけどライブラリじゃなくてか？

130 ：デフォルトの名無しさん：2008/01/11(金) 19:06:44

shared_ptrはもう導入しないでどうするという感じだな
天才が作ってるうえアフォな質問にも丁寧に答えてくれるしな
boostの問題はライブラリによってサポートに差があることかな

131 ：デフォルトの名無しさん：2008/01/11(金) 19:18:34

>>130
次期 C++ で導入されるよ

132 ：デフォルトの名無しさん：2008/01/11(金) 20:05:28

TR1に入ってるものは全部C++0xで標準に入るんだよな。
shared_ptr weak_ptr bind function mem_fn type_traits...

133 ：デフォルトの名無しさん：2008/01/11(金) 20:09:01

regex とか random とか tuple とかも入るよ。
んで、auto_ptr は deprecated になる。

134 ：デフォルトの名無しさん：2008/01/11(金) 21:01:32

>>117
まぁ　そうですね。clear()呼べば済む話ですもんね
お騒がせしました。

135 ：デフォルトの名無しさん：2008/01/11(金) 21:06:37

auto_ptr、deprecatedになるのかｗ
ｶﾜｲｿｽ
strstreamみたいな感じか

136 ：デフォルトの名無しさん：2008/01/11(金) 21:16:13

破壊的だと使い勝手悪いしなあ。

137 ：デフォルトの名無しさん：2008/01/11(金) 21:30:29

コンテナに入れられないのがよほど致命的なんだろ。

138 ：デフォルトの名無しさん：2008/01/11(金) 21:32:59

致命的過ぎるよなー、それ。

139 ：デフォルトの名無しさん：2008/01/11(金) 22:07:12

>>129
いやぁ，shared_ptr だけならヘッダファイルだけ
もってくればつかえるとオモタ．

140 ：デフォルトの名無しさん：2008/01/11(金) 22:08:03

で auto_ptr の直接の代わりは scoped_ptr ？

141 ：デフォルトの名無しさん：2008/01/11(金) 22:28:42

そんなもん使わずに shared_ptr 使えって事だ。

142 ：デフォルトの名無しさん：2008/01/11(金) 23:06:56

auto_ptrはreleaseできるのが地味に便利

143 ：デフォルトの名無しさん：2008/01/11(金) 23:09:13

参照カウンタのオーバーヘッドを気にしてしまう人もいるんじゃないか　たぶん

144 ：デフォルトの名無しさん：2008/01/11(金) 23:16:19

boost::ptr_vectorは地味に便利だ

145 ：デフォルトの名無しさん：2008/01/11(金) 23:16:32

unique_ptrが楽しみ

146 ：デフォルトの名無しさん：2008/01/11(金) 23:24:31

参照カウンタ込みで new できるとオーバーヘッドも小さいんだが。
汎用的に作れないもんかね。

147 ：デフォルトの名無しさん：2008/01/12(土) 00:04:47

>>146
intrusive_ptrではだめなの？

148 ：デフォルトの名無しさん：2008/01/12(土) 00:13:08

>>147
使うために色々と必要な事があるからなあ。

149 ：デフォルトの名無しさん：2008/01/13(日) 20:04:36

multimapのいくつかの要素を述語を使って消去したいのですが
何か良い方法はありますか？

bool pred(pair<int, int> v)
{
return v.first == 3 && v.second == 'c';
}

int main(int argc, char* argv[])
{
multimap<int, char> m;
m.insert(make_pair(1,'a'));
m.insert(make_pair(2,'b'));
m.insert(make_pair(3,'c')); // 消去したい
m.insert(make_pair(3,'c')); // 消去したい
m.insert(make_pair(3,'d'));
m.insert(make_pair(4,'d'));

m.erase(???);

return 0;
}

環境はVC8です。

150 ：デフォルトの名無しさん：2008/01/13(日) 20:05:36

149です。
bool pred(pair<int, int> v)
のところは
bool pred(pair<int, char> v)
の間違いでした。
お願いします。

151 ：デフォルトの名無しさん：2008/01/13(日) 20:14:10

イテレータとfor_eachじゃね？

152 ：デフォルトの名無しさん：2008/01/13(日) 20:38:42

>>151

Effective STL Item9 や JosuttisのSTL本にも載ってるけど
こんな感じだろうか。

bool pred(const pair<int, char>& v)
{
　return v.first == 3 && v.second == 'c';
}

for(multimap<int, char>::iterator it = m.begin(); it != m.end(); )
{
　if( pred(*it) ) {
　　m.erase(it++);
　}
　else {
　　++it;
　}
}

試してはいない。

153 ：デフォルトの名無しさん：2008/01/13(日) 20:52:44

>>152
begin()とend()じゃなくて、lower_bound()とupper_bound()の方がいいと思う。

154 ：149：2008/01/13(日) 20:56:22

>>152
お示しの方法でうまくいきました。

>151,152
ありがとうございました。

155 ：デフォルトの名無しさん：2008/01/13(日) 21:39:07

>>152
折角mapなのに全検索は勿体無くねぇ？

156 ：149：2008/01/13(日) 21:47:11

>>153
lower_bound()とupper_bound()
にするのは速度的な問題でしょうか？

しかし、キーを二回余分に渡すのもちょっと面倒ですね。

>>152
一旦キーでマッチしたものを、すべてシーケンスコンテナに入れて
そこからさらに絞り込むっていう方法も考えていたんですが
今、私が書いているコードで使う要素数が多くても3個ほどなので
あまり変わらないような気がしました。
要素が多いとまた変わってくるかもしれません。

157 ：デフォルトの名無しさん：2008/01/13(日) 22:04:28

>>153　>>155
確かに。multimapだった。
equal_range()でイテレータの組を取ってもいいか。

>>156
全部の要素をlinerで舐めるのは非効率だわ。
上の人たちが言ってるやり方が効率が良い。

158 ：デフォルトの名無しさん：2008/01/13(日) 22:06:48

upper_boundとlower_boundは大小の順にソートシーケンスに
適用するアルゴリズムだ。

std::mapはデフォルトでキー順に既に要素を挿入した時点で
ソートされているのでまさに効率の良い方法。

Cで言うとbinary_search()な。

159 ：デフォルトの名無しさん：2008/01/13(日) 22:13:59

>>156
KeyとValueの両方の条件で削除要素を決定するなら
汎用性を考えた場合、Linerになるけど全部舐める
しかないかもな。まあ、今の場合は削除対象を絞る
条件がKeyが3に固定されてるからいいけど。

160 ：デフォルトの名無しさん：2008/01/13(日) 23:31:50

>>156
149の通りの条件なら、Key == 3 の範囲をequal_rangeで得て、
その範囲に対して Value == 'c' を消してまわるのが速そう。平均的には、ね。
総要素数に対してequal_rangeの範囲が無視できるだけ小さいならおk。

実際に行いたい条件が149と違う場合は話が違ってくる。
Keyが単一とは限らないとか。...って、>>159に書いてあるか。

161 ：デフォルトの名無しさん：2008/01/14(月) 10:47:18

そういえばmultimapってどういう用途に使ってますか？
mapは連想配列の様に便利に使ってますが
multimapという道具の使い方がいまいち思い浮かばない…。

162 ：デフォルトの名無しさん：2008/01/14(月) 11:02:35

得点が0～100点で、名前を要素とする
同一得点は存在するからマルチ

163 ：161：2008/01/14(月) 11:07:45

>>162
なる。　７０点取った人を羅列その他できますね。　サンクスです

164 ：デフォルトの名無しさん：2008/01/14(月) 11:23:23

>>161
辞書

165 ：デフォルトの名無しさん：2008/01/14(月) 11:25:39

STL限定なら別だけど辞書ならbimapの方がよくね？

166 ：デフォルトの名無しさん：2008/01/14(月) 11:48:17

用途の話しだ

167 ：デフォルトの名無しさん：2008/01/14(月) 13:18:36

「ようとのはなししだ」ですか?

168 ：デフォルトの名無しさん：2008/01/14(月) 13:19:33

>>167
辞書引け

169 ：デフォルトの名無しさん：2008/01/14(月) 13:19:40

とりあえず度数分布表以外にも例挙げてよよよ

170 ：デフォルトの名無しさん：2008/01/14(月) 13:21:26

>>168
辞書ならbimapの方がよくね？

171 ：デフォルトの名無しさん：2008/01/14(月) 13:22:53

用途の話だ。

172 ：デフォルトの名無しさん：2008/01/14(月) 16:46:33

>>162
この例で、0点のダメ男君が何人いるかと、
その名前の列記とかってどうやって出力するの？
mismatch()とか使うのかな。
foreachループでフラグ立てながらは勘弁

173 ：デフォルトの名無しさん：2008/01/14(月) 16:59:41

俺ならequal_range

174 ：デフォルトの名無しさん：2008/01/15(火) 02:04:41

割と典型的なequal_rangeの出番だと思う。
人数だけが知りたい場合は、countがいいかな。もちろんメンバ関数のほうね。

175 ：172：2008/01/15(火) 11:07:03

>>173-174
ありがとうございます。　equal_range、及びcount便利ですね。

説明読んでて、「該当者のいる得点一覧」（無重複の使用キー一覧）の方法に
ぶちあたった。　もうちょい調べてみます。

176 ：デフォルトの名無しさん：2008/01/17(木) 18:02:56

配列の先頭を指すポインタと末尾を指すポインタのペアを返す
テンプレート関数を作成したいのですが、うまくいきません。
以下のコードはVC++6.0でもBCC5.5でもコンパイルエラーです。
正しい方法を教えてください。

#include <utility>
#include <algorithm>

template <class T, int n>
std::pair<T*, T*> iseq(T a[n])
{
return std::pair<T*, T*>(a, a + n);
}

int main()
{
int x[] = {6, 1, 3, 4, 2};
std::sort(iseq(x).first, iseq(x).second);
return 0;
}

177 ：デフォルトの名無しさん：2008/01/17(木) 18:07:47

VC6やBCC5といった糞コンパイラを捨てる

178 ：デフォルトの名無しさん：2008/01/17(木) 18:09:45

>>176

#include <utility>
#include <algorithm>
#include <iostream>
#include <iterator>

template <class T, int n>
std::pair<T*, T*> iseq(T (&a)[n])
{
　return std::pair<T*, T*>(a, a + n);
}

int main()
{
　int x[] = {6, 1, 3, 4, 2};
　std::sort(iseq(x).first, iseq(x).second);
　std::copy(x, x + sizeof(x) / sizeof(x[0]), std::ostream_iterator<int>(std::cout, " "));
}

179 ：デフォルトの名無しさん：2008/01/17(木) 18:13:54

ああそうだわ、>>178はBCCじゃコンパイルできないよ。
VC6はどうか知らんが、VC7.1やVC8、VC9なら行けると思う。
gcc3.4.5でもOKだった。

180 ：デフォルトの名無しさん：2008/01/17(木) 18:16:29

>>179
bcc5.5.1と5.8.2でコンパイルできたよ

181 ：デフォルトの名無しさん：2008/01/17(木) 18:17:41

BCC5.9.2でも行けるね。

182 ：176：2008/01/17(木) 18:25:31

>>178
ありがとうございます。>>180さんがおっしゃるとおり
bcc5.5.1ではOKでしたが、VC++6.0ではダメでした。

183 ：デフォルトの名無しさん：2008/01/17(木) 18:52:19

boost::begin()やboost::end()の実装を参考にしてみれば?

184 ：デフォルトの名無しさん：2008/01/17(木) 22:40:09

>>178がコンパイルできないのは、どこが原因？

185 ：デフォルトの名無しさん：2008/01/17(木) 22:44:49

>>184
iseq(T (&a)[n])

この部分が解析できないフロントエンドを持つコンパイラ。

186 ：デフォルトの名無しさん：2008/01/17(木) 23:06:23

VC6 とか無理だった記憶がある。

187 ：デフォルトの名無しさん：2008/01/17(木) 23:47:01

>>185
T (&a)[n] の仮引数aの型が解らんてこと？
aが配列参照と理解できないってことかな

188 ：デフォルトの名無しさん：2008/01/17(木) 23:59:29

配列参照に対応していないだけ。

189 ：デフォルトの名無しさん：2008/01/18(金) 00:54:28

BCCは template で T (&a)[n]とやってあると大丈夫みたいだが
int (&a)[n] のように型を決め打ちされてしまうとコンパイルが
通らなかったような。

templateの特殊化には対応してんのかな。どっかいろんな細かい
部分が標準と挙動が異なるのでSTLportから見捨てられかけたり
boostへの対応度が低かったりする。

190 ：デフォルトの名無しさん：2008/01/18(金) 08:37:20

コンパイラ実装者にとってパターンマッチほど面倒くさいものはない。

191 ：デフォルトの名無しさん：2008/01/18(金) 09:13:16

VC6 はもうそろそろ寝かせてやって，
VC9 使おうよ… Express Edition もあるんだから．

192 ：デフォルトの名無しさん：2008/01/18(金) 09:14:58

VC9も色々バグがあってヤヴァイみたいだけどな
STLをやboostを使うならVC8がgccとかも含めて一番安定して使えるかも

193 ：デフォルトの名無しさん：2008/01/18(金) 09:35:46

質問です。
equal_range()でvectorの特定の値を検索したいのですが
vectorの要素はマルチキーなのです。
typedef struct{
int x;
int y;
}DATA;
このような感じの場合。
どのようにすればいいのでしょうか？
やはり自分で作らないと出来ないのでしょうか？
宜しくお願いします。

194 ：193：2008/01/18(金) 10:30:48

事故解決しました。
第４引数があるんですね・・・。
でもこの引数、ググっても、日本語のページは、４件しかヒットしないや・・・orz

195 ：デフォルトの名無しさん：2008/01/18(金) 10:31:00

boost使うなら現状VC8の方がいいだろうが
それ以外バグが問題でVC8使った方がいい
ってあり得るの？

196 ：デフォルトの名無しさん：2008/01/18(金) 13:53:30

>>194
STLはそういう使い方しないもん。
structじゃなくて、classにしとけよ。
operator定義できないから、多分比較関数定義出来ないぞ。

検索する値はint型、比較する対象はvector<DATA>のDATAっしょ？
比較関数は定義できても、呼び出し側の引数は等価な型を与えるから無理。
先に比較用のoperator書かないと。

197 ：デフォルトの名無しさん：2008/01/18(金) 14:07:07

structかclassかの問題だったのか

198 ：デフォルトの名無しさん：2008/01/18(金) 14:21:50

>>196
別にstructでもoperator()は定義できるでしょ。
今はそれはどうでもよくて、strict weak odering条件を満たす
bool operator(const Data&, const Data&);
を定義して、operator(const Data&, const Data&)で
vector<Data>をソートしておいて、eqaul_rangeに同じ
Comparisonであるoperator(const Data&, const Data&)を
渡せばいいんでないのか？

ということを>>193は言ってると思ったんだが。

199 ：デフォルトの名無しさん：2008/01/18(金) 14:30:05

×　bool operator(const Data&, const Data&);
○　bool operator<(const Data&, const Data&);

200 ：デフォルトの名無しさん：2008/01/18(金) 14:46:28

>>198
operator<を定義してたらComparison(>>194の言う第4引数)渡さなくていいんじゃ？

201 ：デフォルトの名無しさん：2008/01/18(金) 15:12:36

あれ？structでoperator定義出来たんだ。

202 ：デフォルトの名無しさん：2008/01/18(金) 15:18:21

>>200
クラスのメンバーとして定義するなら、そうだね

>>201
structとclassの違いはデフォルトのアクセスレベルだけでしょ。

203 ：200：2008/01/18(金) 16:00:31

>>202
なるほど、>>198の言ってることがようやく解った

204 ：デフォルトの名無しさん：2008/01/19(土) 14:15:43

↓って同一？マングル名とかも含めて。

struct xxx {
xxx();
private:
int n;
};

class xxx {
int n;
public:
xxx();
}

205 ：デフォルトの名無しさん：2008/01/19(土) 14:40:30

class はテンプレート仮引数の型として使えるが、struct は使えない、という違いもなくはない。

206 ：デフォルトの名無しさん：2008/01/19(土) 14:44:14

>>205
お、ほんとだ。知らなかった。何か理由あるのかね。

207 ：デフォルトの名無しさん：2008/01/19(土) 14:48:53

typenameでいいじゃない

208 ：デフォルトの名無しさん：2008/01/19(土) 14:49:26

テンプレート仮引数のclassとクラス宣言のclassって意味が違うんじゃないの。
仮引数のclassは型名を表すだけで、そこにclass入れようがstruct入れようが組み込み型入れようが構わないんだから。

209 ：デフォルトの名無しさん：2008/01/19(土) 14:51:53

クラステンプレートを引数にとるときは class しか使えないね。

210 ：デフォルトの名無しさん：2008/01/19(土) 14:57:54

classを使わずにstructを使うメリットって何？
コンストラクタ定義しなくても、メモリサイズ的に変わったりするの？

211 ：デフォルトの名無しさん：2008/01/19(土) 14:59:21

簡単なデータの塊を表現する時に struct を使ってる。
struct Point3d { double x, y, z; }; とか。

212 ：デフォルトの名無しさん：2008/01/19(土) 15:01:34

構造を保ったままCとインタフェースできる。

213 ：デフォルトの名無しさん：2008/01/19(土) 15:11:54

template <template<typename T> class C> //OK
template <template<typename T> struct C> //NG

214 ：デフォルトの名無しさん：2008/01/19(土) 15:19:24

template <template<typename T> typename C> //NG

これも書いておかないと片手落ちだ

215 ：デフォルトの名無しさん：2008/01/19(土) 16:16:28

>>214
それは常識すぎる。

216 ：デフォルトの名無しさん：2008/01/20(日) 23:29:14

fwrite()でvector<int> vの中身を一気に書き出したいのですが
効率の良い方法はないのでしょうか？

vector<int> v;
fwrite(v, sizeof(int), v.size(), fp);
のような感じで一気に書き出せれば凄くうれしいのですが
これではエラーになります。定義されているoperatorがうまくintのポインタの代わりをしてくれるかと思ったのですが
どうやら無理のようです。

これは、一度個数分ループまわしてintに書き出さないとダメなのでしょうか？

217 ：デフォルトの名無しさん：2008/01/20(日) 23:33:38

&v[0]

218 ：デフォルトの名無しさん：2008/01/20(日) 23:39:03

あるいは &v.front()

好きな方を使え。

次期 C++ だと v.data() で良くなるみたいだが・・・
まだないものは仕方が無い

219 ：デフォルトの名無しさん：2008/01/21(月) 00:14:53

>>216
ofstream ofs;
と
copy(v.begin(), v.end(), ostream_iterator<int>(ofs, " "));
とかではダメなんか？

220 ：デフォルトの名無しさん：2008/01/21(月) 00:43:42

fwriteだからバイナリで書きたいんだろ

221 ：デフォルトの名無しさん：2008/01/21(月) 01:07:58

>>220
じゃあostreambuf_iterator使えば？

222 ：デフォルトの名無しさん：2008/01/21(月) 06:41:18

コンテナの中が連続して配置されていることが
保障されているのはvector だけ？
って，list とかでそんなことできるわけないよな．

223 ：デフォルトの名無しさん：2008/01/21(月) 06:55:51

vectorはC配列との互換性のためにわざわざそんな保証をしてるわけですから

224 ：デフォルトの名無しさん：2008/01/21(月) 08:23:25

そのために無駄なコピーが発生しまくり

225 ：デフォルトの名無しさん：2008/01/21(月) 10:31:26

std::ifstream fin( "in.bat", ios::binary );
std::ofstream fout( "out.bat", ios::binary );

std::copy(
std::istreambuf_iterator<char>( fin ),
std::istreambuf_iterator<char>(),
std::ostreambuf_iterator<char>( fout ) );

このコードって超おせーんだけど、なんで？？

226 ：デフォルトの名無しさん：2008/01/21(月) 12:18:26

>>225
それだとディスク内のin.datにアクセス→ディスク内のout.datにアクセスを何度も繰り返すから、
in.datのデータを一度数キロバイトのバッファに入れてからまとめてout.datに書き込んで
ディスクへのアクセスを減らした方が早いよ。
環境にもよるけど、一度ディスクにアクセスする間にメモリからデータを十万回程度アクセスできる。
読み込みも書き込みもまとめてディスクへアクセスすればシーク時間も節約できる。

227 ：225：2008/01/21(月) 13:30:36

>>226
iterator を使うと、fstream へのアクセスが 1 文字ごとに
なっちゃうっていう理解でいいですか？
なんとなく iterator のほうがカッコいいかなって思ったんだけど、
使い物にならんほど遅いので…。

素直に
fstream::read()
fstream::write()
を使えということでFA？

228 ：デフォルトの名無しさん：2008/01/21(月) 14:20:07

つ streambuf_iterator

229 ：デフォルトの名無しさん：2008/01/21(月) 14:58:03

>>228
俺には>>225のコードがstreambuf_iteratorを使っているように見えるんだが。

230 ：デフォルトの名無しさん：2008/01/21(月) 15:10:47

吊ってくる…

231 ：デフォルトの名無しさん：2008/01/21(月) 15:26:30

低レベル(遅延書き出しなど)でのディスク書き出しはOSの機能
だと思われ。書き出すタイミングも。
streambuf_iteratorを使う（内部的にsgetc, sbumpc, sputcを
使ってる）ということはプログラムレベルでのストリームバッファ
を直接操作してるわけで、ファイルストリームオブジェクトに対して
read、writeを使うと非バッファ操作になるから速くなることは
ないと思える。実測次第だな。
OSのチューニングなりドライバこさえるなりするのも一考。

232 ：デフォルトの名無しさん：2008/01/21(月) 19:53:04

これで速くなるのかな
http://itpro.nikkeibp.co.jp/article/COLUMN/20080104/290425/

233 ：デフォルトの名無しさん：2008/01/21(月) 19:55:10

最新のドラフトを見ると string も連続性を保証するようになるっぽい。

234 ：225：2008/01/21(月) 19:58:24

>>231
う～ん・・・

boost::timer t;
for( int i=0; i < 10; ++i ) {
ifstream fin( "in.dat", ios::binary );
ofstream fout( "out.dat", ios::binary );

copy (
istreambuf_iterator<char>( fin ),
istreambuf_iterator<char>(),
ostreambuf_iterator<char>( fout )
);
}
cout << "iterator=" << t.elapsed() << endl;

t.restart();
for( int i=0; i < 10; ++i ) {
ifstream fin( "in.dat", ios::binary );
ofstream fout( "out.dat", ios::binary );

while( !fin.eof() ) {
char buf[BUFSIZ];
fin.read( buf, BUFSIZ );
fout.write( buf, BUFSIZ );
}
}
cout << "read_write=" << t.elapsed() << endl;

のコードでやったら、iterator=2.093, read_write=0.438で、5倍ほど差がつきました。
環境は WinXP + VC8 です。
まぁ、どうしても iterator 使いたいわけじゃないので、おとなしくread() と write() 使います。

235 ：デフォルトの名無しさん：2008/01/21(月) 20:54:05

multisetの実装について教えてください。

値の重複を許す二分探索木というのは、どう構成したらいいのかよくわかりません。たとえば、

10
8 12

みたいなところ(10がルートで8と12が左右の子)にもうひとつ10を挿入すると、どういう木になるんでしょうか?
red-black treeでなく、単なる二分探索木の話でよいので教えてください。

236 ：デフォルトの名無しさん：2008/01/21(月) 21:34:55

>>234
やっぱりディスクアクセスが頻発するのか。
streambuf_iteratorはstream_iteratorに比べると速いというだけか。

ただ、そのプログラムのread/writeだと正しくファイルがコピーされなかった。
おそらく、fout << fin.rdbuf(); 一行で正しくコピーできると思う。

by VC++ 2008

237 ：デフォルトの名無しさん：2008/01/21(月) 21:39:20

>>234
fout.write( buf, BUFSIZ );

がコピーできない原因か。BUFSIZEのゴミまでコピーされてしまう。

238 ：デフォルトの名無しさん：2008/01/21(月) 21:56:13

flushみたいな名前の

239 ：225：2008/01/21(月) 22:20:19

おお、ほんとだ。
こんな単純なミスをするとはｗｗ

ファイルのサイズがBUFSIZの倍数になってたから
正常に動いてるように見えてたみたい

>>236
書き方は rdbuf() が一番簡単ですね。
さっきのコードで
fout << rdbuf();
と
char buf[BUFSIZ];
fin.read( buf, BUFSIZ );
int n = fin.gcount();
fout.write( buf, n );

でやってみましたが（他の部分は同じ）、
rdbuf=1.375
read_write=0.406
で、速度を気にする場合は read(), write() のほうが早いようです。

簡潔に書きたいときは
rdbuf()
速度が重要な時は
read(), write()
を使う方向でいこうと思います。

240 ：デフォルトの名無しさん：2008/01/21(月) 22:23:42

>>232
あほうすぎる話だなｗ
こんなのDBの研究者が聞いたら鼻で笑っちまうぜ。
挙句の果てVBかよｗ

241 ：デフォルトの名無しさん：2008/01/21(月) 22:29:51

/.J でもさんざん馬鹿にされてる

242 ：デフォルトの名無しさん：2008/01/21(月) 22:30:27

>>239
そうrdbufだと結構遅かったんだよね。
gcount()があったんだ。それ使ったほうが良いよ。
速いに越したことはない。

thx。色々参考になったよ。

243 ：デフォルトの名無しさん：2008/01/21(月) 22:32:50

>>240
DBの検索アルゴリズムはよく知らんが、
アルゴリズムを考えるときに言語使用は関係ないだろ。

それに、どうせ使ってるのはOSのAPIだろうから、VBだろうが、Cだろうが、
呼び出す速度は同じじゃね？

244 ：デフォルトの名無しさん：2008/01/21(月) 22:40:10

「OSの基本機能であるファイル名の検索機能」とやらのアルゴリズムを
そっくりそのままDBに応用しようとは考えなかったんだろうか？？

245 ：デフォルトの名無しさん：2008/01/21(月) 23:05:24

STLの配列にクラスのポインタを入れて使用したいのですけど、
そのようなことって可能なのでしょうか？

246 ：デフォルトの名無しさん：2008/01/21(月) 23:09:31

>>245
コピーしたときに問題がおきるからだめ

たとえば、

class my_class;
vector<my_class*> v1;
vector<my_class*> v2 = v1;

だと、v1とv2の指してる先が同じになっちゃう。
ポインタが（というか、newが）使いたいなら、boost::shared_ptr 使って
入れろ。
boost::shared_ptr でググって、使い方がわからんなら
STLコンテナにポインタ入れるのはあきらめろ。

247 ：デフォルトの名無しさん：2008/01/21(月) 23:10:38

>>245
配列？valarray?
ちなみにコンテナだったら可能だよ。
まあ色々面倒だからスマートポインタ使うか
boostのpointer containerとか。

248 ：デフォルトの名無しさん：2008/01/21(月) 23:12:24

>>246,247
ありがとうございます。
では、早速チャレンジしてみます

249 ：デフォルトの名無しさん：2008/01/21(月) 23:16:08

つーかコンテナにポインタ入れる必要って本当にあるの？
大抵の事ならポインタ入れずに済ませられると思うんだが。

250 ：デフォルトの名無しさん：2008/01/21(月) 23:21:32

ヒープに作成したオブジェクトをコンテナで
管理したい場合もあるんじゃないかな。

251 ：デフォルトの名無しさん：2008/01/21(月) 23:35:47

>>235 だれかおながいします・・
とおもったけどスレチガイ？

252 ：デフォルトの名無しさん：2008/01/21(月) 23:39:15

>>244
>「OSの基本機能であるファイル名の検索機能」とやらのアルゴリズムを
>そっくりそのままDBに応用しようとは考えなかったんだろうか？？

Windows Index Search の機能らしいので
アルゴリズム自体はそっくりそのままDBです

本当にありがとうございました

253 ：デフォルトの名無しさん：2008/01/21(月) 23:41:04

>>245-250
class my_class;
vector<my_class*> v1;

普通に使いまくってますが何がいかんの？

254 ：デフォルトの名無しさん：2008/01/21(月) 23:43:59

コピーしたときに問題が起きるのは使い方が悪い。

255 ：デフォルトの名無しさん：2008/01/22(火) 00:19:14

>>235
10
10 12
8

multiset の実装と関係あるかどうか知らんけど。

256 ：デフォルトの名無しさん：2008/01/22(火) 00:35:31

>>255
http://en.wikipedia.org/wiki/Binary_search_tree#Insertion
ここみると、そんな凝ったことしてないね。

でも、>>255のようにしないとequal_rangeとかまともに実装できない気もする。
どうなんだろ

257 ：デフォルトの名無しさん：2008/01/22(火) 00:45:39

>>256の記事にも書いてあるけど、親と同じ値なら左部分木に入れる、とか決めておくだけだな

258 ：デフォルトの名無しさん：2008/01/22(火) 00:53:14

右じゃないの。　

259 ：デフォルトの名無しさん：2008/01/22(火) 01:00:51

>>258
どちらかに統一しておけばいいんじゃないの?

>>257
左に入れるとして、同じ値を見たら、そのノードの直接の子供としてinsertするのか(255案)、
孫以下の遠い子供として、leafの子としてinsertするのか(この例だと8のrightとして)、どっち?

std::multisetの場合。

260 ：デフォルトの名無しさん：2008/01/22(火) 01:06:36

>>253
newしたオブジェクトを入れるんだったら、
deleteのし忘れ、2重に行ってしまうなどのミスを起こすから
やめとほうがよいというだけのこと。

「気を付ける」なんて言葉は信頼できないので、
やるなら246のいうようにshared_ptrか何か使って、
deleteをコンピュータ任せにするほうがいい。

261 ：257：2008/01/22(火) 01:22:29

>>259
通常と同じ、leafの子としてinsertする
>>255は挿入順の関係でたまたま直接の子になっただけだと思う

262 ：デフォルトの名無しさん：2008/01/22(火) 01:28:48

>>261
それだと、同じ値を持つノードがツリー上で離れてしまいますよね。
equal_rangeをどうやって実装するのか想像がつかないのですが、簡単に教えてもらえませんか？

戻ってきたイテレータを++するたびにO(logN)のサーチが入る???

263 ：デフォルトの名無しさん：2008/01/22(火) 01:36:14

>>262
重複を許そうが許すまいが、二分探索木はそもそもそういうものだろ
隣接した要素が木構造の上では離れた場所に置かれることがある
イテレータをどうやって実装するのが普通かは知らないけど、setとmultisetで事情が変わる訳じゃない

264 ：デフォルトの名無しさん：2008/01/22(火) 01:55:22

>>263
まったくもってそうでした。。。。
イテレータも、単にin-orderでtraverseすれば要素同士が離れていても問題なく連続して触ってくれますね。

265 ：デフォルトの名無しさん：2008/01/24(木) 10:22:33

COAP!

266 ：デフォルトの名無しさん：2008/01/25(金) 08:16:31

COAPってナニ？

267 ：デフォルトの名無しさん：2008/01/25(金) 08:26:55

COAP＝Containers of auto_ptr

Effective STLぐらい買え

268 ：デフォルトの名無しさん：2008/01/25(金) 10:01:54

ありがとう

269 ：デフォルトの名無しさん：2008/01/25(金) 15:47:58

struc foo {
string name;
};

std::vector<foo> v;

foo *f = new foo;

f->name = "ABC";
v.push_back( *f );

とやったときの、findでのABCの検索の仕方が全然解りません。
教えて下さい。

270 ：デフォルトの名無しさん：2008/01/25(金) 16:03:31

>>269

std::vector<foo>::iterator it = v.begin();
size_t pos = it->name.find("ABC");

あるいは
size_t pos = v[0].name.find("ABC");

271 ：269：2008/01/25(金) 16:06:52

コードを端折ってすみません；；
foo *f = new foo; f->name = "ABC"; v.push_back( *f );
の部分が何度も繰り返してる場合です。
for ( i = 0; i <100; i ++ ) {
foo *f = new foo; f->name = IntToStr( i ); v.push_back( *f );
}
とか。。

272 ：デフォルトの名無しさん：2008/01/25(金) 16:24:35

std::vector<foo>::iterator it;
for(it=v.begin(); it != v.end(); it++) {
　if(0 == it->name.find("ABC")) {
　　//hit
　}
}

こうかな？

もしvの中に連続して文字列が存在していることを期待してて、
それをまとめてサーチしたいと思っているなら、各stringの中身は
別個に確保されてて繋がってないので無理じゃないかと。

273 ：269：2008/01/25(金) 16:33:03

なるほど。。なんかfind使う意味なさそうですね。

for ( int i = 0; i < v.size(); i ++ ) {
if ( v[i].name == "もげもげ" ) puts( "一致" );
}

でもいいわけですね。ありがとうございましｔ。

274 ：デフォルトの名無しさん：2008/01/25(金) 16:40:20

algorithmのfind()を使って探したいと言ってるのなら、
fooにoperator==を加えてnameとconst char*を比較できるようにするか、
find_if()に比較関数を渡すかすれば、

vector<foo>::iterator it = find(v.begin(), v.end(), "ABC");

こんな感じにも書ける。
＜速度的な違いはほとんど無いと思うけど

275 ：デフォルトの名無しさん：2008/01/25(金) 16:48:42

もしstring.find()の検索効率を活用したいなら
文字列の格納先は単一のstringにして

name.append(文字列);

を繰り返してどんどん足していくしかないんじゃ。
で、足すときにnameの何バイト目は何個目の要素か
ってなテーブルを同時に作って、findの結果から調べられる
ようにしておくとか。

276 ：デフォルトの名無しさん：2008/01/25(金) 18:05:03

アルゴリズムの改良でSTLが使えないか質問です。

現在、キー文字列を与えると、それに応じた
文字列を返すSTL::mapのようなコードがあります。
ただ、返す文字列が可変です。例えば、キー"気温" を
与えると”今現在”の気温「5ﾟC」を文字列で返すと
いった感じです。

　現在このコードは ifとelseの連続で構成されたものと
なっておりまして、効率面でも文字列比較を繰り返し
行っており、良いものではありません。

これを実現するのに、できればmapに似た簡単で効率の
いい形で改良できないでしょうか？

277 ：デフォルトの名無しさん：2008/01/25(金) 18:18:02

>>276
すぐに思いつくのは文字列から「文字列を返す関数」へのマップだな
"温度"を与えると「温度を計算する関数」が得られるようにする

278 ：デフォルトの名無しさん：2008/01/25(金) 18:19:08

>>276
map<string, string(*)(void*)> のような、キー文字列→関数のマップを作ればいいんじゃないかな

279 ：278：2008/01/25(金) 18:20:31

void*ってなんだろう・・・無視してくださひ。。

280 ：デフォルトの名無しさん：2008/01/25(金) 19:12:55

>>277-279
早速有難う御座います

なるほど関数ポインタをマップですか。　確かに展望良さそうです。
早速コーディング検討したいと思います。　ありがとうございました！

281 ：デフォルトの名無しさん：2008/01/25(金) 23:18:56

>>273
今更だが、部分一致ならfind_ifを使う手もある。

#include <iostream>
#include <string>
#include <vector>
#include <algorithm>
#include <functional>

struct foo {
std::string name;
};

struct FooNameIs : public std::binary_function<char *, foo, bool> {
bool operator() (const char * match, const foo & f) const {
return (f.name == match);
}
};

int main() {
std::vector<foo> v;
/* vに色々追加するコード*/
std::vector<foo>::iterator it = std::find_if(v.begin(), v.end(),
std::bind1st(FooNameIs(), "ABC"));
return 0;
}

あと、foo * f = new fooしてv.push_back(*f)してるのは、凄く気になる。

282 ：デフォルトの名無しさん：2008/01/25(金) 23:21:04

てか>>274に書いてあったorz>>find_if

283 ：デフォルトの名無しさん：2008/01/26(土) 19:04:00

てかstringにsjis入れちゃだめでしょ

284 ：デフォルトの名無しさん：2008/01/26(土) 19:05:50

どこでSJISと特定したのか興味深い。

285 ：デフォルトの名無しさん：2008/01/27(日) 00:03:12

SJISだとしても、別に入れるのは問題ないだろ。

286 ：デフォルトの名無しさん：2008/01/27(日) 00:15:38

findとか使わなきゃね。

287 ：デフォルトの名無しさん：2008/01/27(日) 00:24:35

std::vectorとstd::basic_stringは分かれている必然性があんましない気がする

288 ：デフォルトの名無しさん：2008/01/27(日) 00:27:36

vectorのメモリ連続性が保証されなくなるのは嫌なので統合反対。

289 ：デフォルトの名無しさん：2008/01/27(日) 00:28:10

次期 C++ だと string の連続性が保証されるよ。

290 ：デフォルトの名無しさん：2008/01/27(日) 00:47:37

んじゃ、char_traitsをvectorに入れると只のコンテナじゃ無くなるので統合反対。

291 ：デフォルトの名無しさん：2008/01/27(日) 00:49:36

c_str に触れればいいだけなような

292 ：デフォルトの名無しさん：2008/01/27(日) 00:58:58

>>287
統一してしまうとまずいことがあるよ。

vectorは末尾への要素追加のならし計算時間がO(1)じゃないといけないから、参照カウントによる
copy-on-write最適化ができない。stringにはそういうしばりはないから、COWが可能。まぁ最近
はマルチスレッドの関係でCOWなstringは絶滅危惧種だけど。

他にもあったはずだが、とっさには思いつかない。

293 ：デフォルトの名無しさん：2008/01/27(日) 01:14:54

findしちゃだめって・・もう馬鹿かと。事実上利用不可だろ

294 ：デフォルトの名無しさん：2008/01/27(日) 01:16:36

そうは思わない。入れ物として使うなら十分。

295 ：デフォルトの名無しさん：2008/01/27(日) 01:20:07

c_str 使って外部の検索関数使えばいいだろ。

296 ：デフォルトの名無しさん：2008/01/27(日) 01:20:49

お前ら努力家だな

297 ：デフォルトの名無しさん：2008/01/27(日) 01:25:12

wstringのことも時々でいいから思(ry

298 ：デフォルトの名無しさん：2008/01/27(日) 01:25:43

wstring には SJIS なんて入れられないだろう・・・

299 ：デフォルトの名無しさん：2008/01/27(日) 01:26:03

wstringでSJISが正しく扱えるのかい。

300 ：デフォルトの名無しさん：2008/01/27(日) 01:27:23

これだからWindowsしか知らない奴は。

301 ：デフォルトの名無しさん：2008/01/27(日) 01:31:02

stringは実用なんて論外としても、wstringもサロゲートあぼーんなわけで。。
もう文字列終わってるな

302 ：デフォルトの名無しさん：2008/01/27(日) 01:32:51

そこでUCS-4ですよ。

303 ：デフォルトの名無しさん：2008/01/27(日) 01:36:51

サロゲートあっても find に影響はないだろ？

304 ：デフォルトの名無しさん：2008/01/27(日) 01:37:18

wchar_t はその環境で扱える最大サイズの文字コードを入れる事ができるサイズであって
UTF-16 だと決まってるわけでもないわけだが。実際４バイトの環境もあるし。
まあ、次期 C++ だと char16_t (UTF-16) や char32_t (UTF-32) が追加されるわけだが。

305 ：デフォルトの名無しさん：2008/01/27(日) 01:39:36

しかしwstringだと98系はもうだめだな。
クロスプラットフォームじゃないじゃんstl。。

306 ：デフォルトの名無しさん：2008/01/27(日) 01:40:32

クロス文字エンコーディングじゃないだけ。

307 ：デフォルトの名無しさん：2008/01/27(日) 01:40:52

>>303
UTF-8でもfindは問題ないからそのレベルでいいんだったらwstringを使う意味がない

308 ：デフォルトの名無しさん：2008/01/27(日) 01:41:38

>>304
それはビット幅だけじゃなくて中身もUTF-16/UTF-32であることが保証されてるの?

309 ：デフォルトの名無しさん：2008/01/27(日) 01:42:28

>>303
sizeがだめでしょ。

310 ：デフォルトの名無しさん：2008/01/27(日) 01:43:03

そんなもん中身を入れるコード次第だろ。

311 ：デフォルトの名無しさん：2008/01/27(日) 01:44:59

>>309
sizeは「か」に半濁点とかまで考慮するとUTF-32でもだめ

312 ：デフォルトの名無しさん：2008/01/27(日) 01:45:47

で、おまえらどうやってんの？
string s = "abc"; // sjis!!。findとかしないで。。
wstring s = _T("abc"); // ｳﾆｺｰﾄﾞ。98とかでビルドしないで。サロゲートやばいかも

どっちも地獄だな。CStringの方がましじゃね？

313 ：デフォルトの名無しさん：2008/01/27(日) 01:46:11

>>309
size は配列サイズが取得できれば十分じゃないか？

314 ：デフォルトの名無しさん：2008/01/27(日) 01:49:27

size()/length()はstrlenと等価だから。元々文字数を返すことを期待してはダメ。

315 ：デフォルトの名無しさん：2008/01/27(日) 01:50:00

だからIBMがアレを作ったのさ
なんだっけアレ　眠くて思い出せない

316 ：デフォルトの名無しさん：2008/01/27(日) 01:51:44

ICU

317 ：デフォルトの名無しさん：2008/01/27(日) 01:52:02

集中治療室

318 ：デフォルトの名無しさん：2008/01/27(日) 01:54:11

>>308
Yes.

319 ：デフォルトの名無しさん：2008/01/27(日) 01:55:41

>>311
つか、ウニコード捨てればええだけの話しちゃうの？
ウニコード捨ててもそんなにデメリットないような… … …

320 ：デフォルトの名無しさん：2008/01/27(日) 01:56:41

サロゲートはサブマリン的に最近問題に。。Unicode側は昔っから、
Utf-16はランダムアクセスはできない文字コードですよと言ってきたんだけど
なんとなく流されて2バイトで便利みたいに扱われたり、たいていsizeは文字数を
返すとか説明されたり。。もう混乱の極み。
Javaとかはlengthは2バイト単位の長さを返す仕様に変わり、文字数の取得は
codePointCountが追加されたりどの言語も苦肉の策を講じてる状態。
stlもなんとかしないといけない状況ではある。

321 ：デフォルトの名無しさん：2008/01/27(日) 01:58:34

>>320
日本語だけ扱ってる状況でサロゲートペア関係あるっけ

322 ：デフォルトの名無しさん：2008/01/27(日) 01:58:42

むしろ、stringをタダのコンテナに引きずり落とすくらいの意気込みで。

323 ：デフォルトの名無しさん：2008/01/27(日) 01:59:59

size が文字数返すなら、イテレータは１文字ずつ拾ってくる必要があるし、
そうなった時その型はどうするんだ？って話になる。
UTF-32 で合成があった場合とか、64ビット値を返すのか？

324 ：デフォルトの名無しさん：2008/01/27(日) 02:01:42

やっぱ速度の問題もあるし、javaみたいにsizeとcodePointCountの両方用意
しとくしかないんじゃないかなあと

325 ：デフォルトの名無しさん：2008/01/27(日) 02:02:41

gccのwchat_tは32bitだから楽勝

326 ：デフォルトの名無しさん：2008/01/27(日) 02:04:33

>321
JIS2004と愉快な仲間たち。

>323
ﬁnal はsizeいくつ、って話だよね。

327 ：デフォルトの名無しさん：2008/01/27(日) 02:05:42

>>325
サロゲートの文字数は取れない点は同じだけどね

328 ：デフォルトの名無しさん：2008/01/27(日) 02:07:28

イテレータだけじゃなくて [ ] も文字数に合わせた形にする必要がある。
でも、ランダムアクセスなんて無理じゃん？

329 ：デフォルトの名無しさん：2008/01/27(日) 02:09:46

world_char_tが定まるまで待ちましょう。

330 ：デフォルトの名無しさん：2008/01/27(日) 02:12:03

結局ランダムアクセス用の冗長なデータを込みにしたクラスにしないとどうしようもないし、
パフォーマンス上そこまで標準に組み込まれることは無いだろう。
まあ、それ用のクラスを string 系列とは別に作ることは可能だろうが、
SJIS とかはまあ無理だな。

331 ：デフォルトの名無しさん：2008/01/27(日) 02:12:42

length(L"ﬁnal")が５と帰ってきてくれたら、なにか嬉しい？

332 ：デフォルトの名無しさん：2008/01/27(日) 02:14:25

wstringのfind,insert,appendとかはサロゲートも平気そうな気がするけど
なんとも微妙。。
文字とか文字数を意識した扱いをしようとしない限りは平気なのかな・・？

333 ：デフォルトの名無しさん：2008/01/27(日) 02:15:23

文字数を指定しての置換とかはやばそうだな。

334 ：デフォルトの名無しさん：2008/01/27(日) 02:16:12

非常によく使うデータ構造だから、効率を犠牲にして理想に走れないもどかしさ

335 ：デフォルトの名無しさん：2008/01/27(日) 02:16:41

findは大丈夫そうだけど、insert/appendは、サロゲートの前半だけ＋別の文字、
みたいな不正な文字列を受け付けるべきか、みたいな話はあるよね。

336 ：デフォルトの名無しさん：2008/01/27(日) 02:17:18

英語圏だとマルチバイトうぜーとかしか思われてないだろうしな。

337 ：デフォルトの名無しさん：2008/01/27(日) 02:18:12

stdc++のレベルで理想に走らなくても良いよ。というか理想がなんなのかも分からないし。この話題はこっち向きじゃないかい。

C++で新しい文字列クラスをつくろう 2
http://pc11.2ch.net/test/read.cgi/tech/1167132255/

338 ：デフォルトの名無しさん：2008/01/27(日) 02:20:06

普通insertする文字とかiteratorもfindの結果のiteratorとかなわけで
問題なくね？
>>333
確かに文字数指定でサロゲート文字の途中とかになってたら文字が切れちゃう
よねぇ

339 ：デフォルトの名無しさん：2008/01/27(日) 02:21:08

もうこういうのは boost の領分かもしれないな。

340 ：デフォルトの名無しさん：2008/01/27(日) 02:21:41

がしがし書き換えたいならutf32に変換してから、書き換えて、utf8なりutf16なりに戻すほうが簡単そうだ。

341 ：デフォルトの名無しさん：2008/01/27(日) 02:24:29

結局、find/appendなどの引数に与える文字が文字の途中などでない、
と文字数指定の関数に文字の途中などの数を指定しない
を守ってればサロゲートもおけ、でいいのかな？

342 ：デフォルトの名無しさん：2008/01/27(日) 02:26:18

まぁあと15年位したら皆UTF-32でのんびりやってるさ

343 ：デフォルトの名無しさん：2008/01/27(日) 02:26:48

>>341
それを守るためにどれだけのコストが掛かるかって話してるんじゃないのか

344 ：デフォルトの名無しさん：2008/01/27(日) 02:27:16

>文字数指定の関数に文字の途中などの数を指定しない
これを守るのがすげー大変そうだ。

345 ：デフォルトの名無しさん：2008/01/27(日) 02:27:59

まだSJISが使われてると思います＞＜

346 ：デフォルトの名無しさん：2008/01/27(日) 02:28:55

SJIS 専用のクラスならまあ作れるだろうな。

347 ：デフォルトの名無しさん：2008/01/27(日) 02:29:01

俺頭から5文字取るみたいなコードとりかえしがつかないくらい書いてるな

348 ：デフォルトの名無しさん：2008/01/27(日) 02:32:47

>>341
文字数ならサロゲートを割ってしまうことはないよ。
サロゲートペア一組で一文字だから。

349 ：デフォルトの名無しさん：2008/01/27(日) 02:33:58

wchar五個分でなくて、5「文字」分きちんと取れるコードを？

350 ：デフォルトの名無しさん：2008/01/27(日) 02:35:13

たとえば、
「か゛」は１文字という扱いでいいのか？
「か゛゛゛゛゛゛゛゛゛゛゛゛゛゛゛゛゛゛゛゛゛゛゛゛゛゛゛゛゛゛゛゛゛゛(略」
みたいなどうしようもない連中はどうしよう？

351 ：デフォルトの名無しさん：2008/01/27(日) 02:38:26

>>348
std::string(wstring)の「文字数指定」は、1文字が固定長のコード体系が前提だから、サロゲがあると壊れるよ。
>>350
それペアになってなくない？

352 ：デフォルトの名無しさん：2008/01/27(日) 02:38:36

>>348
>サロゲートペア一組で一文字
一組で4バイト(結合文字は6バイトもある)

で、文字数(というより2バイト単位)指定はアウト。
s = サロゲート文字列
s2 = s.substring(0, 5)
とかやったらあぼーんでしょ

353 ：デフォルトの名無しさん：2008/01/27(日) 02:42:20

>>352
文字数というのは、キャラクタ数という意味で使った。

354 ：デフォルトの名無しさん：2008/01/27(日) 02:47:21

CString的にTCHAR使えてさらにクロスなものはないのかね？

355 ：デフォルトの名無しさん：2008/01/27(日) 02:48:52

>>350
合成文字は2キャラクタでしょ。
合成文字をぶった切ると、意味は通じなくなるかもしれないが違法ではない。

356 ：デフォルトの名無しさん：2008/01/27(日) 02:53:07

ああ、その「キャラクタ数」というのは、要するにUTF-32換算なわけか。

357 ：デフォルトの名無しさん：2008/01/27(日) 03:00:31

Winではstringは使うな。2バイト目が1バイト目とかぶってやがるからな。
wstringはサロゲートに注意して使え。途中で切るなよ。
Win98とかまだやってるカスはCStringでも使ってろ。
LinuxではstringでもEUCとUTF-8は2バイト目が1バイト目とかぶらないからまだ
なんとかなるはずだ。
クロスにしたいなら文字列クラスは当然自前だろ？

が俺の現状の認識

358 ：デフォルトの名無しさん：2008/01/27(日) 03:02:31

>>327
ハァ?

359 ：デフォルトの名無しさん：2008/01/27(日) 03:09:34

>>358
へ？

360 ：デフォルトの名無しさん：2008/01/27(日) 03:14:40

>>357
追加でMac OS XはCFString使っとけ。以上。

361 ：デフォルトの名無しさん：2008/01/27(日) 04:50:39

>>357
OS 関係なくてエンコーディングの話だろ？
Windows でも UTF-8 使えば問題ないし、 Linux でも Shift_JIS 使えば問題は出る。
クロスにしたければエンコーディングを OS 任せにしなければ良いだけの話。
たとえば UTF-8 を使うと決めれば std::string でもいけるでしょ。

362 ：デフォルトの名無しさん：2008/01/27(日) 05:05:46

>>361
だけの話・・って、実際にUTF-8でやったことないんだろ？試しにやってみなよ。
APIに渡すとき、コンソルに出すときすべてに変換をかます必要あるだろ？
文字リテラルはどうするんだ？ソース内のUTF-8はまだコンパイラのサポートが微妙だぞ。
現実的じゃないんだよ。OSが正式にサポートしてるSJISとかUTF-16以外を
内部エンコーディングにするのは。

363 ：デフォルトの名無しさん：2008/01/27(日) 05:33:05

１文字が何バイト使うかはどれ使っても一定ではない　どれを使うか決まっていればどれ使ってもよい

364 ：デフォルトの名無しさん：2008/01/27(日) 05:48:20

UTF-32は4バイト固定。でも合成文字があるので結局同じ問題は残る。

365 ：デフォルトの名無しさん：2008/01/27(日) 06:53:55

一方ロシアはモールス符号を使った

366 ：デフォルトの名無しさん：2008/01/27(日) 06:59:29

合成文字なんて捨てろ
すべての文字を表現したいなんて無駄の極み

367 ：デフォルトの名無しさん：2008/01/27(日) 08:26:25

おいおい、放棄かよ

368 ：デフォルトの名無しさん：2008/01/27(日) 08:37:31

>>362
入出力と多言語以外の問題はなし　日本語使うんだったらどれでも同じ　
入出力にコンバートするのに手間がかかるかどうかだけ

369 ：デフォルトの名無しさん：2008/01/27(日) 10:08:29

全部画像でおｋ

370 ：デフォルトの名無しさん：2008/01/27(日) 12:33:49

16x16ピクセル（256ビット）のパターンで全ての文字を表現するとかどっかで見たな。

371 ：デフォルトの名無しさん：2008/01/27(日) 13:24:31

文字コード総合スレだと思った
つーかPDFでおｋ

372 ：デフォルトの名無しさん：2008/01/27(日) 13:25:37

(　д ) ﾟﾟ

373 ：デフォルトの名無しさん：2008/01/27(日) 15:15:28

>>365
一方ロシアは画像を使った

こっちの方がしっくりくるな。

374 ：デフォルトの名無しさん：2008/01/27(日) 15:52:02

>>370
宇宙の星にそれぞれ新しい文字で名前つけてもあまるだろｗ

375 ：デフォルトの名無しさん：2008/01/27(日) 16:26:01

一文字32バイトは流石に先取りしすぎだな

376 ：デフォルトの名無しさん：2008/01/27(日) 16:37:26

string path = "c:\\機能仕様書\\01.doc";
path.find("\\");
こんなであぼーんするstringは危険としか言いようがない

377 ：デフォルトの名無しさん：2008/01/27(日) 16:47:52

そんなアホなことをする方が悪い。

378 ：デフォルトの名無しさん：2008/01/27(日) 16:55:52

1文字に1GB

379 ：デフォルトの名無しさん：2008/01/27(日) 16:56:20

もう OCR でいいよ・・・

380 ：デフォルトの名無しさん：2008/01/27(日) 17:24:37

人間様の認識能力を利用する形が最強

381 ：デフォルトの名無しさん：2008/01/27(日) 17:28:05

人間なんてよく読み間違うじゃん

382 ：デフォルトの名無しさん：2008/01/27(日) 17:56:59

>371
CID(AJ15)のことか？あのコードも印刷以外に使うのは
結構アレなんだけどなー。

383 ：デフォルトの名無しさん：2008/01/27(日) 18:00:16

Ｃ＋＋
メンバ関数内で
スコープ解決演算子で
classname::メンバ変数の値変更するのと
this->メンバ変数　の値変更するのは何が違うの？

384 ：デフォルトの名無しさん：2008/01/27(日) 18:04:56

struct P{int m;};
struct C : public P{ int m;
void f(){ this->m = 0; this->P::m = 1; }
};
みたいな話。

385 ：デフォルトの名無しさん：2008/01/27(日) 18:07:20

>>377
findが使えないstringって・・・カスめ

386 ：デフォルトの名無しさん：2008/01/27(日) 18:09:21

path[path.find("\\")] == '\\'になるじゃん、ちゃんと。

387 ：デフォルトの名無しさん：2008/01/27(日) 18:12:41

返答ありがとう。

最初の

this->m は　Ｃ　のオブジェクトのメンバ変数ｍ
this->P::m は何でしょうか？

388 ：デフォルトの名無しさん：2008/01/27(日) 18:14:13

>>386
まじか？

389 ：デフォルトの名無しさん：2008/01/27(日) 18:16:16

>>386
そりゃなるだろwww

390 ：デフォルトの名無しさん：2008/01/27(日) 18:16:42

>>387
P の m にきまっちょるだろう

391 ：デフォルトの名無しさん：2008/01/27(日) 18:22:57

>>386
マジレスすると「能」の2バイト目の「\」がfindで見つかっちゃったんです。
string s = SJISの日本語;
はやっちゃだめなんです。初心者はみんなやってしまうんですが。

392 ：デフォルトの名無しさん：2008/01/27(日) 18:23:56

>>384
>>390

継承したときに変数名かぶった場合コウ書くんですね。

でも、多重に継承した場合、どう書くんだろう？

393 ：デフォルトの名無しさん：2008/01/27(日) 18:29:12

scope

394 ：デフォルトの名無しさん：2008/01/27(日) 18:35:01

>>392
間の型へ一旦 this をアップキャストすると良い。

395 ：デフォルトの名無しさん：2008/01/27(日) 18:35:31

>>391
だから、find とか使わない分には使っていいんだってばよ。

396 ：デフォルトの名無しさん：2008/01/27(日) 18:35:39

あー、ダイヤモンド継承か。
P1::P2::Pb::a = 100;
みたいに、継承順を追いかければ指定できたような・・・

397 ：デフォルトの名無しさん：2008/01/27(日) 18:37:14

char []hoge = SJIS文字列;　　とかやって、
strchr( hoge, '\\');　ってまずいじゃん。
でも、「char配列にSJIS文字列入れるの禁止」って言うのはどうよ、みたいな。

398 ：デフォルトの名無しさん：2008/01/27(日) 18:37:36

別の言語の癖が出てるぜ

399 ：デフォルトの名無しさん：2008/01/27(日) 18:37:59

>>397
そうそう。そんな感じ。

400 ：デフォルトの名無しさん：2008/01/27(日) 18:42:17

文字コードの話って、荒れる割に全然面白くないし、有用な知見も得られないんだよな。

401 ：デフォルトの名無しさん：2008/01/27(日) 18:44:35

結局毛唐が ASCII 以外どうでもいいと思ってるからな。

402 ：デフォルトの名無しさん：2008/01/27(日) 18:47:46

何も考えずに動いていたCStringがなつかすぃ。。
そういえばなんでがんばってfind禁止のダウングレードのstd::string使ってるん
だったっけ？
だれかどこでも動くCString作ってぇぇ

403 ：デフォルトの名無しさん：2008/01/27(日) 18:49:03

>>393
>>394
>>396

ありがと。
やっぱＣ＋＋はスゲーや。
Ｃのシンプルな文法に慣れきったオレには奥が深いぜ。

404 ：デフォルトの名無しさん：2008/01/27(日) 18:49:05

ドザは Windows のことしか考えないから困る。

405 ：デフォルトの名無しさん：2008/01/27(日) 18:52:20

どこでも動く？
どこでもSJIS使うの？

406 ：デフォルトの名無しさん：2008/01/27(日) 18:52:31

Linuxとかｶｽいらねーし

407 ：デフォルトの名無しさん：2008/01/27(日) 18:54:02

Mac では SJIS 使わん事も無い。
UTF-8 や EUC も使うが。

408 ：デフォルトの名無しさん：2008/01/27(日) 18:57:06

ASCII自体が腐ってるからな。誰だよ、あんなコードにしたのは。

409 ：デフォルトの名無しさん：2008/01/27(日) 18:58:30

>>405
いや、できればマクロとかでプラットフォームごととか文字コードとか
切り替えられてさ、当たり前だけどfindとかも問題なく動いちゃうやつ。
CStringみたいに楽に使えて、でもUTF-8とか16とかも平気な感じ。
std::ustringみたいに統一しちゃってさ。boostとかかな。

410 ：デフォルトの名無しさん：2008/01/27(日) 18:59:32

findだけの問題ならすぐ解決するけどな。
ただ、SJISのままだと単純サーチにするしかないので効率は悪い。

411 ：デフォルトの名無しさん：2008/01/27(日) 19:01:36

>>410
そりゃWinの場合は内部的には_mbsstr呼ぶとかして高速化しる

412 ：デフォルトの名無しさん：2008/01/27(日) 19:01:45

wstringに自動変換する const char *n_str();と
wstring(char*)を付ければ解決するような気になるけど？

413 ：デフォルトの名無しさん：2008/01/27(日) 19:01:47

>>406
普通sunだよな

414 ：デフォルトの名無しさん：2008/01/27(日) 19:05:17

Windows なら mbs 系でおkだが、
他の環境だとその手の関数あるんだろうか。

415 ：デフォルトの名無しさん：2008/01/27(日) 19:22:06

ついでに質問なのですが、TCHARみたいにstringとwstringを切り分けるにはどう
すればよいのでしょうか？以下のようにしておく必要があるのでしょうか？
他にもっといい方法があるのでしょうか？
#ifdef UNICODE
　#define tstring string
else
　#define tstring wstring
まだ98でもXPでも動かしたいので・・

416 ：デフォルトの名無しさん：2008/01/27(日) 19:23:31

組み込み型にしてもいい位のデータ構造なのに
クロスに作るのが難しいこんな世の中じゃ

417 ：デフォルトの名無しさん：2008/01/27(日) 19:25:51

>>415
とりあえず #define よりは typedef のほうがいいだろうな。

418 ：デフォルトの名無しさん：2008/01/27(日) 19:30:39

>>415
なにかわからないがよくないことが起こりそうな悪寒

419 ：デフォルトの名無しさん：2008/01/27(日) 19:41:43

charとwchar_tも切り替えないと。リテラル使ってるところがあったらそれもマクロで囲まないとね。

…めんどくさいでしょ。

420 ：デフォルトの名無しさん：2008/01/27(日) 19:45:37

つまり、C++0xのユーザ定義リテラルの登場を待てと

421 ：デフォルトの名無しさん：2008/01/27(日) 19:51:06

>>419
それは TCHAR と _T として既に用意されているだろう。

422 ：デフォルトの名無しさん：2008/01/27(日) 23:53:01

>>415
typedef std::basic_string<TCHAR> tstring;

>>362
361のようなことを現実にやれるソフトウェアでは、
多言語対応のため、文字列リテラルの大半はソースコードに含まれないとか、
APIはラッパー層があるから変換も余裕とかそういう次元にいると思う。

423 ：デフォルトの名無しさん：2008/01/28(月) 00:52:04

実際文字列リテラルをまったく含まないのはたいへんだぞ～。
メッセージ的なものはともかくfind(":")的なパース類もすべてfind(COLON)とか
にして事前にUTF-8で用意しておかなくちゃいけなくなるし、全WinAPIをラップする
のはいよいよ無理だろうに。カレントディレクトリ一つ取るのも
GetCurDir(string& s){
　TCHAR t[PATH_MAX];
　::GetCurrentDirectory(PATH_MAX, t);
　#ifdef UNICODE
　Utf-16からUTF-8に変換
　#else
　SJISからUTF-8に変換
}
的にすべてのラップ関数を用意してあげなきゃいけなくなるし。。

424 ：デフォルトの名無しさん：2008/01/28(月) 00:57:46

> find(":")
他に理由がなければ、ASCII分はそのままソースに書いていいと思った。

425 ：デフォルトの名無しさん：2008/01/28(月) 00:59:56

そんなわけがないだろ。

426 ：デフォルトの名無しさん：2008/01/28(月) 01:02:52

A 系使えば大丈夫。

427 ：デフォルトの名無しさん：2008/01/28(月) 01:34:22

せっかくWinがUTF-16なのに内部エンコーディングをUTF-8にして、API呼ぶたびに
UTF-8からUTF-16に変換はちょっとやだなあ。
全てのAPIをラップする開発コストに加えて、実行時の変換コストまでかかるし。。
やっぱWinはUTF-16でいきたいね。

428 ：デフォルトの名無しさん：2008/01/28(月) 01:37:11

いい加減スレチガイだということに(ry

429 ：デフォルトの名無しさん：2008/01/28(月) 09:45:10

std::string/wstringは最重要のコンテナだしスレ違いとは思わんが・・
結局文字コード周りはいまいちなのがわかるだけなんだよなあ。。

430 ：デフォルトの名無しさん：2008/01/28(月) 14:04:09

話の流れぶった切って申し訳ないが言わせてくれ。
なんか良スレの悪寒。

431 ：デフォルトの名無しさん：2008/01/28(月) 15:13:29

日本語と中国語の区別ができない腐れた文字コードそれがUnicode
中国が大体元凶だけどな

432 ：デフォルトの名無しさん：2008/01/28(月) 15:26:40

> 内部エンコーディングをUTF-8にして、
> API呼ぶたびにUTF-8からUTF-16に変換
Dのことかー！

433 ：デフォルトの名無しさん：2008/01/28(月) 16:15:55

>>431 4.0からは区別できますよ

434 ：デフォルトの名無しさん：2008/01/28(月) 16:34:19

>>431
言語の区別ができない文字コードはUnicodeに限らないんだよ

435 ：デフォルトの名無しさん：2008/01/28(月) 17:12:12

ユニコードは本格的多国語環境や16ビット固定長を宣伝文句にしていたからねえ。
次々と撤回して期待外れだったよな。

436 ：デフォルトの名無しさん：2008/01/28(月) 17:37:19

だから、多国語ではなく多文字だったと。

437 ：デフォルトの名無しさん：2008/01/28(月) 17:44:51

見苦しい

438 ：デフォルトの名無しさん：2008/01/28(月) 18:07:33

ユニコードって、UNIXの文字コードだったから
ユニコードって言うんだよね。

439 ：デフォルトの名無しさん：2008/01/28(月) 18:27:51

おまいらいい加減スレ違いだぞコノヤロー。

440 ：デフォルトの名無しさん：2008/01/28(月) 19:13:14

>>438-439
しらんかった

441 ：デフォルトの名無しさん：2008/01/28(月) 19:15:54

ユニコード表みるとハングルが異様なほど文字数が多い
中国だけじゃないぞ

442 ：デフォルトの名無しさん：2008/01/28(月) 19:24:34

>>441
ハングルは現在全く使用されない組み合わせも全部作るように
韓国が強く要求したんだと

それでbatangが異常に膨れている。
韓国死ねよ。

443 ：デフォルトの名無しさん：2008/01/28(月) 19:30:25

>>442 にほんだって「あ゛」とかいれてるじゃん。

444 ：デフォルトの名無しさん：2008/01/28(月) 19:35:52

http://unicode.org/charts/normalization/chart_Hiragana.html
ここをみるかぎり、「あ゛」は単一のコードとして存在しないようだが

445 ：デフォルトの名無しさん：2008/01/28(月) 19:57:49

ごめん、勘違いだったかも。でも日本人だって「あ゛」いれたいしぃ。
可変長で6バイトでもよくなったんだから、なんでもいれていいと思う。

446 ：デフォルトの名無しさん：2008/01/28(月) 19:59:46

>>443
やあチョーセンジン

447 ：デフォルトの名無しさん：2008/01/28(月) 20:06:35

>>442 欧米人にしたらCJK死ねよなわけだが。
なんでなかよくできんもんかね。

448 ：デフォルトの名無しさん：2008/01/28(月) 20:10:36

仲の良い隣国つーのは歴史上稀なわけだが。
稀つーかあるのか。

449 ：デフォルトの名無しさん：2008/01/28(月) 20:13:08

日本だって古代は中国と仲良かったじゃん。
あと、中国と韓国。
どちらも、主従関係だけどｗ

450 ：デフォルトの名無しさん：2008/01/28(月) 20:42:13

「仲良かった古代」、って遣唐使廃止まででそ。1000年も前の話だし。

451 ：デフォルトの名無しさん：2008/01/28(月) 21:41:37

当時は海ってのは命がけで渡るもの凄い大きな壁だったわけで、
隣国っつーよりは、日本とアメリカ・・・は言い過ぎかもしれんが、
そんな感じだったと思うぜ。

452 ：デフォルトの名無しさん：2008/01/28(月) 21:47:52

　　　♪　♪　　　＼＼　♪　　僕ら～はみんな～　生～きている～　　♪.／／　♪　　♪
　　♪　　　　　　　　＼＼　♪　　生き～ているけど　チョンは氏ね～　♪／／　♪
　　　　　　♪　　　 ∧ ∧　　　∧ ∧　　　∧ ∧　　　 ∧ ∧　　　∧ ∧　　　 ∧∧　　♪
　　♪　　　　∧ ∧(ﾟ0 ﾟ*)∧ ∧(ﾟ0 ﾟ*)∧ ∧(ﾟ0 ﾟ*)∧ ∧(ﾟ0 ﾟ*)∧ ∧(ﾟ0 ﾟ*)∧ ∧(ﾟ0 ﾟ*)　♪
　　　　　　　(ﾟ0 ﾟ*)∧ ∧(ﾟ0 ﾟ*)∧ ∧(ﾟ0 ﾟ*)∧ ∧(ﾟ0 ﾟ*)∧ ∧(ﾟ0 ﾟ*)∧ ∧(ﾟ0 ﾟ*)∧ ∧
　　　　　♪ ∧ ∧(ﾟ0 ﾟ*)∧ ∧(ﾟ0 ﾟ*)∧ ∧(ﾟ0 ﾟ*)∧ ∧(ﾟ0 ﾟ*)∧ ∧(ﾟ0 ﾟ*)∧ ∧(ﾟ0 ﾟ*)♪
　 ─♪──(ﾟ0 ﾟ*)｜　U(ﾟ0 ﾟ*)｜　U(ﾟ0 ﾟ*)｜　U(ﾟ0 ﾟ*)｜　U(ﾟ0 ﾟ*)｜　U(ﾟ0 ﾟ*)｜　U
　　　　　　 | 　U.｜　 | | 　U　| 　｜| 　Ｕ. | 　｜| 　Ｕ. | 　｜| 　Ｕ. | 　 |｜　Ｕ. | 　 |～♪
　　　♪　　 |　　|　U U. | 　｜ U U　| 　 |　U U　| 　 |　U U　|　　|　ＵＵ |　　|　U U　♪
　　　　　　　 U Ｕ　　　 U U 　　　 U U　　　 U U 　　　 U U　　　　 U U

453 ：デフォルトの名無しさん：2008/01/28(月) 22:06:43

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2271.html
こんなのがあったのね。知らんかった

確かにゲームや組み込みではSTLそのまま使うのはキツイわな

454 ：デフォルトの名無しさん：2008/01/28(月) 22:11:55

>>447
電脳創世記っていう本にあったんだが、そもそも「CJKその他ヨーロッパの小国死ねよ」
ってやってる連中はアルファベットしかないコードしか使ってなくて、それを日本人が
「文字コード問題は俺たちが解決して業績上げますからメリケン共は口出ししなくても良いよ＾＾」
って挑発して今の流れになったんだと思う。

455 ：デフォルトの名無しさん：2008/01/29(火) 02:36:05

>>453
ゲームがメモリをキツキツに使うからって、数バイト～数十～数百バイト単位の
標準ライブラリのメモリ確保までキツキツにしても、あんまり関係ないと思うんだ。

どうせ画像やサウンドデータが１個増えればだけでそこらへんの努力は
吹っ飛ぶもんじゃないの？処理負荷にしてもさ。

456 ：デフォルトの名無しさん：2008/01/29(火) 02:42:20

>>442
漢字使用国がそれだけは言っちゃいかんだろ
「じゃお前ら文字数が多すぎるから統合ね」と言われても何も言い返せない
むしろ韓国みたいにもっと初期の段階で分離しろと言い張れば分離できたかも
しれないのに日本人おとなしすぎ

457 ：デフォルトの名無しさん：2008/01/29(火) 02:55:03

文字、文字コード関係はこっちいけよ

458 ：デフォルトの名無しさん：2008/01/29(火) 02:55:33

http://pc11.2ch.net/test/read.cgi/tech/1180250376/

459 ：デフォルトの名無しさん：2008/01/29(火) 02:58:15

英語・日本語・中国語間のソフトやマニュアルの翻訳をやってるけど
ほぼ同じ意味の文章なら中国語が一番少ないデータサイズで書ける

460 ：デフォルトの名無しさん：2008/01/29(火) 03:06:02

そんなの中国語知らん俺でも分かるっちゅーの

461 ：デフォルトの名無しさん：2008/01/29(火) 03:47:21

utf-8で？
アニメの中国語のfansubとか見るとかなが入った日本語と
漢字ばっかりの中国語で文字数そんなに変わらんように見えたけど。
だから画数で言えば中国語は不利。

462 ：デフォルトの名無しさん：2008/01/29(火) 04:43:57

一文字に線をたくさん詰め込むんだから、字数が少なくならないとおかしい。

ような気もする。

463 ：デフォルトの名無しさん：2008/01/29(火) 06:14:49

>>455
ゲーム機はメインメモリ領域が結構キツイんでないの

464 ：デフォルトの名無しさん：2008/01/29(火) 06:33:10

>>440
嘘過ぎる

465 ：デフォルトの名無しさん：2008/01/29(火) 06:40:30

さすがに>>440は釣りじゃないのか

466 ：デフォルトの名無しさん：2008/01/29(火) 06:41:36

>>462
ちょうどいいのがなかったけど、これとか
http://jp.youtube.com/watch?v=BdXniHjh2WM

467 ：デフォルトの名無しさん：2008/01/29(火) 07:28:09

詩とか台詞の翻訳はちょっと特殊じゃないか？
ってどこへ行こうとしてるんだこのスレは

468 ：デフォルトの名無しさん：2008/01/29(火) 15:13:48

標準STLではunicodeをちゃんと扱えるんでしょうか？
処理系依存では（例えばVC++とか）扱えそうですけど。

469 ：デフォルトの名無しさん：2008/01/29(火) 16:35:57

ちゃんと扱う、の定義次第。

wstring, wchar_t を問題なく扱えればOKなのか？それなら問題ないよ。
ロカール処理やエンコーディング変換のための十分なサポートがあるか？それなりしかない。

470 ：デフォルトの名無しさん：2008/01/29(火) 21:06:41

>>455
コンテナ(というかアロケータ)のメモリ効率は重要だと思うが。
アラインメントやページ境界にかなり気をつかっているらしい。

演算効率についてはちょっと読みきれていないが...
inline展開とか命令キャッシュ効率とか、分岐予測の弱いプロセッサのこととか、
いろいろ書いてある。

でかいボトルネックは取り除いた上でさらにどうがんばるかって話では。

>>463
"Game platform memory metrics"ってところに主要なゲーム機のspecが書いてある。

471 ：デフォルトの名無しさん：2008/01/29(火) 21:17:44

EAがやたらマルチプラットフォームでゲームを作れるのは
この辺がしっかりしてるからかな

まぁ無理だろうけど、一部位公開してほしいな

472 ：デフォルトの名無しさん：2008/01/29(火) 23:48:57

VC9でライブラリを作ろうとするとえらーがでます。
使えないですか？

473 ：デフォルトの名無しさん：2008/01/29(火) 23:53:57

主語を書け。

474 ：デフォルトの名無しさん：2008/01/30(水) 00:12:34

むちゃぶりだな

475 ：デフォルトの名無しさん：2008/01/30(水) 00:50:00

バージョンは5.1.5です。

476 ：デフォルトの名無しさん：2008/01/30(水) 01:43:11

わたしにほんごわかりません

477 ：デフォルトの名無しさん：2008/01/30(水) 01:59:02

ベンチャーキャピタルが図書館の設立に失敗？

478 ：デフォルトの名無しさん：2008/01/30(水) 15:09:31

STLportじゃないの

479 ：デフォルトの名無しさん：2008/01/31(木) 12:03:42

マルチスレッドにてqueueを使いたいのですが、
STL等にセマフォを任せることは出来ないでしょうか？

480 ：デフォルトの名無しさん：2008/01/31(木) 12:06:11

基本的にSTLはスレッドセーフではない。

481 ：デフォルトの名無しさん：2008/01/31(木) 12:31:30

>>479
いまどきの実装であれば、たいていドキュメントにマルチスレッドについて書かれている。
そういう記述が無いとか、書かれた保証では不十分だとか、広い移植性が必要だとか、
ドキュメントを読むのがメンドイとか言うんなら自分でなんとかするしかない。

482 ：デフォルトの名無しさん：2008/01/31(木) 18:06:11

std::stringの配列の連続性は保障されてないそうですが、
実際配列が連続じゃない実装をしてる環境ってあるんですか？

483 ：デフォルトの名無しさん：2008/01/31(木) 18:10:37

配列じゃないよ

484 ：479：2008/01/31(木) 18:50:24

>>480-481
ありがとうございました。　無い事が分かって安心しました。
必死で作って、既に有ったらかなり凹むのでｗ（勉強にはなるけど）
WinAPIのCreateSemaphore()かmutexで検討したいと思います。

485 ：デフォルトの名無しさん：2008/01/31(木) 19:52:11

まあ実際はc_str()の動作を速くするために連続の場合が多いけどな。
しかもヌルターミネータ文字まで入ってたり。

486 ：デフォルトの名無しさん：2008/01/31(木) 19:54:51

>>482
ない。というか、次期の規格（C++0x）で連続性が保証されるようになる。

N2461) 21.3.1 basic_string general requirements [string.require]
3　 The char-like objects in a basic_string object shall be stored contiguously.
　　 That is, for any basic_string object s, the identity &*(s.begin() + n) == &*s.begin() + n
　　 shall hold for all values of n such that 0 <= n < s.size().

487 ：デフォルトの名無しさん：2008/01/31(木) 19:58:43

std::ropeは標準じゃないけど、初めから切れ切れの文字列を
つなぎ合わせる事を想定してるな。

488 ：デフォルトの名無しさん：2008/01/31(木) 20:01:32

だからstd::ropeにはメンバ関数c_str()がない。

489 ：デフォルトの名無しさん：2008/01/31(木) 20:02:47

でもSTLportのstd::ropeにはc_str()があったりする。変なの。

490 ：デフォルトの名無しさん：2008/01/31(木) 20:04:03

標準じゃないのに std を使うのは違和感あるよな。

491 ：デフォルトの名無しさん：2008/01/31(木) 20:06:10

STLportはSGI-STLに妙なこだわりを持ってるよな。
何か言われてんのかな。

492 ：デフォルトの名無しさん：2008/01/31(木) 21:13:41

> 基本的にSTLはスレッドセーフではない
例えばどんな場合？

493 ：デフォルトの名無しさん：2008/01/31(木) 21:15:33

>>492
どんな場合って・・・何するにしてもスレッドセーフを要求する
仕様なんてないはずだけども。

494 ：デフォルトの名無しさん：2008/01/31(木) 21:17:02

STLportはスレッドセーフだったような

495 ：デフォルトの名無しさん：2008/01/31(木) 21:21:14

うーん、書いてないとスレッドセーフでないってのも・・
beginthread一回でも呼ぶプロセスではstlは一行も使えないってことに
なりそうな。
たぶん皆、同一インスタンスに複数スレッドでアクセスしなければ平気
くらいな解釈で使ってるんだよね

496 ：デフォルトの名無しさん：2008/01/31(木) 22:41:35

標準にスレッドセーフという概念がないから語っても意味ないだろ

497 ：デフォルトの名無しさん：2008/01/31(木) 23:19:44

スレッドの概念自体が無い

498 ：デフォルトの名無しさん：2008/01/31(木) 23:26:59

ちっ、また自己責任かよ。つかえねーな

499 ：デフォルトの名無しさん：2008/01/31(木) 23:30:23

効率のためにintの幅すら決めない言語に向かって何を言ってるのかね

500 ：デフォルトの名無しさん：2008/01/31(木) 23:39:35

int幅が実装依存なのはちゃんと作ってれば別に問題ないだろ。

501 ：デフォルトの名無しさん：2008/01/31(木) 23:41:25

原子力発電所も冷凍餃子もちゃんと作ってれば別に問題無いぞ。

502 ：デフォルトの名無しさん：2008/01/31(木) 23:41:37

AMD64は自然な長さが64ビットなのにintが32ビットだな

503 ：デフォルトの名無しさん：2008/01/31(木) 23:48:23

intが64bitな処理系は現存するのか？
その場合、32bitを示す型は何だろう？

504 ：デフォルトの名無しさん：2008/01/31(木) 23:52:06

C言語が設計された時期が古いので64ビットとか考えてなかったんだろ

505 ：デフォルトの名無しさん：2008/01/31(木) 23:52:21

>>503
ILP64 でググれ。

506 ：デフォルトの名無しさん：2008/02/01(金) 00:09:02

32bitといったらlongなんじゃないのか

507 ：デフォルトの名無しさん：2008/02/01(金) 00:16:41

>506
まさか、int 64bitでlong 32bitと言ってる？

508 ：デフォルトの名無しさん：2008/02/01(金) 00:17:56

ねたにまじ（ry

509 ：デフォルトの名無しさん：2008/02/01(金) 00:24:17

LP64のほうが素直だねやっぱり。

I16/LP32はDOSで経験があるし(w

510 ：デフォルトの名無しさん：2008/02/01(金) 00:25:16

もうビット数気にする処理には stdint.h 使えばいいということで。

511 ：デフォルトの名無しさん：2008/02/01(金) 00:29:14

_int64とかタイプしたくないよヽ(`Д´)ﾉｳﾜｧｧｧﾝ
4G超えのファイルなんかザラだろうが。

512 ：デフォルトの名無しさん：2008/02/01(金) 00:31:19

typedef すれば？

513 ：デフォルトの名無しさん：2008/02/01(金) 00:34:47

typedef _int64 long long ってできねーだろ

514 ：デフォルトの名無しさん：2008/02/01(金) 00:37:09

え？

515 ：デフォルトの名無しさん：2008/02/01(金) 00:37:34

long long とか名前長くしてどうするよ。

516 ：デフォルトの名無しさん：2008/02/01(金) 00:42:24

long long は既にあるべよ。long_long_long とかにしようべ。

517 ：デフォルトの名無しさん：2008/02/01(金) 00:44:20

>>515
C99にあるんですよlong long。
>>516
そうします。

518 ：デフォルトの名無しさん：2008/02/01(金) 00:47:19

long long ago むかーしむかし、あるところに長い長いアゴの男がおりましたとさ

519 ：デフォルトの名無しさん：2008/02/01(金) 00:50:58

_int64とはVC++くさいが、
VC++ .NET 2003からはlong longも使えるぞ。

520 ：デフォルトの名無しさん：2008/02/01(金) 00:51:20

中学の英語の授業中誰もが経験するであろうネタだな

521 ：デフォルトの名無しさん：2008/02/01(金) 00:53:43

>>516
別に知っとるが、_int64 の方が短くて分かりやすくていいじゃン

522 ：デフォルトの名無しさん：2008/02/01(金) 00:55:01

i8 u8 i16 u16 i32 u32 i64 u64
これでtypedefしとけば字数的にはint未満だ。何かとぶつかりそうだけどな。

523 ：デフォルトの名無しさん：2008/02/01(金) 00:55:52

そこで名前空間ですよ。

524 ：デフォルトの名無しさん：2008/02/01(金) 00:55:54

以下（8bitのみ未満）の間違い。

525 ：デフォルトの名無しさん：2008/02/01(金) 00:56:53

my_primitive_type::u64

なげーよ。

526 ：デフォルトの名無しさん：2008/02/01(金) 00:59:03

だから、自分のプログラム全体を特定の名前空間内に入れて、
そこで i8 とか定義しとけば何も付けなくて大丈夫。

527 ：デフォルトの名無しさん：2008/02/01(金) 02:14:27

stdintはC++の標準に入ったんだっけか
intN_tな連中。

528 ：デフォルトの名無しさん：2008/02/01(金) 02:18:41

_tてなんかの略？

529 ：デフォルトの名無しさん：2008/02/01(金) 02:30:24

type

530 ：デフォルトの名無しさん：2008/02/01(金) 02:47:05

>>527
最新のドラフトに cstdint と stdint.h が載ってた。次の改訂 (C++0x) で入るみたいだね。

531 ：デフォルトの名無しさん：2008/02/01(金) 06:38:05

C++0xはC99の(ほぼ)上位互換になるんですか
それともC99で使えてもC++0xではサポートされない機能もあり?

532 ：デフォルトの名無しさん：2008/02/01(金) 07:22:07

コンパウンドリテラルとか
配列個数に変数使うとか
そういうのは C++0x で無視

533 ：デフォルトの名無しさん：2008/02/01(金) 07:24:48

restricted ポインタとか色々無視されてる。

534 ：デフォルトの名無しさん：2008/02/01(金) 07:54:32

「配列の要素数に変数」はSTLと相性悪すぎだからな。

535 ：デフォルトの名無しさん：2008/02/01(金) 08:29:10

>>534
kwsk

536 ：デフォルトの名無しさん：2008/02/01(金) 09:01:10

コンパイル時に型が決まらない、だっけ？

537 ：デフォルトの名無しさん：2008/02/01(金) 13:51:10

type* v = new type[n]; ... delete[] v;

の糖衣構文にしてくれるだけでいいのに。

538 ：デフォルトの名無しさん：2008/02/01(金) 16:33:28

stlportsは2008には使えないの？

539 ：デフォルトの名無しさん：2008/02/01(金) 16:49:23

>>538
STLPort はインストーラ(make)が VS2008 にまだ対応していない。
手動でインストールするなら可能らしい。STLport VS2008 でググレ。俺はまだ試していないので、試したら結果を教えてくれ。

540 ：デフォルトの名無しさん：2008/02/01(金) 17:54:00

>>538
iostream使うとC2487がいっぱい出るよ

541 ：デフォルトの名無しさん：2008/02/01(金) 18:14:05

っ _STLP_STATIC_CONST_INIT_BUG

542 ：デフォルトの名無しさん：2008/02/02(土) 01:05:39

>>537
std::vector で何が不満なのさ？

543 ：デフォルトの名無しさん：2008/02/02(土) 01:06:58

見た目が汚い

544 ：デフォルトの名無しさん：2008/02/02(土) 01:09:31

はぁ？

545 ：デフォルトの名無しさん：2008/02/02(土) 01:21:27

std::vector<double> v(i);

と

double v[i];

なら下の方が綺麗だろう。

２次元配列とかなるともうキモいったらありゃしない。

546 ：デフォルトの名無しさん：2008/02/02(土) 03:43:09

エェー

547 ：デフォルトの名無しさん：2008/02/02(土) 04:00:52

valarray使えや

548 ：デフォルトの名無しさん：2008/02/02(土) 07:03:42

[i] はキモいだろ。どんだけ使い込んでるんだよ。

(i) これは正常。むしろ性情。

549 ：デフォルトの名無しさん：2008/02/02(土) 07:29:17

少し、頭冷やそうか

550 ：デフォルトの名無しさん：2008/02/02(土) 08:16:48

　　(O)　＜くぱぁ
　　╋　　　　　　　
　　/＼　　　　　　　　　　　　　　　　

551 ：デフォルトの名無しさん：2008/02/02(土) 11:50:57

>>548
FORTRAN か BASIC ばっかつかってるからそうなるんだ。

552 ：デフォルトの名無しさん：2008/02/02(土) 12:08:05

>>546 は
double v[i][j];
より
std::vector< std::vector<double> > v(i, std::vector<double>(j));
や
std::vector< std::vector<double> > v(i);
std::for_each(v.begin(), v.end(), std::bind2nd(std::mem_fun_ref(&std::vector<double>::resize), j));
の方が美しいと感じるようだ。

553 ：デフォルトの名無しさん：2008/02/02(土) 12:21:14

どうしても知識をひけらかしたい奴がいるようだ。

554 ：デフォルトの名無しさん：2008/02/02(土) 12:29:59

馬鹿か？
typedefしろよ

555 ：デフォルトの名無しさん：2008/02/02(土) 12:30:33

あんまりしょうもないtypedefたくさん作らないで欲しいお…

556 ：デフォルトの名無しさん：2008/02/02(土) 12:35:53

グローバルスコープでないならまだ許せる

557 ：デフォルトの名無しさん：2008/02/02(土) 12:50:03

typedef vector<int> vector_int;
typedef vector<double> vector_double;
…

こんなのがtypedefs.hに延々ならんでるソースを見せられたときは会社やめようかと思った。
結局1年しか勤めなかったけど･･

558 ：デフォルトの名無しさん：2008/02/02(土) 13:15:32

>>557
なにがあかんねん

559 ：デフォルトの名無しさん：2008/02/02(土) 13:17:39

>>558
いみないやん

560 ：デフォルトの名無しさん：2008/02/02(土) 13:18:26

まぁ普通意味を考えて命名するよな

#define VALUE_100 100

て定義する様なもの

561 ：デフォルトの名無しさん：2008/02/02(土) 14:29:30

>>557
そのレベルだと好みが分かれそうだなあ
vector<string> string_list
とかはありがちだけど。intとはな。。

562 ：デフォルトの名無しさん：2008/02/02(土) 14:32:11

vectorなのにlist?

563 ：デフォルトの名無しさん：2008/02/02(土) 14:36:40

>>561
そういう問題じゃない。

・typedef名に意味付けがない
↓のようなコメントと通じるものがある
a += 100; // aに100を足す

・字数がほとんど変わらず、打鍵数減少につながらない

…ところで、あなたは list<string>をどのようにtypedefするの？

564 ：デフォルトの名無しさん：2008/02/02(土) 14:39:41

んなマジレスされても。。名前考えんのめんどうだからしないねくらいだが

565 ：デフォルトの名無しさん：2008/02/02(土) 14:48:34

557に意味がないわけじゃないけどな。

typedefされた型しか使わないというのは、
互換性を重視するときは有利になる。

566 ：デフォルトの名無しさん：2008/02/02(土) 14:51:03

>>565
具体的にどんな移植性の問題が typedef によって解決されるんでしょうか？

567 ：デフォルトの名無しさん：2008/02/02(土) 14:54:21

>>565
typedefはそういう用途に使えることは否定しないけど、
vectorもintも標準の一部だから、互換性の点でもtypedef vector<int> vector_int;とする意味は無いんじゃないの。

568 ：デフォルトの名無しさん：2008/02/02(土) 14:55:54

>>566
typedefが移植性のためにあるようなものなのにな。
なぜなにの子供か？

569 ：デフォルトの名無しさん：2008/02/02(土) 14:56:04

もしかしてあれか？ int のサイズが違う環境では
typedef vector<long> vector_int;
に置き換えて「すっきり解決」とか、そういう話か？

570 ：デフォルトの名無しさん：2008/02/02(土) 15:01:04

intのサイズ違いをそのレベルで解決すべきじゃない。

571 ：デフォルトの名無しさん：2008/02/02(土) 15:03:50

つsize_t/off_t

572 ：デフォルトの名無しさん：2008/02/02(土) 15:05:24

だからやっぱり vector_int は意味無いだろ >565

573 ：デフォルトの名無しさん：2008/02/02(土) 15:31:24

std:: を省略できれば打鍵数が結構減る。

574 ：デフォルトの名無しさん：2008/02/02(土) 17:22:02

打鍵数とかでなく、会社からSTLは一律typedefせよ　の命題が
課せられれば、vector_int みたいなものは生まれるし、それでもよいと思うぞ。

だから >>557 がどうこう言う程の問題ではないと思われるが。
こういうのは出たての若いのによくいる自分は社内でも皆よりよく分かってる　と
思いこんでる井の中の蛙ってこった。

575 ：デフォルトの名無しさん：2008/02/02(土) 17:31:06

std::foreachとかどうやってtypedefするの？

576 ：デフォルトの名無しさん：2008/02/02(土) 17:34:44

>>574
そんな命題を甘んじて受けるほど奴隷ではありません。

577 ：デフォルトの名無しさん：2008/02/02(土) 17:35:12

>>574
その通り、会社の方針なら勤めてる以上は従わざるを得ないのは言うまでもない。

そこで、無能だったり考え方の一致しなかったりする上司の下で働く羽目になった場合に取り得る行動は、
我慢して働きつづけるか、さっさと辞めるかの二者択一で、>>557は後者を選んだだけだろ。
別に非難されるようなことではない。

578 ：デフォルトの名無しさん：2008/02/02(土) 17:36:14

>>574
それは無能なプログラマが無能な会社に変わっただけで、>>557の判断には影響ないだろｗ

579 ：デフォルトの名無しさん：2008/02/02(土) 17:39:09

>>576
それで問題が発生したとき責任取って解決できるのなら
それでも良いんじゃね？　いざとなったら逃げるのはただの口だけ君。

580 ：デフォルトの名無しさん：2008/02/02(土) 17:43:00

vector<vector<vector<int> > >みたいなものを書かざるをえない状況なら
vector<T>をtypedefすることもあるんじゃないかな？

581 ：デフォルトの名無しさん：2008/02/02(土) 17:43:44

>>579
会社の命令に背いて問題を起こすなんて選択肢はもとからないよ

常識があれば、「従う」と「去る」の二択しか取れない

582 ：デフォルトの名無しさん：2008/02/02(土) 17:43:51

そんな当たり前の事言われましても。

583 ：デフォルトの名無しさん：2008/02/02(土) 17:48:52

>>566
このケースでvector<int>は必要なかったとしても、
list<string>はtypedefしたほうがいい。
とすれば、必要あるなしの境界はどこで切る？

こういう皆が使って判断の微妙な境界線は、
「一律typedef」が安全。

584 ：デフォルトの名無しさん：2008/02/02(土) 17:53:28

STLって型によらずアルゴリズムを記述できるような抽象化を
目指して作られてるはずなのに、ソースはtypedefだらけ。
それを異常と感じないほうがおかしい。

585 ：デフォルトの名無しさん：2008/02/02(土) 17:55:26

抽象的な書き方をしない箇所もある。適切にtypedefすることには何の問題もない。

586 ：デフォルトの名無しさん：2008/02/02(土) 18:03:04

そもそもどういう理由でtypedefしてるの？

587 ：デフォルトの名無しさん：2008/02/02(土) 18:04:36

>>584
抽象化するためにtypedefが必要だったりするし、STLなんかtypedefだらけだけど？

588 ：デフォルトの名無しさん：2008/02/02(土) 18:12:31

>>581
まぁね。　ドラマのまねっこで「僕はそんなことはできません」なんて
楯突いてその後その人間同士が上手く行くことなんてまぁないからね。
ドラマはご都合主義だから上手くいくけどさｗ

589 ：デフォルトの名無しさん：2008/02/02(土) 18:17:26

>>588
自分も会社の一員だけどね。そういうこだわりのない人間が集まってるから駄目な会社になったとも言える。

590 ：デフォルトの名無しさん：2008/02/02(土) 18:17:50

>>574
仕事ってオブジェクト(?)をもっと理解した方がいいよ。

逆に考えて、君がお客で奴隷とかいうのが車屋の店員だったとする。
君は赤色の車を注文した。　しかし店員は「いやいまのトレンドは白です。
そこは譲れません」　と言ってるのと大して変わらん。

591 ：590：2008/02/02(土) 18:21:36

アンカー違い　>>576 へ訂正

592 ：デフォルトの名無しさん：2008/02/02(土) 18:24:24

本日の課題

授業単元：コンピュータ理論
課題：本字の流れをvectorとlistを使って表しなさい。但しtypedefは使わないものとする。

593 ：デフォルトの名無しさん：2008/02/02(土) 18:27:27

販売拒否も車屋の勝手だろ
それで商売になるならそれでいいし、ならないなら別のことをするだけだ
意に反して赤い車を売らされることはない。もちろん妥協して赤い車を売ってもいい

594 ：デフォルトの名無しさん：2008/02/02(土) 18:33:44

>>590
それは違うだろ

595 ：デフォルトの名無しさん：2008/02/02(土) 18:43:17

>>593
おまえ尾崎豊の歌大好きだろ？ｗ

596 ：デフォルトの名無しさん：2008/02/02(土) 18:59:03

>>595
ほとんど聴いたことすらないｗｗ

597 ：デフォルトの名無しさん：2008/02/02(土) 19:31:33

typedef厨いる？

598 ：デフォルトの名無しさん：2008/02/02(土) 19:42:18

まあたいして責められてるわけでもないのに
いきなり奴隷なんて言葉を使い出す輩とは
あまり議論もしたくないな、おれは。
どこぞのウィルス流してつかまったヤツを想起してしまうよ。

599 ：デフォルトの名無しさん：2008/02/02(土) 19:49:14

>>587
それは抽象化とはいわん。単なる簡略化。
型の違いを意識の外に放り出してしまえるのが本来の抽象化。
現実はその逆。

600 ：デフォルトの名無しさん：2008/02/02(土) 19:49:59

個人でやってる分にはいいが、人が動かせない大きな岩(ﾌﾟﾛｼﾞｪｸﾄ)を
動かすには、全員が力合わせて同じ方向に綱引かないと成功なんか
ないよね。　俺は反対に引きたい　とか関係ねーよ。
社会の歯車とかTVで憶えた訳分からん言葉に流されるべからず。

601 ：デフォルトの名無しさん：2008/02/02(土) 19:54:16

>>599
std::binary_functionの中とかでやってるtypedefはどう考えても抽象化のためだろ？

602 ：デフォルトの名無しさん：2008/02/02(土) 19:56:43

>>600
本心は別だろ？ｗ
マが鬱になる原因はそういうところが始まりなんだよ？

603 ：デフォルトの名無しさん：2008/02/02(土) 19:58:08

>593
本当は「会社として金を儲けるにはどうすりゃいい」というのに従うべきなんだけどな。
車売って利益上げるのが商売なんだから。

>586
色々。主に抽象化と手抜き。一例として
template<template<class>class trail_t>
struct Policy {
typedef trail_t<Policy<trail_t> > Trail;
// (snip)
};
template<class policy_t> // Policyの派生型を取り込むことを想定
class S {
typedef policy_t Policy;
typedef policy_t::Trail Trail;
// Trailをバンバン活用
};

といった感じで手が抜ける。

604 ：デフォルトの名無しさん：2008/02/02(土) 19:58:17

>>601
使ったこと無いから知らん
それにここまでの話の流れじゃはそういうとこじゃないだろ

605 ：デフォルトの名無しさん：2008/02/02(土) 19:59:30

俺は、木しか見ていない>>557より、森も見ている会社の
typedefs.hの方が賢いと思う。

606 ：デフォルトの名無しさん：2008/02/02(土) 19:59:50

ミス
それにここまでの話の流れじゃそういうとこじゃないだろ
↑typedef乱用のところな

607 ：デフォルトの名無しさん：2008/02/02(土) 20:00:42

>>604
使ったことないのね。了解。

608 ：603：2008/02/02(土) 20:01:43

ごめん。policy_tはPolicyの派生型じゃ無いわな。

609 ：デフォルトの名無しさん：2008/02/02(土) 20:19:10

>>602
本心は当然別よ。　本来人の考えが一致するなんて奇蹟ぐらいの考えで丁度いいよ。
映画あらしのよるに　で上手く分かりやすく描かれてるよ。羊と狼が友情築くｱﾆﾒ風のやつ。

610 ：デフォルトの名無しさん：2008/02/02(土) 20:37:17

typedefs.h には元々プロジェクトの成功を見ていた２人の心を分かつ効果もありそうだ。

611 ：デフォルトの名無しさん：2008/02/02(土) 21:14:32

つうかコンテナをvectorからdequeに変えたくなった時や
intじゃなくて複素数入れたくなった時に

vector_int

じゃカコワルイだろ

612 ：デフォルトの名無しさん：2008/02/02(土) 21:18:35

おまいらソフトウェアプロジェクトマネジメントの本を読んでみ。「ピープルウェア」とか。
>600を実現するためにどれだけの苦労が必要かがわかる。
あくまでマネージャー視点だけど、プログラマ側からするとマネージャーの資質を
測るのに良いヒントになるよ。
ついでに「デスマーチ」もドゾー。現実は厳しいということを教えてくれる古典的名著。

613 ：デフォルトの名無しさん：2008/02/02(土) 21:19:56

そんな話はマ板でやれよ

614 ：デフォルトの名無しさん：2008/02/02(土) 21:20:00

>611 変えない……というのは冗談として。
そんときはリファクタリングじゃね？名前総取っ替えだろうね。

615 ：デフォルトの名無しさん：2008/02/02(土) 21:21:41

>613 だったら>603にコメント入れろよ。放置されてバカみたいだろ。
他のtypedefの使いかたでも良いよ。

616 ：デフォルトの名無しさん：2008/02/02(土) 21:27:10

だから vector_int には意味がなくて

typedef int Code;

typedef std::vector<Code> CodeList;

とか

typedef std::vector<Code> CodeSequence;

とかにしたほうが良いんじゃないのって言うのが良識のあるプログラマの意見じゃないかな

617 ：デフォルトの名無しさん：2008/02/02(土) 21:29:19

このスレでまともにSTLの話をしているのを見たことがない俺

618 ：デフォルトの名無しさん：2008/02/02(土) 21:35:25

文字コードの次はtypedefかお

619 ：デフォルトの名無しさん：2008/02/02(土) 21:40:05

で、赤い車は買えたの？

620 ：デフォルトの名無しさん：2008/02/02(土) 21:48:46

というか、おまいらTemplate使ってる？
Policyは非常に強力なコンセプトだと思うんだがね。

本当はもっと制約の少ないMix-in機能が欲しいけどね。
Policy同士で相互依存があると破綻しがちだから、けっこう設計が面倒。

621 ：デフォルトの名無しさん：2008/02/02(土) 21:49:24

>619
あぁ、早速それ乗って近くの本屋にEffectiveSTL買いに行く予定だよ

622 ：デフォルトの名無しさん：2008/02/02(土) 22:12:32

>>620
アレキサンドレスクの受け売りですか？

623 ：デフォルトの名無しさん：2008/02/02(土) 22:20:19

メイヤーズもヴァンデヴォーデも質問したら
ちゃんと返事くれるんだな。できる人は違うわ。

624 ：デフォルトの名無しさん：2008/02/02(土) 22:20:59

>>620
相互依存のあるPolicyなんて思い浮かばないんだけど
具体的にどんなの？

625 ：デフォルトの名無しさん：2008/02/02(土) 22:23:26

あれってヴァンデヴォーデって読むのか……

626 ：デフォルトの名無しさん：2008/02/02(土) 22:23:56

>622 基本的にはそんな感じなんだけど、Policyの組替えを想定してるんじゃなくて
単にデカいクラスのモジュール化をするときに使ったりしてる。

本当は包含とかでも何とかなるんだけどねぇ。
委譲関数書かなくて良いのが素敵なんで何となくポリシー使ってる。

627 ：デフォルトの名無しさん：2008/02/02(土) 22:26:16

>>625
いや適当

628 ：デフォルトの名無しさん：2008/02/02(土) 22:27:48

>624
もちろんきっちり設計してから組めば相互依存はほとんど無くすことができるんだけど、
トライ＆エラーで設計するときはそんなこと言ってられないからね。
ルーズに始めるときは、たいてい相互依存バリバリだったりする…………

リファクタリングするときも相互依存した状態を経由するから、そういうときも不便。

629 ：デフォルトの名無しさん：2008/02/02(土) 22:32:02

orthogonalってやつか

630 ：デフォルトの名無しさん：2008/02/02(土) 22:43:00

>629
直交に分離するのは理想だけど、神様でもなければ一発でそんなに上手く行くわきゃ無いよな。

631 ：デフォルトの名無しさん：2008/02/05(火) 08:39:38

std::map<T1, T2>をT2順に整列したものを使いたいんだけど、std::vector<std::pair<T1, T2> >に
コピーしてsortする方法だと、std::pair<T1, T2>が大きい時にコストがかかるのでイヤーン。
mapの要素へのポインタをvectorに格納してsortしたいんだけどうまくいかない。
std::vector<const std::pair<T1, T2>*>みたいの。
エロい人サンプルコード書いてくだちい。

632 ：デフォルトの名無しさん：2008/02/05(火) 09:21:28

const pair<const int, int>* addressof(const pair<const int, int> &obj)
{
return &obj;
}

map<int, int> m;
m[0] = 3;

vector<const pair<const int, int>*> vec;
transform(m.begin(), m.end(), back_inserter(vec), addressof);

こんな感じ？

633 ：デフォルトの名無しさん：2008/02/05(火) 20:54:58

ありが㌧。
でもソートも書いて欲しいよﾏﾏﾝ

634 ：デフォルトの名無しさん：2008/02/05(火) 22:28:39

>633
そんな難しくもなさそうな気もするけど、まずはうまくいかなかったコードを書いてみれば？

635 ：デフォルトの名無しさん：2008/02/05(火) 22:39:37

というか std::sortにbool op( const int *l, const int *r) { return *l<*r;}
を渡せば終わる話だからなー

636 ：デフォルトの名無しさん：2008/02/05(火) 22:44:01

pair だからそれだと足りない。けどまぁその程度ではあるんでどういうところでつまるのかな、という方に興味があったり。

637 ：デフォルトの名無しさん：2008/02/05(火) 23:10:39

こんなのは？意味違うかもしれんが。

typedef map<int, string> Mymap;

struct Mycomp {
　bool operator()(const pair<const int, string>* p1,
　　　　　　　　　 const pair<const int, string>* p2) {
　　return p1->second < p2->second;
　}
};

int main()
{
　Mymap m;
　//いろいろ挿入
　
　vector<pair<const int, string>* > vec;
　for(Mymap::iterator i = m.begin(); i != m.end(); ++i) {
　　　　vec.push_back(&(*i));
　}

　sort(vec.begin(), vec.end(), Mycomp());

}

638 ：デフォルトの名無しさん：2008/02/05(火) 23:15:32

sort_inserterみたいの作れば挿入とソートが一発で。コスト的にはあんまり美味しくないか。

639 ：デフォルトの名無しさん：2008/02/06(水) 00:02:14

>>638
それなんてstd::set?

640 ：デフォルトの名無しさん：2008/02/06(水) 00:15:23

>>639
pairのsecondだけでソートってできるんだっけ？

641 ：デフォルトの名無しさん：2008/02/06(水) 00:18:18

あー失礼、compare指定すりゃいいだけだ。

642 ：デフォルトの名無しさん：2008/02/09(土) 11:47:37

vectorで使用したメモリ領域を開放する方法を教えてください。

vector<int> v;
v.reserve (100000);

ぐらいの領域を使った後

v.clear ();
cout << "capacity = " << v.catacity() << "\n";

capacityが100000を返してくるのですが、どうやって領域を開放したらいいのでしょうか？
v自体はまだ使うので消したくありません。

643 ：デフォルトの名無しさん：2008/02/09(土) 11:54:07

vector<int>().swap(v);

644 ：642：2008/02/09(土) 12:01:01

>>643
できた。ありがとう！お前まじ天才
さしつかえなければ、何をどうやって勉強すればお前みたいになれるのか教えてください。

645 ：デフォルトの名無しさん：2008/02/09(土) 12:03:27

とりあえず

つ"Effective STL"

646 ：642：2008/02/09(土) 12:08:50

買った。
これを読んで俺も天才になる

647 ：デフォルトの名無しさん：2008/02/09(土) 12:31:42

天才って言葉の使い方間違ってる

648 ：デフォルトの名無しさん：2008/02/09(土) 13:05:16

むしろ転載に近いよな。

649 ：デフォルトの名無しさん：2008/02/09(土) 13:29:09

メイヤーズSTLはジョスティスの内容をパクってるものが多い。

650 ：デフォルトの名無しさん：2008/02/09(土) 16:10:30

で　っていう

651 ：デフォルトの名無しさん：2008/02/09(土) 17:58:50

その本にじょてぃすすげー参考にしたって書いてあったから
じょてぃす買った俺が通りますよ。
じょてぃすは絶版になるべきではなかった。

652 ：デフォルトの名無しさん：2008/02/09(土) 18:19:14

>>651
原書を読み漁ったおれもいますよ。平易な英語だから無問題。

653 ：デフォルトの名無しさん：2008/02/09(土) 19:24:52

Vandevoorde も忘れないでね。

654 ：デフォルトの名無しさん：2008/02/09(土) 19:50:38

>>653
TemplateならあるがSTLの本なんて書いてたっけ？

655 ：デフォルトの名無しさん：2008/02/09(土) 20:56:21

お前ら日本語でしゃべれ

656 ：デフォルトの名無しさん：2008/02/10(日) 02:11:51

よし今回だけだぞ

657 ：デフォルトの名無しさん：2008/02/11(月) 07:54:08

>643 の方法だとstd::stringには効果無いのですが、
stringの場合は明示的にメモリ解放する手段て無いのでしょうか？

658 ：657：2008/02/11(月) 08:06:11

すみません、VC2005のstd::stringだと、作成した
直後の状態である程度のバッファが確保されてるだけでした。

659 ：デフォルトの名無しさん：2008/02/14(木) 09:50:34

STLにTStringListみたいなのありましたっけ？

やっぱ、
＞std::vector <std::string>
ですか？

660 ：デフォルトの名無しさん：2008/02/14(木) 09:53:14

>>659
うん。 TStringList という名前だけ見ると、どちらかといえば std::list<std::string> かと。

661 ：デフォルトの名無しさん：2008/02/14(木) 10:03:11

有難う。

実は、vectorしか使ったことないのです。listとvectorの違いを知りたいです。

662 ：デフォルトの名無しさん：2008/02/14(木) 10:06:33

事故解決しました。
記述は大差ないみたいですね。
実行効率とメモリの違いみたいな。

ttp://ml.tietew.jp/cppll/cppll_novice/article/269

663 ：デフォルトの名無しさん：2008/02/14(木) 13:05:03

大差ある。

664 ：デフォルトの名無しさん：2008/02/14(木) 17:07:51

vector
ランダムアクセス可能。
メモリが連続している。

list
ランダムアクセスできない。
当該要素のerase以外で参照・イテレータが無効化されない。（個人的にはこれが一番重要）
任意位置への挿入・削除が定数時間。
独特な操作（spliceなど）がある。

選択する上で気をつけるのはこんなとこか？

665 ：デフォルトの名無しさん：2008/02/14(木) 17:20:05

なるほど、どうも有難うございます。

選択って意味では、
vector と list を間違えるより、
vector と map（←これもまだ使ったこと無いｗ）を間違えたら大変な気がしました。

666 ：デフォルトの名無しさん：2008/02/14(木) 18:24:34

いや、vector使うつもりでlistつかうよりmap使った方が多分マシだぞ

667 ：デフォルトの名無しさん：2008/02/14(木) 19:46:00

そもそもコンテナに何を求めているかによる。
連続性が重要ならlistもmapも同じくらい散々な目に遭うし、一応コンパイルが通ればいいだけなら
vectorでもmapでも問題ない。

668 ：デフォルトの名無しさん：2008/02/14(木) 21:59:15

ポインタつなげて線形リンクリスト作らされたことってないの？

669 ：デフォルトの名無しさん：2008/02/14(木) 22:17:35

>>668
標準ではないがstd::slistってのがある。

670 ：デフォルトの名無しさん：2008/02/14(木) 22:56:57

>>669
std::listだって線形リンクリストでしょ。双方向であるというだけで。

671 ：デフォルトの名無しさん：2008/02/15(金) 01:50:44

std::list って単方向じゃなかったけか？

672 ：デフォルトの名無しさん：2008/02/15(金) 01:53:08

いいえ。

673 ：デフォルトの名無しさん：2008/02/15(金) 01:53:10

あ、ごめ。双方向だった・・・
よく考えたら reverse_iterator 使えるもんね。

674 ：デフォルトの名無しさん：2008/02/15(金) 02:14:36

連続性が要らないなら、vectorよりdequeつかっとけって誰かえらいひとが
言ってた気がする

675 ：デフォルトの名無しさん：2008/02/15(金) 02:36:37

要素数が万単位にならなければlistよりvectorつかっとけって誰かえらいひとが
言ってた気がする

676 ：デフォルトの名無しさん：2008/02/15(金) 02:41:25

つ http://www.codeproject.com/KB/stl/vector_vs_deque.aspx

677 ：デフォルトの名無しさん：2008/02/15(金) 03:13:20

>>676
dequeメチャメチャ速いやん

678 ：デフォルトの名無しさん：2008/02/15(金) 03:35:20

むしろvectorがいらない子だろう

679 ：デフォルトの名無しさん：2008/02/15(金) 07:49:19

オブジェクトのサイズ/要素数が大きくない場合
listはvectorに比べてアロケーションの多さと断片化が弱点になりそうだよね

680 ：666：2008/02/15(金) 08:45:44

なるほど、今までvectorのみ使ってましたがmapにトライしてみます。

というより、実はネットで拾ったライブラリがmap使ってて、初期化宣言見ただけで”えっ”と思ってもう理解するの必須。

vectorの連続性って、普通の変数配列みたいにメモリがばっとコピーしても大丈夫なんですよね？
何度も文献とかで確認しましたが、結局怖くて１つ１つイテレーター参照してますが。

ところで、map使うとプライマリキーみたいなのが必須ですよね？
キーがいる場合にはピッタリですが、開発途中でやっぱキーいらね、とかなったら、
とりあえず連番で埋めとけば良いわけですかね。
その時点でvectorかlistに差し替えかな。

>>668
線形リスト勉強しました。その頃C++どころかC初心者だったため、氏にました。
で、STLって何て便利なんだろう（これで使い方さえもう少し簡単であれば）って思ってまつ。

681 ：デフォルトの名無しさん：2008/02/15(金) 08:46:35

　↑
＞666

は間違いで、665です。

682 ：デフォルトの名無しさん：2008/02/15(金) 09:04:18

mapについてそんなふうに思ってる人は始めて見たｗ
データベースみたいな複雑なものじゃなくてただの写像ですよ。
電話帳みたいな何かと何かの対応表だと思えばいい。
パフォーマンスに関してはそれを理解してからでいいと思う。

>vectorの連続性って、普通の変数配列みたいにメモリがばっとコピーしても大丈夫なんですよね？
多分大丈夫だけどやる必要ないならやらないに越したものはない。

>その時点でvectorかlistに差し替えかな。
パフォーマンス以前に用途が違うのでそのとおり。

>で、STLって何て便利なんだろう（これで使い方さえもう少し簡単であれば）って思ってまつ。
便利さを追求した結果こうなったんだろう。
ただしその上で、できるだけ簡単にはなってると思う。

683 ：デフォルトの名無しさん：2008/02/15(金) 09:56:51

mapなんて連想配列ですよ。awk使いの私が言うんだから間違いありません。

＞>vectorの連続性って、普通の変数配列みたいにメモリがばっとコピーしても大丈夫なんですよね？
多分じゃなくて大丈夫だけど、memcpy()などを自分で使うのはお勧めしない。潜在的なバグの原因になりかねない。
APIに渡すなどのように、必要に迫られたときに限定した方がいい。

684 ：デフォルトの名無しさん：2008/02/15(金) 10:18:40

boostとかにTStringListに近いものがあったりしないでしょうかね？

685 ：デフォルトの名無しさん：2008/02/15(金) 10:38:33

そんな無駄なものはない

686 ：デフォルトの名無しさん：2008/02/15(金) 10:39:27

ま、StringListクラス宣言して、中の人にmultimapすれば、自分でメソッド作るだけですか。
車輪の再開発とか言われたら嫌だから、既にあるものをなるべく使いたいです。

687 ：デフォルトの名無しさん：2008/02/15(金) 10:40:46

コンテナに使われている例えば連想コンテナのデータ構造（平衡二分木）とか
に詳しい人いる？

688 ：デフォルトの名無しさん：2008/02/15(金) 10:42:54

>686
どんなことがやりたいの？

689 ：686：2008/02/15(金) 10:55:33

どちらかというと、やりたいことがあるのでなくて、移植作業のためにTStringListメソッド実装。

CommaTextの入出力、iniファイルの１行処理のためのValues/Namesプロパティ、IndexOf、ファイル入出力メソッド、要素文字連結 etc..

690 ：デフォルトの名無しさん：2008/02/15(金) 11:11:00

>>687
ここにそれなりに詳しく書かれてるよ
http://ja.wikipedia.org/wiki/%E8%B5%A4%E9%BB%92%E6%9C%A8

691 ：デフォルトの名無しさん：2008/02/15(金) 11:29:40

>>689
組み合わせて使えばできそうな気がする。

boost.lambda
boost.string_algo
boost.tokenizer

ファイル入出力はfstreamとalgorithm使えばよし。

692 ：デフォルトの名無しさん：2008/02/15(金) 12:48:59

typedef vector<int> vector_int;
を
typedef deque<int> vector_int;

に書き換えただけで、うちのソフトの体感速度が上がったｗ
処理速度アップ！ってバージョンアップ唄えるお( ^ω^)

693 ：デフォルトの名無しさん：2008/02/15(金) 13:02:15

＞typedef vector<int> vector_int;
＞typedef deque<int> vector_int;

kwsk
何が違うのか教えれ！

694 ：デフォルトの名無しさん：2008/02/15(金) 13:09:15

vectorに数万とかpush_backして再アロケートが発生しまくったんじゃないかと予想

695 ：デフォルトの名無しさん：2008/02/15(金) 13:11:54

その２つはメソッドは同じなの？

696 ：デフォルトの名無しさん：2008/02/15(金) 13:13:34

バッファの連続性が必要なくて、
確保すべきメモリ量が事前によく分からないなら、
vector より deque の方が圧倒的に効率的。

697 ：デフォルトの名無しさん：2008/02/15(金) 14:07:45

いままでboost::shared_ptrのコンテナにstd::listを使ってたけど
std::dequeにしたら速くなるのかな
でもスマポのコピーは時間かかりそうだな...

698 ：デフォルトの名無しさん：2008/02/15(金) 14:11:04

push_back のコストは list より deque の方が平均的には少ないはずだが

699 ：デフォルトの名無しさん：2008/02/15(金) 14:16:41

mapってシーケンシャルアクセス、かつ、入れた順番に取り出す、もできますか？

700 ：デフォルトの名無しさん：2008/02/15(金) 14:18:42

もっと詳しく

701 ：デフォルトの名無しさん：2008/02/15(金) 14:20:57

mapをbeginからendまで参照した場合、
順番は、mapに登録した順番になっててくれますか？

702 ：デフォルトの名無しさん：2008/02/15(金) 14:23:46

>>699
入れた順番は失われる

703 ：デフォルトの名無しさん：2008/02/15(金) 14:24:29

>>701
Sort Criterionによる

704 ：699：2008/02/15(金) 14:27:50

＞Sort Criterionによる

kwsk
ググっても出ません。

705 ：デフォルトの名無しさん：2008/02/15(金) 14:30:43

map<string, int> m;
m["foo"] = 0;
m["bar"] = 1;

と、

map<string, int> m;
m["bar"] = 1;
m["foo"] = 0;

で異なる挙動になるようにしたいって事だろ？
標準のmapではどうやっても不可能だと思う

706 ：699：2008/02/15(金) 14:35:07

え”～ショック。

つまり、並び順が保障されるのは、vectorとdequeだけですかぁ。

707 ：デフォルトの名無しさん：2008/02/15(金) 14:37:31

だってmapはシーケンスコンテナじゃないし

708 ：デフォルトの名無しさん：2008/02/15(金) 14:42:34

>>704
テンプレートパラメータかオブジェクトととして渡す
ソート基準による。

709 ：699：2008/02/15(金) 14:47:40

じゃ、mapはやめて、vectorします。

vectorのヘルプ見てると、pos番目の要素をとるには[pos]ではなくて、at(pos)を使えと書いてありますね。

atを使わずに[]を使ってると、dequeに置き換えが出来なくなるわけでしょうか？

710 ：デフォルトの名無しさん：2008/02/15(金) 14:48:47

operator[]は範囲チェックをしないけどatはする
違いはそれだけ

dequeにもoperator[]はあるから、その心配は要らない

711 ：デフォルトの名無しさん：2008/02/15(金) 16:19:32

ごめん。未だに
「Associative Containerじゃ駄目なんですか。じゃあSequenceにします」
が簡単に出来る場面というのが想像できない

712 ：デフォルトの名無しさん：2008/02/15(金) 16:29:56

線形探索しても痛くないときとか

713 ：デフォルトの名無しさん：2008/02/15(金) 17:07:05

>>695 >>709
>>676のリンク先にも書いてあるけど、vectorとdequeのメンバ関数の違いは
・vectorにだけある……capacity() reserve()
・dequeにだけある……push_front() pop_front()
だけ。

いずれもメモリの連続性に関わるもので、前者が「あらかじめ確保しておく」系（dequeには要らない）、
後者が「先頭要素を出し入れする」系（vectorには高コスト過ぎ）。

714 ：695：2008/02/15(金) 17:11:30

ｻﾝｸｽ。

STLってｷﾓｶﾜｲｲね。

715 ：デフォルトの名無しさん：2008/02/15(金) 17:31:49

個人的にはlistがいらない子のようなきがしてます

716 ：デフォルトの名無しさん：2008/02/15(金) 17:40:48

dequeにはspliceが無いだろ？

717 ：デフォルトの名無しさん：2008/02/15(金) 17:46:29

listはアロケータさえちゃんと作れば、本当はやれば出来る子

718 ：デフォルトの名無しさん：2008/02/15(金) 17:54:59

vectorはお金がかかる子。

vector（笑）

719 ：デフォルトの名無しさん：2008/02/15(金) 18:11:05

vectorとdequeの最大の違いは、stackコンテナでdequeがデフォルト
コンテナとして使われてることを見ればわかるね。メモリ構造の違い
によってvectorは要素を削除した場合に絶対にメモリを解放しないが
dequeはチャンクの集まりだから不要なチャンクは解放されることが多い。
（これはstandardでは求められていないらしいが）
また、reallocateの際、vectorは全ての要素を移動する必要があるが
dequeは必ずしもそうはならない。同じ要素へのアクセスではvectorの
ほうが理論的には高速。dequeはメモリ構造上indirect accessとなるから。

このくらいしか気にしてないけど、結局は要素数と実測で決めることにしてる。

720 ：デフォルトの名無しさん：2008/02/15(金) 23:04:47

>>706
次期C++ではinsert(iterator, value)の意味が変わって、
同順の要素の間で好きな場所に値を挿入できるようになる。
それまではstd::map<Key, std::deque<T> >でも使うしかないね。

721 ：デフォルトの名無しさん：2008/02/15(金) 23:27:40

>>720
へぇ。知らなかった。

これか。
http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#233

722 ：デフォルトの名無しさん：2008/02/16(土) 00:04:14

メタプログラミングをゴリゴリやってる奴いないの？
STLを専ら使うだけ？

723 ：デフォルトの名無しさん：2008/02/16(土) 00:18:21

>>722
それはboostスレで。

724 ：デフォルトの名無しさん：2008/02/16(土) 12:16:37

C++/TemplateMetaProgramming専用スレってないの？

725 ：デフォルトの名無しさん：2008/02/16(土) 12:27:05

ないね。
欲しければ立てれば？

726 ：デフォルトの名無しさん：2008/02/16(土) 12:42:44

過疎りそうだけどな
TMPと言ったって大概はSTL、Boostの範疇だし

727 ：デフォルトの名無しさん：2008/02/16(土) 12:45:39

　　　　　　　　　　　　　ｒ､ﾉVV＾ｰ八
　　　　　　　　　　　　､^':::::::::::::::::::::::＾vｨ　　　　　　　､ヽ l / ,
　　　　　　　　　　　　　 l..:.::::::::::::::::::::::::::::ｲ　　　　　　= 　　　　=
　　　　　　　　　　　 |.:::::::::::::::::::::::::::::: |　　　　　ﾆ= 724そ　-=
　　　　　　　　　　　　　 |:r￢‐--─勹:::::|　　　　　ﾆ=　なれ　=ﾆ
　　　　　　　　　　　　　　 |:} _＿　､.＿｀}f'〉ｎ＿　　 =-　らで　-=
　　、､ l | /, ,　　　　　　 ,ﾍ}´`'｀｀　`´`　|ﾉ:::|.|　　ヽ　ﾆ　.：. も　ﾆ
　.ヽ　　　　　´´, 　　　　　,ゝ|、　､, 　　 l|ヽ:ヽヽ　　}　´r　　　ヽ｀
.ヽげき 724　ﾆ. 　　／|｛/ :ヽ　-=-　./| |.|:::::| |　　|　　´/小ヽ｀
=　てっ　な　 =ﾆ　／:.:.::ヽ､　　＼二／ :| |.|:::::| |　 /
ﾆ　く. と　ら　　-=　ヽ､:.:::::::ヽ､.＿､　　＿,ﾉ/.:::::| | /|
= 　れ.盛　　　-= 　ヽ､:::::::::＼､＿＿／::.z:::::.:| |' :|
ﾆ　るり　　　=ﾆ　　　| |:::::::::::::::::::::::::::::::::::.|'.:Y′ﾄ､
/,　：　上　　ヽ､　　 | |::::::::::::::::::::::::::::::::::::_:::::_::|　 'ﾞ, .＼
　/　　　　　ヽ、　　　 | |:::::::::::::::::::::::::::::::::::.|:::::::|.ﾄ､　　　＼
　 / / 小＼　　　 r￢|ﾉ::::::::::::::::::::::::::::::::::::::::::::::::|　＼

728 ：デフォルトの名無しさん：2008/02/16(土) 12:46:16

724だけど、立てたぞ。
http://pc11.2ch.net/test/read.cgi/tech/1203133502/

729 ：デフォルトの名無しさん：2008/02/16(土) 14:03:50

>>726
甘いな

730 ：デフォルトの名無しさん：2008/02/16(土) 18:04:09

TMPとSTLって全然ちがくね？

731 ：デフォルトの名無しさん：2008/02/16(土) 18:10:33

どっちかっつーと、非 STL 部分の方が TMP っぽいな。
char_traits とか。

732 ：デフォルトの名無しさん：2008/02/16(土) 20:53:06

iterator_traits

733 ：デフォルトの名無しさん：2008/02/16(土) 22:54:48

numeric_limits

734 ：デフォルトの名無しさん：2008/02/16(土) 22:55:47

std::advanceもTMPっていっていいの？

735 ：デフォルトの名無しさん：2008/02/16(土) 23:00:21

いいんじゃね？

736 ：デフォルトの名無しさん：2008/02/17(日) 13:45:21

vectorやdequeってさ、変更せず読み込みだけなら複数スレッドからアクセスしても
大丈夫ですか？

737 ：デフォルトの名無しさん：2008/02/17(日) 13:49:27

volatileつけとけ

738 ：デフォルトの名無しさん：2008/02/17(日) 14:49:07

誰も書かないならvolatileいらない

739 ：デフォルトの名無しさん：2008/02/17(日) 15:05:58

例えばVisual C++ならここに書いてある。ほかは知らないけど。
http://msdn2.microsoft.com/ja-jp/library/c9ceah3b(VS.80).aspx

740 ：デフォルトの名無しさん：2008/02/18(月) 14:53:30

MFCやVCLにある、StringOfChar って無いですか？
ある文字を指定個数分返してくれるメソッド。

741 ：デフォルトの名無しさん：2008/02/18(月) 15:08:12

string s(10, 'A');

742 ：デフォルトの名無しさん：2008/02/18(月) 15:09:32

thx!　>>741

あやうくfor文で回すところですた。

743 ：デフォルトの名無しさん：2008/02/18(月) 18:28:13

>>731
STLの中でメタプログラミングの要素があるのは
iterator_traitsとiterator_tagを使ったディスパッチくらいかな。

744 ：デフォルトの名無しさん：2008/02/18(月) 18:33:37

>>743
関数テンプレートのオーバーロードを利用した
ランダムアクセスとその他の振り分けか。
でもほとんど使ったことないなあ。

745 ：デフォルトの名無しさん：2008/02/18(月) 19:36:19

Vectorで、５番目の要素の次にデータを挿入したいときは、どう書きますか？

746 ：デフォルトの名無しさん：2008/02/18(月) 19:43:45

直接は使わなくても、advance とかで間接的には使ってる事ない？

747 ：745：2008/02/18(月) 19:44:02

既存の要素が４の場合と５の場合と、場合分けして、記述する必要があるのでしょうか？

748 ：デフォルトの名無しさん：2008/02/18(月) 19:46:41

既存の要素が１とかの時どうすんの？

749 ：デフォルトの名無しさん：2008/02/18(月) 20:07:40

>>745
std::vector なら v.insert(v.begin() + 5, value);
とかかな。要素数が最低5個は存在してないとマズイから。
v.size()で要素数調べる必要はあるか。

>>746
そういう意味では使うこともあるなあ。
本では読んだけど自分で書いたことはないな。

750 ：745：2008/02/19(火) 08:35:45

＞v.begin() + 5

あ、イテレーターって足し算できるんですね。
勉強になりました。

751 ：デフォルトの名無しさん：2008/02/19(火) 11:13:44

vectorのイテレータはランダムアクセス可能だからな。

752 ：745：2008/02/19(火) 11:15:48

では、vectorのイテレータだけが、＋－演算子定義されてるってことですか？
（dequeは無理と）

753 ：デフォルトの名無しさん：2008/02/19(火) 11:35:47

dequeもランダムアクセスイテレータなので+ - は定義されているよ

754 ：745：2008/02/19(火) 11:42:15

え”～、自分vectorのみ使ってるのに、それじゃvectorはやっぱり要らない子じゃん。

755 ：デフォルトの名無しさん：2008/02/19(火) 11:46:41

+や-ができないのは、たとえばlistとかsetの双方向イテレータ。
こいつらでは、インクリメントやデクリメントを繰り返す必要がある。
そんなときはstd::advanceなんていう関数が既に用意されている、もちろんO(N)。

vectorは、要素のメモリアドレスの連続が保障されているので、
組込の配列やmallocなんかで確保したメモリと同じように使えるという点が決定的にほかと違う。
例えばC用のAPIに渡すバッファなんかにも使える。

756 ：745：2008/02/19(火) 11:53:08

＞vectorは、要素のメモリアドレスの連続が保障されているので、

その通りなんですが、上レス読むと、やっぱふつーはイテレーター使えって逝われてるじゃん。

757 ：デフォルトの名無しさん：2008/02/19(火) 12:00:24

>>745-750

std::vector<int> v;
if (v.begin() + 5 > v.end()) v.resize(5);

を実行したら、VS2008 では Debug Assertion Failed! で落ちた。

v.end() を越えるような vector::itrator::opearator+() の結果に対して、
_SCL_SECURE_VALIDATE_RANGEマクロが範囲外を検出して例外を起こしている。
言いたいことはわかるが、融通利かせてほしい。

758 ：デフォルトの名無しさん：2008/02/19(火) 12:03:22

じゃ malloc的な使い方する時は、あえて
vector<int>って直書きしないとちょっと恐いな。

759 ：デフォルトの名無しさん：2008/02/19(火) 12:05:37

>>756
そうだから、vectorで要素へのポインタを使うのはchar*な引数に渡すなんて使い方くらいだね。

760 ：デフォルトの名無しさん：2008/02/19(火) 12:06:05

すまん、char*に限らず任意のT*でいいんだ。

761 ：デフォルトの名無しさん：2008/02/19(火) 12:13:51

>>757
組み込み配列だって要素数超える足し算は未定義動作なんだぜ。 assert() が
入ってる分ありがたいぐらいだ。

762 ：デフォルトの名無しさん：2008/02/19(火) 12:32:11

イテレータについて質問です。
イテレータをインクリメントするコストはコンテナによって違うと思うのですが、
STL解説サイトなどで、そのことについて触れているのをみかけません。
速度を知りたければ、実装毎にテストして計るしかないのでしょうか？

763 ：デフォルトの名無しさん：2008/02/19(火) 13:08:30

>>762
実際の速度(具体的な処理時間)を知りたいのならそれでいいんじゃね？
ソースやアセンブル結果を見て見当をつけても良いけど。

764 ：デフォルトの名無しさん：2008/02/19(火) 13:08:44

VC++2005で、
std::map<std::string,int> mp;
mp["key000"]=0;
とすると、「stringに>演算子がない」ってエラーが出るんだが、これって標準C++準拠の正しいエラーなのかな？
それともVC++2005のstringの方がおかしいのかな？

ネットで検索した時に普通にstd::stringをキーにしてるソースあったんで、問題ない書き方だとは思うんだが。

765 ：デフォルトの名無しさん：2008/02/19(火) 13:13:37

>>762
折角ソースがあるんだから読めばいいんじゃね?

766 ：デフォルトの名無しさん：2008/02/19(火) 13:18:50

>>764
標準準拠である確信は無いけど、g++-4.2.3では普通に使えた

767 ：デフォルトの名無しさん：2008/02/19(火) 13:31:04

>>764
VS2005でその二行を今書いているコードにペーストしてビルドしたけど、普通に通ったよ。

768 ：デフォルトの名無しさん：2008/02/19(火) 13:32:00

>>764
エラーメッセージを変に略さずに、そのまま晒したり Google に放り込むと、
なにか余計なことをしているのが見つかるかもしれない。

769 ：デフォルトの名無しさん：2008/02/19(火) 13:38:22

ヘッダincludeしてない時に出るメッセージに似てる…

770 ：デフォルトの名無しさん：2008/02/19(火) 13:38:42

>>764 ヘッダのincludeが足りてないのでは？

#include "stdafx.h"
#include <map>
#include <string>　←これをコメントアウトすると、「stringに>演算子がない」ってエラーが出る

int _tmain(int argc, _TCHAR* argv[])
{
std::map<std::string,int> mp;
mp["key000"]=0;

return 0;
}

771 ：764：2008/02/19(火) 13:45:41

早いレス㌧。
#include <string>が抜けてただけでした。
お騒がせして申し訳ないです。

772 ：762：2008/02/19(火) 14:07:09

>>763,765
どうもです。
ソース見て見当つけるの難しいですね(if文のコストとポインタ代入のコストの比率がどのぐらいになるのかとかさっぱりです)。
c++の制御文や演算のコストについて、本などでほとんど目にしないのですが、皆さんはどうやって勉強されました？

773 ：デフォルトの名無しさん：2008/02/19(火) 14:20:26

>>772
環境によって違うんだから、ある程度一般化せざるをえない本なんかで「勉強」するのは
無理だろ。

速度が要るプログラム組むときに、いろんなコードに対応するアセンブリを見て経験的に
身に付けるのがいいんじゃね？

環境が変われば結果が変わるということにも気をつけないといけない。

774 ：762：2008/02/19(火) 14:47:14

>>773
なるほど。
経験的に身につけていくしかないですか。
速度見積もるのに技術がいる上、環境で変わることを考えると、
速度はあまり気にせず、プロファイリングしてからボトルネックとなっている部分だけ考えるのがいいんでしょうね。

775 ：デフォルトの名無しさん：2008/02/19(火) 14:55:08

ばかすぎる

776 ：デフォルトの名無しさん：2008/02/19(火) 15:00:48

自己卑下ですか？

777 ：デフォルトの名無しさん：2008/02/19(火) 16:31:26

スパコンやx86-64のSSE2最適化の場合はvectorを使って、ベクトル化させたい場所はポインタに変換してる。
iteratorなんか使うと最適化してくれないし。

778 ：デフォルトの名無しさん：2008/02/19(火) 16:34:19

>>772
まあ、こういう細かい部分を気にするのは悪いことじゃないよね。
でもそれはC++の勉強ではなくて、ターゲット環境のしくみを先に勉強した方が良いよ。
CPUがC++で作ったコードをどう処理するのか、とかさ。
昔みたいにクロック数を数えれば分かるような簡単な時代じゃないけど、
その疑問に答えるためには、結局そのあたりの知識が必要だから。

779 ：デフォルトの名無しさん：2008/02/19(火) 17:38:29

スパコンでどんなソフト作ってんの？

780 ：デフォルトの名無しさん：2008/02/19(火) 17:59:00

>>777
やっぱり、本物の数値演算には valarray は使い物になりませんか？

781 ：デフォルトの名無しさん：2008/02/19(火) 18:00:28

下手にC++で書くよりMatlabで書いた方が早い

782 ：デフォルトの名無しさん：2008/02/19(火) 19:57:54

>>774
理論的な計算量のオーダーだけは気にしておいた方がいい。
O(N^2)の処理をやっている場所やO(N)の処理を繰り返す場所があったら
適切なコンテナやアルゴリズムを選定することを考えるべき。
結果的にはmapやsetを使うよりvectorを毎回検索、ソートした方が
速いというケースはあるけど、チューニングする以前のエイヤッと決める段階では、
理論的に速いアルゴリズムを選んでおいた方が無難。

783 ：デフォルトの名無しさん：2008/02/19(火) 21:41:57

>>780
つーか、C++自体が使い物にならなったりする。
ヌパコン屋はFortranしか本気でコンパイラを使ってない。

784 ：デフォルトの名無しさん：2008/02/19(火) 21:42:40

>>783
×使ってない
○作ってない

785 ：デフォルトの名無しさん：2008/02/19(火) 21:45:54

スパコンは並列化がキモだから、
並列化コンパイラの作りやすい Fortran を作りたがるのかもね。
言語仕様も単純で作りやすいし。

786 ：デフォルトの名無しさん：2008/02/19(火) 22:00:50

質問です。
vectorのイテレータが有効なイテレータかどうか調べる方法を教えてください。

787 ：デフォルトの名無しさん：2008/02/19(火) 22:04:23

質問です。
ポインタが有効なポインタかどうか調べる方法を教えてください。

と同じく、ありません。

788 ：785：2008/02/19(火) 22:30:42

>>787
わかりました。
ありがとうございます。

789 ：デフォルトの名無しさん：2008/02/19(火) 22:34:26

有効なポインタの全てと等しくならなければ有効・・・かも。
大小比較演算子使えるなら簡単になる。
当然、親となる配列が固定されていないと無理だが。
でも、こういうことしていいのかは微妙。
有効に見えるけど、指してる所が違うとかありうるし。

790 ：786：2008/02/19(火) 22:40:03

vec.begin() < itr && itr < vec.end()

こんな感じでやっていたのですがこれでいいのか不安でした。

791 ：デフォルトの名無しさん：2008/02/19(火) 22:42:01

やるなら vec.begin() <= itr かと。

それで一応どこか有効な要素は指してるかもしれないが、
「元々指していた箇所から決して動いていない」
ということまでは保証してくれない。

792 ：デフォルトの名無しさん：2008/02/19(火) 23:00:47

非常に厳密に言えば>>790のコードは全く意味がない
そのコードを実行してよい事前条件が、まさに itr が有効なイテレータであることなので

793 ：デフォルトの名無しさん：2008/02/19(火) 23:43:39

>>790
reallocateされた場合どうすんのよ？

794 ：デフォルトの名無しさん：2008/02/19(火) 23:55:31

なんだかんだいっても、あれだよあれ。

795 ：デフォルトの名無しさん：2008/02/20(水) 00:12:26

メジャーリーグに興味持ち始めた頃、STL vs ATLってのがあって何かと思ったら
セントルイス・カージナルス対アトランタ・ブレーブスだった。

796 ：デフォルトの名無しさん：2008/02/20(水) 09:16:18

＞vectorのイテレータが有効なイテレータかどうか調べる方法を教えてください。
＞vec.begin() < itr && itr < vec.end()

自分もこれに関する情報欲しい。
良い記述があれば教えてｷﾎﾞﾝ!

797 ：デフォルトの名無しさん：2008/02/20(水) 09:26:21

しかしイテレータをそんな長く持ってるのって
プログラムを考え直した方がよいような

798 ：デフォルトの名無しさん：2008/02/20(水) 09:35:17

いや、長く持つんじゃなくて、取得した直後に調べたいんだけど。

799 ：デフォルトの名無しさん：2008/02/20(水) 09:36:58

*itr
で対象をproxyにしてis_valid()でも持たせたら？

800 ：デフォルトの名無しさん：2008/02/20(水) 09:44:22

そのis_validの実装をどうするかの話をしてるんだろ…

801 ：デフォルトの名無しさん：2008/02/20(水) 10:16:45

盛り上がってきますたｗ

802 ：デフォルトの名無しさん：2008/02/20(水) 10:25:13

>>798
本当に「取得した直後」なら、i != vec.end()でいいのでは。

803 ：デフォルトの名無しさん：2008/02/20(水) 10:35:54

ｻﾝｸｽ>>802
絶対あってる？保障してくれる？

804 ：デフォルトの名無しさん：2008/02/20(水) 11:09:57

>>803
どんな手段で取得した直後を想定しているの?

805 ：デフォルトの名無しさん：2008/02/20(水) 11:10:48

どれだけ力強く保証したって、しょせん名無しのレスだぜ。

806 ：デフォルトの名無しさん：2008/02/20(水) 11:12:20

こんなに調べる気ゼロな奴だと知ってたら、大嘘教えたのにな。

807 ：803：2008/02/20(水) 11:14:32

>>804
　>>745- のような使い方です。

808 ：デフォルトの名無しさん：2008/02/20(水) 11:16:06

>>806
本人からすると、ここで質問することだって調べる気でしょ。
そういう破壊的なことするのは良くないお( ＾ω＾)

809 ：デフォルトの名無しさん：2008/02/20(水) 11:20:42

答になってないぞ。
>>745に書いてあるのは「取得したあとにやりたいこと」。
質問は「どんな手段で取得した直後を想定しているのか」だ。

810 ：803：2008/02/20(水) 11:30:31

>>809

ですから、

vector::insertするためにはイテレーターが要りますよね？

で、item[6] としてイテレーターを取得したときに、そのイテレーターは有効なのか無効なのか、という判定。

811 ：デフォルトの名無しさん：2008/02/20(水) 11:51:08

>>810
イテレータを取得する前に検査すべき。
例えば、std::vector<int> foo(5); std::vector<int>::iterator it = foo + 6;の結果は鼻から悪魔。

812 ：デフォルトの名無しさん：2008/02/20(水) 11:54:57

>>810
item[6] ではイテレータを取得できないと思うよ
item.begin() + 6 のことか？
itemの6番目の要素が存在するなら、当然有効だし、
存在しないなら、何が返ってこようかくるまいが item.begin() + 6 を実行した時点でアウト

813 ：デフォルトの名無しさん：2008/02/20(水) 11:58:27

>>810

よくわからんが、こういうことか？

void foo(vector<int>& v, int index) {
vector::iterator iｔer = v.begin() + index; // この iter は有効か判断したい.
v.insert(iter, 5);
}

ならば、こう書けば良い

void foo1(vector<int>& v, int index) {
if (v.size() < index) v.resize(index); // iterが必ず有効になるように、事前にvectorを拡大する.
vector::iterator iｔer = v.begin() + index;
v.insert(iter, 5);
}

void foo2(vector<int>& v, int index) {
if (v.size() < index) throw std::invalid_argument("index が大き杉"); // 範囲外なら例外を投げる.
vector::iterator iｔer = v.begin() + index;
v.insert(iter, 5);
}

814 ：デフォルトの名無しさん：2008/02/20(水) 12:15:16

作った直後で無効なイテレータってあるのか？
作ること自体が違法だったり、作った後に無効になったりするのなら分かるんだが・

815 ：810：2008/02/20(水) 12:20:17

>>813
やりたいことは、
ある行の後に１行追加したい、
だから、foo1でできるのはできます。

でも、ある行の後に１行追加するメソッドくらい、std::vectorとかが標準で持ってて欲しいと思うお。

816 ：デフォルトの名無しさん：2008/02/20(水) 12:33:35

>>815
却下だな。
- 勝手に resize() するなら、途中の要素を何で埋めるか指定しないといけない。
- 挿入位置は iterator で指定するのが標準コンテナの流儀なのに、この場合だけ
インデックスで指定するのはおかしい。
- vector のメンバにしてもユーザーが実装しても効率などは変わらない。
標準で持っていたほうがいい理由が何も思いつかない。

817 ：デフォルトの名無しさん：2008/02/20(水) 12:35:35

>>814
作った直後のイテレータは、コンテナの中身を指しているか、end()と等値か、だよな。
だからこっちは「本当に作った直後なら、!= vector.end()との比較でいい」って言ってるのに、
この質問者、「自分の訊きたいこと」と「自分の訊いていること」を一致させられないんだよ。

818 ：デフォルトの名無しさん：2008/02/20(水) 12:57:08

おまえら頑張ってるが、実行効率も考えろ。
結果的に再取得したほうが良かったりして。

819 ：786：2008/02/20(水) 13:51:57

いろいろ勘違いしていました。
実際はイテレータじゃなくてただのインデックスでした。
0<=index<vec.size()
で十分でした。

イテレータの場合は持ってる間vectorを変更しないようにしています。

820 ：デフォルトの名無しさん：2008/02/20(水) 13:53:28

ｴｴｪｪｪ

821 ：デフォルトの名無しさん：2008/02/20(水) 14:18:16

>>819
う゛ーう゛ー

822 ：デフォルトの名無しさん：2008/02/20(水) 14:20:36

これは酷い釣りだ…

823 ：デフォルトの名無しさん：2008/02/20(水) 16:22:14

結論としてイテレーターは役立たずでOk?

824 ：デフォルトの名無しさん：2008/02/20(水) 16:30:10

list をイテレータなしでというのはちょっと
vector にはいらないけどさ

825 ：デフォルトの名無しさん：2008/02/20(水) 16:37:03

listの返したイテレータが無効になるタイミングって、
list本体が破棄された場合と、イテレータ先がeraseされた
時だけでしょうか？

826 ：デフォルトの名無しさん：2008/02/20(水) 16:46:18

元からC++にあった下位概念（ポインタ）が要求するメモリ構造を持っているvectorは、
後から加わった上位概念（イテレータ）を使わずとも、下位概念のやり方で各要素を見ていける、
だから「必須ではない」・・・という意味では、無くてもいいかもね。

実際には、stringやlistがbegin() end()してる中、vectorだけ&vec[0]とか使ってポインタでいじるのは
えらく不自然だから、vectorもイテレータで扱ってしまうけれども。

827 ：デフォルトの名無しさん：2008/02/20(水) 18:04:53

>>825
合ってる(要素を消す関数はerase()以外にもあるけど)。あと標準には
list1.splice(list2);
するとlist2へのイテレータが全部無効になる、と書いてあるけど、
実際にはほぼ間違いなくlist1への有効なイテレータになる。
これは標準の方が訂正される可能性が高い。

828 ：デフォルトの名無しさん：2008/02/20(水) 19:40:59

>>827
返答ありがとうございます。
listに要素追加したときイテレータを保存しておいて、
それを別なコンテナでインデックス化するってな使い方を
しても大丈夫そうですね。

spliceの
＞実際にはほぼ間違いなく
ってところはちと怖いので、使用は避けときます。

829 ：デフォルトの名無しさん：2008/02/20(水) 21:01:56

>>827
最新のドラフトだと「移動した要素を指し続ける」と書いてあるね。

830 ：デフォルトの名無しさん：2008/02/20(水) 21:36:58

250. splicing invalidates iterators
Section: 23.2.3.4 [list.ops] Status: WP Submitter: Brian Parker Date: 2000-07-14

void splice(iterator position, list<T, Allocator>& x);
invalidates all iterators and references to list x.

This is unnecessary and defeats an important feature of splice. In fact, the SGI STL guarantees that iterators to x remain valid after splice.

WPってWorking Paperってなってるけど一度却下されてるんだよね。
で、最新のドラフトだとC++0xで修正されることは決定？

WP　The proposed resolution has not been accepted as a Technical Corrigendum, but the full WG21 committee has voted to apply the Defect Report's Proposed Resolution to the working paper.

831 ：デフォルトの名無しさん：2008/02/20(水) 21:44:24

N2461 だと次のように書いてある。

23.2.3.4 list operations

void splice(const_iterator position, list<T, Allocator>&& x);

4 Effects: Inserts the contents of x before position and x becomes empty.
Pointers and references to the moved elements of x now refer to those same elements
but as members of *this.
Iterators referring to the moved elements will continue to refer to their elements,　　　← ここ
but they now behave as iterators into *this, not into x.

832 ：デフォルトの名無しさん：2008/02/20(水) 21:49:02

moveの導入による影響おそるべし

833 ：デフォルトの名無しさん：2008/02/20(水) 21:53:24

>>831
Working Draftか。
そうなりそうだね。

834 ：デフォルトの名無しさん：2008/02/20(水) 22:02:47

>>832
list の splice は，標準ライブラリへの move の本格導入以前から，
auto_ptr と並ぶ標準ライブラリにおける move の代名詞だったような？
現行の規格が不必要に制限が強すぎた
(iterator の stability を保証しなかった) だけで，
move 導入とは直接関係ないんじゃないですかね？

>>831の splice の第2引数が右辺値参照型に変更されたのも
単に一時変数を渡すことができるようにしただけでしょうし．

835 ：デフォルトの名無しさん：2008/02/20(水) 22:05:17

rvalue reference うぜえな。。　基本仕様としては
これが一番インパクトでかいかな。

836 ：デフォルトの名無しさん：2008/02/20(水) 22:07:39

concept 周りが間に合えばあれも相当インパクト大きいのでは

837 ：デフォルトの名無しさん：2008/02/20(水) 22:07:54

今まで
const Widget operator+(Widget, Widget)
とかしてたものが
Widget&& operator+(Widget, Widget)
になるのか。

838 ：デフォルトの名無しさん：2008/02/20(水) 22:08:37

テンポラリオブジェクトを渡せるようになるのはいいのだが、
そのせいで左辺値参照でいい状況でもムーブが発生するのが微妙だな。

839 ：デフォルトの名無しさん：2008/02/20(水) 22:26:14

以下は C++0x を前提にしたレスです．スレ違いですいません．

>>837
Widget の実装と operator+ の機能によりますけれど
値で返すのと参照で返すのでは基本的に意味が違ってしまうのでは？
で， move の恩恵を受けたければ Widget を move 可能にした上で
Widget operator+(Widget, Widget)
となるのが一般的かと思います．

>>838
＞そのせいで左辺値参照でいい状況でもムーブが発生するのが微妙だな。
その微妙になる具体例ってどんなのがありますかね？

840 ：デフォルトの名無しさん：2008/02/20(水) 22:37:12

l1.splice(it, l2);

右辺値参照の場合
1. l2 -> x のムーブ
2. x のノードを l1 に付け替える

左辺値参照の場合
1. l2 のノードを l1 に付け替える

841 ：デフォルトの名無しさん：2008/02/20(水) 22:42:46

>>839
戻り値をWidgetにしてしまうと代入できてしまうので
constをつけてるんだけど、

①const Widget operator+(const Widget&, const Widget&);

②Widget&& operator+(const Widget&, const Widget&);

現在は①のようにしてるけど、C++0xからは②でいいかなと思った。
どちらも
Widget w1, w2, w3;
if( (w1 = w2) = w3 )
のようなケアレスミスをコンパイルエラーにしてくれると思ったけど、
②だと (w1 = w2) = w3 はOKになってしまうか。右辺値参照に左辺値
は代入できるか。

842 ：デフォルトの名無しさん：2008/02/20(水) 22:44:44

const Widget operator+(const Widget&, const Widget&);

と書いた場合、const Widget はムーブできるのか？

843 ：デフォルトの名無しさん：2008/02/20(水) 22:44:56

>839
>838 じゃないけど。
値渡しにした段階でコピーが発生しちゃうから、

Widget&& operator+(Widget&&, Widget&&);
Widget&& operator+(Widget&&, const Widget&);
Widget&& operator+(const Widget&, Widget&&);
Widget operator+(const Widget&, const Widget&);

頑張るんならこうなるんじゃないの？
std::string の operator+() はこうなってるが。

あと、微妙ってのは左辺値参照なら単純にアドレス渡すだけで済んだものが、ムーブ処理が発生しちゃうのが嫌ってことなんじゃないかと。
で、↑はそのためにオーバーロードしてるけど。

844 ：デフォルトの名無しさん：2008/02/20(水) 22:46:52

>>840
引数のl2は右辺値という前提だよね。そうするとmoveの分だけ効率が
悪くなるということかな。

845 ：デフォルトの名無しさん：2008/02/20(水) 22:51:32

>>842
ん？メイヤーズの本で推奨されてたから従ってる。

>>843
ドラフト見たところでは、例えば
Widget&& operator+(Widget&& lhs, const Widget&& rhs);
の場合、両方の実引数にWidgetの一時オブジェクトを
渡すとlhsとrhsは右辺値になって、両方に左辺値を渡すとlhsとrhsは
左辺値になるという理解でいい？

846 ：デフォルトの名無しさん：2008/02/20(水) 22:55:53

>>840
現行の list の splice の意味からすると，
splice という名前に前者の操作を overload させると混乱するのでは？
前者は最新の working draft に従えば，例えば
l1.splice(it,decltype(l2)(move_iterator(l2.begin()),move_iterator(l2.end())));
と書けると思いますけれど，これではダメなのですか？

あと，「左辺値参照の場合……」「右辺値参照の場合……」という書き方を
されていますけれど， l2 の型が右辺値参照型か左辺値参照型か，ということですか？
もしそうだとすると，l2 はそのままでは常に左辺値として扱われるので，
void splice(iterator, list<T,A>&);
と
void splice(iterator, list<T,A>&&);
があった場合には， l2 が右辺値参照型か左辺値参照型かに関わらず
常に前者が呼ばれると思います．

847 ：デフォルトの名無しさん：2008/02/20(水) 23:00:25

しかし void splice iterator, list<T,A>&); は存在しない

848 ：デフォルトの名無しさん：2008/02/20(水) 23:03:20

>>841
一時オブジェクトに対するメンバ関数呼び出しの overload は
右辺値参照型の *this への拡張が対応するかと思います．

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2439.htm

例えば，右辺値に対して Widget::operator=(const Widget&) を禁止したければ

class Widget{
Widget& operator=(const Widget&) & { ... }
Widget& operator=(const Widget&) && = delete;
...
}

上記のようになるかと思います．従って Effective C++ にある>>845の記述は
C++0x では deprecated になるかと思います．

849 ：デフォルトの名無しさん：2008/02/20(水) 23:06:33

>>842
move はそのソース (move 元) に対して破壊的操作を行うことになるので
戻り値に対して const を指定しているとその戻り値に対して
move を行うことはできなくなると思います．
Widget& Widget::operator=(const Wideget&); // copy assignment
と
Widget& Widget::operator=(Wideget&&&); // move assignment
があった場合，>>842の operator+ の戻り値に対しては
オーバーロードの優先順位を解決した結果， copy assignment が呼ばれるかと．

850 ：デフォルトの名無しさん：2008/02/20(水) 23:06:55

dequeとvectorの速さ比べをしてみた(gcc　3.4.5 mingw)

for(i=0; i < num; i++){
　foo += v[i];
}

みたいなの。

vectorの先頭をポインタに渡してポインタ経由でアクセス
>>>>>>vectorを[]でアクセス>>>vector をiteratorでアクセス=dequeをiteratorでアクセス
>>>>>>>(越えられない壁)>>>>>>dequeを[]でアクセス

dequeがあればvectorはいらない子みたいなカキコがあったけど、やっぱvectorはやればデキる子だよ。

851 ：デフォルトの名無しさん：2008/02/20(水) 23:15:29

>>843
ありがとうございます．微妙な具体例が理解できました．
これを気にするならば overload 頑張るしかないですね．

852 ：デフォルトの名無しさん：2008/02/20(水) 23:18:07

オーバーロードで解決は出来るけど、
沢山あると大変だね。

853 ：デフォルトの名無しさん：2008/02/20(水) 23:27:12

蛇足ですけれど，>>843は書かれているような「微妙な状況」の他に，
引数が一時オブジェクトで，その一時オブジェクトのバッファが
結合後の文字列を保持できる余裕がある場合に，
バッファの再確保を回避できる最適化を積極的に活用できる
というのもあるかと思います．

854 ：デフォルトの名無しさん：2008/02/20(水) 23:34:05

>>847
元々 splice は move (破壊的コピー) を行うという意味づけであり
右辺値と左辺値を区別する必要はなく，
void splice(iterator, list<T,A>&);
と
void splice(iterator, list<T,A>&&);
をオーバーロードする必要もないと自分は思います
(し，おっしゃるとおり working draft も今のところそうなっています)

855 ：デフォルトの名無しさん：2008/02/20(水) 23:35:07

>>850
vectorアクセスするのにiterator経由より[]の方が速いって謎すぎる。
何らかの理由で最適化に失敗してるか、assertが効いてるんじゃ？

856 ：デフォルトの名無しさん：2008/02/20(水) 23:48:29

>>855
最適化オプション何もなしだお

857 ：デフォルトの名無しさん：2008/02/20(水) 23:49:40

>>855
ちなみに、倍速くらい
ポインタにすると[]のさらに倍
ちなみにdequeの[]はvectorの[]の4倍遅い

858 ：デフォルトの名無しさん：2008/02/20(水) 23:50:03

-O2つけて測定コード毎最適化で消してしまえ。

859 ：デフォルトの名無しさん：2008/02/20(水) 23:50:18

あほすぎ。

860 ：デフォルトの名無しさん：2008/02/20(水) 23:54:00

ふつーSTLは最適化かけて実測するもんだと思ってたのだが、違うのか？

861 ：デフォルトの名無しさん：2008/02/20(水) 23:57:15

STL に限らず、実測は最適化かけてからやるのが普通。
最適化しない場合の影響を調べるのでもない限りは。

862 ：デフォルトの名無しさん：2008/02/21(木) 00:05:39

ふつー、最適化をかけるとvetor::operator[]はポインタアクセスと同じコードに
展開される。実際、gcc3.4.6 -O2ではそう。

863 ：デフォルトの名無しさん：2008/02/21(木) 00:24:53

dequeのメモリ構造は複数のメモリブロックから成っているので
ブロック間でindirect accessが発生するから、要素へのアクセス
とiteratorの操作はvectorより遅くなるというのが一般論。

864 ：デフォルトの名無しさん：2008/02/21(木) 00:35:31

>>854
ほほう。結局、
void splice(iterator pos, list<T,A>&& l2);
この場合、l2に右辺値（一時オブジェクト）を渡そうが
左辺値を渡そうが、l2は常に左辺値として扱われるという
ことだよね？この仕様変更のメリットとしては、右辺値も
渡せるということかね。

865 ：デフォルトの名無しさん：2008/02/21(木) 00:47:02

>>864
splice の定義内では，明示的にキャストをかけるか
std::move を使うかしないと l2 は左辺値として扱われると思います．

＞この仕様変更のメリットとしては、右辺値も渡せるということかね。
自分はそう理解していたので>>834のように書きました．
右辺値が渡せるので>>846に書いたような
l1.splice(it,decltype(l2)(move_iterator(l2.begin()),move_iterator(l2.end())));
みたいなコードも通るようになります．

866 ：デフォルトの名無しさん：2008/02/21(木) 00:50:32

>>865
後半は漏れの理解不足で分からんけど、アリガトン。

867 ：デフォルトの名無しさん：2008/02/21(木) 00:55:32

>>866
すいません．
l1.splice(it,list<int>(l2.begin(),l2.end()));
みたいなコードも通るようになるといいたかったんです．
といいますか>>846のとかこれの場合は insert で良いですね……orz

868 ：デフォルトの名無しさん：2008/02/21(木) 01:37:08

>>867
いえいえ。
move_iteratorとか見たことなかったので漏れの理解不足というより
知識不足だった。範囲指定のコンストラクタで一時オブジェクト
をそのまま渡すことができると。
それが、l1.insert(it, l2.begin(), l2.end());で可能だったという
こっですね。

869 ：デフォルトの名無しさん：2008/02/21(木) 10:09:34

>>813

＞vector::iterator iｔer = v.begin() + index;

やっぱ、イテレーターとるときってbegin()で取るのが正しいのか。

＞vector::iterator iｔer = &v[index];

ってのはダメ？
ってか、おｋ、だったとしてもvectorとdequeでしか通用しないＢＡＤな書き方？

870 ：デフォルトの名無しさん：2008/02/21(木) 10:21:31

それはポインタ。
全てのSTL実装でコンパイルが通る保証はない。

871 ：デフォルトの名無しさん：2008/02/21(木) 10:27:49

ｻﾝｸｽ。

つまり、書き方という問題じゃなくて、使ってるSTLの実装上たまたまコンパイルエラーが出ないだけなんだね。

すげー賢くなったお( ＾ω＾)

872 ：871：2008/02/21(木) 10:30:40

あっ、本当だ。vectorをdequeに変えたらコンパイルエラー。
実行時エラーじゃなくて、コンパイルエラーなのは好感( ＾ω＾)

873 ：デフォルトの名無しさん：2008/02/21(木) 12:52:05

散々既出だけど、vectorの場合は、int* p = &v[index];も可能。
ただ、end相当の&v[v.size()]は未定義だから、&v[0] + v.size()を使えって話があった気もする。

874 ：デフォルトの名無しさん：2008/02/21(木) 12:58:44

いいえ。

875 ：デフォルトの名無しさん：2008/02/21(木) 13:01:28

>int* p = &v[index];
これはvectorに限らずあらゆるコンテナで可能だろ

876 ：デフォルトの名無しさん：2008/02/21(木) 13:08:38

そうですね。

877 ：デフォルトの名無しさん：2008/02/21(木) 13:09:09

え”？
dequeでコンパイルエラー出たけど、気のせい？
もうテストコード消しちゃったお。

878 ：デフォルトの名無しさん：2008/02/21(木) 13:11:06

>>875
釣りですか？

879 ：デフォルトの名無しさん：2008/02/21(木) 13:17:54

いいえ。

880 ：デフォルトの名無しさん：2008/02/21(木) 13:37:04

不正確な物言いだったな
operator[]を持っていて、value_typeがintであるような、あらゆるコンテナのインスタンスについて可能、と言いたかった

881 ：デフォルトの名無しさん：2008/02/21(木) 13:55:22

それはうっかりだった、すまん。
vectorのポインタの場合は、配列の要素を指すポインタの如く、
ポインタ演算を使用してそのvectorインスタンスの保持する他の要素も参照できると言えばいいか。

882 ：デフォルトの名無しさん：2008/02/21(木) 13:58:46

std::stringは、イテレーﾀﾝを無視して、何文字目かを数字で指定しても、おｋだおね？

883 ：デフォルトの名無しさん：2008/02/21(木) 14:03:08

＞ただ、end相当の&v[v.size()]は未定義だから、&v[0] + v.size()を使えって話があった気もする。
で、これは?

884 ：デフォルトの名無しさん：2008/02/21(木) 15:09:32

&v[0]の時点でただのポインタなんだから、それにどんな値を足しても
指してる先にアクセスしなきゃ大丈夫でしょ。

885 ：デフォルトの名無しさん：2008/02/21(木) 15:30:22

配列の最後の要素の一つ後の要素のアドレスをポインタ演算に
使用することは規格で認められていた記憶がある。
これが正しければ &v[v.size()] は有効だと思う。

886 ：デフォルトの名無しさん：2008/02/21(木) 15:30:54

>>884
ダウト。

887 ：デフォルトの名無しさん：2008/02/21(木) 15:31:47

stringのuppercaseはどう書きますか？

888 ：デフォルトの名無しさん：2008/02/21(木) 15:56:50

>>885
その式は右から評価するからアウト

889 ：デフォルトの名無しさん：2008/02/21(木) 16:01:43

>>885
vectorのoperator []は多重定義された関数なのだから、それとは別に規定があるはず。
と思ってX 3014見てみたが、23.1.1 列の中で参照されている表68に
a[n]は*(a.begin() + n)と書かれているがそれ以上は何もない。
もちろん、atはn >= a.size()のときにout_of_rangeを送出と書いてあるけど。

890 ：デフォルトの名無しさん：2008/02/21(木) 16:23:53

>>885
v[v.size()]の時点で鼻から悪魔確定だろ

891 ：デフォルトの名無しさん：2008/02/21(木) 16:27:30

>>890
なんで？

892 ：デフォルトの名無しさん：2008/02/21(木) 16:29:38

>>886
なんで？

893 ：デフォルトの名無しさん：2008/02/21(木) 16:36:28

>>889
a.begin() + n は dereferenceable ではないので
これを dereference した時点で規格としては undefined behavior，
でよいのでは？

894 ：デフォルトの名無しさん：2008/02/21(木) 16:48:51

std::string に trim が無いなんて不自由でつね。

895 ：デフォルトの名無しさん：2008/02/21(木) 16:51:25

まぁ、色々足りないものはある。

896 ：デフォルトの名無しさん：2008/02/21(木) 17:25:46

>>888
No

アドレス演算子&はオペランドが[ ]演算子の結果の場合、単項&演算子と
[ ]演算子が暗黙に意味する単項*演算子は評価されず、&演算子を削除し
[ ]演算子を+演算子に変更した場合と同じ結果となる。

つまり、&v[v.size()] は v + v.size() に評価されるのであって、
&(*(v + v.size)) とは評価されない。

897 ：デフォルトの名無しさん：2008/02/21(木) 17:27:38

>>888
C言語もあまり詳しくないだろ？K&Rにも、>>885が正しいことは書いてある。
かつ、C++でも同じ。

898 ：デフォルトの名無しさん：2008/02/21(木) 17:44:24

>>896
それはポインタについてじゃないのか
>>889も言ってるが、vectorの[]や、vectorのイテレータの+と*は単なる関数かもしれない訳で、
ポインタについての規定がそのままあてはまるとする理由はないだろ

899 ：デフォルトの名無しさん：2008/02/21(木) 18:01:34

stringの数字チェックはできますか？

900 ：デフォルトの名無しさん：2008/02/21(木) 18:47:36

>>898
そのとおりだ。ポインタの話しと思ってた。

901 ：デフォルトの名無しさん：2008/02/21(木) 18:52:15

&v[0] + v.size()でOK

902 ：デフォルトの名無しさん：2008/02/21(木) 22:31:04

私はヘタレなのでそんなに悩んでる暇があったらイタレータ使っちゃいます
ごめんなさい

903 ：デフォルトの名無しさん：2008/02/21(木) 22:33:11

>>902
僕もです。

904 ：デフォルトの名無しさん：2008/02/21(木) 23:01:29

サイズが0のときの&v[0]は不定だ。VS2005だとアサート。

905 ：デフォルトの名無しさん：2008/02/22(金) 00:39:14

おかしなコード書きすぎ＞＜

906 ：デフォルトの名無しさん：2008/02/22(金) 08:41:26

結局STLって無いと困るけど、書き難いね。

複数ファイルイメージみたいなのをバッファに持っておきたいばあいは、
みなさんどうされてます？
void*？char*?

やっぱ、vector <char*>みたいな感じ？

907 ：906：2008/02/22(金) 08:54:20

*で宣言しちゃうと、メモリの開放を書かないと逝けないから、
vector <string>の方が良いかなぁ？

908 ：906：2008/02/22(金) 09:30:49

たまには質問にも応えて欲しいお。

909 ：デフォルトの名無しさん：2008/02/22(金) 10:05:33

>>906
テキストファイルである保証があるなら兎も角、普通はvector<string>はつかわんだろ。
つーか、ファイルの内容によって違うものを一般化されても困る。

910 ：906：2008/02/22(金) 10:06:37

テキストファイルじゃなくてバイナリファイルです。

TMemoryStremaみたいなのが欲しいんです。

911 ：デフォルトの名無しさん：2008/02/22(金) 10:08:23

ファイルをvector<char>に入れるとして、複数ファイルならvector<vector<char> >でいいんでね?
なにをやりたいか判ればもっと適当な方法もあるかもしれないけど。

912 ：デフォルトの名無しさん：2008/02/22(金) 10:08:31

>>906 vector<char> じゃないのか？

913 ：906：2008/02/22(金) 10:27:17

＞vector<vector<char> >

おｋ。
ファイルのロードとか要りますよね。
出来上がったクラスが標準だったり、ネットに転がってて欲しい。

914 ：デフォルトの名無しさん：2008/02/22(金) 10:40:03

クラス? 何を言ってるんだ? このスレがなんだか判っているか?
STLの使い方を提示されたんだから、後は自分で勝手に実装すればいいだろ。

915 ：デフォルトの名無しさん：2008/02/22(金) 10:46:03

だって普段STL使ってる人たちが、便利な標準クラス使ってるか自作クラスライブラリそろえてるに決まってるじゃん。

916 ：デフォルトの名無しさん：2008/02/22(金) 10:55:17

もうかまうなよ。

917 ：デフォルトの名無しさん：2008/02/22(金) 11:00:59

>>913
あのさ、先日からC++BuilderのVCLを移したいみたいだけどさ
STLはVCLと範疇が違うんだから、ファイルロードだのなんだのは
自分でやってくれるかな。

918 ：デフォルトの名無しさん：2008/02/22(金) 13:53:18

じゃ、せめて、

＞vector<vector<char> >

をカプセル化した便利なクラスだけでも教えてorz

919 ：デフォルトの名無しさん：2008/02/22(金) 13:54:32

そんなものないよ

920 ：デフォルトの名無しさん：2008/02/22(金) 13:57:18

そういえば、copiedはともかくfile_rangeくらいBoostにあってもいいのにって思う。
namespace oven = pstade::oven;
std::size_t n;

std::vector<std::vector<char> > v;
v.reserve(n);

for (std::size_t i = 0; i < n; ++i)
{
std::ifstream is(...);
v.push_back(oven::file_range<char>(...) | oven::copied);
}

921 ：デフォルトの名無しさん：2008/02/22(金) 14:00:54

どう見てもifstreamの行は消し忘れです、本当に(ry。

922 ：デフォルトの名無しさん：2008/02/22(金) 14:56:03

string::compareはありますが、大文字小文字を無視してcompareする場合は、皆さんどうされてるのでしょうか？

923 ：デフォルトの名無しさん：2008/02/22(金) 15:03:55

stricmp

924 ：デフォルトの名無しさん：2008/02/22(金) 15:06:51

文字列まわりはSTLに期待すんな、クソだ

925 ：デフォルトの名無しさん：2008/02/22(金) 15:12:43

そーなんですか。

構造体まわりはSTLで完璧ですが。

で、文字列まわりは何使えば良いですか？
ってstringしか無いじゃん。
あー、ハイパーなstringのソース落ちてないかなぁ。

926 ：デフォルトの名無しさん：2008/02/22(金) 15:17:24

構造体てｗ

927 ：デフォルトの名無しさん：2008/02/22(金) 15:18:47

あ、structもclassも等価らしいですが、
何もしないデータの塊にはstruct使ってます。

変ですか？

928 ：デフォルトの名無しさん：2008/02/22(金) 15:21:17

＞stricmp

試してみましたが、やっぱ、.c_str() 付けないとコンパイル通りませんね。
これくらい標準にして欲しいお。

929 ：デフォルトの名無しさん：2008/02/22(金) 15:36:00

春だなぁ

930 ：デフォルトの名無しさん：2008/02/22(金) 15:42:26

まだ冬ですよ

931 ：デフォルトの名無しさん：2008/02/22(金) 15:57:45

これがvipクオリティ

932 ：デフォルトの名無しさん：2008/02/22(金) 16:13:44

ファイルや文字列処理は微妙にスレ違いな気もするなぁ。
boostでよければboost.string_algoに色々あるしSTLにこだわる必要はないだろ。
boost.string_algoなら>>922はboost::algorithm::ilexicographical_compare。

ところでstricmp/strcmpiって標準だっけ？

933 ：デフォルトの名無しさん：2008/02/22(金) 16:49:51

std::string って、
==
で比較できましたっけ？

934 ：デフォルトの名無しさん：2008/02/22(金) 16:55:53

できる

935 ：デフォルトの名無しさん：2008/02/22(金) 17:53:15

>>932
stricmpもstrcmpiもstrcasecmpも標準Cには存在しない。
最近のPOSIXにはstrcasecmpがあるけど、locale依存なので
画面に表示する文字列をソートするくらいしか使い道がない。

936 ：デフォルトの名無しさん：2008/02/22(金) 18:08:08

>>935
なるほど。㌧

937 ：デフォルトの名無しさん：2008/02/22(金) 20:58:33

一瞬、初心者歓迎スレきたのかと思ったぜｗ

938 ：デフォルトの名無しさん：2008/02/23(土) 00:16:23

似たようなもんかもw

939 ：デフォルトの名無しさん：2008/02/23(土) 00:18:06

string って STL に含まれるの？

940 ：デフォルトの名無しさん：2008/02/23(土) 00:50:55

ど　　っ　　ち　　で　　も　　い　　い

強いて言うならC++標準。
つまんないことにこだわらんでも良いよ。

941 ：デフォルトの名無しさん：2008/02/23(土) 00:51:02

頻出ネタの上に面白くない議論にしかならないのでスルー

942 ：デフォルトの名無しさん：2008/02/24(日) 11:20:20

std::map<int, std::string> string_map;
assert(string_map[1].empry());
assert(string_map[100].empry());
assert(string_map.size() == 2);

つまり、存在しないキーを operator[] で指定すると
そのキーが自動的に挿入されて値はデフォルトコンストラクタ
で作成されてしまうということですか？
うむむ、例外になってくれればいいのだが。

std::vector でも operator[] は例外を出さないから
それに対応した動作ということなんでしょうか？

943 ：デフォルトの名無しさん：2008/02/24(日) 11:45:26

単に
string_map[1] = "foo";
ってやったときに存在しないキーを指定すると自動的に追加されてほしいからじゃね？

944 ：デフォルトの名無しさん：2008/02/24(日) 11:53:02

そうそう
存在するかどうかも含めて問い合わせるにはfindを使う

945 ：デフォルトの名無しさん：2008/02/24(日) 13:17:17

>>942
次の規格の改訂では、存在しないキーに対して例外を投げる at() が追加されるよ。

946 ：デフォルトの名無しさん：2008/02/24(日) 13:58:04

統一性のある素晴らしい改訂ですな。

947 ：デフォルトの名無しさん：2008/02/24(日) 14:42:27

まぁ copy_if の一軒もあるしな

948 ：デフォルトの名無しさん：2008/02/24(日) 14:42:47

for_each_if とかもほしい

949 ：デフォルトの名無しさん：2008/02/24(日) 14:43:47

なんで標準にcopy_ifがないんだって話？

950 ：デフォルトの名無しさん：2008/02/24(日) 14:47:46

vector に data が追加されたり、
何で無かったんだ？って機能が色々追加されてるみたいだね。

951 ：デフォルトの名無しさん：2008/02/24(日) 14:48:12

そういえば規格の改訂で copy_if() が追加されないのはなぜなんだぜ？

952 ：デフォルトの名無しさん：2008/02/24(日) 14:54:32

最新ドラフト（これ、最終ドラフトだっけ？）にも載ってないな。

953 ：デフォルトの名無しさん：2008/02/24(日) 14:55:44

今公開されてる最新は n2521.pdf のはず。無いな。

954 ：デフォルトの名無しさん：2008/02/24(日) 14:57:21

禿が１０年越しの天丼ねらってる、とか？

955 ：デフォルトの名無しさん：2008/02/24(日) 14:59:55

質問失礼します。。
struct ST{
　　int n;
};
vector<ST> v;
set<ST> s;

int main(){
　　ST x={0};

　　v.push_back(x);
　　vector<ST>::iterator itv=v.begin();
　　itv->n++;

　　s.insert(x);
　　set<ST>::iterator its=s.begin();
　　its->n++;
}
のようにすると、its->n++;の行で
error: increment of data-member ‘ST::n’ in read-only structure
と出るのですがvectorで出来てsetで出来ないのはなぜでしょうか？

956 ：デフォルトの名無しさん：2008/02/24(日) 15:03:57

今すぐsetのイテレータタグを調べるんだ

957 ：デフォルトの名無しさん：2008/02/24(日) 15:04:24

ごめんnの方だったのね

958 ：デフォルトの名無しさん：2008/02/24(日) 15:04:44

>>955
set は常にソートされた並びを保っている必要があるから。

959 ：955：2008/02/24(日) 15:17:04

>>956-958さん
iterator経由で勝手に中身を変えられたら困るということは、
setとmapだけの例外扱いなのですか？
イテレータタグというのは初見なのでちょっと調べてみます。

960 ：デフォルトの名無しさん：2008/02/24(日) 15:28:50

map は second の方は変えれる。

961 ：デフォルトの名無しさん：2008/02/24(日) 15:28:54

>>959
map の場合は value_type である pair の first がソートキーなので、これは
書き換えられないように const が付いてる。 second は順序に関係ないので
書き換えてもいい。

962 ：955：2008/02/24(日) 15:31:13

>>960,961さん
なるほど、そうなっているのですね。
よく分かりました、どうもありがとうございました。

963 ：デフォルトの名無しさん：2008/02/24(日) 15:43:02

compareが感知しないメンバなら、mutable付けていじることはできるけどね。

964 ：デフォルトの名無しさん：2008/02/24(日) 16:01:24

まぁそれは奥の手ということでｗ

965 ：デフォルトの名無しさん：2008/02/25(月) 14:04:12

ファイルに簡単に新規作成、追記ができる方法ありますか？

ofstreamって、bad()とかfail()とか使いにくい。

966 ：デフォルトの名無しさん：2008/02/25(月) 14:18:47

ofstream.exceptions(badbit | failbit);
ってやっとけばいちいちチェックしなくても例外吐いてくれると思う
それが使いやすいかどうかはわからんが…

967 ：965：2008/02/25(月) 14:25:43

ｻﾝｸｽ>>966

968 ：デフォルトの名無しさん：2008/02/25(月) 16:54:00

そんな機能があったとは

969 ：デフォルトの名無しさん：2008/02/25(月) 17:08:09

そういえばostreamのfail()が真になる事ってあるの?

970 ：デフォルトの名無しさん：2008/02/25(月) 17:24:02

>>920
＞file_range

ずっと見てても分からないんですが、file_rangeって何ですか？

971 ：デフォルトの名無しさん：2008/02/25(月) 17:29:12

ファイルの先頭から末尾の一つ後ろまでを指すイテレータのペアみたいなもん

972 ：デフォルトの名無しさん：2008/02/25(月) 17:30:41

使い方ｷﾎﾞﾝ

973 ：デフォルトの名無しさん：2008/02/25(月) 18:12:11

複数のファイルがあって、それがローデータだったり、テーブルデータだったりします。

複数のファイルを混在させずに簡単にロードしてしまうクラスが欲しいのですが、どんな実装になりますか？

974 ：デフォルトの名無しさん：2008/02/25(月) 18:13:10

>>972
コンストラクタで開いたら後はただのRange。
http://p-stade.svn.sourceforge.net/viewvc/p-stade/trunk/pstade/libs/oven/test/file_range.cpp?revision=1481&view=markup
http://p-stade.sourceforge.net/oven/doc/html/oven/ranges.html#oven.ranges.file_range

Range自体はここでも見て。
http://www.kmonos.net/alang/boost/classes/range.html

975 ：デフォルトの名無しさん：2008/02/25(月) 18:16:01

さんｋｓ>>974

boostなんですね。STLに昇格するまで待ってようかなぁ。
ちょっと気後れしてしまうorz

976 ：デフォルトの名無しさん：2008/02/26(火) 08:54:04

973もﾖﾛ!

977 ：デフォルトの名無しさん：2008/02/26(火) 08:59:15

>>973
ローデータ、テーブルデータ、ファイルを混在、簡単に、ロード
これだけ曖昧な言葉を並んでるとさすがに意味がわからん。

978 ：デフォルトの名無しさん：2008/02/26(火) 11:28:42

いや、だからメモリにロードしたいけど、
ファイルの種類が増えるたび書き換えするのは面倒なので、
ポケットみたいにどんどんファイル（ファイル名）を入れていくとその中でメモリになってる、みたいな。

979 ：デフォルトの名無しさん：2008/02/26(火) 12:01:54

>>978
// ちょっとエスパーにチャレンジしてみたい気分になった
// こうですか？
#include <vector>
#include <map>
#include <string>
#include <istream>
#include <iterator>
#include <fstream>
#include <cstddef>
#include <exception>
#include <iostream>
typedef std::vector<char> memory_type;
class pocket {
std::map<std::string, memory_type> naka;
public:
void ireru(std::string const& filename) {
std::ifstream file(filename.c_str());
file.exceptions(std::ios::badbit | std::ios::failbit);
naka[filename].assign(std::istreambuf_iterator<char>(file)
, std::istreambuf_iterator<char>());
}
};
int main(int argc, char* argv[]) {
try {
pocket pocket;
for (int i = 1; i < argc; ++i) { pocket.ireru(argv[i]); }
return EXIT_SUCCESS;
}
catch (std::exception const& e) { std::cerr << e.what() << std::endl; return EXIT_FAILURE; }
}

980 ：デフォルトの名無しさん：2008/02/26(火) 12:18:03

乞食は消えろ

981 ：デフォルトの名無しさん：2008/02/26(火) 12:25:50

さて埋めるか。

982 ：978：2008/02/26(火) 12:58:13

サンｋｓ>>979

そのまま使ってみます。
でも、ireruメソッドはメソッド名変えるけど。

class pocketもclass memoryPocketの方が良いかなぁ？

983 ：デフォルトの名無しさん：2008/02/26(火) 14:12:22

978がアホすぎて吹いた

984 ：デフォルトの名無しさん：2008/02/26(火) 14:15:27

吹いても良いから、自分はどーゆーふーに作ってるか書けお。

985 ：デフォルトの名無しさん：2008/02/26(火) 14:24:08

スレタイに「初心者」か「宿題」が付いてるスレへ行ってくれ。
マジで邪魔。