[過去ログ] C++相談室 part156 (1002レス)
1-

このスレッドは過去ログ倉庫に格納されています。
次スレ検索 歴削→次スレ 栞削→次スレ 過去ログメニュー
523: 2021/06/26(土)08:08 ID:EcYCTODA(1) AAS
ifndef イフンデフ
524: 2021/06/26(土)11:51 ID:7nyRjnb4(1) AAS
アとイ
525: 2021/06/26(土)13:16 ID:l0P5IISj(1) AAS
C++20でもバイナリファイルからdoubleとかの値を読み出す時って未だにreinterpret_cast使う感じ?
526: 2021/06/26(土)16:37 ID:qjgQHw2b(1) AAS
HTML★ふとまる
527: 2021/06/27(日)10:16 ID:0fbyaJPK(1) AAS
basic_istream::readの引数がvoid*なら何も悩まずに済むのにな
528: 2021/06/27(日)11:20 ID:hddKqCef(1) AAS
ファイルに書いている時点でアラインメントの保証が難しいから結局memcpyになる気がする
529: 2021/06/27(日)12:53 ID:CJK40NDs(1/3) AAS
アライメントの問題はファイル関係なくね↑?
530
(2): 2021/06/27(日)13:14 ID:CJK40NDs(2/3) AAS
エンディアン変換が関係しない場合
C++20でもバイナリファイルからdoubleとかの値を読み出す時はfread()
書き込むときはfwrite()
何の問題も無いし速い……
531: 2021/06/27(日)13:16 ID:CJK40NDs(3/3) AAS
ていうかエンディアン変換が関係する場合でも
fread()してからメモリ上でエンディアン変換しても良いし
メモリ上でエンディアン変換してからfwrite()したら良い
特にファイル内容全体がメモリ上に収まるケースとかは上記だけでほとんど何も考えなくてもよい
532: 2021/06/27(日)13:48 ID:NNV++T6E(1/2) AAS
P言語、Ruby、Java、C#などでファイルを読んだり書いたりしなければならなくなることを想定したファイル仕様にしたほうがいいと思うけどどうかな
533: はちみつ餃子 ◆8X2XSCHEME 2021/06/27(日)13:55 ID:+5rTVQj/(1/7) AAS
スタンダードレイアウトな型はバイナリレベルでコピーしてかまわないし
結果的に fwrite して fread できることは保証されるが、
具体的なレイアウトについての保証はない (他の処理系では同じレイアウトにならないかもしれない)
ということも合わせて考えると適当なシリアライザは挟んだほうが良いな。

