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

【C++】STL（Standard ..

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
少し、頭冷やそうか

550:デフォルトの名無しさん
08/02/02 08:16:48
　　(O)　＜くぱぁ
　　╋　　　　　　　
　　/＼　　　　　　　　　　　　　　　　

551:デフォルトの名無しさん
08/02/02 11:50:57
>>548
FORTRAN か BASIC ばっかつかってるからそうなるんだ。

552:デフォルトの名無しさん
08/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:デフォルトの名無しさん
08/02/02 12:21:14
どうしても知識をひけらかしたい奴がいるようだ。

554:デフォルトの名無しさん
08/02/02 12:29:59
馬鹿か？
typedefしろよ

555:デフォルトの名無しさん
08/02/02 12:30:33
あんまりしょうもないtypedefたくさん作らないで欲しいお…

556:デフォルトの名無しさん
08/02/02 12:35:53
グローバルスコープでないならまだ許せる

557:デフォルトの名無しさん
08/02/02 12:50:03
typedef vector<int> vector_int;
typedef vector<double> vector_double;
…

こんなのがtypedefs.hに延々ならんでるソースを見せられたときは会社やめようかと思った。
結局1年しか勤めなかったけど･･

558:デフォルトの名無しさん
08/02/02 13:15:32
>>557
なにがあかんねん

559:デフォルトの名無しさん
08/02/02 13:17:39
>>558
いみないやん

560:デフォルトの名無しさん
08/02/02 13:18:26
まぁ普通意味を考えて命名するよな

#define VALUE_100 100

て定義する様なもの

561:デフォルトの名無しさん
08/02/02 14:29:30
>>557
そのレベルだと好みが分かれそうだなあ
vector<string> string_list
とかはありがちだけど。intとはな。。

562:デフォルトの名無しさん
08/02/02 14:32:11
vectorなのにlist?

563:デフォルトの名無しさん
08/02/02 14:36:40
>>561
そういう問題じゃない。

・typedef名に意味付けがない
↓のようなコメントと通じるものがある
a += 100; // aに100を足す

・字数がほとんど変わらず、打鍵数減少につながらない

…ところで、あなたは list<string>をどのようにtypedefするの？

564:デフォルトの名無しさん
08/02/02 14:39:41
んなマジレスされても。。名前考えんのめんどうだからしないねくらいだが

565:デフォルトの名無しさん
08/02/02 14:48:34
557に意味がないわけじゃないけどな。

typedefされた型しか使わないというのは、
互換性を重視するときは有利になる。

566:デフォルトの名無しさん
08/02/02 14:51:03
>>565
具体的にどんな移植性の問題が typedef によって解決されるんでしょうか？

567:デフォルトの名無しさん
08/02/02 14:54:21
>>565
typedefはそういう用途に使えることは否定しないけど、
vectorもintも標準の一部だから、互換性の点でもtypedef vector<int> vector_int;とする意味は無いんじゃないの。

568:デフォルトの名無しさん
08/02/02 14:55:54
>>566
typedefが移植性のためにあるようなものなのにな。
なぜなにの子供か？

569:デフォルトの名無しさん
08/02/02 14:56:04
もしかしてあれか？ int のサイズが違う環境では
typedef vector<long> vector_int;
に置き換えて「すっきり解決」とか、そういう話か？

570:デフォルトの名無しさん
08/02/02 15:01:04
intのサイズ違いをそのレベルで解決すべきじゃない。

571:デフォルトの名無しさん
08/02/02 15:03:50
つsize_t/off_t

572:デフォルトの名無しさん
08/02/02 15:05:24
だからやっぱり vector_int は意味無いだろ >565

573:デフォルトの名無しさん
08/02/02 15:31:24
std:: を省略できれば打鍵数が結構減る。

574:デフォルトの名無しさん
08/02/02 17:22:02
打鍵数とかでなく、会社からSTLは一律typedefせよ　の命題が
課せられれば、vector_int みたいなものは生まれるし、それでもよいと思うぞ。

だから >>557 がどうこう言う程の問題ではないと思われるが。
こういうのは出たての若いのによくいる自分は社内でも皆よりよく分かってる　と
思いこんでる井の中の蛙ってこった。

575:デフォルトの名無しさん
08/02/02 17:31:06
std::foreachとかどうやってtypedefするの？

576:デフォルトの名無しさん
08/02/02 17:34:44
>>574
そんな命題を甘んじて受けるほど奴隷ではありません。

577:デフォルトの名無しさん
08/02/02 17:35:12
>>574
その通り、会社の方針なら勤めてる以上は従わざるを得ないのは言うまでもない。

そこで、無能だったり考え方の一致しなかったりする上司の下で働く羽目になった場合に取り得る行動は、
我慢して働きつづけるか、さっさと辞めるかの二者択一で、>>557は後者を選んだだけだろ。
別に非難されるようなことではない。

578:デフォルトの名無しさん
08/02/02 17:36:14
>>574
それは無能なプログラマが無能な会社に変わっただけで、>>557の判断には影響ないだろｗ

