- 1 名前：858 [2007/12/24(月) 03:41:59 ]
- C++標準ライブラリの一つ、STLについて。
前スレ
【C++】STL（Standard Template Library）相談室 7
pc11.2ch.net/test/read.cgi/tech/1185986999/
過去ログ・リンク・書籍紹介は >>2 以降
- 231 名前：デフォルトの名無しさん mailto:sage [2008/01/21(月) 15:26:30 ]
- 低レベル(遅延書き出しなど)でのディスク書き出しはOSの機能
だと思われ。書き出すタイミングも。
streambuf_iteratorを使う（内部的にsgetc, sbumpc, sputcを
使ってる）ということはプログラムレベルでのストリームバッファ
を直接操作してるわけで、ファイルストリームオブジェクトに対して
read、writeを使うと非バッファ操作になるから速くなることは
ないと思える。実測次第だな。
OSのチューニングなりドライバこさえるなりするのも一考。
- 232 名前：デフォルトの名無しさん mailto:sage [2008/01/21(月) 19:53:04 ]
- これで速くなるのかな
itpro.nikkeibp.co.jp/article/COLUMN/20080104/290425/
- 233 名前：デフォルトの名無しさん mailto:sage [2008/01/21(月) 19:55:10 ]
- 最新のドラフトを見ると string も連続性を保証するようになるっぽい。
- 234 名前：225 mailto:sage [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 名前：デフォルトの名無しさん mailto:sage [2008/01/21(月) 21:34:55 ]
- >>234
やっぱりディスクアクセスが頻発するのか。
streambuf_iteratorはstream_iteratorに比べると速いというだけか。
ただ、そのプログラムのread/writeだと正しくファイルがコピーされなかった。
おそらく、fout << fin.rdbuf(); 一行で正しくコピーできると思う。
by VC++ 2008
- 237 名前：デフォルトの名無しさん mailto:sage [2008/01/21(月) 21:39:20 ]
- >>234
fout.write( buf, BUFSIZ );
がコピーできない原因か。BUFSIZEのゴミまでコピーされてしまう。
- 238 名前：デフォルトの名無しさん mailto:sage [2008/01/21(月) 21:56:13 ]
- flushみたいな名前の
- 239 名前：225 mailto:sage [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 名前：デフォルトの名無しさん mailto:sage [2008/01/21(月) 22:23:42 ]
- >>232
あほうすぎる話だなｗ
こんなのDBの研究者が聞いたら鼻で笑っちまうぜ。
挙句の果てVBかよｗ
- 241 名前：デフォルトの名無しさん [2008/01/21(月) 22:29:51 ]
- /.J でもさんざん馬鹿にされてる
- 242 名前：デフォルトの名無しさん mailto:sage [2008/01/21(月) 22:30:27 ]
- >>239
そうrdbufだと結構遅かったんだよね。
gcount()があったんだ。それ使ったほうが良いよ。
速いに越したことはない。
thx。色々参考になったよ。
- 243 名前：デフォルトの名無しさん mailto:sage [2008/01/21(月) 22:32:50 ]
- >>240
DBの検索アルゴリズムはよく知らんが、
アルゴリズムを考えるときに言語使用は関係ないだろ。
それに、どうせ使ってるのはOSのAPIだろうから、VBだろうが、Cだろうが、
呼び出す速度は同じじゃね？
- 244 名前：デフォルトの名無しさん mailto:sage [2008/01/21(月) 22:40:10 ]
- 「OSの基本機能であるファイル名の検索機能」とやらのアルゴリズムを
そっくりそのままDBに応用しようとは考えなかったんだろうか？？
- 245 名前：デフォルトの名無しさん [2008/01/21(月) 23:05:24 ]
- STLの配列にクラスのポインタを入れて使用したいのですけど、
そのようなことって可能なのでしょうか？
- 246 名前：デフォルトの名無しさん mailto:sage [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 名前：デフォルトの名無しさん mailto:sage [2008/01/21(月) 23:10:38 ]
- >>245
配列？valarray?
ちなみにコンテナだったら可能だよ。
まあ色々面倒だからスマートポインタ使うか
boostのpointer containerとか。
- 248 名前：デフォルトの名無しさん mailto:sage [2008/01/21(月) 23:12:24 ]
- >>246,247
ありがとうございます。
では、早速チャレンジしてみます
- 249 名前：デフォルトの名無しさん mailto:sage [2008/01/21(月) 23:16:08 ]
- つーかコンテナにポインタ入れる必要って本当にあるの？
大抵の事ならポインタ入れずに済ませられると思うんだが。
- 250 名前：デフォルトの名無しさん mailto:sage [2008/01/21(月) 23:21:32 ]
- ヒープに作成したオブジェクトをコンテナで
管理したい場合もあるんじゃないかな。
- 251 名前：デフォルトの名無しさん [2008/01/21(月) 23:35:47 ]
- >>235 だれかおながいします・・
とおもったけどスレチガイ？
- 252 名前：デフォルトの名無しさん mailto:sage [2008/01/21(月) 23:39:15 ]
- >>244
>「OSの基本機能であるファイル名の検索機能」とやらのアルゴリズムを
>そっくりそのままDBに応用しようとは考えなかったんだろうか？？
Windows Index Search の機能らしいので
アルゴリズム自体はそっくりそのままDBです
本当にありがとうございました
- 253 名前：デフォルトの名無しさん mailto:sage [2008/01/21(月) 23:41:04 ]
- >>245-250
class my_class;
vector<my_class*> v1;
普通に使いまくってますが何がいかんの？
- 254 名前：デフォルトの名無しさん mailto:sage [2008/01/21(月) 23:43:59 ]
- コピーしたときに問題が起きるのは使い方が悪い。
- 255 名前：デフォルトの名無しさん mailto:sage [2008/01/22(火) 00:19:14 ]
- >>235
10
10 12
8
multiset の実装と関係あるかどうか知らんけど。
- 256 名前：デフォルトの名無しさん mailto:sage [2008/01/22(火) 00:35:31 ]
- >>255
en.wikipedia.org/wiki/Binary_search_tree#Insertion
ここみると、そんな凝ったことしてないね。
でも、>>255のようにしないとequal_rangeとかまともに実装できない気もする。
どうなんだろ
- 257 名前：デフォルトの名無しさん mailto:sage [2008/01/22(火) 00:45:39 ]
- >>256の記事にも書いてあるけど、親と同じ値なら左部分木に入れる、とか決めておくだけだな
- 258 名前：デフォルトの名無しさん mailto:sage [2008/01/22(火) 00:53:14 ]
- 右じゃないの。
- 259 名前：デフォルトの名無しさん [2008/01/22(火) 01:00:51 ]
- >>258
どちらかに統一しておけばいいんじゃないの?
>>257
左に入れるとして、同じ値を見たら、そのノードの直接の子供としてinsertするのか(255案)、
孫以下の遠い子供として、leafの子としてinsertするのか(この例だと8のrightとして)、どっち?
std::multisetの場合。
- 260 名前：デフォルトの名無しさん mailto:sage [2008/01/22(火) 01:06:36 ]
- >>253
newしたオブジェクトを入れるんだったら、
deleteのし忘れ、2重に行ってしまうなどのミスを起こすから
やめとほうがよいというだけのこと。
「気を付ける」なんて言葉は信頼できないので、
やるなら246のいうようにshared_ptrか何か使って、
deleteをコンピュータ任せにするほうがいい。
- 261 名前：257 mailto:sage [2008/01/22(火) 01:22:29 ]
- >>259
通常と同じ、leafの子としてinsertする
>>255は挿入順の関係でたまたま直接の子になっただけだと思う
- 262 名前：デフォルトの名無しさん [2008/01/22(火) 01:28:48 ]
- >>261
それだと、同じ値を持つノードがツリー上で離れてしまいますよね。
equal_rangeをどうやって実装するのか想像がつかないのですが、簡単に教えてもらえませんか？
戻ってきたイテレータを++するたびにO(logN)のサーチが入る???
- 263 名前：デフォルトの名無しさん mailto:sage [2008/01/22(火) 01:36:14 ]
- >>262
重複を許そうが許すまいが、二分探索木はそもそもそういうものだろ
隣接した要素が木構造の上では離れた場所に置かれることがある
イテレータをどうやって実装するのが普通かは知らないけど、setとmultisetで事情が変わる訳じゃない
- 264 名前：デフォルトの名無しさん mailto:sage [2008/01/22(火) 01:55:22 ]
- >>263
まったくもってそうでした。。。。
イテレータも、単にin-orderでtraverseすれば要素同士が離れていても問題なく連続して触ってくれますね。
- 265 名前：デフォルトの名無しさん mailto:sage [2008/01/24(木) 10:22:33 ]
- COAP!
- 266 名前：デフォルトの名無しさん [2008/01/25(金) 08:16:31 ]
- COAPってナニ？
- 267 名前：デフォルトの名無しさん mailto:sage [2008/01/25(金) 08:26:55 ]
- COAP＝Containers of auto_ptr
Effective STLぐらい買え
- 268 名前：デフォルトの名無しさん mailto:sage [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 名前：デフォルトの名無しさん mailto:sage [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 mailto:sage [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 名前：デフォルトの名無しさん mailto:sage [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 mailto:sage [2008/01/25(金) 16:33:03 ]
- なるほど。。なんかfind使う意味なさそうですね。
for ( int i = 0; i < v.size(); i ++ ) {
if ( v[i].name == "もげもげ" ) puts( "一致" );
}
でもいいわけですね。ありがとうございましｔ。
- 274 名前：デフォルトの名無しさん mailto:sage [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 名前：デフォルトの名無しさん mailto:sage [2008/01/25(金) 16:48:42 ]
- もしstring.find()の検索効率を活用したいなら
文字列の格納先は単一のstringにして
name.append(文字列);
を繰り返してどんどん足していくしかないんじゃ。
で、足すときにnameの何バイト目は何個目の要素か
ってなテーブルを同時に作って、findの結果から調べられる
ようにしておくとか。
- 276 名前：デフォルトの名無しさん mailto:sage [2008/01/25(金) 18:05:03 ]
- アルゴリズムの改良でSTLが使えないか質問です。
現在、キー文字列を与えると、それに応じた
文字列を返すSTL::mapのようなコードがあります。
ただ、返す文字列が可変です。例えば、キー"気温" を
与えると”今現在”の気温「5ﾟC」を文字列で返すと
いった感じです。
現在このコードは ifとelseの連続で構成されたものと
なっておりまして、効率面でも文字列比較を繰り返し
行っており、良いものではありません。
これを実現するのに、できればmapに似た簡単で効率の
いい形で改良できないでしょうか？
- 277 名前：デフォルトの名無しさん mailto:sage [2008/01/25(金) 18:18:02 ]
- >>276
すぐに思いつくのは文字列から「文字列を返す関数」へのマップだな
"温度"を与えると「温度を計算する関数」が得られるようにする
- 278 名前：デフォルトの名無しさん mailto:sage [2008/01/25(金) 18:19:08 ]
- >>276
map<string, string(*)(void*)> のような、キー文字列→関数のマップを作ればいいんじゃないかな
- 279 名前：278 mailto:sage [2008/01/25(金) 18:20:31 ]
- void*ってなんだろう・・・無視してくださひ。。
- 280 名前：デフォルトの名無しさん mailto:sage [2008/01/25(金) 19:12:55 ]
- >>277-279
早速有難う御座います
なるほど関数ポインタをマップですか。 確かに展望良さそうです。
早速コーディング検討したいと思います。 ありがとうございました！
- 281 名前：デフォルトの名無しさん mailto:sage [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 名前：デフォルトの名無しさん mailto:sage [2008/01/25(金) 23:21:04 ]
- てか>>274に書いてあったorz>>find_if
- 283 名前：デフォルトの名無しさん mailto:sage [2008/01/26(土) 19:04:00 ]
- てかstringにsjis入れちゃだめでしょ
- 284 名前：デフォルトの名無しさん mailto:sage [2008/01/26(土) 19:05:50 ]
- どこでSJISと特定したのか興味深い。
- 285 名前：デフォルトの名無しさん mailto:sage [2008/01/27(日) 00:03:12 ]
- SJISだとしても、別に入れるのは問題ないだろ。
- 286 名前：デフォルトの名無しさん mailto:sage [2008/01/27(日) 00:15:38 ]
- findとか使わなきゃね。
- 287 名前：デフォルトの名無しさん mailto:sage [2008/01/27(日) 00:24:35 ]
- std::vectorとstd::basic_stringは分かれている必然性があんましない気がする
- 288 名前：デフォルトの名無しさん mailto:sage [2008/01/27(日) 00:27:36 ]
- vectorのメモリ連続性が保証されなくなるのは嫌なので統合反対。
- 289 名前：デフォルトの名無しさん mailto:sage [2008/01/27(日) 00:28:10 ]
- 次期 C++ だと string の連続性が保証されるよ。
- 290 名前：デフォルトの名無しさん mailto:sage [2008/01/27(日) 00:47:37 ]
- んじゃ、char_traitsをvectorに入れると只のコンテナじゃ無くなるので統合反対。
- 291 名前：デフォルトの名無しさん mailto:sage [2008/01/27(日) 00:49:36 ]
- c_str に触れればいいだけなような
- 292 名前：デフォルトの名無しさん mailto:sage [2008/01/27(日) 00:58:58 ]
- >>287
統一してしまうとまずいことがあるよ。
vectorは末尾への要素追加のならし計算時間がO(1)じゃないといけないから、参照カウントによる
copy-on-write最適化ができない。stringにはそういうしばりはないから、COWが可能。まぁ最近
はマルチスレッドの関係でCOWなstringは絶滅危惧種だけど。
他にもあったはずだが、とっさには思いつかない。
- 293 名前：デフォルトの名無しさん mailto:sage [2008/01/27(日) 01:14:54 ]
- findしちゃだめって・・もう馬鹿かと。事実上利用不可だろ
- 294 名前：デフォルトの名無しさん mailto:sage [2008/01/27(日) 01:16:36 ]
- そうは思わない。入れ物として使うなら十分。
- 295 名前：デフォルトの名無しさん mailto:sage [2008/01/27(日) 01:20:07 ]
- c_str 使って外部の検索関数使えばいいだろ。
- 296 名前：デフォルトの名無しさん mailto:sage [2008/01/27(日) 01:20:49 ]
- お前ら努力家だな
- 297 名前：デフォルトの名無しさん mailto:sage [2008/01/27(日) 01:25:12 ]
- wstringのことも時々でいいから思(ry
- 298 名前：デフォルトの名無しさん mailto:sage [2008/01/27(日) 01:25:43 ]
- wstring には SJIS なんて入れられないだろう・・・
- 299 名前：デフォルトの名無しさん mailto:sage [2008/01/27(日) 01:26:03 ]
- wstringでSJISが正しく扱えるのかい。
- 300 名前：デフォルトの名無しさん [2008/01/27(日) 01:27:23 ]
- これだからWindowsしか知らない奴は。
- 301 名前：デフォルトの名無しさん mailto:sage [2008/01/27(日) 01:31:02 ]
- stringは実用なんて論外としても、wstringもサロゲートあぼーんなわけで。。
もう文字列終わってるな
- 302 名前：デフォルトの名無しさん mailto:sage [2008/01/27(日) 01:32:51 ]
- そこでUCS-4ですよ。
- 303 名前：デフォルトの名無しさん mailto:sage [2008/01/27(日) 01:36:51 ]
- サロゲートあっても find に影響はないだろ？
- 304 名前：デフォルトの名無しさん mailto:sage [2008/01/27(日) 01:37:18 ]
- wchar_t はその環境で扱える最大サイズの文字コードを入れる事ができるサイズであって
UTF-16 だと決まってるわけでもないわけだが。実際４バイトの環境もあるし。
まあ、次期 C++ だと char16_t (UTF-16) や char32_t (UTF-32) が追加されるわけだが。
- 305 名前：デフォルトの名無しさん mailto:sage [2008/01/27(日) 01:39:36 ]
- しかしwstringだと98系はもうだめだな。
クロスプラットフォームじゃないじゃんstl。。
- 306 名前：デフォルトの名無しさん mailto:sage [2008/01/27(日) 01:40:32 ]
- クロス文字エンコーディングじゃないだけ。
- 307 名前：デフォルトの名無しさん mailto:sage [2008/01/27(日) 01:40:52 ]
- >>303
UTF-8でもfindは問題ないからそのレベルでいいんだったらwstringを使う意味がない
- 308 名前：デフォルトの名無しさん mailto:sage [2008/01/27(日) 01:41:38 ]
- >>304
それはビット幅だけじゃなくて中身もUTF-16/UTF-32であることが保証されてるの?
- 309 名前：デフォルトの名無しさん mailto:sage [2008/01/27(日) 01:42:28 ]
- >>303
sizeがだめでしょ。
- 310 名前：デフォルトの名無しさん mailto:sage [2008/01/27(日) 01:43:03 ]
- そんなもん中身を入れるコード次第だろ。
- 311 名前：デフォルトの名無しさん mailto:sage [2008/01/27(日) 01:44:59 ]
- >>309
sizeは「か」に半濁点とかまで考慮するとUTF-32でもだめ
- 312 名前：デフォルトの名無しさん mailto:sage [2008/01/27(日) 01:45:47 ]
- で、おまえらどうやってんの？
string s = "abc"; // sjis!!。findとかしないで。。
wstring s = _T("abc"); // ｳﾆｺｰﾄﾞ。98とかでビルドしないで。サロゲートやばいかも
どっちも地獄だな。CStringの方がましじゃね？
- 313 名前：デフォルトの名無しさん mailto:sage [2008/01/27(日) 01:46:11 ]
- >>309
size は配列サイズが取得できれば十分じゃないか？
- 314 名前：デフォルトの名無しさん mailto:sage [2008/01/27(日) 01:49:27 ]
- size()/length()はstrlenと等価だから。元々文字数を返すことを期待してはダメ。
- 315 名前：デフォルトの名無しさん mailto:sage [2008/01/27(日) 01:50:00 ]
- だからIBMがアレを作ったのさ
なんだっけアレ 眠くて思い出せない
- 316 名前：デフォルトの名無しさん [2008/01/27(日) 01:51:44 ]
- ICU
- 317 名前：デフォルトの名無しさん mailto:sage [2008/01/27(日) 01:52:02 ]
- 集中治療室
- 318 名前：デフォルトの名無しさん mailto:sage [2008/01/27(日) 01:54:11 ]
- >>308
Yes.
- 319 名前：デフォルトの名無しさん mailto:sage [2008/01/27(日) 01:55:41 ]
- >>311
つか、ウニコード捨てればええだけの話しちゃうの？
ウニコード捨ててもそんなにデメリットないような… … …
- 320 名前：デフォルトの名無しさん mailto:sage [2008/01/27(日) 01:56:41 ]
- サロゲートはサブマリン的に最近問題に。。Unicode側は昔っから、
Utf-16はランダムアクセスはできない文字コードですよと言ってきたんだけど
なんとなく流されて2バイトで便利みたいに扱われたり、たいていsizeは文字数を
返すとか説明されたり。。もう混乱の極み。
Javaとかはlengthは2バイト単位の長さを返す仕様に変わり、文字数の取得は
codePointCountが追加されたりどの言語も苦肉の策を講じてる状態。
stlもなんとかしないといけない状況ではある。
- 321 名前：デフォルトの名無しさん mailto:sage [2008/01/27(日) 01:58:34 ]
- >>320
日本語だけ扱ってる状況でサロゲートペア関係あるっけ
- 322 名前：デフォルトの名無しさん mailto:sage [2008/01/27(日) 01:58:42 ]
- むしろ、stringをタダのコンテナに引きずり落とすくらいの意気込みで。
- 323 名前：デフォルトの名無しさん mailto:sage [2008/01/27(日) 01:59:59 ]
- size が文字数返すなら、イテレータは１文字ずつ拾ってくる必要があるし、
そうなった時その型はどうするんだ？ って話になる。
UTF-32 で合成があった場合とか、64ビット値を返すのか？
- 324 名前：デフォルトの名無しさん mailto:sage [2008/01/27(日) 02:01:42 ]
- やっぱ速度の問題もあるし、javaみたいにsizeとcodePointCountの両方用意
しとくしかないんじゃないかなあと
- 325 名前：デフォルトの名無しさん [2008/01/27(日) 02:02:41 ]
- gccのwchat_tは32bitだから楽勝
- 326 名前：デフォルトの名無しさん mailto:sage [2008/01/27(日) 02:04:33 ]
- >321
JIS2004と愉快な仲間たち。
>323
final はsizeいくつ、って話だよね。
- 327 名前：デフォルトの名無しさん mailto:sage [2008/01/27(日) 02:05:42 ]
- >>325
サロゲートの文字数は取れない点は同じだけどね
- 328 名前：デフォルトの名無しさん mailto:sage [2008/01/27(日) 02:07:28 ]
- イテレータだけじゃなくて [ ] も文字数に合わせた形にする必要がある。
でも、ランダムアクセスなんて無理じゃん？
- 329 名前：デフォルトの名無しさん mailto:sage [2008/01/27(日) 02:09:46 ]
- world_char_tが定まるまで待ちましょう。
- 330 名前：デフォルトの名無しさん mailto:sage [2008/01/27(日) 02:12:03 ]
- 結局ランダムアクセス用の冗長なデータを込みにしたクラスにしないとどうしようもないし、
パフォーマンス上そこまで標準に組み込まれることは無いだろう。
まあ、それ用のクラスを string 系列とは別に作ることは可能だろうが、
SJIS とかはまあ無理だな。
- 331 名前：デフォルトの名無しさん mailto:sage [2008/01/27(日) 02:12:42 ]
- length(L"final")が５と帰ってきてくれたら、なにか嬉しい？
|
 |