多言語を意識しつつ高速なバイナリフォーマットというと MessagePack あたりかな?
534
(1): 2021/06/27(日)13:57 ID:mY5L/v8k(1/4) AAS
PerlやPythonでバイナリ読み書きするのに何の支障もないだろ。
535
(2): はちみつ餃子 ◆8X2XSCHEME 2021/06/27(日)14:00 ID:+5rTVQj/(2/7) AAS
>>534
読み書きに支障はないが、言語上の型とバイナリの対応付けについて明確な保証がないと困る。
536: 2021/06/27(日)14:16 ID:U1pSP8r9(1) AAS
バイナリなんだからどう扱おうが自由だろ
言語のせいにするのは本人の技術が無いから
言い訳するな
537
(2): ◆QZaw55cn4c 2021/06/27(日)14:25 ID:I46qTe+f(1/3) AAS
今時数値をバイナリで読み書きするとか、あり得ないのでは?
538
(1): 2021/06/27(日)14:30 ID:NNV++T6E(2/2) AAS
Comparison of data-serialization formats - Wikipedia
外部リンク:en.wikipedia.org
539
(1): 2021/06/27(日)15:19 ID:o9peEwic(1) AAS
>>537
バイナリでないと実用的でないデータなんていくらでもあるし。画像、動画、アーカイブ、db、ip...
qzはもうエロ画像見るなよ。
540: ◆QZaw55cn4c 2021/06/27(日)15:44 ID:I46qTe+f(2/3) AAS
>>539
ごめんなさい誤りましたので謝りますからその刑だけは平にご容赦を‥‥
541
(1): 2021/06/27(日)15:47 ID:mY5L/v8k(2/4) AAS
>>535
保証されてるから支障はない。エンディアンが違うデータだって読み書きできる。
542
(1): はちみつ餃子 ◆8X2XSCHEME 2021/06/27(日)15:54 ID:+5rTVQj/(3/7) AAS
>>541
データがリトルエンディアンなのかビッグエンディアンなのかわかっていればね。
C++ が単にメモリ上のデータを書き出したときに、それがどっちなのか、
(言語としては) 保証してないって話をしてるんだよ。
543: 2021/06/27(日)16:14 ID:jKhjPg/S(1) AAS
C++20でstd::endianが使えるようになるけど
544
(1): ◆QZaw55cn4c 2021/06/27(日)16:39 ID:I46qTe+f(3/3) AAS
シェアの高かった 68 系かインテルザイログ系か、の二分図がここにも残っているのですか
もう UTF-8 のようなエンディアンに依存しないバイナリが優秀だ、という価値観にするべきかと
545: 2021/06/27(日)17:01 ID:CxF0bT8t(1) AAS
インターネットのプロトコルはビックエンディアン
USB等のPC系発祥のデバイスはリトルエンディアン
この辺はもう変更しようが無いだろ
546
(1): はちみつ餃子 ◆8X2XSCHEME 2021/06/27(日)18:13 ID:+5rTVQj/(4/7) AAS
>>544
ここでのトピックは >>530 に対しての反論。
メモリ上にあるバイト列には保証がないからなんらかの明確な
データ交換用フォーマットに変換する処理が必要という話で、
出力先のデータ交換用フォーマットが BE か LE かなんていう以前の段階。
547: はちみつ餃子 ◆8X2XSCHEME 2021/06/27(日)18:17 ID:+5rTVQj/(5/7) AAS
ファイルに書き出すにあたって「エンディアンの変換が不要なら」という前提を置きたくねぇなぁという話だな。
パディングとかも入るかもわからんし。
548
(2): ◆QZaw55cn4c 2021/06/27(日)19:47 ID:igNiq52h(1) AAS
>>546
であれば、私はどちらかというと >>530 の味方側ですね、>>530 がそう意図しているかどうかは不明ですが、処理系のエンディアンを仮定することなくコードを書くことは可能だったと記憶しています。‥‥?

ただ同時に、確かにパフォーマンスの点で過剰な不利を承知で >>537 を再提示するべきかな
つまり、>>537 みたいな画像フォーマットはありました PPM/PGM/PBM
2chスレ:tech 
このコードは?を検証したものだったかと遠い記憶に残っていますね

あ、罰ゲームは勘弁ね、私だってエロ画像は見たい‥‥動画リンク[YouTube]
549
(1): はちみつ餃子 ◆8X2XSCHEME 2021/06/27(日)20:29 ID:+5rTVQj/(6/7) AAS
>>548
だからそういうコードが書けるかどうかという話じゃなくて
書かなきゃなんない (書くべき) ねという話なんだってば。
550: ◆QZaw55cn4c 2021/06/27(日)20:58 ID:2wFMzLzL(1) AAS
>>549
それは失礼しました
551
(1): 2021/06/27(日)22:44 ID:mY5L/v8k(3/4) AAS
>>542
C++だって読もうとするバイナリデータのエンディアンを事前に知らなきゃならんのは変わらんだろ。
自分で書いたものを読むならエンディアンが一致するのはあたりまえ。
552
(2): はちみつ餃子 ◆8X2XSCHEME 2021/06/27(日)23:46 ID:+5rTVQj/(7/7) AAS
>>551
> エンディアンを事前に知らなきゃならんのは

知らなきゃならないがわからん (保証されてない) のだという話をしている。
C++ で書いてメモリをそのまま書き出したらそれのエンディアンは保証されてない。