579:デフォルトの名無しさん
08/02/02 17:39:09
>>576
それで問題が発生したとき責任取って解決できるのなら
それでも良いんじゃね？　いざとなったら逃げるのはただの口だけ君。

580:デフォルトの名無しさん
08/02/02 17:43:00
vector<vector<vector<int> > >みたいなものを書かざるをえない状況なら
vector<T>をtypedefすることもあるんじゃないかな？

581:デフォルトの名無しさん
08/02/02 17:43:44
>>579
会社の命令に背いて問題を起こすなんて選択肢はもとからないよ

常識があれば、「従う」と「去る」の二択しか取れない

582:デフォルトの名無しさん
08/02/02 17:43:51
そんな当たり前の事言われましても。

583:デフォルトの名無しさん
08/02/02 17:48:52
>>566
このケースでvector<int>は必要なかったとしても、
list<string>はtypedefしたほうがいい。
とすれば、必要あるなしの境界はどこで切る？

こういう皆が使って判断の微妙な境界線は、
「一律typedef」が安全。

584:デフォルトの名無しさん
08/02/02 17:53:28
STLって型によらずアルゴリズムを記述できるような抽象化を
目指して作られてるはずなのに、ソースはtypedefだらけ。
それを異常と感じないほうがおかしい。

585:デフォルトの名無しさん
08/02/02 17:55:26
抽象的な書き方をしない箇所もある。適切にtypedefすることには何の問題もない。

586:デフォルトの名無しさん
08/02/02 18:03:04
そもそもどういう理由でtypedefしてるの？

587:デフォルトの名無しさん
08/02/02 18:04:36
>>584
抽象化するためにtypedefが必要だったりするし、STLなんかtypedefだらけだけど？

588:デフォルトの名無しさん
08/02/02 18:12:31
>>581
まぁね。　ドラマのまねっこで「僕はそんなことはできません」なんて
楯突いてその後その人間同士が上手く行くことなんてまぁないからね。
ドラマはご都合主義だから上手くいくけどさｗ

589:デフォルトの名無しさん
08/02/02 18:17:26
>>588
自分も会社の一員だけどね。そういうこだわりのない人間が集まってるから駄目な会社になったとも言える。

590:デフォルトの名無しさん
08/02/02 18:17:50
>>574
仕事ってオブジェクト(?)をもっと理解した方がいいよ。

逆に考えて、君がお客で奴隷とかいうのが車屋の店員だったとする。
君は赤色の車を注文した。　しかし店員は「いやいまのトレンドは白です。
そこは譲れません」　と言ってるのと大して変わらん。

591:590
08/02/02 18:21:36
アンカー違い　>>576 へ訂正

592:デフォルトの名無しさん
08/02/02 18:24:24
本日の課題

授業単元：コンピュータ理論
課題：本字の流れをvectorとlistを使って表しなさい。但しtypedefは使わないものとする。

593:デフォルトの名無しさん
08/02/02 18:27:27
販売拒否も車屋の勝手だろ
それで商売になるならそれでいいし、ならないなら別のことをするだけだ
意に反して赤い車を売らされることはない。もちろん妥協して赤い車を売ってもいい

594:デフォルトの名無しさん
08/02/02 18:33:44
>>590
それは違うだろ

595:デフォルトの名無しさん
08/02/02 18:43:17
>>593
おまえ尾崎豊の歌大好きだろ？ｗ

596:デフォルトの名無しさん
08/02/02 18:59:03
>>595
ほとんど聴いたことすらないｗｗ

597:デフォルトの名無しさん
08/02/02 19:31:33
typedef厨いる？

598:デフォルトの名無しさん
08/02/02 19:42:18
まあたいして責められてるわけでもないのに
いきなり奴隷なんて言葉を使い出す輩とは
あまり議論もしたくないな、おれは。
どこぞのウィルス流してつかまったヤツを想起してしまうよ。

599:デフォルトの名無しさん
08/02/02 19:49:14
>>587
それは抽象化とはいわん。単なる簡略化。
型の違いを意識の外に放り出してしまえるのが本来の抽象化。
現実はその逆。

600:デフォルトの名無しさん
08/02/02 19:49:59
個人でやってる分にはいいが、人が動かせない大きな岩(ﾌﾟﾛｼﾞｪｸﾄ)を
動かすには、全員が力合わせて同じ方向に綱引かないと成功なんか
ないよね。　俺は反対に引きたい　とか関係ねーよ。
社会の歯車とかTVで憶えた訳分からん言葉に流されるべからず。

601:デフォルトの名無しさん
08/02/02 19:54:16
>>599
std::binary_functionの中とかでやってるtypedefはどう考えても抽象化のためだろ？

602:デフォルトの名無しさん
08/02/02 19:56:43
>>600
本心は別だろ？ｗ
マが鬱になる原因はそういうところが始まりなんだよ？

603:デフォルトの名無しさん
08/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:デフォルトの名無しさん
08/02/02 19:58:17
>>601
使ったこと無いから知らん
それにここまでの話の流れじゃはそういうとこじゃないだろ

605:デフォルトの名無しさん
08/02/02 19:59:30
俺は、木しか見ていない>>557より、森も見ている会社の
typedefs.hの方が賢いと思う。

