[過去ﾛｸﾞ] C++相談室 part157 (1002ﾚｽ)
上下前次1-新
このｽﾚｯﾄﾞは過去ﾛｸﾞ倉庫に格納されています｡
次ｽﾚ検索 歴削→次ｽﾚ 栞削→次ｽﾚ 過去ﾛｸﾞﾒﾆｭｰ
503: 2021/10/06(水)09:41 ID:DE23Rkof(1) AAS
>>498
> 普通はオーバーロードだな。
これに一票
504: 2021/10/06(水)10:03 ID:7OUEgWer(1) AAS
>>489
gcc7でも-O2つけるとダメだね
つけなきゃ一致するけど
505: 2021/10/06(水)10:45 ID:Cv4NDZSF(2/2) AAS
デフォとかナウいとかアホかと
506: 2021/10/06(水)12:20 ID:iqYhGyd9(1) AAS
最適化オプションの違いで挙動が変わるようなコードはそもそもダメだって理解してくれよ
507: 2021/10/06(水)13:11 ID:BBSbIN5v(1) AAS
インテルコンパイラはもう規格満たしてないだろってくらい滅茶苦茶に挙動を変える
gccなら、最適化で結果が変わるようなコードはダメコードと言って良いと思う
508: 2021/10/08(金)05:56 ID:Xasiu/5n(1) AAS
>>496
遅レスすまそ
testなら部分特殊化できるのはわかるんだが
その場合クラス定義の全部を書き直すよな
template<class T1>
struct test<T1, void>
{
void fig1();
void fig2(); //特殊化したいのはここだけ
void fig3();
省3
509(1): 2021/10/08(金)23:05 ID:xNy0cJty(1) AAS
関数テンプレート内でラムダ式使おうとしたらコンパイルできない
template<class T> void hoge(){
auto func = [](){return 0;};
}
int main(){
hoge<int>();
return 0;
}
in instantiation of function template specialization 'hoge<int>' requested here
と出るが、何がだめなのかよくわからん
510: はちみつ餃子 ◆8X2XSCHEME 2021/10/08(金)23:18 ID:ZAq25yo3(1/2) AAS
>>509
そのメッセージは「関数テンプレートはここで特殊化 (テンプレート引数を当てはめて具体的な型に展開) されたやで」
というメッセージで、普通は他の警告やエラーの補足として出てくる。 なんか警告が一緒に出てない？
func が定義されとるけど使ってないという警告は出てくるけど無視して問題ない警告なのでコンパイルできないってことはない。
警告をエラー扱いにするオプションを付けてたりしない？
511(1): 2021/10/08(金)23:23 ID:awgtN1Ul(1) AAS
C+pod
画像ﾘﾝｸ[jpg]:toyota.jp
512: はちみつ餃子 ◆8X2XSCHEME 2021/10/08(金)23:28 ID:ZAq25yo3(2/2) AAS
>>511
C++20 では std::is_pod や POD の概念自体が非推奨になってるぞ。
次あたりでは廃止されるんとちゃうか。
513(1): 2021/10/09(土)21:11 ID:PhB5rfBq(1) AAS
あるラムダ式が他のラムダ式をコピーするとき、参照キャプチャにするかコピーキャプチャにするか迷うんですが、皆さんはどういう基準で決められてますか
514: 2021/10/09(土)21:14 ID:yAn344zh(1/2) AAS
外部ﾘﾝｸ:ideone.com
やたーセマフォできたよ。
これバグってるかな?
515: 2021/10/09(土)21:17 ID:yAn344zh(2/2) AAS
>>513
コピーキャプチャはコピーなので、それ相応のリソースを食う。
基本は参照キャプチャにしている。
516(2): 2021/10/10(日)01:44 ID:qGt3mQky(1/7) AAS
破壊的代入の余地が無いようする
つまりコピーを第一の選択肢として考えるする
517: 2021/10/10(日)01:50 ID:qGt3mQky(2/7) AAS
*thisはさすがに参照にすることが多いが（だいたいコピコンがあるとも限らないし、
とはいえ参照コピーしてパラメータに対する破壊的代入を許すと思想的に重箱読みになって気持ち悪い気がするし、
参照渡ししたオブジェクトは一般にスレッドローカルとは言い切れなくなることから
スレッドセーフと断言しにくくなるというのは実害に数えて良いと思う
入れ子になったラムダ式の奥深くでそれをやられると、いつ排他制御すべきなのかが全くﾜｹﾜｶﾒになりかねない
518(1): 2021/10/10(日)04:41 ID:/ScOmKIj(1) AAS
>>516
だとすると一番効果的なのは
C++でコード書くこと自体をやめることだな
あんたの場合は
519(1): 2021/10/10(日)07:01 ID:H3uBjuzu(1) AAS
>>516
コピーキャプチャが第一選択肢という結論は分かるが
それ以外の説明が完全に意味不明
520: 2021/10/10(日)09:28 ID:lWUpu20f(1/8) AAS
意図しない破壊を防ぐにはキャプチャしなきゃいいだけ
それを参照のせいにするゴミはプログラマの資質がない
521: 2021/10/10(日)09:31 ID:MbdCJRMe(1/2) AAS
とりあえずで[&]で書いてるな
丁寧にやりたければ変数ごとに考えて明示する
522(2): 2021/10/10(日)09:34 ID:lWUpu20f(2/8) AAS
コピーのコストに無頓着なやつは11以後のC++に向かないな
523: 2021/10/10(日)10:09 ID:B/tc3JZb(1/3) AAS
スレッド立ち上げるとかファイル書くとかクソ重い操作が伴う時にコピーコスト気にしてもしょうがない
場合によるとしか
524: 2021/10/10(日)10:37 ID:2ZvzU42q(1/7) AAS
どこでも使う汎用性高いものなら問題が起きる前に[=]にしてる
逆に[&]はよほど安全だと思わない限り使わない
525(1): 2021/10/10(日)10:45 ID:qGt3mQky(3/7) AAS
>>522
スレッドセーフをどう保証するかに無頓着な香具師はマルチスレッドプログラミングに向かんわ
>>518、>>519
低レベルなレスどうも
ラムダ式の成り立ちを知らなかったり
どのように使われるか想像できなかったり
使ったこと無いんじゃね；；；
526(1): 2021/10/10(日)10:59 ID:lWUpu20f(3/8) AAS
>>525
スレッドがどうたらはおまえさんが勝手に言い出したことで元質問にはない
まさかとは思うがコピーしてりゃスレッドセーフなんて主張はしてないよな
527(1): 2021/10/10(日)11:13 ID:qGt3mQky(4/7) AAS
ラムダ式は一般にラムダ式を定義したスコープの外に持ち出され、予見できないタイミングで使われうる
参照キャプチャだと
(1) ラムダ式が使われるタイミングで参照xの参照先が存在することが保証されていなければならない
(2) ラムダ式が使われるタイミングで参照xの参照先へのアクセスが他のスレッドと競合しないことが保証されていなければならない
とゆー2条件をクリアする必要がある。
コピーキャプチャだと（オブジェクトがディープコピーなら）どっちの配慮も不要
参照キャプチャして(1)、(2)を満たして安心できるのは、イミュータブルなオブジェクトだけ……！
528(1): 2021/10/10(日)11:14 ID:qGt3mQky(5/7) AAS
>>526
ラムダ式、が含意する事柄について不十分な理解なレスktkr、
危険プログラマー認定のレベル3ぐらいやな；；；
529(2): 2021/10/10(日)11:18 ID:B/tc3JZb(2/3) AAS
>>527
ラムダ式をスコープ外に持ち出すなんてレアケースを「一般に」とか言われましても
530: 2021/10/10(日)11:28 ID:2ZvzU42q(2/7) AAS
遅延評価されるものはよくコンテナに入れて後でぶん回されるから・・・
531(1): 2021/10/10(日)11:28 ID:qGt3mQky(6/7) AAS
>>529
定義するのと使う（評価する）のを同じスコープ内でやるならラムダ式使うまでもないじゃん？
ていうか使うまでもないんですよ
>>529はｱﾚな人？
532: 2021/10/10(日)11:38 ID:QniiN4Lz(1) AAS
スコープ内の変数をキャプチャする処理をスレッドで動かす場合は普通にラムダ式を使うと思うが。
533(1): 2021/10/10(日)11:39 ID:B/tc3JZb(3/3) AAS
>>531
はぁ？お前これしないの？ラムダ式のユースケースって9割方この類だろ
std::functionに突っ込んではるか遠くにぶん投げたりコンテナに詰め込んだりするのだけがラムダ式の使い道だと思ってるの？
std::sort(v.begin(), v.end(), [](int a, int b){/*...*/});
534: 2021/10/10(日)11:57 ID:tv4afNG+(1) AAS
みなさんスレッドセーフにしたいときはスレッドセーフになる様に書きましょう
535: ハノン ◆QZaw55cn4c 2021/10/10(日)12:13 ID:KKHdhYPj(1) AAS
>>522
11以前でも
536: 2021/10/10(日)12:21 ID:Ld3aFVRt(1) AAS
任意のスレッド安全性を実現するのはゼロコストでは不可能だから
必ずシングルスレッドで実行される保障がある場合などはあえてスレッド安全性を捨てることもある
537: 2021/10/10(日)12:31 ID:6/7jGiIK(1) AAS
std::conj() に double を渡したら std::complex<double> にキャストされるのが嫌なので、double を渡したら何もしないで double を返し、std::complex<double> を渡したら std::conj() と同じ動作をするオーバーロード関数 conj() を作ろうかと思うのですがアリですか？
なぜ std::conj() がそういう動作じゃないのか不思議で、何か見落としてたら教えてください
538(1): 2021/10/10(日)12:36 ID:2ZvzU42q(3/7) AAS
こここ・・こういうこと？
(A)キャプチャが必要でスコープ内で実行までされるケース
(B)キャプチャが必要でスコープ外まで実行が遅延されるケース
(B-1)ラムダ式生成時と実行スレッドが同じケース
(B-2)ラムダ式生成時と実行スレッドが違うケース
(A)なら全員「[&]で問題があるケースはない」と考えている
(B-1)は好みが別れているところ
(B-2)は好みが別れているところで、さらにキャプチャされる変数側をスレッドセーフにするかどうも好み
[&]と[=]がよく分からない人はコチラ
外部ﾘﾝｸ:ideone.com
省3
539: 2021/10/10(日)14:46 ID:lWUpu20f(4/8) AAS
>>528
日本語でおｋ
540(1): 2021/10/10(日)16:03 ID:lWUpu20f(5/8) AAS
>>538
おまえさんの論法では同時並行はすべて別プロセスにすべきってことだな
541: 2021/10/10(日)16:49 ID:2ZvzU42q(4/7) AAS
>>540
う〜ん、伝わらないですね・・・
共有リソースに競合するアクセスがなければ排他制御の必要がなく、スレッドセーフにする必要がないってことです
そもそもコピーして共有しないことで排他制御が必要なくなれば、スレッドセーフにしなくていいという考え方ですよ
542(1): 2021/10/10(日)16:51 ID:lWUpu20f(6/8) AAS
だから共有＝リスクなんだろ？
もうマシンも別の実機にすれば最強防御じゃん
543(1): 2021/10/10(日)17:01 ID:2ZvzU42q(5/7) AAS
>>542
残念ですが理解してもらうことは諦めます
544: 2021/10/10(日)17:32 ID:qGt3mQky(7/7) AAS
>>533
頭の中がgdgdな人が話をgdgdにしようとしていまつね……
std::sort()の呼び出しと同じスコープが終わった後に
[](int a, int b)が呼び出されないということは、単にstd::sort()がreturnするまでにラムダ式を忘れてくれる作りだから（たまたま）担保されているだけであって、
[](int a, int b)のスコープが限定されるために担保されているわけではないし、
[](int a, int b)がラムダ式だから担保されているわけでもないの。
つまり、>>533は
>ラムダ式をスコープ外に持ち出すなんてレアケース（>>529）
の根拠に全くなっていないワケ
545: はちみつ餃子 ◆8X2XSCHEME 2021/10/10(日)17:47 ID:cCUvKLuJ(1) AAS
レアケースがどうこういったところでレアケースなら考えなくていいってわけでもない。
そんなの個別の事例ごとに考えるしかしょうがないだろう。
546(1): 2021/10/10(日)17:56 ID:lWUpu20f(7/8) AAS
>>543
無理筋の主張ってことがわかってもらえたならいいよ
547: 2021/10/10(日)18:04 ID:2ZvzU42q(6/7) AAS
>>546
無理筋ではありませんよ
スレッド以前から並列処理で共有される実行コンテキストを分けることは大昔からやられてきました
今更その手法自体を想像できない人に、こんなところで説明するのは困難なだけです
548(1): 2021/10/10(日)18:11 ID:lWUpu20f(8/8) AAS
おまえさんの言う「大昔」がどのくらいか知らんが
俺が若手の頃はRENT,REUSなんてやってたよ
549: 2021/10/10(日)18:25 ID:Euz3vWgQ(1) AAS
ラムダ式によって作られたオブジェクトがキャプチャされたオブジェクトより長生きする可能性があるならコピーキャプチャ
そうでなくともレジスタに乗ると思われるならコピーキャプチャ
そうでない場合に初めて参照キャプチャ
排他に関してはshared_ptr<mutex>とshared_ptr<なかみ>をメンバに持たせてコピー可能にしつつ、メンバ関数経由で排他制御するのが筋だと思う
RustのArc<Mutex<T>>パターンに影響されすぎかもしれないが……
いずれにせよキャプチャと排他制御の問題とは切り離して考えることができるし、そうすべき
550(1): 2021/10/10(日)21:19 ID:MbdCJRMe(2/2) AAS
ラムダ式関連でいうと参照とかコピーをデフォルトだけで指定したときも実際に使ったものの分しかクロージャオブジェクトのサイズに乗ってこないと思ってるんだけどヤバい？
551(1): 2021/10/10(日)23:42 ID:9PtWfEC6(1) AAS
>>550
むしろ他に何が乗ると思っているのか？
気になるなら生成コード見て確認すればいいだろうとも思うし。
552(1): 2021/10/10(日)23:58 ID:2ZvzU42q(7/7) AAS
>>548
大昔とは1990年頃の話です
COBOLなのか知りませんが、reentrantとreusableは今回の話と直接関係ありません
553: 2021/10/11(月)02:51 ID:1CVjhT+M(1) AAS
>>551
cppref見たらクロージャオブジェクトのサイズは未規定とあって気になった
554(1): 2021/10/11(月)05:43 ID:FIUH1xZN(1) AAS
>>552
関係大ありだよ
あの当時はアセンブラでC++は使ってなかったというだけだ
わかってないのおまえさんだな
555(1): 2021/10/11(月)07:43 ID:M/9mFHzI(1/2) AAS
>>554
説明するべきでないのが残念ですが、その頃からあなたが分かってなかっただけですよ
556(1): 2021/10/11(月)07:52 ID:pMbZgi1h(1/2) AAS
>>555
おまえさんがどう思おうと勝手だが
センターオウンコーディングとかやってたよ
マウント取られる気が全くしねえぜ
557: 2021/10/11(月)08:08 ID:M/9mFHzI(2/2) AAS
>>556
マウント取る取らないとかどうでもいいです
あなたが理解できないのをどうにもできないだけなんです
558: 2021/10/11(月)08:46 ID:pMbZgi1h(2/2) AAS
と言うことにしたいのですね
559: 2021/10/11(月)09:17 ID:G+wdAsto(1) AAS
リエントラント目指してもいいじゃないの
560(1): 2021/10/11(月)09:58 ID:F+cmXQty(1/2) AAS
クラスの型を自動変換して関数に入れるにはどうすればいいですか？例えば、
class A {
public:
double hoge;
};
class B {
public:
int hogehoge;
};
int function(A aaa);
省3
561: 2021/10/11(月)10:22 ID:T3qmZxdk(1/3) AAS
>>560
Bを受け付けるfunctionを書くんや
562: 2021/10/11(月)10:50 ID:QW1mycSW(1) AAS
B extends A
としたら
function
の引数をキャスト？で動かない？
563: 2021/10/11(月)10:54 ID:RUUSz/4T(1/2) AAS
簡単や
template<class A>
int function(A aaa);
564(1): 2021/10/11(月)12:11 ID:F+cmXQty(2/2) AAS
できました。ありがとうございます。
また、ポインタのvectorを実体として使うにはどうすればよいでしょうか？
std::vector<A*>
で定義されてるものを、
std::vector<A>として使いたいです。
別のvectorにポインタ値を詰め直せばいけると思うのですが、元のポインタの場所のまま実体で使いたいです。無理でしょうか。
565: 2021/10/11(月)12:31 ID:T3qmZxdk(2/3) AAS
参照を使うんや
566: 2021/10/11(月)13:03 ID:NaSXzxBw(1) AAS
参照のvectorなんて作れたっけ？
567: 2021/10/11(月)13:16 ID:T3qmZxdk(3/3) AAS
reference_wrapper使うんや
まあ下らんこと考えんほうがええ
568: 2021/10/11(月)17:28 ID:0Mn4AOx6(1) AAS
>>564
ややこしい所有権・所有責任問題が発生するから、ソースコードを見直したほうがいい。
具体的にはstd::vector<*A>を
std::vector<std::shared_ptr<A>>
にして、shared_ptr<A>をやり取りするようにすべきだな。
性能問題とか互換問題とかでも無ければvector<*A>なんて使うもんじゃない。
569: 2021/10/11(月)20:43 ID:bPHZE8G4(1) AAS
言ってることは同意だが、ポインタの型もまともに書けないような人に言われても説得力がない
570: 2021/10/11(月)20:47 ID:c9XBGwkD(1) AAS
Rustと間違えたんじゃね
571: 2021/10/11(月)22:25 ID:RUUSz/4T(2/2) AAS
簡単や
std::vector<std::shared_ptr<A>>
572: 2021/10/11(月)23:13 ID:9gfKW03X(1) AAS
ドラクエ３のバージョン違いの謎に迫る！
動画ﾘﾝｸ[YouTube]
2021/10/01に公開済み
FC版DQ3には、ＡバージョンとＢバージョンが存在する
今回はROM内のプログラムを徹底比較！
どこが違うのか白黒ハッキリさせると息巻いた内藤プロ
当時自分が作ったのに全て忘れてて大変なことに・・
573(2): 2021/10/12(火)04:13 ID:jMkI4z1q(1) AAS
ぶっちゃけ継承とかポリモフィズムはオワコンでテンプレート最強？
574: はちみつ餃子 ◆8X2XSCHEME 2021/10/12(火)04:25 ID:WB1ScBpO(1) AAS
>>573
過去の C++ の流行においては継承が強調されすぎたこともあって
継承の害悪な面も見えて大幅な揺り戻しは有った。
しかしそれぞれに役割があるのでどれかが廃れるとかいう話ではない。
バランスとしては継承が控えめになったけれど、だからといって継承のない C++ はありえない。
結局のところそれぞれを適切に使えというだけのこと。
575: 2021/10/12(火)06:45 ID:LoAbYEbi(1) AAS
継承が有効に使われている事例をひとつも知らないヒヨっ子丸出しな質問だな
テンプレートの何がいいのかもわかってなさそう
576(1): 2021/10/12(火)07:03 ID:bL2VfUhD(1) AAS
CRTPとか見たら脳を壊しそう
577: 2021/10/12(火)07:24 ID:+oJUuDWk(1) AAS
>>576
virtual使えないor使わない処理系で、使ってみたけど確かに頭にスッキリ入らんパターンだわｗ
あれはあれでポイントで使うと便利だし、反対にやっぱvirtualも便利でいいよねーとか。
578: 2021/10/12(火)08:16 ID:4AIb2U7h(1) AAS
>>573
メソッド共通化を実現するための継承はオワコン。
プレースホルダーを用意するための継承は現役。
総称型が実装されれば継承自体をオワコンにできそうな気がするけど、総称型風スマートポインタて無かったっけ？
579: 2021/10/12(火)08:20 ID:vDVhyOYS(1) AAS
耳が腐る
580: 2021/10/12(火)09:51 ID:kjIGaWla(1/2) AAS
何でこんな荒れてんの？
581: 2021/10/12(火)10:09 ID:qN1bonoC(1) AAS
いつものこと
582: 2021/10/12(火)10:40 ID:kjIGaWla(2/2) AAS
単発荒らしか
583: 2021/10/13(水)04:27 ID:yxtzEQdj(1) AAS
void * の生ポが最強
584: 2021/10/13(水)07:29 ID:w2mbz/VV(1) AAS
○○なんていらねーよ害悪だけだ
まだ使ってるやつは全員バカ
これからは△△を使うべきだ
なーんて言っちゃってマウント取った気になってるおめでたいやつ
メガトン級にアホにされてることに気付かねえよな
585: 2021/10/13(水)09:41 ID:V99uCirA(1/2) AAS
vector を shuffle する場合について質問です(gcc/windows10でテスト)
vector<int> vec(50, 0);
for(int i = 0; i < 10; ++i) vec[i] = 1;
random_device dev_seed;
mt19937_64 mt(dev_seed());
shuffle(vec.begin(), vec.end(), mt);
で確かに shuffle されているのですが疑問点がいくつかあります
1.dev_seed()が毎回同じ値を返してる？
(random_deviceの使い方を間違えてる？)
2.先頭の値が1に偏ってる？
省3
586: 2021/10/13(水)09:47 ID:V99uCirA(2/2) AAS
ああこれか
外部ﾘﾝｸ[html]:cpprefjp.github.io
>GCC (MinGW): GCC 9.1までは擬似乱数生成器 mt19937 を用いるため使用を推奨しない。詳細は備考欄を参照。GCC 9.2からは暗号論的な乱数である rand_s を使用する。
587: 2021/10/13(水)10:51 ID:ocY7/s3a(1) AAS
偏りを判断する目が偏ってるのでは
588: 2021/10/13(水)12:39 ID:L2HfUVD6(1) AAS
random_deviceがダメな環境でrdtsc命令使ったことあるな
良いやり方かは知らん
589(1): 2021/10/13(水)16:09 ID:SuRXriSW(1/2) AAS
外部ﾘﾝｸ:cpprefjp.github.io って
外部ﾘﾝｸ:ja.cppreference.com があるのになんで使われてるの？
590(1): はちみつ餃子 ◆8X2XSCHEME 2021/10/13(水)16:23 ID:6cp7j/AO(1) AAS
>>589
前者は編集者による解説なども含んでいて仕様の意図や習慣がわかりやすい。 実装の現実みたいな補足もあるし。
後者は仕様書の再編を指向してるから正確だけど規則の羅列を読むのがしんどいこともある。
適宜使い分けて。
591: 2021/10/13(水)16:49 ID:SuRXriSW(2/2) AAS
>>590
ありがとう
592: 2021/10/14(木)00:25 ID:unU20Liw(1) AAS
逆にjaはほぼ見ないな
cpprefjpかen
593: 2021/10/14(木)17:38 ID:0xmYH4RJ(1) AAS
みんなで広げよう友達の輪
外部ﾘﾝｸ[io]:github.com
594(2): 2021/10/14(木)19:08 ID:D5VUtH01(1) AAS
今までJavaでやってきたけどC++もやってみたいんだよね
すぐ出来るようになると思う？
595: 2021/10/14(木)19:10 ID:u3valL3D(1) AAS
>>594
ならない
C言語のポインタや文字列について勉強したほうがいい
596(1): 2021/10/14(木)19:12 ID:pMO89bX6(1) AAS
>>594
c++でちょっとした文字列パースして内容に応じたオブジェクト構築する処理書いてたの、
ほぼ使ったことないJavaに移植したらスゲー早く出来てワロタ。C#もサクサクできたな〜
逆は色々イラッとするんじゃねぇかな?
597(1): 2021/10/15(金)01:29 ID:oSpeFu2A(1) AAS
元々C++はその辺の文字列処理を毎回1からゴリゴリ書くような言語じゃなくて何らかのライブラリを利用するものだと思うけど、
クロスプラットフォームで各種文字コードが自由に扱えて、c++11以降の仕様に対応してて、かつかゆいところに手の届くライブラリって意外とないんだよね
いや、俺が知らないだけかもしらんけどw
598: 2021/10/15(金)05:56 ID:JZ8LRo6T(1/5) AAS
実質的な標準と呼べるものは今もないよ
599(1): 2021/10/15(金)09:26 ID:c8xS1fS2(1) AAS
>>596
std::regex使ってようやっと、かね。
c++はいつまでたっても文字列処理苦手なままだわ。
600: 2021/10/15(金)10:21 ID:Sjupi756(1/3) AAS
Javaから入ると不能(陰ポ)になる
もう手遅れ
601: 2021/10/15(金)10:22 ID:Sjupi756(2/3) AAS
>>597
wxWidgets
602: 2021/10/15(金)10:26 ID:Eg3Mb3n8(1) AAS
あれ出来上がるバイナリ重すぎなんだけど、今は違ったりするのかね
上下前次1-新書関写板覧索設栞歴
あと 400 ﾚｽあります
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ AAｻﾑﾈｲﾙ
ぬこの手 ぬこTOP 0.059s