言語が何であれデータフォーマットが固定されてないとどうにもならん。
553
(1): 2021/06/27(日)23:53 ID:mY5L/v8k(4/4) AAS
>>552
それは言語関係ない話だろ。
554
(1): はちみつ餃子 ◆8X2XSCHEME 2021/06/28(月)00:31 ID:nxXyAxnK(1) AAS
>>553
言語に関係あるという話はしてないよ。
555: 2021/06/28(月)00:34 ID:AdoNh79c(1) AAS
Javaはメモリモデルも明確に決まってたんじゃないかな
556
(1): 2021/06/28(月)02:47 ID:DsF+RsPk(1/2) AAS
多言語間でポータブルにしたくば
XMLとかyamlとかjsonにしたら良いんじゃーあ!
557: 2021/06/28(月)03:12 ID:DsF+RsPk(2/2) AAS
どうしてもバイナリファイルが良いという向きは、
パディングとかもfwrite()とfread()で取り扱い得る
といっても単に適当なサイズのバイトの配列として読み書きして
メモリ上でご使用のアーキテクチャーに合わせることになるが
fwrite()とfread()を使わなければもっとマシになるという類の話ではない
558
(1): 2021/06/28(月)03:44 ID:QdlxBFRk(1) AAS
別にバイナリ吐き出すときは必ずポータブルにする必要ないだろうに
なんで勝手に条件追加して批判してんだか
559
(1): ◆QZaw55cn4c 2021/06/28(月)07:17 ID:oYDZ1nWa(1) AAS
>>556
お手軽な XML/yaml/json 読み書きライブラリを紹介してください、よろしくお願いいたします
560
(2): 2021/06/28(月)07:48 ID:cZa6zFVz(1) AAS
>>554
PerlでもPythonでもC++と変わりなくバイナリの読み書きはできるという話をしてるんだが。
エンディアンがわからなければC++でも読めないというのは当たり前。
フォーマットを知らないバイナリファイルってことだからな。
561: 2021/06/28(月)08:30 ID:RYml5aTx(1) AAS
これ以上、バイナリ読み書きの話をする前にとりあえず>>538に目を通せ
車輪の再発明をしたいのか、既存の車輪を利用したいのかをはっきりさせてから話を進めたほうがいい
562: 2021/06/28(月)09:09 ID:XSoi24Ug(1) AAS
僕はノンバイナリーだから読みたくないです
563: 2021/06/28(月)09:56 ID:SQEqm/bz(1) AAS
こんどはバイナリに噛み付いてるキチガイがいるな
564: 2021/06/28(月)11:09 ID:bLKGwGq9(1) AAS
標準ライブラリのみであれば車輪の再発明しか手段がない?
565: 2021/06/28(月)12:52 ID:bIZ7S0Sd(1/2) AAS
MsgPack は json と同じで無駄が多い
566: 2021/06/28(月)12:59 ID:bIZ7S0Sd(2/2) AAS
>>558
温暖化詐欺SDG詐欺と手口が一緒だな
567: 2021/06/28(月)13:35 ID:quG4wdoj(1) AAS
>>559
WSL2, Ubuntu 18.04 では、

apt list --installed libxml2

libxml2/bionic-updates,bionic-security,bionic-updates,bionic-security,
now 2.9.4+dfsg1-6.1ubuntu1.4 amd64 [インストール済み、自動]
568
(1): 2021/06/28(月)13:52 ID:5OdlGlMi(1) AAS
Comparisonて何て読むの?
コンパリソン?
569
(1): 2021/06/28(月)14:55 ID:qFu4iqR6(1) AAS
msgpackはクソやね
バイナリの扱いに慣れないスクリプト坊がバイナリを扱わざるを得なくなった場合を除いては全く価値のないフォーマット
570: 2021/06/28(月)14:56 ID:R7ScYjSP(1) AAS
>>568 こんpぇぁりzん 外部リンク:www.google.com
571: 2021/06/28(月)15:26 ID:JcAv6JCW(1/2) AAS
>バイナリの扱いに慣れないスクリプト坊がバイナリを扱わざるを得なくなった場合

この表現すき💛
572: 2021/06/28(月)15:26 ID:JcAv6JCW(2/2) AAS
>バイナリの扱いに慣れないスクリプト坊がバイナリを扱わざるを得なくなった場合

この表現すき💛
573
(1): 2021/06/28(月)16:13 ID:dKXkMhte(1) AAS
>>569のお勧めは何?
理由もセットで教えて頂戴。
574: 2021/06/28(月)16:32 ID:uBCftstC(1) AAS
「モジュール」はC++で作られたパッケージを配布しやすくしますか?
575
(1): はちみつ餃子 ◆8X2XSCHEME 2021/06/29(火)00:03 ID:OP5z1lEO(1/2) AAS
>>560
そうだよ。 その当たり前の話をしてるんだよ……。