606:デフォルトの名無しさん
08/02/02 19:59:50
ミス
それにここまでの話の流れじゃそういうとこじゃないだろ
↑typedef乱用のところな

607:デフォルトの名無しさん
08/02/02 20:00:42
>>604
使ったことないのね。了解。

608:603
08/02/02 20:01:43
ごめん。policy_tはPolicyの派生型じゃ無いわな。

609:デフォルトの名無しさん
08/02/02 20:19:10
>>602
本心は当然別よ。　本来人の考えが一致するなんて奇蹟ぐらいの考えで丁度いいよ。
映画あらしのよるに　で上手く分かりやすく描かれてるよ。羊と狼が友情築くｱﾆﾒ風のやつ。

610:デフォルトの名無しさん
08/02/02 20:37:17
typedefs.h には元々プロジェクトの成功を見ていた２人の心を分かつ効果もありそうだ。

611:デフォルトの名無しさん
08/02/02 21:14:32
つうかコンテナをvectorからdequeに変えたくなった時や
intじゃなくて複素数入れたくなった時に

vector_int

じゃカコワルイだろ

612:デフォルトの名無しさん
08/02/02 21:18:35
おまいらソフトウェアプロジェクトマネジメントの本を読んでみ。「ピープルウェア」とか。
>600を実現するためにどれだけの苦労が必要かがわかる。
あくまでマネージャー視点だけど、プログラマ側からするとマネージャーの資質を
測るのに良いヒントになるよ。
ついでに「デスマーチ」もドゾー。現実は厳しいということを教えてくれる古典的名著。

613:デフォルトの名無しさん
08/02/02 21:19:56
そんな話はマ板でやれよ

614:デフォルトの名無しさん
08/02/02 21:20:00
>611 変えない……というのは冗談として。
そんときはリファクタリングじゃね？名前総取っ替えだろうね。

615:デフォルトの名無しさん
08/02/02 21:21:41
>613 だったら>603にコメント入れろよ。放置されてバカみたいだろ。
他のtypedefの使いかたでも良いよ。

616:デフォルトの名無しさん
08/02/02 21:27:10
だから vector_int には意味がなくて

typedef int Code;

typedef std::vector<Code> CodeList;

とか

typedef std::vector<Code> CodeSequence;

とかにしたほうが良いんじゃないのって言うのが良識のあるプログラマの意見じゃないかな

617:デフォルトの名無しさん
08/02/02 21:29:19
このスレでまともにSTLの話をしているのを見たことがない俺

618:デフォルトの名無しさん
08/02/02 21:35:25
文字コードの次はtypedefかお

619:デフォルトの名無しさん
08/02/02 21:40:05
で、赤い車は買えたの？

620:デフォルトの名無しさん
08/02/02 21:48:46
というか、おまいらTemplate使ってる？
Policyは非常に強力なコンセプトだと思うんだがね。

本当はもっと制約の少ないMix-in機能が欲しいけどね。
Policy同士で相互依存があると破綻しがちだから、けっこう設計が面倒。

621:デフォルトの名無しさん
08/02/02 21:49:24
>619
あぁ、早速それ乗って近くの本屋にEffectiveSTL買いに行く予定だよ

622:デフォルトの名無しさん
08/02/02 22:12:32
>>620
アレキサンドレスクの受け売りですか？

623:デフォルトの名無しさん
08/02/02 22:20:19
メイヤーズもヴァンデヴォーデも質問したら
ちゃんと返事くれるんだな。できる人は違うわ。

624:デフォルトの名無しさん
08/02/02 22:20:59
>>620
相互依存のあるPolicyなんて思い浮かばないんだけど
具体的にどんなの？

625:デフォルトの名無しさん
08/02/02 22:23:26
あれってヴァンデヴォーデって読むのか……

626:デフォルトの名無しさん
08/02/02 22:23:56
>622 基本的にはそんな感じなんだけど、Policyの組替えを想定してるんじゃなくて
単にデカいクラスのモジュール化をするときに使ったりしてる。

本当は包含とかでも何とかなるんだけどねぇ。
委譲関数書かなくて良いのが素敵なんで何となくポリシー使ってる。

627:デフォルトの名無しさん
08/02/02 22:26:16
>>625
いや適当

628:デフォルトの名無しさん
08/02/02 22:27:48
>624
もちろんきっちり設計してから組めば相互依存はほとんど無くすことができるんだけど、
トライ＆エラーで設計するときはそんなこと言ってられないからね。
ルーズに始めるときは、たいてい相互依存バリバリだったりする…………

リファクタリングするときも相互依存した状態を経由するから、そういうときも不便。

629:デフォルトの名無しさん
08/02/02 22:32:02
orthogonalってやつか

630:デフォルトの名無しさん
08/02/02 22:43:00
>629
直交に分離するのは理想だけど、神様でもなければ一発でそんなに上手く行くわきゃ無いよな。

631:デフォルトの名無しさん
08/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:デフォルトの名無しさん
08/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:デフォルトの名無しさん
08/02/05 20:54:58
ありが㌧。
でもソートも書いて欲しいよﾏﾏﾝ

