C++相談室 part135
■ このスレッドは過去ログ倉庫に格納されています
次スレを立てる時は本文の1行目に以下を追加して下さい。 !extend:on:vvvvv:1000:512 C++に関する質問やら話題やらはこちらへどうぞ。 ただし質問の前にはFAQに一通り目を通してください。 IDE (VC++など)などの使い方の質問はその開発環境のスレにお願いします。 前スレ C++相談室 part134 http://mevius.5ch.net/test/read.cgi/tech/1516406742/ このスレもよろしくね。 【初心者歓迎】C/C++室 Ver.102【環境依存OK】 http://mevius.5ch.net/test/read.cgi/tech/1509780815/ ■長いソースを貼るときはここへ。■ http://codepad.org/ https://ideone.com/ [C++ FAQ] https://isocpp.org/wiki/faq/ http://www.bohyoh.com/CandCPP/FAQ/ (日本語) VIPQ2_EXTDAT: default:vvvvv:1000:512:----: EXT was configured クラス関数はthisを第一パラメータとして渡してるだけで、これは構造体でも同じことが出来る virtual関数は関数ポインタテーブルへのポインタを持ってるだけ 同じことは当然Cの構造体でも出来る テンプレートは型ごとにコードを書くのと同じ >>663 だから、いわゆるC++の機能を使ったら、管理が楽になる分だけ遅くなる、というだけ。 C++の機能を全く使わないコードはCと言うんだよ。 だから、C++はCより常に遅い。それだけ。 >>664 そういえば、 例外発生時のスタックにあるリターンアドレスを検索するとかどこかでみたような どこかに仕組みが書いてあった気がしてきた >>665 > virtual関数は関数ポインタテーブルへのポインタを持ってるだけ > 同じことは当然Cの構造体でも出来る Cでやる場合は、関数ポインタを引数で渡すことも出来るんだよ。 (勿論C++でも出来るが、クラスを使う意味が無くなるから普通はやらない) この場合、間接参照が抜ける分だけ速くなる。 (実際はメモリアクセス1個よりはキャッシュを壊すことの影響の方が大きいとは思うが) C++独自の機能を使うとCより常に遅い? それは嘘だな >>669 C++にだけ独自の縛りを設けてCのが速い? 強引に主張を通したいのはわかるが そろそろ痛いぞおまえ >>667 それはスタックウォークという、従来の例外実装方法だ。 君の場合なら、x86がそれになってる。 >>670 ならC++の機能を使って、Cよりも速くなるケースを挙げてみろ。 ないから。 もとは>>638 だ C++で最適化に行き詰まった時に わざわざコンパイラをCに変えて最適化する事なんてないから Cっぽい記述とかアセンブラっぽい記述とかなら そりゃいくらでも >>672 前半 自分で調べろ >>672 後半 ええと、... 「C++独自の機能を使うとCより常に遅い」 の否定はわかるかな? >>658 って単に32bitプログラムを64bit CPUで走らせてオーバーヘッドがーって言ってるんじゃね? >>674 君は理解できてないようだから、定義を確認しておこう。 ただしこれは一般的な解釈であり、おそらくこのスレの住民は共有してる。 ・テンプレート、クラス構文、スマポ等、 C++コンパイラではないと通らない機能を使ったコードを、C++のコードという。 ・その他、関数ポインタ等、Cコンパイラでも通る機能のみで書かれたコードを、Cのコードという。 > 一般に、カーネルモジュールをC++で設計するやつは、以下のいずれかだ。 > > (a) 好んで厄介事に巻き込まれたい者 > (b) 自分が書いているのは実はCだと気がついていないC++バカ > (c) 授業でそういう課題を与えられた者 > > (d)を付け加えるなら好きにしてくれ。 > > Linus > https://cpplover.blogspot.jp/2013/05/linus-torvalsc.html 君は多分(b)だね。 今の話題はC++のコードとCのコードの速度比較ということでよろしく。 >>673 > C++で最適化に行き詰まった時に > わざわざコンパイラをCに変えて最適化する事なんてないから そんな話は誰もしてない。 勿論その場合はCのコードに変更し、C++コンパイラを使うに決まっている。 じゃないと他の部分が通らないだろ。 君の定義は、C++コンパイラを使っていればどういう書き方であってC++ということだったのか。 なら話は噛み合わないさ。 #define SIZE 100000000 long long array[SIZE]; int comp(void const* lhs, void const* rhs) { if(*(long long*)lhs < *(long long*)rhs) return -1; if(*(long long*)lhs > *(long long*)rhs) return +1; return 0; } int main(void) { clock_t t0 = clock(); qsort(array, SIZE, sizeof(long long), comp); clock_t t1 = clock(); printf("%g[sec]\n", (double)(t1 - t0) / CLOCKS_PER_SEC); //2.288[sec] } #define SIZE 100000000 long long array[SIZE]; int main(void) { clock_t t0 = clock(); std::sort(array, array + SIZE, std::less<long long>()); clock_t t1 = clock(); printf("%g[sec]\n", (double)(t1 - t0) / CLOCKS_PER_SEC); //8.245[sec] ・・・あれ? 何だこりゃ } >>657-658 そういやスタックにとる可変長配列はC++にないんだな まあメジャーな環境でalloca( )使えないものはないと思うが 例外は使わないようにすればいいだけかと >>678 一応、基本的確認をするが…データは同じなんだよな? 俺の予測では同速。多分そちらの期待も同じだと思うが。 >>676 > ・その他、関数ポインタ等、Cコンパイラでも通る機能のみで書かれたコードを、Cのコードという。 可変長配列とか使ってないならC++のコードでもある つまりC++の範疇で書き直してるだけ って言うのが大方の人の解釈だと思うが >>676 それは単なる君の定義 100歩譲っても5chで一般的なだけ 普通C言語, C++と言えば、 その規格や規格に準拠したコードを表す >>681 それは君の勘違いだね。 その定義ならC/C++を区別する理由がないし、多分LinuxもC++になってしまうだろ。 >>676 たとえばヘッダファイルなんか、同一のファイルを Cコンパイラに入力したり C++コンパイラに入力したり ってこともあるよな 内容には無関係で単に Cコンパイラに入力したらCのコードで C++コンパイラに入力したらC++のコードだろ 最適化の内容だってrestrictのように CとC++で違ってくる可能性はあるしな >>682 最適化の掛け忘れでは? Cの方はほぼ最適コードだが、(メモリアクセス減らして一時変数に取れとかその程度) C++の方は最適化無しだとトンデモコードが出てくるが、 最適化でそれを消すからおkというノリだったと思ったぞ。 最適化無し同士の比較は意味がない。最大最適化同士の比較やってみそ。 使うモジュールの差を言語で言うから話が紛れる で、 君の定義であるごく一般的な記述を行った場合の話であれば C++の方が速いこともあるしCの方が速いこともある C++はテンプレートによって専用のコードをたくさん作る 当然汎用バイナリよりも専用バイナリの方が最適化がかかりやすいし、 変数よりも即値の方が速いことも多い C++例外処理も有効で、 これによって処理が速くなる場合がある >>686 gcc unko.c -O3でやってる >>685 > 内容には無関係で単に Linus全否定かよ。 >>682 オールゼロでクイックソート? それは... >>687 > 君の定義であるごく一般的な記述を行った場合の話であれば > C++の方が速いこともあるしCの方が速いこともある ねーよ。 実例挙げてみ? それって単なるコンパイラの適性であって、コード自体の速度ではないだろ。 C++とCの本質的な速度差ってのは絶対にひっくり返らないものであって、 例えば、スマポを使っている限り参照ポインタを管理する分だけ遅くなる、というもの。 コンパイラがどう進化しても、「0」「ADDまたはDEC命令」の差はひっくり返らないんだよ。 > C++例外処理も有効で、 > これによって処理が速くなる場合がある ねーよ。Cは最初から全部noexceptだ。 ソートって メモリサイズ 比較コスト コピーコスト キャッシュサイズ ... こんなんで結果(時間)が大きく異なるんだよね クイックソートだと データの並び順でもたまたま選んだピボット値でも変わる 1個の場合を比較してもあまり意味が無いぞ clでやってみたら期待どおりの結果になった >>677 1.789[sec] >>678 0.623[sec] 最適化は/Ox >>690 ああ、それは確かに テストデータをまじめに作るか。。。 >>688 となるとアセンブラを確認するしかないね。 (いいサイトはあったはずだが、普段使わんから忘れた) >>693 それさ、以下の3条件でやってみ。 1) Cのコード(677)を、Cコンパイラ 2) Cのコード(677)を、C++コンパイラ ←追加 3) C++のコー(678)を、C++コンパイラ Cコンパイラってポインタ周りは最適化をかけないから、多分、 速度差はコンパイラ起因であって、コード起因では無いと思う。 >>696 > (b) 自分が書いているのは実はCだと気がついていないC++バカ > https://cpplover.blogspot.jp/2013/05/linus-torvalsc.html 君の定義が正しければ、上記(b)の定義が出来なくなるだろ。 >>691 C++が遅くなる例だけあげてC++が遅いって言ってもねえ C++が速い例 double p = 1.; int n; for (n = 1 ; ; n++){ p *= n; } C++だと例外処理をつかって、いつオーバーフローするかわかるんだけど 例外を使わないとどういうコードになるかねえ? --- Cで普通に汎用vectorを作るとすると 普通は汎用バイナリで作ることになるんで 関数ポインタを経由する事になっちゃうけど C++のテンプレートだとだとそれぞれ専用なんで 関数コールが速いよね アドレス計算も即値の乗算だから色々なテクニックが使える >>699 > C++が速い例 Java出身か?死ね C++だとコンテナを使ってまともなソートを簡単に書けるけど Cだと面倒だからバカソート ってのも普通にある 要素数が少なければ意図的にやったりもする 一般的なコードではCの方が速い事の方が多い ってくらいの主張にしとけば良いものを 強い主張をしちゃうから >>701 ん? 良くわからんが負け宣言てことでいいのかな? >>684 何を言ってるのか意味不明すぎる よほど感覚が独自なんだろうな w >>699 おっとすまん、ポインタアクセスでのメモリオーバーフローと勘違いしてた。 doubleの無限大の例外って事? 俺はそっちには詳しくないが、浮動小数点例外をソフトウェアで検出するのなら同じだし、 ハードウェアでの検出なら割り込みがかかるだけで、速度的にはこれまた同じだが。 vectorについては完全に君の勘違いだぞ。 Cではそれぞれ専用の物を作るのが基本であり、それを一つにかけるようにしたのがテンプレートだ。 多分、理解の仕方が逆だ。 >>699 > Cで普通に汎用vectorを作るとすると > 普通は汎用バイナリで作ることになるんで 速度云々議論してるところでそんなことする奴はバカって言われてもしょうがないと思う >>705 > ハードウェアでの検出なら割り込みがかかるだけで、速度的にはこれまた同じだが。 Cだと言語の範疇ではその割り込みを処理できない なのでif文とかでオーバーフローするのを検出するとかが必要 って話だろ >>707 > if文とかでオーバーフローするのを検出するとかが必要 ほう。ならそのコードを書いてみ。 そしたらそのコードの中でオーバーフローするから無限ループだね。 そんな言語が実用だったとでも? >>705 例外については「お前は頭が悪すぎて会話にならん」とだけ コンテナは 「C++の方が遅い例だけ扱って、速い例は自分の想定と違う」 という主張を続けるならお前と会話しても無意味だ IDが変わってしまった まあそんな事はどうでもいいか ちなみに速度比較についてはいろんな人が様々やってるけど、 俺的にまあ公平だと思えるのはこれだね。俺の体感ともだいたい一致する。 おれはC++は1.1-1.3位かと思っているけど。 > C 1.00 > C++ 1.56 > Java 1.89 > C# 3.14 > https://jaxenter.com/wp-content/uploads/2017/09/energy-efficient-languages-768x689.png > https://jaxenter.com/energy-efficient-programming-languages-137264.html C++の機能をバリバリに使ったら、そりゃJavaと大して変わらんだろ、ということになるし。 スマポってのは良くできたGCとコストはほぼ同じだし。(GCは全自動なだけ) Javaは以前は3程度だったが、ゴリゴリチューニングしてきているらしい。 >>706 速度優先のコード前提ってことなら 保護されまくった高機能汎用コンテナを使うこと自体アホってことになるねえ さらに条件を加えちゃってもう >>708 なんで喧嘩腰なのかがよくわからないけど、 C言語では「n <= DBL_MAX」というif文が必要ってことだろ? double p = 1.; int n; for (n = 1 ; n < DBL_MAX; n++){ p *= n; } >>714 いやオーバーフローするのは p だろ。 と思ったが、もしかして n の方なのか? >>716 通じたようで何より。 だからオーバーフローの検出はソフトウェアでは辛くて、通常はハードウェアのはずだ。 そしてその場合は割り込みとなり、Cの場合は割り込みハンドラにコードを書くことになる。 C++の場合は『そこから例外処理ルーチンまで引っ張ってきてくれるコード』をコンパイラが用意し、 ユーザーのcatchコードを実行する。つまり、上記『』内コードでラップされてる分だけ遅い。 (実際にはラップだけではなくスタックウォークも行うから相当遅いはずだが) なんだが、実際俺はゼロ割例外しか見てないからオーバーフローについてはよくは知らん。 ハードウェア的には上記の動作になる。 一般的にはオーバーフロー例外は出ない環境(無限大に貼り付けるだけ)で使うのではないかと。 Cではアホみたいにゼロ割チェックやってるよ。 これはC++でも同じだと思うが、C++erはやらないのが作法なのか? とはいえ、ゼロ割はCMP+Brachであり、通常は分岐しないから、x86ではほぼゼロコストだ。 割り込みは関数呼び出し自体が遅くなるから、結局これもCの方が速いはずだが。 >>712 お前話の流れが読めてないだろ w >>638 から読み直せ、バカ overflowてexception吐くんだっけか >>708 バカはこれだから w isfinite( ) マクロとかも知らんのかよ >>717 オーバーフローで例外や割り込みが起動することはないのでは? 普通、無符号ならキャリー、符号有りならオーバーフローのどっちかのフラグで判定するかと unsigned long long array[100000000]; ↑ ここに同じファイルから乱数を読み込んで比較してみた clのオプションは /Ox /arch:AVX gccのオプションは -O3 -mtune=sandybridge qsort cl 27.171[sec] gcc 26.139[sec] std::sort 途中で書き込まれてしまった unsigned long long array[100000000]; ↑ ここに同じファイルから乱数を読み込んで比較してみた clのオプションは /Ox /arch:AVX gccのオプションは -O3 -mtune=sandybridge qsort cl 27.171[sec] gcc 26.139[sec] std::sort cl 13.456[sec] gcc 9.103[sec] おまけ std::sortにstd::execution::parを指定してみた cl 3.288[sec] gcc 未実装 >>698 そこの2通目に箇条書きしてある部分は 1992年当時に俺が思っていたことに近い ・例外がクソ うん、マジクソだ C++11以後マシになったが下痢が治ったという程度 ・newいらねー 演算子newを初めて聞いた瞬間、 mallocの設計理念が大声でわめき立てた C++11以後ブーイングが更にエスカレートした ・キーワードclassいらねー 禿自身が認めやがった ・・・しかし、それがなぜ>>685 への反駁に引用されるのかがわからん >>721 大抵のプロセッサの浮動小数点ユニットにはオーバーフローしたら例外を発生させる機能がある それを有効にしてるかどうかは環境による あとC言語の話で割込ハンドラーとか言ってる>>717 は単なる知ったかなのでスルーした方がいい >>726 >大抵のプロセッサの浮動小数点ユニットには 「浮動小数点ユニット」なんですね、ここで確認しておきます。 >オーバーフローしたら例外を発生させる 演算結果が ±inf になることを「オーバーフロー」と言うのですか?ちょっと耳慣れないですね >>726 >C言語の話で割込ハンドラー lsi-c ver3, MS-C ver6 あたりでは、そういうのもあったと記憶してます、 matherr() ですね だから >>717 はあながち間違いとはいいきれない面もあります >>725 世間では「どちらのコンパイラを使うか」ではなく、 「どちらのスタイルで書いているか」でCとC++を区別してるんだよ。 >>727 > 演算結果が ±inf になることを「オーバーフロー」と言うのですか?ちょっと耳慣れないですね それ反対、オーバーフローしたら結果をinfにしてるだけ >>729 inf も NaN も浮動小数点表現の中にあるので「オーバーフロー」と呼びにくい、と思っています、まあ人それぞれ >>730 だから誰もinfがオーバーフローとは言ってないだろ オーバーフローしたらそれっぽい値としてinfを入れてるだけ >>728 それなら Cスタイル、C++スタイル と言えば良い CかC++かは当然コンパイラで決まる C++は元々上位互換を目標に作られた物だ >>732 > C++は元々上位互換を目標に作られた物だ そうだ。そしてだからこそ、スタイルで区別されるんだよ。 元々C++はCの完全上位互換だった。 だから君らの定義なら、C++が登場したときから全てのCは消滅し、C++になっているはずだろ。 実際はそうじゃない。 「○○のコードはCで書かれています」 「○○のコードはC++で書かれています」というのは、 世間では俺の言った定義(>>676 )で使われてる。 その後、CとC++が仕様的に分離してしまったから、 今現在はCコンパイラで通るコードがC++コンパイラで通らないケースが存在する。 だから今は明確に「どちらのコンパイラを使うか」を想定しておく必要があるが、 それもコーナーケースで、 大半の「Cのコード」はC++コンパイラでもそのまま通る。 お前らがC++信者でC++の範囲を広く取りたいのは分かるが、世間はそうじゃない。 C++がCの仕様を全て取り込んだら、 お前らにとってはCは消滅、全てはC++になり、お前らは幸せになれるだろうさ。 ただ、その後も世間はCとC++を引き続き区別するだろうよ。 お前用語の定義の説明とかどうでもいい スタイルの意味ならスタイルと書け >>734 それは嘘だなぁ extern "C"が無いとCライクに見えるオブジェクトを吐かない事が常となっているC++(コンパイラ)について、いくらpure Cライクなコードを書いてもpure Cでないextern "C"を書かないとCライクに見えるオブジェクトは吐けないってそれはもうC++でしょう 他の内容にも誤りがあって君の世間ではCライクなコードであればCで書いたと宣言していいらしいけど、少しでも世間のOSSのコードを見て回れば良いよ Cで書かれているのはCだから お前らが誤解したままでいるのはお前らの自由だが、 お前らの定義だと、CとObjective-Cを区別できないだろ。 あれはCの完全上位互換で、Cコードそのまま食えるらしいからね。 お前らも少し考えれば自分で矛盾に気づけるはずだが。 >>734 それは言い過ぎでしょ。 流石にそれは、世間を知らなすぎ、と言われても仕方ない意見にみえてきたなあ。。。 ならもうちょっと分かりやすい説明をしてやる。 >>677-678 について、お前らの定義では『コード』について議論できないだろ。 俺の定義では、677は「Cのコード」で、678は「C++のコード」だ。コンパイラに依らない。 お前らの定義では、678は明確に「C++のコード」だが、677については、 「Cコンパイラを通した場合、677はCのコード」 「C++コンパイラを通した場合、677はC++のコード」 になってしまうだろ。 それだと、CとC++の『コード』の速度比較自体が定義できないだろ。 677をCコンパイラを通した場合とC++コンパイラを通した場合の速度差は、 「コードの差」ではなく、「コンパイラの差」なんだよ。 当たり前だろ。 というか、C++erもここまでレベルが落ちたのか。世も末だな。 std::filesystemで片方のスレッドでファイルを出力し もう片方のスレッドでファイルが存在していたら読み込むというプログラムを書いた場合 出力中に存在すると判定されて読み込んでしまいそうですが、 そんなことないでしょうか? もし読み込んでしまう場合、自力でフラグ管理かMutexを使うなどして 判定する以外の方法はあるでしょうか? >>739 お前が考えた定義とかどうでも良いって言ってるの というか何でお前らそんなに必死なんだ? 俺の言ってる定義が世間一般の定義だよ。 そうじゃなきゃ『コード』の善し悪しの議論が出来ないだろ。自明だと思うが。 繰り返すが、C++がCよりも遅いのは事実で、それもググレばいくらでも出てくるだろ。 ただこれはC++そのものよりもオブジェクト指向の弊害だが。 http://chrismdp.com/2015/04/how-i-doubled-the-speed-of-my-game-by-giving-up-on-c-plus-plus/ https://www.quora.com/Why-is-object-oriented-programming-OOP-slower-than-procedural 逆に言えば、C++の機能をふんだんに使ったとして、Javaに対する速度優位がどれだけあると思ってるの? C++で世界が再統一されることは、今のC++の仕様/方向性ではあり得ない。C++ではCを殺しきれない。 だからRustが生まれた。 >>711 の表を信じるなら、RustはCの代替としてはC++以上に上手く行ってる。 お前の定義じゃないと議論が出来ないのは おまえがアホだから 面白くていいじゃないですかぁ… ここで linus メールをコピペ(省略) >>742 面白い表ですね つい C# とか lisp の立ち位置を確認してしまった… >>739 だからお前のオレオレ定義なんてどうでもいい そもそも>>638 みたいな話でC++→Cで全面書き換えなんてする奴はいないだろ まともなプログラマーならボトルネックを見つけてその部分を書き換える 例えば1つのファイルに関数f1()とf2()があってf2()がボトルネックだからC++からCの範囲で動くようなコードに書き換えたとする お前はそのファイルの記述言語は何て言うんだよ? 関数毎に記述言語が違うとか言い出すのかよ w >>740 > 出力中に存在すると判定されて読み込んでしまいそうですが、 > そんなことないでしょうか? そりゃ普通にそんなことあるだろ > もし読み込んでしまう場合、自力でフラグ管理かMutexを使うなどして > 判定する以外の方法はあるでしょうか? そもそも何をしたいのよ? 出力完了してから読みたいだけなら出力完了してから読み込む側のスレッド起動するとかする方法もあるだろうし >>749 お前がIDコロコロしてまでも定義にこだわる理由が分からん。 お前の定義なら、仮に全面インラインアセンブラで記述してあっても、 Cコンパイラを通したらそれは「Cのコード」であり、 C++コンパイラを通したらそれは「C++のコード」になり、 Objective-Cコンパイラを通したらそれは「Objective-Cのコード」と言うんだろ。 そんな定義の奴はいない。それは「アセンブラ」と言うんだよ。 ただこの定義はもういい。 君は間違いを認めないようだし、仮に俺が間違っていたとしても、 お互いの認識のズレは確認できたのだからそれでいいだろ。 そして>>638 は最初からそう言っているだけだ。 お前は「コンパイル単位」でしか言語を規定できないからおかしな事になっている。 世間は「コード単位」でも言語を規定する。だから、お前が > f2()がボトルネックだからC++からCの範囲で動くようなコードに書き換え と言うのを、世間では「f2()をCコードに書き換え」と言うんだよ。 仮にお前の定義が正しくても、これを日常的にやるようなら、じきに略されて 俺(世間)の言い方に落ち着くのも分かるだろ。 だから>>638 は最初から、お前の言葉で言う、 > f2()がボトルネックだからC++からCの範囲で動くようなコードに書き換える 「f2()がボトルネックだからC++からアセンブラの範囲で動くようなコードに書き換える」事を > もっと速くしたい所をCやasmで書く と表現している。元々「コンパイル」単位ではなく、「コード」単位なんだよ。 その「コード」について議論するのに、「コンパイル」単位を持ち出すのはおかしいだろ。 「速くしたい『所』」ってのは一部限定って事を明示してるだろ。 お前はどうしても認めないようだが。 お前は根本的に考え方がおかしい。それではまともな議論が成立しないだろ。 議論している粒度に合わせた言葉を使え。 >>751 > ただこの定義はもういい。 > 君は間違いを認めないようだし、仮に俺が間違っていたとしても、 > お互いの認識のズレは確認できたのだからそれでいいだろ。 いきなり弱気になってて笑うわ w 自己解決しました。 仮の名前でファイルを書き出してからリネームすれば書き込み中か書き込み済みか 判定する処理をなくせるみたいでした。 >>751 コンパイラが変わらない単なる最適化で C++からCにする なんて言わないから普通 少なくともエンジニアの会話では無い 簡単にいう場合は「最適化」「チューニング」だし 詳しくいう場合は中身を具体的に言う 頭の悪い文系を騙すのには使えるのかもしれないけど C言語風なコード と C言語のコード 全く意味が違う 「C++で書く」→カジュアルにSTLとか使って読みやすく書く 「Cやasmで書く」→キャッシュやSIMDとか低級に考慮してガリガリ最適化する くらいの軽い気持ちで書いただけなのに紛糾しすぎててワイ将困惑 >>756 おまえさんの頭がC++03のまま更新が止まってしまっていることはわかった C++xx この末尾のへんなナンバリングが施されるようになったのっていつ頃から? >>762 元々はC++09を狙ってたらしいから2008年頃じゃね? ■ このスレッドは過去ログ倉庫に格納されています
read.cgi ver 07.5.1 2024/04/28 Walang Kapalit ★ | Donguri System Team 5ちゃんねる