互換性の問題というのは内部的なものなら問題が起きたときに修正すればいいが、
外部に出ているデータはそれに皆が合わせなければならない仕様と化すので
特定の C++ 処理系 (実行環境) でなら処理できるけど
出力されたデータフォーマットの詳細はわからんし処理系のバージョンがちょっと変わったら変わるかもしれん
というのでは困るやんというごく普通の話。
(もちろん普通の処理系はちょっとバージョンが更新されたくらいでは
バイナリ互換性をあまり壊さないように配慮するのが普通ではあるけど。)
576
(1): 2021/06/29(火)00:15 ID:MxyOwUyS(1/5) AAS
>>575
いつのまにか話ずらしてんな。

>>535
>読み書きに支障はないが、言語上の型とバイナリの対応付けについて明確な保証がないと困る。

言語上の型とバイナリの対応付けはPerlでもPythonでも保証されてるんだよ。
577: はちみつ餃子 ◆8X2XSCHEME 2021/06/29(火)00:20 ID:OP5z1lEO(2/2) AAS
>>576
されないよ。
ファイルのバイナリが BE か LE かわかっていない状況の話なんだから。
578
(1): 2021/06/29(火)08:12 ID:MxyOwUyS(2/5) AAS
>BE か LE かわかっていない状況

これの意味だが

・全く何の情報もない状況
→どんな言語を使おうが正しく読める保証がないし論ずるだけ無駄。

>>552の「C++ で書いてメモリをそのまま書き出したらそれのエンディアンは保証されてない。」状況
→「自環境のエンディアン」で読めるのはC++でもPerlでもPythonでも同じ。
579
(1): 2021/06/29(火)08:29 ID:qbDSHPwG(1) AAS
>>573
方法はともかく、普通にビット列かバイト列のレベルで仕様を決めてその通りに読み書きすりゃいいんじゃない
C++プログラマなら生データの扱いは得意でしょ
とはいえ手間がかかるしミスを生じやすいのも事実なので、めんどくせえ今すぐ読み書きしたいってだけならprotobufとかavroとか他にも色々あるよ
msgpackとの大きな違いはスキーマの有無で、スクリプト言語じゃなきゃスキーマはあったほうが便利だし、一般に実装が高速になりやすくデータサイズも小さくできる
580
(1): 2021/06/29(火)08:38 ID:zFDqDEto(1) AAS
>>579
「他人含めた仕様の強要」という観点が抜けてない?
それに、何回車輪の再開発させるつもりだよ。
581: 2021/06/29(火)08:57 ID:bpKPj1F0(1) AAS
>>580
強要したいならちゃんと仕様書書いて押し付けるだけの話
実装が面倒ってんならそれこそprotobufのようなスキーマのある汎用フォーマットならスキーマさえ書いとけば大抵の言語でserde用の型の自動生成までやってくれるよ
その点で言えばmsgpackは所詮mapなんで、仕様を強要したいなら別途仕様書が必要になるよ
582: 2021/06/29(火)10:54 ID:c9Dh6S0q(1) AAS
実の無い話はすぐ切り上げるのが大事だぞ
お互いの時間を無駄にしあってはいけない
583: 2021/06/29(火)12:00 ID:gO51uzZW(1) AAS
他人に構ってもらわなければ生きて行けないかまってちゃん人種は救いようがない
584
(1): 2021/06/29(火)13:20 ID:IWxlvq96(1/4) AAS
>>560
Perlでバイナリを扱うのは物凄く大変だった。
さまざまな自動変換がかかってしまうので、結局どうなるのかが分からない事が
多かったから。
例えば、数値なのか、文字なのかの区別が曖昧な感じで、たままた数値が入った
文字が、勝手に数値になって、'0' + 1 が、0x30 + 1 のつもりが、0 + 1に
なってしまったり、物凄く難しかった。
ASCIIコードの数値番号を取得したいと思っても、結果が数値の入った文字列に
なったりとか、よく分からない事が多かった。
何を何に変換しているのか、めちゃくちゃ難しかった。
省1
585: 2021/06/29(火)13:23 ID:IWxlvq96(2/4) AAS
>>584
16進数も複雑だった。
単に表示したいために16進数の文字列に直したら、どこかで勝手に数値として
解釈されていつの間にか思いもよらぬ「もの」に変化したりとか。
それで、バイナリや文字を細かく扱い際には、如何にCが楽であるかを思い知った。
586
(1): 2021/06/29(火)14:44 ID:UyxOx+sC(1) AAS
Cというか、それは最早動的型付けか静的型付けかとかの話では
587: 2021/06/29(火)15:11 ID:IWxlvq96(3/4) AAS
>>586
JSやRubyは、動的型付けだけど、Perlのように文字と数値の相互変換が勝手に
起きたりはしない。
588
(1): 2021/06/29(火)15:25 ID:MxyOwUyS(3/5) AAS
pack/unpack使えばそんな変なことにはならんぞ。
perlでバイナリ扱うなら常識。
589
(1): 2021/06/29(火)15:37 ID:IWxlvq96(4/4) AAS
>>588
それ自体はそうでも、その後いろいろなことが起きてややこしかったな。
590: 2021/06/29(火)18:21 ID:7i3kfcoq(1) AAS
強気なこと書き込む人はだいたい経験浅い
591: 2021/06/29(火)18:35 ID:tM55IFN7(1) AAS
ボカァもうOOPは捨てた!w
592
(1): ◆QZaw55cn4c 2021/06/29(火)18:54 ID:qfvhyFdx(1) AAS
>>578
あなたはちょっと残念な人ですね