634:デフォルトの名無しさん
08/02/05 22:28:39
>633
そんな難しくもなさそうな気もするけど、まずはうまくいかなかったコードを書いてみれば？

635:デフォルトの名無しさん
08/02/05 22:39:37
というか std::sortにbool op( const int *l, const int *r) { return *l<*r;}
を渡せば終わる話だからなー

636:デフォルトの名無しさん
08/02/05 22:44:01
pair だからそれだと足りない。けどまぁその程度ではあるんでどういうところでつまるのかな、という方に興味があったり。

637:デフォルトの名無しさん
08/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:デフォルトの名無しさん
08/02/05 23:15:32
sort_inserterみたいの作れば挿入とソートが一発で。コスト的にはあんまり美味しくないか。

639:デフォルトの名無しさん
08/02/06 00:02:14
>>638
それなんてstd::set?

640:デフォルトの名無しさん
08/02/06 00:15:23
>>639
pairのsecondだけでソートってできるんだっけ？

641:デフォルトの名無しさん
08/02/06 00:18:18
あー失礼、compare指定すりゃいいだけだ。

642:デフォルトの名無しさん
08/02/09 11:47:37
vectorで使用したメモリ領域を開放する方法を教えてください。

vector<int> v;
v.reserve (100000);

ぐらいの領域を使った後

v.clear ();
cout << "capacity = " << v.catacity() << "\n";

capacityが100000を返してくるのですが、どうやって領域を開放したらいいのでしょうか？
v自体はまだ使うので消したくありません。

643:デフォルトの名無しさん
08/02/09 11:54:07
vector<int>().swap(v);

644:642
08/02/09 12:01:01
>>643
できた。ありがとう！お前まじ天才
さしつかえなければ、何をどうやって勉強すればお前みたいになれるのか教えてください。

645:デフォルトの名無しさん
08/02/09 12:03:27
とりあえず

つ"Effective STL"

646:642
08/02/09 12:08:50
買った。
これを読んで俺も天才になる

647:デフォルトの名無しさん
08/02/09 12:31:42
天才って言葉の使い方間違ってる

648:デフォルトの名無しさん
08/02/09 13:05:16
むしろ転載に近いよな。

649:デフォルトの名無しさん
08/02/09 13:29:09
メイヤーズSTLはジョスティスの内容をパクってるものが多い。

650:デフォルトの名無しさん
08/02/09 16:10:30
で　っていう

651:デフォルトの名無しさん
08/02/09 17:58:50
その本にじょてぃすすげー参考にしたって書いてあったから
じょてぃす買った俺が通りますよ。
じょてぃすは絶版になるべきではなかった。

652:デフォルトの名無しさん
08/02/09 18:19:14
>>651
原書を読み漁ったおれもいますよ。平易な英語だから無問題。

653:デフォルトの名無しさん
08/02/09 19:24:52
Vandevoorde も忘れないでね。

654:デフォルトの名無しさん
08/02/09 19:50:38
>>653
TemplateならあるがSTLの本なんて書いてたっけ？

655:デフォルトの名無しさん
08/02/09 20:56:21
お前ら日本語でしゃべれ

656:デフォルトの名無しさん
08/02/10 02:11:51
よし今回だけだぞ

657:デフォルトの名無しさん
08/02/11 07:54:08
>643 の方法だとstd::stringには効果無いのですが、
stringの場合は明示的にメモリ解放する手段て無いのでしょうか？

658:657
08/02/11 08:06:11
すみません、VC2005のstd::stringだと、作成した
直後の状態である程度のバッファが確保されてるだけでした。

659:デフォルトの名無しさん
08/02/14 09:50:34
STLにTStringListみたいなのありましたっけ？

やっぱ、
＞std::vector <std::string>
ですか？

660:デフォルトの名無しさん
08/02/14 09:53:14
>>659
うん。 TStringList という名前だけ見ると、どちらかといえば std::list<std::string> かと。

661:デフォルトの名無しさん
08/02/14 10:03:11
有難う。

実は、vectorしか使ったことないのです。listとvectorの違いを知りたいです。

662:デフォルトの名無しさん
08/02/14 10:06:33
事故解決しました。
記述は大差ないみたいですね。
実行効率とメモリの違いみたいな。

URLﾘﾝｸ(ml.tietew.jp)

663:デフォルトの名無しさん
08/02/14 13:05:03
大差ある。

664:デフォルトの名無しさん
08/02/14 17:07:51
vector
ランダムアクセス可能。
メモリが連続している。

list
ランダムアクセスできない。
当該要素のerase以外で参照・イテレータが無効化されない。（個人的にはこれが一番重要）
任意位置への挿入・削除が定数時間。
独特な操作（spliceなど）がある。

選択する上で気をつけるのはこんなとこか？

665:デフォルトの名無しさん
08/02/14 17:20:05
なるほど、どうも有難うございます。

選択って意味では、
vector と list を間違えるより、
vector と map（←これもまだ使ったこと無いｗ）を間違えたら大変な気がしました。

666:デフォルトの名無しさん
08/02/14 18:24:34
いや、vector使うつもりでlistつかうよりmap使った方が多分マシだぞ

