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

【C++】STL（Standard ..

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

264:デフォルトの名無しさん
08/01/22 01:55:22
>>263
まったくもってそうでした。。。。
イテレータも、単にin-orderでtraverseすれば要素同士が離れていても問題なく連続して触ってくれますね。

265:デフォルトの名無しさん
08/01/24 10:22:33
COAP!

266:デフォルトの名無しさん
08/01/25 08:16:31
COAPってナニ？

267:デフォルトの名無しさん
08/01/25 08:26:55
COAP＝Containers of auto_ptr

Effective STLぐらい買え

268:デフォルトの名無しさん
08/01/25 10:01:54
ありがとう

269:デフォルトの名無しさん
08/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:デフォルトの名無しさん
08/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
08/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:デフォルトの名無しさん
08/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
08/01/25 16:33:03
なるほど。。なんかfind使う意味なさそうですね。

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

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

274:デフォルトの名無しさん
08/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:デフォルトの名無しさん
08/01/25 16:48:42
もしstring.find()の検索効率を活用したいなら
文字列の格納先は単一のstringにして

name.append(文字列);

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

276:デフォルトの名無しさん
08/01/25 18:05:03
アルゴリズムの改良でSTLが使えないか質問です。

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

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

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

277:デフォルトの名無しさん
08/01/25 18:18:02
>>276
すぐに思いつくのは文字列から「文字列を返す関数」へのマップだな
"温度"を与えると「温度を計算する関数」が得られるようにする

278:デフォルトの名無しさん
08/01/25 18:19:08
>>276
map<string, string(*)(void*)> のような、キー文字列→関数のマップを作ればいいんじゃないかな

279:278
08/01/25 18:20:31
void*ってなんだろう・・・無視してくださひ。。

280:デフォルトの名無しさん
08/01/25 19:12:55
>>277-279
早速有難う御座います

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

281:デフォルトの名無しさん
08/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:デフォルトの名無しさん
08/01/25 23:21:04
てか>>274に書いてあったorz>>find_if

283:デフォルトの名無しさん
08/01/26 19:04:00
てかstringにsjis入れちゃだめでしょ

284:デフォルトの名無しさん
08/01/26 19:05:50
どこでSJISと特定したのか興味深い。

285:デフォルトの名無しさん
08/01/27 00:03:12
SJISだとしても、別に入れるのは問題ないだろ。

286:デフォルトの名無しさん
08/01/27 00:15:38
findとか使わなきゃね。

287:デフォルトの名無しさん
08/01/27 00:24:35
std::vectorとstd::basic_stringは分かれている必然性があんましない気がする

288:デフォルトの名無しさん
08/01/27 00:27:36
vectorのメモリ連続性が保証されなくなるのは嫌なので統合反対。

289:デフォルトの名無しさん
08/01/27 00:28:10
次期 C++ だと string の連続性が保証されるよ。

290:デフォルトの名無しさん
08/01/27 00:47:37
んじゃ、char_traitsをvectorに入れると只のコンテナじゃ無くなるので統合反対。

291:デフォルトの名無しさん
08/01/27 00:49:36
c_str に触れればいいだけなような

292:デフォルトの名無しさん
08/01/27 00:58:58
>>287
統一してしまうとまずいことがあるよ。

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

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

293:デフォルトの名無しさん
08/01/27 01:14:54
findしちゃだめって・・もう馬鹿かと。事実上利用不可だろ

294:デフォルトの名無しさん
08/01/27 01:16:36
そうは思わない。入れ物として使うなら十分。

295:デフォルトの名無しさん
08/01/27 01:20:07
c_str 使って外部の検索関数使えばいいだろ。

296:デフォルトの名無しさん
08/01/27 01:20:49
お前ら努力家だな