実際には C/C++ ならば、処理系が LE/BE どちらに依存かにもかかわらず処理系に独立して LE なら LE用, BE なら BE用に書きわけることができる‥‥?
?の証拠は >>548
ことほど左様に、処理系に独立して LE/BE を書き分けることができるのなら「〜するべき」とかいう「べき論」は無意味でしょう
多分、はちみつ氏は?を失念していたのでしょう、べき論なんて振り回しても無駄なのに、あいかわらずべき論に拘泥するところなどは「ダメリカ様が守ってくださる!」的な馬鹿左翼並の振る舞いですから、そろそろあきらめるべきでしょうね
593: 2021/06/29(火)21:05 ID:MxyOwUyS(4/5) AAS
>>592

なにか別の話とごっちゃにしてないか?べき論って???

>実際には C/C++ ならば、処理系が LE/BE どちらに依存かにもかかわらず処理系に独立して LE なら LE用, BE なら BE用に書きわけることができる‥‥?

C/C++じゃなくてもPerlやPythonだってLE/BE書き分けられる手段は用意されているって話をしていただけなんだがな。
594: 2021/06/29(火)21:08 ID:MxyOwUyS(5/5) AAS
>>589
pack/unpackの後の話ならバイナリファイルとか関係なくて、ようは「Perlがややこしかった」というだけだろ。

>例えば、数値なのか、文字なのかの区別が曖昧な感じで、たままた数値が入った
>文字が、勝手に数値になって、'0' + 1 が、0x30 + 1 のつもりが、0 + 1に
>なってしまったり、物凄く難しかった。

これなんかまさにそうだな。
595: 2021/06/29(火)23:39 ID:uMLxaJ5z(1) AAS
この話のゴールどこ?
596: 2021/06/29(火)23:59 ID:yAVMK7JX(1) AAS
pack/unpack使え
597: 2021/06/30(水)00:03 ID:6riO4yVW(1) AAS
use strict
use warnings;;
use Carp;
use utf8;
#use Encode; # ウィンドーズのパスを使う場合必須
our $os_enc = 'cp932';
binmode STDIN, ":encoding($os_enc)";
binmode STDOUT, "encoding(%os_enc)";

でエラーかどうかは
(エラー出ない条件) or croak "*** ERR ***";  # 改行は付けない
省1
598: 2021/06/30(水)00:07 ID:d2kdzRUr(1) AAS
Encodeは日本語入りのパスとか$ARGV[]とかをutf8にしたり戻したりするのに使う
コマンドプロンプトの文字をutf8にしたら実はEncode要らんかもしれんがそこまでは知らん
599: 2021/06/30(水)00:40 ID:uW/S3RKL(1) AAS
Perlの特定の某なんか出されても知らんがな……
600: 2021/06/30(水)03:10 ID:vkj6zKzF(1) AAS
Perl Python PHP Java C# EcmaScript TypeScript Javaくらいは流石に教養だろうさ。
601
(4): 2021/06/30(水)07:38 ID:F9CAzHJ+(1) AAS
func の返り値を変数 hoge に受けるときって
auto hoge = func();
auto& hoge = func();
auto&& hoge = func();
のいずれにおいてもオブジェクトの再構築 (コピー) は行われないって思って良いんですよね?
602: 2021/06/30(水)10:58 ID:x9tVpfG6(1) AAS
no
603
(1): 2021/06/30(水)11:13 ID:EDSlPJC8(1) AAS
>>601
c++17:値のコピー省略を保証、て奴かね。