667:デフォルトの名無しさん
08/02/14 19:46:00
そもそもコンテナに何を求めているかによる。
連続性が重要ならlistもmapも同じくらい散々な目に遭うし、一応コンパイルが通ればいいだけなら
vectorでもmapでも問題ない。

668:デフォルトの名無しさん
08/02/14 21:59:15
ポインタつなげて線形リンクリスト作らされたことってないの？

669:デフォルトの名無しさん
08/02/14 22:17:35
>>668
標準ではないがstd::slistってのがある。

670:デフォルトの名無しさん
08/02/14 22:56:57
>>669
std::listだって線形リンクリストでしょ。双方向であるというだけで。

671:デフォルトの名無しさん
08/02/15 01:50:44
std::list って単方向じゃなかったけか？

672:デフォルトの名無しさん
08/02/15 01:53:08
いいえ。

673:デフォルトの名無しさん
08/02/15 01:53:10
あ、ごめ。双方向だった・・・
よく考えたら reverse_iterator 使えるもんね。

674:デフォルトの名無しさん
08/02/15 02:14:36
連続性が要らないなら、vectorよりdequeつかっとけって誰かえらいひとが
言ってた気がする

675:デフォルトの名無しさん
08/02/15 02:36:37
要素数が万単位にならなければlistよりvectorつかっとけって誰かえらいひとが
言ってた気がする

676:デフォルトの名無しさん
08/02/15 02:41:25
つ URLﾘﾝｸ(www.codeproject.com)

677:デフォルトの名無しさん
08/02/15 03:13:20
>>676
dequeメチャメチャ速いやん

678:デフォルトの名無しさん
08/02/15 03:35:20
むしろvectorがいらない子だろう

679:デフォルトの名無しさん
08/02/15 07:49:19
オブジェクトのサイズ/要素数が大きくない場合
listはvectorに比べてアロケーションの多さと断片化が弱点になりそうだよね

680:666
08/02/15 08:45:44
なるほど、今までvectorのみ使ってましたがmapにトライしてみます。

というより、実はネットで拾ったライブラリがmap使ってて、初期化宣言見ただけで”えっ”と思ってもう理解するの必須。

vectorの連続性って、普通の変数配列みたいにメモリがばっとコピーしても大丈夫なんですよね？
何度も文献とかで確認しましたが、結局怖くて１つ１つイテレーター参照してますが。

ところで、map使うとプライマリキーみたいなのが必須ですよね？
キーがいる場合にはピッタリですが、開発途中でやっぱキーいらね、とかなったら、
とりあえず連番で埋めとけば良いわけですかね。
その時点でvectorかlistに差し替えかな。

>>668
線形リスト勉強しました。その頃C++どころかC初心者だったため、氏にました。
で、STLって何て便利なんだろう（これで使い方さえもう少し簡単であれば）って思ってまつ。

681:デフォルトの名無しさん
08/02/15 08:46:35
　↑
＞666

は間違いで、665です。

682:デフォルトの名無しさん
08/02/15 09:04:18
mapについてそんなふうに思ってる人は始めて見たｗ
データベースみたいな複雑なものじゃなくてただの写像ですよ。
電話帳みたいな何かと何かの対応表だと思えばいい。
パフォーマンスに関してはそれを理解してからでいいと思う。

>vectorの連続性って、普通の変数配列みたいにメモリがばっとコピーしても大丈夫なんですよね？
多分大丈夫だけどやる必要ないならやらないに越したものはない。

>その時点でvectorかlistに差し替えかな。
パフォーマンス以前に用途が違うのでそのとおり。

>で、STLって何て便利なんだろう（これで使い方さえもう少し簡単であれば）って思ってまつ。
便利さを追求した結果こうなったんだろう。
ただしその上で、できるだけ簡単にはなってると思う。

683:デフォルトの名無しさん
08/02/15 09:56:51
mapなんて連想配列ですよ。awk使いの私が言うんだから間違いありません。

＞>vectorの連続性って、普通の変数配列みたいにメモリがばっとコピーしても大丈夫なんですよね？
多分じゃなくて大丈夫だけど、memcpy()などを自分で使うのはお勧めしない。潜在的なバグの原因になりかねない。
APIに渡すなどのように、必要に迫られたときに限定した方がいい。

684:デフォルトの名無しさん
08/02/15 10:18:40
boostとかにTStringListに近いものがあったりしないでしょうかね？

685:デフォルトの名無しさん
08/02/15 10:38:33
そんな無駄なものはない

686:デフォルトの名無しさん
08/02/15 10:39:27
ま、StringListクラス宣言して、中の人にmultimapすれば、自分でメソッド作るだけですか。
車輪の再開発とか言われたら嫌だから、既にあるものをなるべく使いたいです。

687:デフォルトの名無しさん
08/02/15 10:40:46
コンテナに使われている例えば連想コンテナのデータ構造（平衡二分木）とか
に詳しい人いる？

688:デフォルトの名無しさん
08/02/15 10:42:54
>686
どんなことがやりたいの？

689:686
08/02/15 10:55:33
どちらかというと、やりたいことがあるのでなくて、移植作業のためにTStringListメソッド実装。