297:デフォルトの名無しさん
08/01/27 01:25:12
wstringのことも時々でいいから思(ry

298:デフォルトの名無しさん
08/01/27 01:25:43
wstring には SJIS なんて入れられないだろう・・・

299:デフォルトの名無しさん
08/01/27 01:26:03
wstringでSJISが正しく扱えるのかい。

300:デフォルトの名無しさん
08/01/27 01:27:23
これだからWindowsしか知らない奴は。

301:デフォルトの名無しさん
08/01/27 01:31:02
stringは実用なんて論外としても、wstringもサロゲートあぼーんなわけで。。
もう文字列終わってるな

302:デフォルトの名無しさん
08/01/27 01:32:51
そこでUCS-4ですよ。

303:デフォルトの名無しさん
08/01/27 01:36:51
サロゲートあっても find に影響はないだろ？

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

305:デフォルトの名無しさん
08/01/27 01:39:36
しかしwstringだと98系はもうだめだな。
クロスプラットフォームじゃないじゃんstl。。

306:デフォルトの名無しさん
08/01/27 01:40:32
クロス文字エンコーディングじゃないだけ。

307:デフォルトの名無しさん
08/01/27 01:40:52
>>303
UTF-8でもfindは問題ないからそのレベルでいいんだったらwstringを使う意味がない

308:デフォルトの名無しさん
08/01/27 01:41:38
>>304
それはビット幅だけじゃなくて中身もUTF-16/UTF-32であることが保証されてるの?

309:デフォルトの名無しさん
08/01/27 01:42:28
>>303
sizeがだめでしょ。

310:デフォルトの名無しさん
08/01/27 01:43:03
そんなもん中身を入れるコード次第だろ。

311:デフォルトの名無しさん
08/01/27 01:44:59
>>309
sizeは「か」に半濁点とかまで考慮するとUTF-32でもだめ

312:デフォルトの名無しさん
08/01/27 01:45:47
で、おまえらどうやってんの？
string s = "abc"; // sjis!!。findとかしないで。。
wstring s = _T("abc"); // ｳﾆｺｰﾄﾞ。98とかでビルドしないで。サロゲートやばいかも

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

313:デフォルトの名無しさん
08/01/27 01:46:11
>>309
size は配列サイズが取得できれば十分じゃないか？

314:デフォルトの名無しさん
08/01/27 01:49:27
size()/length()はstrlenと等価だから。元々文字数を返すことを期待してはダメ。

315:デフォルトの名無しさん
08/01/27 01:50:00
だからIBMがアレを作ったのさ
なんだっけアレ　眠くて思い出せない

316:デフォルトの名無しさん
08/01/27 01:51:44
ICU

317:デフォルトの名無しさん
08/01/27 01:52:02
集中治療室

318:デフォルトの名無しさん
08/01/27 01:54:11
>>308
Yes.

319:デフォルトの名無しさん
08/01/27 01:55:41
>>311
つか、ウニコード捨てればええだけの話しちゃうの？
ウニコード捨ててもそんなにデメリットないような… … …

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

321:デフォルトの名無しさん
08/01/27 01:58:34
>>320
日本語だけ扱ってる状況でサロゲートペア関係あるっけ

322:デフォルトの名無しさん
08/01/27 01:58:42
むしろ、stringをタダのコンテナに引きずり落とすくらいの意気込みで。

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

324:デフォルトの名無しさん
08/01/27 02:01:42
やっぱ速度の問題もあるし、javaみたいにsizeとcodePointCountの両方用意
しとくしかないんじゃないかなあと

325:デフォルトの名無しさん
08/01/27 02:02:41
gccのwchat_tは32bitだから楽勝

326:デフォルトの名無しさん
08/01/27 02:04:33
>321
JIS2004と愉快な仲間たち。

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

327:デフォルトの名無しさん
08/01/27 02:05:42
>>325
サロゲートの文字数は取れない点は同じだけどね

328:デフォルトの名無しさん
08/01/27 02:07:28
イテレータだけじゃなくて [ ] も文字数に合わせた形にする必要がある。
でも、ランダムアクセスなんて無理じゃん？

329:デフォルトの名無しさん
08/01/27 02:09:46
world_char_tが定まるまで待ちましょう。

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

331:デフォルトの名無しさん
08/01/27 02:12:42
length(L"ﬁnal")が５と帰ってきてくれたら、なにか嬉しい？

332:デフォルトの名無しさん
08/01/27 02:14:25
wstringのfind,insert,appendとかはサロゲートも平気そうな気がするけど
なんとも微妙。。
文字とか文字数を意識した扱いをしようとしない限りは平気なのかな・・？

333:デフォルトの名無しさん
08/01/27 02:15:23
文字数を指定しての置換とかはやばそうだな。

334:デフォルトの名無しさん
08/01/27 02:16:12
非常によく使うデータ構造だから、効率を犠牲にして理想に走れないもどかしさ

335:デフォルトの名無しさん
08/01/27 02:16:41
findは大丈夫そうだけど、insert/appendは、サロゲートの前半だけ＋別の文字、
みたいな不正な文字列を受け付けるべきか、みたいな話はあるよね。

336:デフォルトの名無しさん
08/01/27 02:17:18
英語圏だとマルチバイトうぜーとかしか思われてないだろうしな。

337:デフォルトの名無しさん
08/01/27 02:18:12
stdc++のレベルで理想に走らなくても良いよ。というか理想がなんなのかも分からないし。この話題はこっち向きじゃないかい。

C++で新しい文字列クラスをつくろう 2
ｽﾚﾘﾝｸ(tech板)

338:デフォルトの名無しさん
08/01/27 02:20:06
普通insertする文字とかiteratorもfindの結果のiteratorとかなわけで
問題なくね？
>>333
確かに文字数指定でサロゲート文字の途中とかになってたら文字が切れちゃう
よねぇ

339:デフォルトの名無しさん
08/01/27 02:21:08
もうこういうのは boost の領分かもしれないな。

340:デフォルトの名無しさん
08/01/27 02:21:41
がしがし書き換えたいならutf32に変換してから、書き換えて、utf8なりutf16なりに戻すほうが簡単そうだ。

341:デフォルトの名無しさん
08/01/27 02:24:29
結局、find/appendなどの引数に与える文字が文字の途中などでない、
と文字数指定の関数に文字の途中などの数を指定しない
を守ってればサロゲートもおけ、でいいのかな？

342:デフォルトの名無しさん
08/01/27 02:26:18
まぁあと15年位したら皆UTF-32でのんびりやってるさ

343:デフォルトの名無しさん
08/01/27 02:26:48
>>341
それを守るためにどれだけのコストが掛かるかって話してるんじゃないのか

344:デフォルトの名無しさん
08/01/27 02:27:16
>文字数指定の関数に文字の途中などの数を指定しない
これを守るのがすげー大変そうだ。

345:デフォルトの名無しさん
08/01/27 02:27:59
まだSJISが使われてると思います＞＜

346:デフォルトの名無しさん
08/01/27 02:28:55
SJIS 専用のクラスならまあ作れるだろうな。

347:デフォルトの名無しさん
08/01/27 02:29:01
俺頭から5文字取るみたいなコードとりかえしがつかないくらい書いてるな

348:デフォルトの名無しさん
08/01/27 02:32:47
>>341
文字数ならサロゲートを割ってしまうことはないよ。
サロゲートペア一組で一文字だから。

349:デフォルトの名無しさん
08/01/27 02:33:58
wchar五個分でなくて、5「文字」分きちんと取れるコードを？

350:デフォルトの名無しさん
08/01/27 02:35:13
たとえば、
「か゛」は１文字という扱いでいいのか？
「か゛゛゛゛゛゛゛゛゛゛゛゛゛゛゛゛゛゛゛゛゛゛゛゛゛゛゛゛゛゛゛゛゛゛(略」
みたいなどうしようもない連中はどうしよう？

351:デフォルトの名無しさん
08/01/27 02:38:26
>>348
std::string(wstring)の「文字数指定」は、1文字が固定長のコード体系が前提だから、サロゲがあると壊れるよ。
>>350
それペアになってなくない？

352:デフォルトの名無しさん
08/01/27 02:38:36
>>348
>サロゲートペア一組で一文字
一組で4バイト(結合文字は6バイトもある)

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

353:デフォルトの名無しさん
08/01/27 02:42:20
>>352
文字数というのは、キャラクタ数という意味で使った。

354:デフォルトの名無しさん
08/01/27 02:47:21
CString的にTCHAR使えてさらにクロスなものはないのかね？

355:デフォルトの名無しさん
08/01/27 02:48:52
>>350
合成文字は2キャラクタでしょ。
合成文字をぶった切ると、意味は通じなくなるかもしれないが違法ではない。

356:デフォルトの名無しさん
08/01/27 02:53:07
ああ、その「キャラクタ数」というのは、要するにUTF-32換算なわけか。

357:デフォルトの名無しさん
08/01/27 03:00:31
Winではstringは使うな。2バイト目が1バイト目とかぶってやがるからな。
wstringはサロゲートに注意して使え。途中で切るなよ。
Win98とかまだやってるカスはCStringでも使ってろ。
LinuxではstringでもEUCとUTF-8は2バイト目が1バイト目とかぶらないからまだ
なんとかなるはずだ。
クロスにしたいなら文字列クラスは当然自前だろ？

が俺の現状の認識

358:デフォルトの名無しさん
08/01/27 03:02:31
>>327
ハァ?

359:デフォルトの名無しさん
08/01/27 03:09:34
>>358
へ？

360:デフォルトの名無しさん
08/01/27 03:14:40
>>357
追加でMac OS XはCFString使っとけ。以上。

361:デフォルトの名無しさん
08/01/27 04:50:39
>>357
OS 関係なくてエンコーディングの話だろ？
Windows でも UTF-8 使えば問題ないし、 Linux でも Shift_JIS 使えば問題は出る。
クロスにしたければエンコーディングを OS 任せにしなければ良いだけの話。
たとえば UTF-8 を使うと決めれば std::string でもいけるでしょ。

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

363:デフォルトの名無しさん
08/01/27 05:33:05
１文字が何バイト使うかはどれ使っても一定ではない　どれを使うか決まっていればどれ使ってもよい

364:デフォルトの名無しさん
08/01/27 05:48:20
UTF-32は4バイト固定。でも合成文字があるので結局同じ問題は残る。

365:デフォルトの名無しさん
08/01/27 06:53:55
一方ロシアはモールス符号を使った

366:デフォルトの名無しさん
08/01/27 06:59:29
合成文字なんて捨てろ
すべての文字を表現したいなんて無駄の極み

367:デフォルトの名無しさん
08/01/27 08:26:25
おいおい、放棄かよ

368:デフォルトの名無しさん
08/01/27 08:37:31
>>362
入出力と多言語以外の問題はなし　日本語使うんだったらどれでも同じ　
入出力にコンバートするのに手間がかかるかどうかだけ

369:デフォルトの名無しさん
08/01/27 10:08:29
全部画像でおｋ

370:デフォルトの名無しさん
08/01/27 12:33:49
16x16ピクセル（256ビット）のパターンで全ての文字を表現するとかどっかで見たな。

371:デフォルトの名無しさん
08/01/27 13:24:31
文字コード総合スレだと思った
つーかPDFでおｋ

372:デフォルトの名無しさん
08/01/27 13:25:37
(　д ) ﾟﾟ

373:デフォルトの名無しさん
08/01/27 15:15:28
>>365
一方ロシアは画像を使った

こっちの方がしっくりくるな。

374:デフォルトの名無しさん
08/01/27 15:52:02
>>370
宇宙の星にそれぞれ新しい文字で名前つけてもあまるだろｗ

375:デフォルトの名無しさん
08/01/27 16:26:01
一文字32バイトは流石に先取りしすぎだな

376:デフォルトの名無しさん
08/01/27 16:37:26
string path = "c:\\機能仕様書\\01.doc";
path.find("\\");
こんなであぼーんするstringは危険としか言いようがない

377:デフォルトの名無しさん
08/01/27 16:47:52
そんなアホなことをする方が悪い。

378:デフォルトの名無しさん
08/01/27 16:55:52
1文字に1GB

379:デフォルトの名無しさん
08/01/27 16:56:20
もう OCR でいいよ・・・

380:デフォルトの名無しさん
08/01/27 17:24:37
人間様の認識能力を利用する形が最強

381:デフォルトの名無しさん
08/01/27 17:28:05
人間なんてよく読み間違うじゃん

382:デフォルトの名無しさん
08/01/27 17:56:59
>371
CID(AJ15)のことか？あのコードも印刷以外に使うのは
結構アレなんだけどなー。

383:デフォルトの名無しさん
08/01/27 18:00:16
Ｃ＋＋
メンバ関数内で
スコープ解決演算子で
classname::メンバ変数の値変更するのと
this->メンバ変数　の値変更するのは何が違うの？

384:デフォルトの名無しさん
08/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:デフォルトの名無しさん
08/01/27 18:07:20
>>377
findが使えないstringって・・・カスめ

386:デフォルトの名無しさん
08/01/27 18:09:21
path[path.find("\\")] == '\\'になるじゃん、ちゃんと。

387:デフォルトの名無しさん
08/01/27 18:12:41
返答ありがとう。

最初の

this->m は　Ｃ　のオブジェクトのメンバ変数ｍ
this->P::m は何でしょうか？

388:デフォルトの名無しさん
08/01/27 18:14:13
>>386
まじか？

389:デフォルトの名無しさん
08/01/27 18:16:16
>>386
そりゃなるだろwww

390:デフォルトの名無しさん
08/01/27 18:16:42
>>387
P の m にきまっちょるだろう

391:デフォルトの名無しさん
08/01/27 18:22:57
>>386
マジレスすると「能」の2バイト目の「\」がfindで見つかっちゃったんです。
string s = SJISの日本語;
はやっちゃだめなんです。初心者はみんなやってしまうんですが。

392:デフォルトの名無しさん
08/01/27 18:23:56
>>384
>>390

継承したときに変数名かぶった場合コウ書くんですね。

でも、多重に継承した場合、どう書くんだろう？

393:デフォルトの名無しさん
08/01/27 18:29:12
scope

394:デフォルトの名無しさん
08/01/27 18:35:01
>>392
間の型へ一旦 this をアップキャストすると良い。

395:デフォルトの名無しさん
08/01/27 18:35:31
>>391
だから、find とか使わない分には使っていいんだってばよ。

396:デフォルトの名無しさん
08/01/27 18:35:39
あー、ダイヤモンド継承か。
P1::P2::Pb::a = 100;
みたいに、継承順を追いかければ指定できたような・・・

397:デフォルトの名無しさん
08/01/27 18:37:14
char []hoge = SJIS文字列;　　とかやって、
strchr( hoge, '\\');　ってまずいじゃん。
でも、「char配列にSJIS文字列入れるの禁止」って言うのはどうよ、みたいな。

398:デフォルトの名無しさん
08/01/27 18:37:36
別の言語の癖が出てるぜ

399:デフォルトの名無しさん
08/01/27 18:37:59
>>397
そうそう。そんな感じ。

400:デフォルトの名無しさん
08/01/27 18:42:17
文字コードの話って、荒れる割に全然面白くないし、有用な知見も得られないんだよな。

401:デフォルトの名無しさん
08/01/27 18:44:35
結局毛唐が ASCII 以外どうでもいいと思ってるからな。

402:デフォルトの名無しさん
08/01/27 18:47:46
何も考えずに動いていたCStringがなつかすぃ。。
そういえばなんでがんばってfind禁止のダウングレードのstd::string使ってるん
だったっけ？
だれかどこでも動くCString作ってぇぇ

403:デフォルトの名無しさん
08/01/27 18:49:03
>>393
>>394
>>396

ありがと。
やっぱＣ＋＋はスゲーや。
Ｃのシンプルな文法に慣れきったオレには奥が深いぜ。

404:デフォルトの名無しさん
08/01/27 18:49:05
ドザは Windows のことしか考えないから困る。

405:デフォルトの名無しさん
08/01/27 18:52:20
どこでも動く？
どこでもSJIS使うの？

406:デフォルトの名無しさん
08/01/27 18:52:31
Linuxとかｶｽいらねーし

407:デフォルトの名無しさん
08/01/27 18:54:02
Mac では SJIS 使わん事も無い。
UTF-8 や EUC も使うが。

408:デフォルトの名無しさん
08/01/27 18:57:06
ASCII自体が腐ってるからな。誰だよ、あんなコードにしたのは。

409:デフォルトの名無しさん
08/01/27 18:58:30
>>405
いや、できればマクロとかでプラットフォームごととか文字コードとか
切り替えられてさ、当たり前だけどfindとかも問題なく動いちゃうやつ。
CStringみたいに楽に使えて、でもUTF-8とか16とかも平気な感じ。
std::ustringみたいに統一しちゃってさ。boostとかかな。

410:デフォルトの名無しさん
08/01/27 18:59:32
findだけの問題ならすぐ解決するけどな。
ただ、SJISのままだと単純サーチにするしかないので効率は悪い。

411:デフォルトの名無しさん
08/01/27 19:01:36
>>410
そりゃWinの場合は内部的には_mbsstr呼ぶとかして高速化しる

412:デフォルトの名無しさん
08/01/27 19:01:45
wstringに自動変換する const char *n_str();と
wstring(char*)を付ければ解決するような気になるけど？

413:デフォルトの名無しさん
08/01/27 19:01:47
>>406
普通sunだよな

414:デフォルトの名無しさん
08/01/27 19:05:17
Windows なら mbs 系でおkだが、
他の環境だとその手の関数あるんだろうか。

415:デフォルトの名無しさん
08/01/27 19:22:06
ついでに質問なのですが、TCHARみたいにstringとwstringを切り分けるにはどう
すればよいのでしょうか？以下のようにしておく必要があるのでしょうか？
他にもっといい方法があるのでしょうか？
#ifdef UNICODE
　#define tstring string
else
　#define tstring wstring
まだ98でもXPでも動かしたいので・・

416:デフォルトの名無しさん
08/01/27 19:23:31
組み込み型にしてもいい位のデータ構造なのに
クロスに作るのが難しいこんな世の中じゃ

417:デフォルトの名無しさん
08/01/27 19:25:51
>>415
とりあえず #define よりは typedef のほうがいいだろうな。

418:デフォルトの名無しさん
08/01/27 19:30:39
>>415
なにかわからないがよくないことが起こりそうな悪寒

419:デフォルトの名無しさん
08/01/27 19:41:43
charとwchar_tも切り替えないと。リテラル使ってるところがあったらそれもマクロで囲まないとね。

…めんどくさいでしょ。

420:デフォルトの名無しさん
08/01/27 19:45:37
つまり、C++0xのユーザ定義リテラルの登場を待てと

421:デフォルトの名無しさん
08/01/27 19:51:06
>>419
それは TCHAR と _T として既に用意されているだろう。

422:デフォルトの名無しさん
08/01/27 23:53:01
>>415
typedef std::basic_string<TCHAR> tstring;

>>362
361のようなことを現実にやれるソフトウェアでは、
多言語対応のため、文字列リテラルの大半はソースコードに含まれないとか、
APIはラッパー層があるから変換も余裕とかそういう次元にいると思う。

423:デフォルトの名無しさん
08/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:デフォルトの名無しさん
08/01/28 00:57:46
> find(":")
他に理由がなければ、ASCII分はそのままソースに書いていいと思った。

425:デフォルトの名無しさん
08/01/28 00:59:56
そんなわけがないだろ。

426:デフォルトの名無しさん
08/01/28 01:02:52
A 系使えば大丈夫。

427:デフォルトの名無しさん
08/01/28 01:34:22
せっかくWinがUTF-16なのに内部エンコーディングをUTF-8にして、API呼ぶたびに
UTF-8からUTF-16に変換はちょっとやだなあ。
全てのAPIをラップする開発コストに加えて、実行時の変換コストまでかかるし。。
やっぱWinはUTF-16でいきたいね。

428:デフォルトの名無しさん
08/01/28 01:37:11
いい加減スレチガイだということに(ry

429:デフォルトの名無しさん
08/01/28 09:45:10
std::string/wstringは最重要のコンテナだしスレ違いとは思わんが・・
結局文字コード周りはいまいちなのがわかるだけなんだよなあ。。

430:デフォルトの名無しさん
08/01/28 14:04:09
話の流れぶった切って申し訳ないが言わせてくれ。
なんか良スレの悪寒。

431:デフォルトの名無しさん
08/01/28 15:13:29
日本語と中国語の区別ができない腐れた文字コードそれがUnicode
中国が大体元凶だけどな

432:デフォルトの名無しさん
08/01/28 15:26:40
> 内部エンコーディングをUTF-8にして、
> API呼ぶたびにUTF-8からUTF-16に変換
Dのことかー！

433:デフォルトの名無しさん
08/01/28 16:15:55
>>431 4.0からは区別できますよ

434:デフォルトの名無しさん
08/01/28 16:34:19
>>431
言語の区別ができない文字コードはUnicodeに限らないんだよ

435:デフォルトの名無しさん
08/01/28 17:12:12
ユニコードは本格的多国語環境や16ビット固定長を宣伝文句にしていたからねえ。
次々と撤回して期待外れだったよな。

436:デフォルトの名無しさん
08/01/28 17:37:19
だから、多国語ではなく多文字だったと。

437:デフォルトの名無しさん
08/01/28 17:44:51
見苦しい

438:デフォルトの名無しさん
08/01/28 18:07:33
ユニコードって、UNIXの文字コードだったから
ユニコードって言うんだよね。

439:デフォルトの名無しさん
08/01/28 18:27:51
おまいらいい加減スレ違いだぞコノヤロー。

440:デフォルトの名無しさん
08/01/28 19:13:14
>>438-439
しらんかった

441:デフォルトの名無しさん
08/01/28 19:15:54
ユニコード表みるとハングルが異様なほど文字数が多い
中国だけじゃないぞ

442:デフォルトの名無しさん
08/01/28 19:24:34
>>441
ハングルは現在全く使用されない組み合わせも全部作るように
韓国が強く要求したんだと

それでbatangが異常に膨れている。
韓国死ねよ。

443:デフォルトの名無しさん
08/01/28 19:30:25
>>442 にほんだって「あ゛」とかいれてるじゃん。

444:デフォルトの名無しさん
08/01/28 19:35:52
URLﾘﾝｸ(unicode.org)
ここをみるかぎり、「あ゛」は単一のコードとして存在しないようだが

445:デフォルトの名無しさん
08/01/28 19:57:49
ごめん、勘違いだったかも。でも日本人だって「あ゛」いれたいしぃ。
可変長で6バイトでもよくなったんだから、なんでもいれていいと思う。

446:デフォルトの名無しさん
08/01/28 19:59:46
>>443
やあチョーセンジン

447:デフォルトの名無しさん
08/01/28 20:06:35
>>442 欧米人にしたらCJK死ねよなわけだが。
なんでなかよくできんもんかね。

448:デフォルトの名無しさん
08/01/28 20:10:36
仲の良い隣国つーのは歴史上稀なわけだが。
稀つーかあるのか。

449:デフォルトの名無しさん
08/01/28 20:13:08
日本だって古代は中国と仲良かったじゃん。
あと、中国と韓国。
どちらも、主従関係だけどｗ

450:デフォルトの名無しさん
08/01/28 20:42:13
「仲良かった古代」、って遣唐使廃止まででそ。1000年も前の話だし。

451:デフォルトの名無しさん
08/01/28 21:41:37
当時は海ってのは命がけで渡るもの凄い大きな壁だったわけで、
隣国っつーよりは、日本とアメリカ・・・は言い過ぎかもしれんが、
そんな感じだったと思うぜ。

452:デフォルトの名無しさん
08/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:デフォルトの名無しさん
08/01/28 22:06:43
URLﾘﾝｸ(www.open-std.org)
こんなのがあったのね。知らんかった

確かにゲームや組み込みではSTLそのまま使うのはキツイわな

454:デフォルトの名無しさん
08/01/28 22:11:55
>>447
電脳創世記っていう本にあったんだが、そもそも「CJKその他ヨーロッパの小国死ねよ」
ってやってる連中はアルファベットしかないコードしか使ってなくて、それを日本人が
「文字コード問題は俺たちが解決して業績上げますからメリケン共は口出ししなくても良いよ＾＾」
って挑発して今の流れになったんだと思う。

455:デフォルトの名無しさん
08/01/29 02:36:05
>>453
ゲームがメモリをキツキツに使うからって、数バイト～数十～数百バイト単位の
標準ライブラリのメモリ確保までキツキツにしても、あんまり関係ないと思うんだ。

どうせ画像やサウンドデータが１個増えればだけでそこらへんの努力は
吹っ飛ぶもんじゃないの？処理負荷にしてもさ。

456:デフォルトの名無しさん
08/01/29 02:42:20
>>442
漢字使用国がそれだけは言っちゃいかんだろ
「じゃお前ら文字数が多すぎるから統合ね」と言われても何も言い返せない
むしろ韓国みたいにもっと初期の段階で分離しろと言い張れば分離できたかも
しれないのに日本人おとなしすぎ

457:デフォルトの名無しさん
08/01/29 02:55:03
文字、文字コード関係はこっちいけよ

458:デフォルトの名無しさん
08/01/29 02:55:33
ｽﾚﾘﾝｸ(tech板)

459:デフォルトの名無しさん
08/01/29 02:58:15
英語・日本語・中国語間のソフトやマニュアルの翻訳をやってるけど
ほぼ同じ意味の文章なら中国語が一番少ないデータサイズで書ける

460:デフォルトの名無しさん
08/01/29 03:06:02
そんなの中国語知らん俺でも分かるっちゅーの

461:デフォルトの名無しさん
08/01/29 03:47:21
utf-8で？
アニメの中国語のfansubとか見るとかなが入った日本語と
漢字ばっかりの中国語で文字数そんなに変わらんように見えたけど。
だから画数で言えば中国語は不利。

462:デフォルトの名無しさん
08/01/29 04:43:57
一文字に線をたくさん詰め込むんだから、字数が少なくならないとおかしい。

ような気もする。

463:デフォルトの名無しさん
08/01/29 06:14:49
>>455
ゲーム機はメインメモリ領域が結構キツイんでないの

464:デフォルトの名無しさん
08/01/29 06:33:10
>>440
嘘過ぎる

465:デフォルトの名無しさん
08/01/29 06:40:30
さすがに>>440は釣りじゃないのか

466:デフォルトの名無しさん
08/01/29 06:41:36
>>462
ちょうどいいのがなかったけど、これとか
URLﾘﾝｸ(jp.youtube.com)

467:デフォルトの名無しさん
08/01/29 07:28:09
詩とか台詞の翻訳はちょっと特殊じゃないか？
ってどこへ行こうとしてるんだこのスレは

468:デフォルトの名無しさん
08/01/29 15:13:48
標準STLではunicodeをちゃんと扱えるんでしょうか？
処理系依存では（例えばVC++とか）扱えそうですけど。

469:デフォルトの名無しさん
08/01/29 16:35:57
ちゃんと扱う、の定義次第。

wstring, wchar_t を問題なく扱えればOKなのか？それなら問題ないよ。
ロカール処理やエンコーディング変換のための十分なサポートがあるか？それなりしかない。

470:デフォルトの名無しさん
08/01/29 21:06:41
>>455
コンテナ(というかアロケータ)のメモリ効率は重要だと思うが。
アラインメントやページ境界にかなり気をつかっているらしい。

演算効率についてはちょっと読みきれていないが...
inline展開とか命令キャッシュ効率とか、分岐予測の弱いプロセッサのこととか、
いろいろ書いてある。

でかいボトルネックは取り除いた上でさらにどうがんばるかって話では。

>>463
"Game platform memory metrics"ってところに主要なゲーム機のspecが書いてある。

471:デフォルトの名無しさん
08/01/29 21:17:44
EAがやたらマルチプラットフォームでゲームを作れるのは
この辺がしっかりしてるからかな

まぁ無理だろうけど、一部位公開してほしいな

472:デフォルトの名無しさん
08/01/29 23:48:57
VC9でライブラリを作ろうとするとえらーがでます。
使えないですか？

473:デフォルトの名無しさん
08/01/29 23:53:57
主語を書け。

474:デフォルトの名無しさん
08/01/30 00:12:34
むちゃぶりだな

475:デフォルトの名無しさん
08/01/30 00:50:00
バージョンは5.1.5です。

476:デフォルトの名無しさん
08/01/30 01:43:11
わたしにほんごわかりません

477:デフォルトの名無しさん
08/01/30 01:59:02
ベンチャーキャピタルが図書館の設立に失敗？

478:デフォルトの名無しさん
08/01/30 15:09:31
STLportじゃないの

479:デフォルトの名無しさん
08/01/31 12:03:42
マルチスレッドにてqueueを使いたいのですが、
STL等にセマフォを任せることは出来ないでしょうか？

480:デフォルトの名無しさん
08/01/31 12:06:11
基本的にSTLはスレッドセーフではない。

481:デフォルトの名無しさん
08/01/31 12:31:30
>>479
いまどきの実装であれば、たいていドキュメントにマルチスレッドについて書かれている。
そういう記述が無いとか、書かれた保証では不十分だとか、広い移植性が必要だとか、
ドキュメントを読むのがメンドイとか言うんなら自分でなんとかするしかない。

482:デフォルトの名無しさん
08/01/31 18:06:11
std::stringの配列の連続性は保障されてないそうですが、
実際配列が連続じゃない実装をしてる環境ってあるんですか？

483:デフォルトの名無しさん
08/01/31 18:10:37
配列じゃないよ

484:479
08/01/31 18:50:24
>>480-481
ありがとうございました。　無い事が分かって安心しました。
必死で作って、既に有ったらかなり凹むのでｗ（勉強にはなるけど）
WinAPIのCreateSemaphore()かmutexで検討したいと思います。

485:デフォルトの名無しさん
08/01/31 19:52:11
まあ実際はc_str()の動作を速くするために連続の場合が多いけどな。
しかもヌルターミネータ文字まで入ってたり。

486:デフォルトの名無しさん
08/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:デフォルトの名無しさん
08/01/31 19:58:43
std::ropeは標準じゃないけど、初めから切れ切れの文字列を
つなぎ合わせる事を想定してるな。

488:デフォルトの名無しさん
08/01/31 20:01:32
だからstd::ropeにはメンバ関数c_str()がない。

489:デフォルトの名無しさん
08/01/31 20:02:47
でもSTLportのstd::ropeにはc_str()があったりする。変なの。

490:デフォルトの名無しさん
08/01/31 20:04:03
標準じゃないのに std を使うのは違和感あるよな。

491:デフォルトの名無しさん
08/01/31 20:06:10
STLportはSGI-STLに妙なこだわりを持ってるよな。
何か言われてんのかな。

492:デフォルトの名無しさん
08/01/31 21:13:41
> 基本的にSTLはスレッドセーフではない
例えばどんな場合？

493:デフォルトの名無しさん
08/01/31 21:15:33
>>492
どんな場合って・・・何するにしてもスレッドセーフを要求する
仕様なんてないはずだけども。

494:デフォルトの名無しさん
08/01/31 21:17:02
STLportはスレッドセーフだったような

495:デフォルトの名無しさん
08/01/31 21:21:14
うーん、書いてないとスレッドセーフでないってのも・・
beginthread一回でも呼ぶプロセスではstlは一行も使えないってことに
なりそうな。
たぶん皆、同一インスタンスに複数スレッドでアクセスしなければ平気
くらいな解釈で使ってるんだよね

496:デフォルトの名無しさん
08/01/31 22:41:35
標準にスレッドセーフという概念がないから語っても意味ないだろ

497:デフォルトの名無しさん
08/01/31 23:19:44
スレッドの概念自体が無い

498:デフォルトの名無しさん
08/01/31 23:26:59
ちっ、また自己責任かよ。つかえねーな

499:デフォルトの名無しさん
08/01/31 23:30:23
効率のためにintの幅すら決めない言語に向かって何を言ってるのかね

500:デフォルトの名無しさん
08/01/31 23:39:35
int幅が実装依存なのはちゃんと作ってれば別に問題ないだろ。

501:デフォルトの名無しさん
08/01/31 23:41:25
原子力発電所も冷凍餃子もちゃんと作ってれば別に問題無いぞ。

502:デフォルトの名無しさん
08/01/31 23:41:37
AMD64は自然な長さが64ビットなのにintが32ビットだな

503:デフォルトの名無しさん
08/01/31 23:48:23
intが64bitな処理系は現存するのか？
その場合、32bitを示す型は何だろう？

504:デフォルトの名無しさん
08/01/31 23:52:06
C言語が設計された時期が古いので64ビットとか考えてなかったんだろ

505:デフォルトの名無しさん
08/01/31 23:52:21
>>503
ILP64 でググれ。

506:デフォルトの名無しさん
08/02/01 00:09:02
32bitといったらlongなんじゃないのか

507:デフォルトの名無しさん
08/02/01 00:16:41
>506
まさか、int 64bitでlong 32bitと言ってる？

508:デフォルトの名無しさん
08/02/01 00:17:56
ねたにまじ（ry

509:デフォルトの名無しさん
08/02/01 00:24:17
LP64のほうが素直だねやっぱり。

I16/LP32はDOSで経験があるし(w

510:デフォルトの名無しさん
08/02/01 00:25:16
もうビット数気にする処理には stdint.h 使えばいいということで。

511:デフォルトの名無しさん
08/02/01 00:29:14
_int64とかタイプしたくないよヽ(`Д´)ﾉｳﾜｧｧｧﾝ
4G超えのファイルなんかザラだろうが。

512:デフォルトの名無しさん
08/02/01 00:31:19
typedef すれば？

513:デフォルトの名無しさん
08/02/01 00:34:47
typedef _int64 long long ってできねーだろ

514:デフォルトの名無しさん
08/02/01 00:37:09
え？

515:デフォルトの名無しさん
08/02/01 00:37:34
long long とか名前長くしてどうするよ。

516:デフォルトの名無しさん
08/02/01 00:42:24
long long は既にあるべよ。long_long_long とかにしようべ。

517:デフォルトの名無しさん
08/02/01 00:44:20
>>515
C99にあるんですよlong long。
>>516
そうします。

518:デフォルトの名無しさん
08/02/01 00:47:19
long long ago むかーしむかし、あるところに長い長いアゴの男がおりましたとさ

519:デフォルトの名無しさん
08/02/01 00:50:58
_int64とはVC++くさいが、
VC++ .NET 2003からはlong longも使えるぞ。

520:デフォルトの名無しさん
08/02/01 00:51:20
中学の英語の授業中誰もが経験するであろうネタだな

521:デフォルトの名無しさん
08/02/01 00:53:43
>>516
別に知っとるが、_int64 の方が短くて分かりやすくていいじゃン

522:デフォルトの名無しさん
08/02/01 00:55:01
i8 u8 i16 u16 i32 u32 i64 u64
これでtypedefしとけば字数的にはint未満だ。何かとぶつかりそうだけどな。

523:デフォルトの名無しさん
08/02/01 00:55:52
そこで名前空間ですよ。

524:デフォルトの名無しさん
08/02/01 00:55:54
以下（8bitのみ未満）の間違い。

525:デフォルトの名無しさん
08/02/01 00:56:53
my_primitive_type::u64

なげーよ。

526:デフォルトの名無しさん
08/02/01 00:59:03
だから、自分のプログラム全体を特定の名前空間内に入れて、
そこで i8 とか定義しとけば何も付けなくて大丈夫。

527:デフォルトの名無しさん
08/02/01 02:14:27
stdintはC++の標準に入ったんだっけか
intN_tな連中。

528:デフォルトの名無しさん
08/02/01 02:18:41
_tてなんかの略？

529:デフォルトの名無しさん
08/02/01 02:30:24
type

530:デフォルトの名無しさん
08/02/01 02:47:05
>>527
最新のドラフトに cstdint と stdint.h が載ってた。次の改訂 (C++0x) で入るみたいだね。

531:デフォルトの名無しさん
08/02/01 06:38:05
C++0xはC99の(ほぼ)上位互換になるんですか
それともC99で使えてもC++0xではサポートされない機能もあり?

532:デフォルトの名無しさん
08/02/01 07:22:07
コンパウンドリテラルとか
配列個数に変数使うとか
そういうのは C++0x で無視

533:デフォルトの名無しさん
08/02/01 07:24:48
restricted ポインタとか色々無視されてる。

534:デフォルトの名無しさん
08/02/01 07:54:32
「配列の要素数に変数」はSTLと相性悪すぎだからな。

535:デフォルトの名無しさん
08/02/01 08:29:10
>>534
kwsk

536:デフォルトの名無しさん
08/02/01 09:01:10
コンパイル時に型が決まらない、だっけ？

537:デフォルトの名無しさん
08/02/01 13:51:10
type* v = new type[n]; ... delete[] v;

の糖衣構文にしてくれるだけでいいのに。

538:デフォルトの名無しさん
08/02/01 16:33:28
stlportsは2008には使えないの？

539:デフォルトの名無しさん
08/02/01 16:49:23
>>538
STLPort はインストーラ(make)が VS2008 にまだ対応していない。
手動でインストールするなら可能らしい。STLport VS2008 でググレ。俺はまだ試していないので、試したら結果を教えてくれ。

540:デフォルトの名無しさん
08/02/01 17:54:00
>>538
iostream使うとC2487がいっぱい出るよ

541:デフォルトの名無しさん
08/02/01 18:14:05
っ _STLP_STATIC_CONST_INIT_BUG

542:デフォルトの名無しさん
08/02/02 01:05:39
>>537
std::vector で何が不満なのさ？

543:デフォルトの名無しさん
08/02/02 01:06:58
見た目が汚い

544:デフォルトの名無しさん
08/02/02 01:09:31
はぁ？

545:デフォルトの名無しさん
08/02/02 01:21:27
std::vector<double> v(i);

と

double v[i];

なら下の方が綺麗だろう。

２次元配列とかなるともうキモいったらありゃしない。

546:デフォルトの名無しさん
08/02/02 03:43:09
エェー

547:デフォルトの名無しさん
08/02/02 04:00:52
valarray使えや

548:デフォルトの名無しさん
08/02/02 07:03:42
[i] はキモいだろ。どんだけ使い込んでるんだよ。

(i) これは正常。むしろ性情。

549:デフォルトの名無しさん
08/02/02 07:29:17
少し、頭冷やそうか

次ページ