戻り値が右辺値かどうかで変わるんじゃない?
604: 2021/06/30(水)12:11 ID:2LaR0NZ5(1/5) AAS
関数の戻り値は必ず右辺値のはずだが。
605: 2021/06/30(水)12:19 ID:8KWEqHlz(1) AAS
んなこたーない
606
(1): 2021/06/30(水)12:29 ID:sL9lkuh+(1) AAS
参照返し……と思ったけど、
参照て右辺値だっけ?左辺値だっけ?
607: 2021/06/30(水)13:29 ID:2LaR0NZ5(2/5) AAS
関数の戻り値は、戻り値の型が左辺値参照で有る場合だけは左辺値で、
それ以外は右辺値らしい。
608: 2021/06/30(水)13:34 ID:2LaR0NZ5(3/5) AAS
>>606
戻り値の型が右辺値参照の場合、関数呼び出しの結果は、xvalueだが、分類上は、右辺値でもあり、glvalueでもある。
戻り値の型が左辺値参照の場合、関数呼び出しの結果は、左辺値。
戻り値の型が参照型でない場合、関数呼び出しの結果は、prvalueで、右辺値。

prvalue = 純粋右辺値。
glvalue = 一般化左辺値。
xvalue = 消えかかっている値。謎の値とも言われる。
609
(3): 2021/06/30(水)13:39 ID:2LaR0NZ5(4/5) AAS
>>601
一番上の書き方だと、少なくとも move になる。
下の二つは、moveもcopyも行われないで、アドレスだけが参照型変数に
入るのだと思う。
610
(1): 2021/06/30(水)14:18 ID:DhAhW4Ik(1) AAS
>>609
funcの戻り値型が左辺値参照の場合moveにはならんのでは?
611: 2021/06/30(水)14:56 ID:2LaR0NZ5(5/5) AAS
>>610
その通りで、コピーコンストラクタが呼び出される気がする。
「少なくとも」と書いたのは、効率面で最低でも move が生じる
という意味で書いたつもりだった。
612: 2021/07/03(土)19:40 ID:Ju/axMXt(1/2) AAS
くっそ素朴な疑問だけど
「operator>>」
って声に出して読むときどうしてる?

独学/個人開発なので他の人から聞く機会がない
613: 2021/07/03(土)19:42 ID:dunp4iC4(1) AAS
右シフト記号?
614: 2021/07/03(土)20:04 ID:ApVtA7Dx(1) AAS
入力オーバーライドとか? うーん・・・ダブルGT!
615: 2021/07/03(土)20:04 ID:Y97o1UBK(1) AAS
個人的には「おぺれーたーだいなりだいなり」だな
他人には言ったことないけど
616: 2021/07/03(土)20:18 ID:Ju/axMXt(2/2) AAS
自分のレス読んで気づいたけど他の人に声出し読むう機会も無いからどうでもいいな
617: 2021/07/03(土)20:23 ID:A2f3M294(1) AAS
おぺれーたーぐれぐれ
618: 2021/07/03(土)21:03 ID:WO4lFPcp(1/2) AAS
オペレータ・イン

<<は当然オペレータ・アウト
619
(1): 2021/07/03(土)21:05 ID:WO4lFPcp(2/2) AAS
朗読問題は根深くて、古くは漢文の読み下しからあり、
座右の書たるC言語を256倍使うための本にもちゃんと発音方法が載ってる
620: 2021/07/03(土)21:29 ID:iUoBj2xP(1) AAS
>> みぎみぎ
<< ひだりひだり
621
(1): 2021/07/03(土)21:41 ID:iArH0hMS(1) AAS
>>603-611
ありがとうございます
func の返り値が左辺値参照である場合を除けば、コピーは起こらないでFAですね

で、func の返り値は左辺値参照でない限りは右辺値だとすると、auto& じゃ受けれないから auto&& で受けるべきということですね
622: 2021/07/03(土)22:59 ID:5pcVeoYl(1) AAS
オペレーター、クィっ、クィっ
1-
あと 380 レスあります
スレ情報 赤レス抽出 画像レス抽出 歴の未読スレ AAサムネイル

ぬこの手 ぬこTOP 0.114s