CommaTextの入出力、iniファイルの１行処理のためのValues/Namesプロパティ、IndexOf、ファイル入出力メソッド、要素文字連結 etc..

690:デフォルトの名無しさん
08/02/15 11:11:00
>>687
ここにそれなりに詳しく書かれてるよ
Wikipedia項目ﾘﾝｸ

691:デフォルトの名無しさん
08/02/15 11:29:40
>>689
組み合わせて使えばできそうな気がする。

boost.lambda
boost.string_algo
boost.tokenizer

ファイル入出力はfstreamとalgorithm使えばよし。

692:デフォルトの名無しさん
08/02/15 12:48:59
typedef vector<int> vector_int;
を
typedef deque<int> vector_int;

に書き換えただけで、うちのソフトの体感速度が上がったｗ
処理速度アップ！ってバージョンアップ唄えるお( ^ω^)

693:デフォルトの名無しさん
08/02/15 13:02:15
＞typedef vector<int> vector_int;
＞typedef deque<int> vector_int;

kwsk
何が違うのか教えれ！

694:デフォルトの名無しさん
08/02/15 13:09:15
vectorに数万とかpush_backして再アロケートが発生しまくったんじゃないかと予想

695:デフォルトの名無しさん
08/02/15 13:11:54
その２つはメソッドは同じなの？

696:デフォルトの名無しさん
08/02/15 13:13:34
バッファの連続性が必要なくて、
確保すべきメモリ量が事前によく分からないなら、
vector より deque の方が圧倒的に効率的。

697:デフォルトの名無しさん
08/02/15 14:07:45
いままでboost::shared_ptrのコンテナにstd::listを使ってたけど
std::dequeにしたら速くなるのかな
でもスマポのコピーは時間かかりそうだな...

698:デフォルトの名無しさん
08/02/15 14:11:04
push_back のコストは list より deque の方が平均的には少ないはずだが

699:デフォルトの名無しさん
08/02/15 14:16:41
mapってシーケンシャルアクセス、かつ、入れた順番に取り出す、もできますか？

700:デフォルトの名無しさん
08/02/15 14:18:42
もっと詳しく

701:デフォルトの名無しさん
08/02/15 14:20:57
mapをbeginからendまで参照した場合、
順番は、mapに登録した順番になっててくれますか？

702:デフォルトの名無しさん
08/02/15 14:23:46
>>699
入れた順番は失われる

703:デフォルトの名無しさん
08/02/15 14:24:29
>>701
Sort Criterionによる

704:699
08/02/15 14:27:50
＞Sort Criterionによる

kwsk
ググっても出ません。

705:デフォルトの名無しさん
08/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
08/02/15 14:35:07
え”～ショック。

つまり、並び順が保障されるのは、vectorとdequeだけですかぁ。

707:デフォルトの名無しさん
08/02/15 14:37:31
だってmapはシーケンスコンテナじゃないし

708:デフォルトの名無しさん
08/02/15 14:42:34
>>704
テンプレートパラメータかオブジェクトととして渡す
ソート基準による。

709:699
08/02/15 14:47:40
じゃ、mapはやめて、vectorします。

vectorのヘルプ見てると、pos番目の要素をとるには[pos]ではなくて、at(pos)を使えと書いてありますね。

atを使わずに[]を使ってると、dequeに置き換えが出来なくなるわけでしょうか？

710:デフォルトの名無しさん
08/02/15 14:48:47
operator[]は範囲チェックをしないけどatはする
違いはそれだけ

dequeにもoperator[]はあるから、その心配は要らない

711:デフォルトの名無しさん
08/02/15 16:19:32
ごめん。未だに
「Associative Containerじゃ駄目なんですか。じゃあSequenceにします」
が簡単に出来る場面というのが想像できない

712:デフォルトの名無しさん
08/02/15 16:29:56
線形探索しても痛くないときとか

713:デフォルトの名無しさん
08/02/15 17:07:05
>>695 >>709
>>676のリンク先にも書いてあるけど、vectorとdequeのメンバ関数の違いは
・vectorにだけある……capacity() reserve()
・dequeにだけある……push_front() pop_front()
だけ。

いずれもメモリの連続性に関わるもので、前者が「あらかじめ確保しておく」系（dequeには要らない）、
後者が「先頭要素を出し入れする」系（vectorには高コスト過ぎ）。

714:695
08/02/15 17:11:30
ｻﾝｸｽ。

STLってｷﾓｶﾜｲｲね。

715:デフォルトの名無しさん
08/02/15 17:31:49
個人的にはlistがいらない子のようなきがしてます

716:デフォルトの名無しさん
08/02/15 17:40:48
dequeにはspliceが無いだろ？

717:デフォルトの名無しさん
08/02/15 17:46:29
listはアロケータさえちゃんと作れば、本当はやれば出来る子

718:デフォルトの名無しさん
08/02/15 17:54:59
vectorはお金がかかる子。

vector（笑）

719:デフォルトの名無しさん
08/02/15 18:11:05
vectorとdequeの最大の違いは、stackコンテナでdequeがデフォルト
コンテナとして使われてることを見ればわかるね。メモリ構造の違い
によってvectorは要素を削除した場合に絶対にメモリを解放しないが
dequeはチャンクの集まりだから不要なチャンクは解放されることが多い。
（これはstandardでは求められていないらしいが）
また、reallocateの際、vectorは全ての要素を移動する必要があるが
dequeは必ずしもそうはならない。同じ要素へのアクセスではvectorの
ほうが理論的には高速。dequeはメモリ構造上indirect accessとなるから。

このくらいしか気にしてないけど、結局は要素数と実測で決めることにしてる。

720:デフォルトの名無しさん
08/02/15 23:04:47
>>706
次期C++ではinsert(iterator, value)の意味が変わって、
同順の要素の間で好きな場所に値を挿入できるようになる。
それまではstd::map<Key, std::deque<T> >でも使うしかないね。

721:デフォルトの名無しさん
08/02/15 23:27:40
>>720
へぇ。知らなかった。

これか。
URLﾘﾝｸ(www.open-std.org)

722:デフォルトの名無しさん
08/02/16 00:04:14
メタプログラミングをゴリゴリやってる奴いないの？
STLを専ら使うだけ？

723:デフォルトの名無しさん
08/02/16 00:18:21
>>722
それはboostスレで。

724:デフォルトの名無しさん
08/02/16 12:16:37
C++/TemplateMetaProgramming専用スレってないの？

725:デフォルトの名無しさん
08/02/16 12:27:05
ないね。
欲しければ立てれば？

726:デフォルトの名無しさん
08/02/16 12:42:44
過疎りそうだけどな
TMPと言ったって大概はSTL、Boostの範疇だし

727:デフォルトの名無しさん
08/02/16 12:45:39
　　　　　　　　　　　　　ｒ､ﾉVV＾ｰ八
　　　　　　　　　　　　､^':::::::::::::::::::::::＾vｨ　　　　　　　､ヽ l / ,
　　　　　　　　　　　　　 l..:.::::::::::::::::::::::::::::ｲ　　　　　　= 　　　　=
　　　　　　　　　　　 |.:::::::::::::::::::::::::::::: |　　　　　ﾆ= 724そ　-=
　　　　　　　　　　　　　 |:r￢‐--─勹:::::|　　　　　ﾆ=　なれ　=ﾆ
　　　　　　　　　　　　　　 |:} _＿　､.＿｀}f'〉ｎ＿　　 =-　らで　-=
　　、､ l | /, ,　　　　　　 ,ﾍ}´`'｀｀　`´`　|ﾉ:::|.|　　ヽ　ﾆ　.：. も　ﾆ
　.ヽ　　　　　´´, 　　　　　,ゝ|、　､, 　　 l|ヽ:ヽヽ　　}　´r　　　ヽ｀
.ヽげき 724　ﾆ. 　　／|｛/ :ヽ　-=-　./| |.|:::::| |　　|　　´/小ヽ｀
=　てっ　な　 =ﾆ　／:.:.::ヽ､　　＼二／ :| |.|:::::| |　 /
ﾆ　く. と　ら　　-=　ヽ､:.:::::::ヽ､.＿､　　＿,ﾉ/.:::::| | /|
= 　れ.盛　　　-= 　ヽ､:::::::::＼､＿＿／::.z:::::.:| |' :|
ﾆ　るり　　　=ﾆ　　　| |:::::::::::::::::::::::::::::::::::.|'.:Y′ﾄ､
/,　：　上　　ヽ､　　 | |::::::::::::::::::::::::::::::::::::_:::::_::|　 'ﾞ, .＼
　/　　　　　ヽ、　　　 | |:::::::::::::::::::::::::::::::::::.|:::::::|.ﾄ､　　　＼
　 / / 小＼　　　 r￢|ﾉ::::::::::::::::::::::::::::::::::::::::::::::::|　＼

728:デフォルトの名無しさん
08/02/16 12:46:16
724だけど、立てたぞ。
ｽﾚﾘﾝｸ(tech板)

729:デフォルトの名無しさん
08/02/16 14:03:50
>>726
甘いな

730:デフォルトの名無しさん
08/02/16 18:04:09
TMPとSTLって全然ちがくね？

731:デフォルトの名無しさん
08/02/16 18:10:33
どっちかっつーと、非 STL 部分の方が TMP っぽいな。
char_traits とか。

732:デフォルトの名無しさん
08/02/16 20:53:06
iterator_traits

733:デフォルトの名無しさん
08/02/16 22:54:48
numeric_limits

734:デフォルトの名無しさん
08/02/16 22:55:47
std::advanceもTMPっていっていいの？

735:デフォルトの名無しさん
08/02/16 23:00:21
いいんじゃね？

736:デフォルトの名無しさん
08/02/17 13:45:21
vectorやdequeってさ、変更せず読み込みだけなら複数スレッドからアクセスしても
大丈夫ですか？

737:デフォルトの名無しさん
08/02/17 13:49:27
volatileつけとけ

738:デフォルトの名無しさん
08/02/17 14:49:07
誰も書かないならvolatileいらない

739:デフォルトの名無しさん
08/02/17 15:05:58
例えばVisual C++ならここに書いてある。ほかは知らないけど。
URLﾘﾝｸ(msdn2.microsoft.com)(VS.80).aspx

740:デフォルトの名無しさん
08/02/18 14:53:30
MFCやVCLにある、StringOfChar って無いですか？
ある文字を指定個数分返してくれるメソッド。

741:デフォルトの名無しさん
08/02/18 15:08:12
string s(10, 'A');

742:デフォルトの名無しさん
08/02/18 15:09:32
thx!　>>741

あやうくfor文で回すところですた。

743:デフォルトの名無しさん
08/02/18 18:28:13
>>731
STLの中でメタプログラミングの要素があるのは
iterator_traitsとiterator_tagを使ったディスパッチくらいかな。

744:デフォルトの名無しさん
08/02/18 18:33:37
>>743
関数テンプレートのオーバーロードを利用した
ランダムアクセスとその他の振り分けか。
でもほとんど使ったことないなあ。

745:デフォルトの名無しさん
08/02/18 19:36:19
Vectorで、５番目の要素の次にデータを挿入したいときは、どう書きますか？

746:デフォルトの名無しさん
08/02/18 19:43:45
直接は使わなくても、advance とかで間接的には使ってる事ない？

747:745
08/02/18 19:44:02
既存の要素が４の場合と５の場合と、場合分けして、記述する必要があるのでしょうか？

748:デフォルトの名無しさん
08/02/18 19:46:41
既存の要素が１とかの時どうすんの？

749:デフォルトの名無しさん
08/02/18 20:07:40
>>745
std::vector なら v.insert(v.begin() + 5, value);
とかかな。要素数が最低5個は存在してないとマズイから。
v.size()で要素数調べる必要はあるか。

>>746
そういう意味では使うこともあるなあ。
本では読んだけど自分で書いたことはないな。

750:745
08/02/19 08:35:45
＞v.begin() + 5

あ、イテレーターって足し算できるんですね。
勉強になりました。

751:デフォルトの名無しさん
08/02/19 11:13:44
vectorのイテレータはランダムアクセス可能だからな。

752:745
08/02/19 11:15:48
では、vectorのイテレータだけが、＋－演算子定義されてるってことですか？
（dequeは無理と）

753:デフォルトの名無しさん
08/02/19 11:35:47
dequeもランダムアクセスイテレータなので+ - は定義されているよ

754:745
08/02/19 11:42:15
え”～、自分vectorのみ使ってるのに、それじゃvectorはやっぱり要らない子じゃん。

755:デフォルトの名無しさん
08/02/19 11:46:41
+や-ができないのは、たとえばlistとかsetの双方向イテレータ。
こいつらでは、インクリメントやデクリメントを繰り返す必要がある。
そんなときはstd::advanceなんていう関数が既に用意されている、もちろんO(N)。

vectorは、要素のメモリアドレスの連続が保障されているので、
組込の配列やmallocなんかで確保したメモリと同じように使えるという点が決定的にほかと違う。
例えばC用のAPIに渡すバッファなんかにも使える。

756:745
08/02/19 11:53:08
＞vectorは、要素のメモリアドレスの連続が保障されているので、

その通りなんですが、上レス読むと、やっぱふつーはイテレーター使えって逝われてるじゃん。

757:デフォルトの名無しさん
08/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:デフォルトの名無しさん
08/02/19 12:03:22
じゃ malloc的な使い方する時は、あえて
vector<int>って直書きしないとちょっと恐いな。

759:デフォルトの名無しさん
08/02/19 12:05:37
>>756
そうだから、vectorで要素へのポインタを使うのはchar*な引数に渡すなんて使い方くらいだね。

760:デフォルトの名無しさん
08/02/19 12:06:05
すまん、char*に限らず任意のT*でいいんだ。

761:デフォルトの名無しさん
08/02/19 12:13:51
>>757
組み込み配列だって要素数超える足し算は未定義動作なんだぜ。 assert() が
入ってる分ありがたいぐらいだ。

762:デフォルトの名無しさん
08/02/19 12:32:11
イテレータについて質問です。
イテレータをインクリメントするコストはコンテナによって違うと思うのですが、
STL解説サイトなどで、そのことについて触れているのをみかけません。
速度を知りたければ、実装毎にテストして計るしかないのでしょうか？

763:デフォルトの名無しさん
08/02/19 13:08:30
>>762
実際の速度(具体的な処理時間)を知りたいのならそれでいいんじゃね？
ソースやアセンブル結果を見て見当をつけても良いけど。

764:デフォルトの名無しさん
08/02/19 13:08:44
VC++2005で、
std::map<std::string,int> mp;
mp["key000"]=0;
とすると、「stringに>演算子がない」ってエラーが出るんだが、これって標準C++準拠の正しいエラーなのかな？
それともVC++2005のstringの方がおかしいのかな？

ネットで検索した時に普通にstd::stringをキーにしてるソースあったんで、問題ない書き方だとは思うんだが。

765:デフォルトの名無しさん
08/02/19 13:13:37
>>762
折角ソースがあるんだから読めばいいんじゃね?

次ページ