C vs C++ vs Rust Part.3

**デフォルトの名無しさん** · 2022/01/27(木) 22:19:47.56

闘え
※前スレ
C++ vs Rust
https://mevius.5ch.net/test/read.cgi/tech/1619219089/
C vs C++ vs Rust Part.2
https://mevius.5ch.net/test/read.cgi/tech/1639539350/

**デフォルトの名無しさん** · 2022/03/16(水) 14:20:20.70

rustは詳しく知れば知るほど使える領域が狭いことに気付く。まあ勉強して損することはないとは思うけど。

**デフォルトの名無しさん** · 2022/03/16(水) 16:01:45.47

まぁ、Rustがものすごく人気になるようだったら、Rustを下敷きにしたC++サブセット Smart C++が出てくると思うわ。

そしてc++はライブラリアン向けのunsafe的な扱いになる、と。

**デフォルトの名無しさん** · 2022/03/16(水) 17:58:27.77

>>515
無理じゃないかな。

**デフォルトの名無しさん** · 2022/03/16(水) 20:15:10.51

rustが他言語の仕様に影響を与える部分はでてくるだろうね。

**デフォルトの名無しさん** · 2022/03/16(水) 21:02:09.61

反面教師にはなるよねｗ

**デフォルトの名無しさん** · 2022/03/16(水) 21:24:41.08

>>512
それはあなたの能力では理解できなかったから思うだけで留まり実際には書けていない

>>513
逆だ
同じことが簡潔に書ける

>>514
むしろ幅広い分野で有効
後発だからとも言えるが言語仕様が幅広いパラダイムを洗練して採り入れていることが勝因とみた

**デフォルトの名無しさん** · 2022/03/16(水) 21:56:01.01

少なくともC++はリプレイスしてほしいな

**デフォルトの名無しさん** · 2022/03/16(水) 21:58:33.64

Rust信者って本当にバカだなｗ
妄想で他人を説得はできないんだよ
グラフ構造を標準ライブラリとunsafe使わずに簡潔に書いてみろよｗ
他の言語で出来ないやつないから
Rustも超狭い領域ではオンリーワンくらい有効なんだけど、それ以外では趣味でしか使われない

**デフォルトの名無しさん** · 2022/03/16(水) 23:51:54.51

>>491 >>492
横からやけどほんまにどんな仕様にしてもええの？
それなら長さlenのsubsetsイテレータは10文字で完成
『0..(1<<len)』
数字を2進数で見てbit立っている要素による各subset
0は全ての要素がないから空集合

それで納得してもらえんのやったら入力inputとして
(0..(1 << len))
.map(|c| (0..len)
.filter_map(move |i| (c & (1 << i) != 0).then(|| &input[i]))
.collect::<Vec<_>>())
これでちゃんとしたsubsetsイテレータが完成
例えばinput = &["a", "b", "c"]ならば以下が順に出る
[]
["a"]
["b"]
["a", "b"]
["c"]
["a", "c"]
["b", "c"]
["a", "b", "c"]

**デフォルトの名無しさん** · 2022/03/16(水) 23:53:02.55

>>491 >>492
横からやけどほんまにどんな仕様にしてもええの？
それなら長さlenのsubsetsイテレータは10文字で完成
『0..(1<<len)』
数字を2進数で見てbit立っている要素による各subset
0は全ての要素がないから空集合

それで納得してもらえんのやったら入力inputとして
(0..(1 << len))
.map(|c| (0..len)
.filter_map(move |i| (c & (1 << i) != 0).then(|| &input[i]))
.collect::<Vec<_>>())
これでちゃんとしたsubsetsイテレータが完成
例えばinput = &["a", "b", "c"]ならば以下が順に出る
[]
["a"]
["b"]
["a", "b"]
["c"]
["a", "c"]
["b", "c"]
["a", "b", "c"]

**デフォルトの名無しさん** · 2022/03/17(木) 01:31:24.96

collectするならfoldで十分かな

fn subsets<T>(input: &[T]) -> impl Iterator<Item=Vec<&T>> {
let len = input.len();
(0..(1 << len))
.map(move |c| (0..len)
.fold(vec![], |mut v, i| {
if c & (1 << i) != 0 {
v.push(&input[i])
};
v
})
)
}

**デフォルトの名無しさん** · 2022/03/17(木) 02:22:57.24

C++でsubsetsイテレータを書くとどんな感じになるの？

**デフォルトの名無しさん** · 2022/03/17(木) 02:29:21.66

>>519
馬鹿

**デフォルトの名無しさん** · 2022/03/17(木) 02:39:09.51

Rust同様どうとでも出来るよｗ
C++のは古いから名前がアレだけど
俺は>>522じゃないけどfilterとmapで書いた方が分かりやすいとは思う
この書き方でpushとかは見たくなかったｗ

**デフォルトの名無しさん** · 2022/03/17(木) 02:53:46.50

うむ

>>522
filter_mapとthenによるOption利用が分かりやすいな

**デフォルトの名無しさん** · 2022/03/17(木) 03:28:10.97

>>527
ぜひC++版お願い

**デフォルトの名無しさん** · 2022/03/17(木) 04:22:11.55

>>529
何度でも言うけど、そういう要求は飲まない
金くれたら書くよｗ

**デフォルトの名無しさん** · 2022/03/17(木) 08:12:49.73

>>520
リプレースはしなくていい。
コーダーとかが通常使う安全運転版と、ライブラリアン用のフル版が住み分け・共存できればいい。
従来はコーディング規約とライブラリでやっていたところだけど、こういうのはshared ptrみたいに旨が使う共通仕様にしたほうがいい。

**デフォルトの名無しさん** · 2022/03/17(木) 08:19:10.27

Rustに移行すれば
色んな問題が一気に解決するだけでなく
プログラミングもしやすくなって一石二鳥

**デフォルトの名無しさん** · 2022/03/17(木) 08:41:07.21

>>532
サンプルコードがもっと充実してきて、標準的なコーディングが普及してきてから検討するわ。

Rustは土方向け言語目指しているのに、今のRustの仕様だと土方に難しすぎるから中途半端。それならc++＆コーディング規約でいいや。

**デフォルトの名無しさん** · 2022/03/17(木) 08:49:29.01

>>533
君たち土方には難しいのかも知れないが普通のプログラマーにとっては難しくないしコーティングがC++より快適

**デフォルトの名無しさん** · 2022/03/17(木) 08:57:01.71

Pythonくらいしかやったことない人にとって難しいのはそうだろうけど
C++14/17についていってる人ならRust余裕だと思うけどなぁ

**デフォルトの名無しさん** · 2022/03/17(木) 10:08:01.84

Rustに出来てC++が似たようなことを出来ないってことはまずないよ
ただ同じことをしたい場合、手間がすごいかかる(23は知らんけど)
そしてどう転んでもエラーがRustほど人間に優しくなったりはしない(と思う)

C++に出来てRustが似たようなことを出来ないってこともそんなに多くない
まあでもこっちは本当に出来ない
https://www.reddit.com/r/rust/comments/n7rjfk/what_can_c_do_that_rust_cant_2021_edition/

ただRustは初心者には難しすぎ、ある程度他の言語をやってる人にも難しいというハンデがある
なのでスクリプト言語感覚でRustをやろうと思うのはちょっとオススメできない
楽を出来る場面は確かにあるので、そこをどの程度メリットと捉えるか
制約をどの程度デメリットと捉えるかで評価が分かれる

**デフォルトの名無しさん** · 2022/03/17(木) 12:06:55.23

>>534
土方にやらせる話をしているんだよ。

Rust信者がそういう意識なら、RustがJavaみたいに流行ることは無いな。
やっぱりHaskellコースかね。

**デフォルトの名無しさん** · 2022/03/17(木) 16:20:31.29

>>534
>君たち土方には難しいのかも知れないが普通のプログラマーにとっては難しくないしコーティングがC++より快適
自分がどれくらい矛盾してること言ってるのかも理解してなさげ。

**デフォルトの名無しさん** · 2022/03/17(木) 18:26:55.16

>>522
Rustはスクリプト言語のように簡潔に書ける点もいいね
それでいてC言語並に速い
C++は簡潔に書けず手間暇かかりすぎる

**デフォルトの名無しさん** · 2022/03/17(木) 18:35:40.91

お手軽さっていう話だと、関数の仮引数の型も型推論してほしい、ってたまに思っちゃう

**デフォルトの名無しさん** · 2022/03/17(木) 18:44:45.18

>>540
技術的にはできるし、できるならやりたくなっちゃうところをあえて削ったのは英断だと思ってる
過去のコードや他人のコードを読むときに直近に型があるのは大きい

**デフォルトの名無しさん** · 2022/03/17(木) 18:59:38.79

> 仮引数の型も型推論
OCamlだとそれはフツーにできてるのにね

> 過去のコードや他人のコードを読むときに直近に型があるのは大きい

同じような話だがJavaのジェネリクスで

> List<Foo> list = new ArrayList<>();
> この右辺のパラメータが省略できるのを有難がるのは残念で
> ホントは左を省略してvar ist = new ArrayList<Foo>();
> と書けたほうが嬉しいのにJavaはやっぱりダメダメ

みたいな意見をみたことがあるが、左を残すことこそ大事なんだよな
実装に対してではなくてインタフェースに対してプログラミングするのであって
変数の型を必要最低限の小さいインタフェースで宣言するのが嬉しいのに
それをわかってないやつはタイピング数などで判断して世迷い言を言う

**デフォルトの名無しさん** · 2022/03/17(木) 19:25:12.70

Rust学習しはじめだがEnumの仕組みは良いと思う。
C#あたりに組み込まれればいいのに。

**デフォルトの名無しさん** · 2022/03/17(木) 20:43:27.53

enum Optionとか便利で簡潔に
null nil undefined -1など無くして安全に出来ていいよね
それでいてコンパイル後は最適化されたり消えたりして効率も両立されたり

**デフォルトの名無しさん** · 2022/03/17(木) 20:52:32.01

別にC++でも同じことはできるけどね
自分で組めばC++14とかでもrxっぽく書いたり、Optionの実装も余裕
手間さえ惜しまなければｗ

**デフォルトの名無しさん** · 2022/03/17(木) 20:55:03.76

Javaも最近は左側省略できるよ
おっしゃるとおり基底型何にするかは選べないけどｗ

**デフォルトの名無しさん** · 2022/03/17(木) 20:58:40.56

C++17にstd::optional<T>があるにはあるのだが...

膨大な量の既存のSTLが無効値をoptionalに置き換えられることはない
つまり無効値でoptionalを返す風潮ができにくいから悲しみ

**デフォルトの名無しさん** · 2022/03/17(木) 20:59:36.98

引数の型推論は原理的にはかなり出来そうだけど
例えば引数がas_ref()で使われていて変換後がPathなら引数はimpl AsRef<Path>までやっちゃう？
でもその利用者へのインタフェース明示や可読性と保守性を考えると型明記でいいような気がする

**デフォルトの名無しさん** · 2022/03/17(木) 21:13:38.45

C++もautoだらけlambdaだらけにすると引数も戻り値も結構型書かなくていいけど、遠すぎて何に怒られてるのか分からん代入エラーが出たりもするｗ
Rustも同じだけどエラーは分かりやすい

**デフォルトの名無しさん** · 2022/03/17(木) 21:15:46.46

>>545
そこはやろうと思えばできるレベルと
Rustが標準ライブラリで全面採用サポートしてるレベルで天と地の差があるよね
例えば>>522もbool値がthenでOptionを生成してそれをfilter_mapが受け取ることで簡潔なコードになっていたり

**デフォルトの名無しさん** · 2022/03/17(木) 21:23:13.02

そこはfilterとmapの方が分かりやすい

**デフォルトの名無しさん** · 2022/03/17(木) 21:32:28.43

一般的にfilter_mapはわかりやすと速さを両立
だからわざわざfilter_mapやfilter_map_okが用意されている

**デフォルトの名無しさん** · 2022/03/17(木) 21:35:05.28

そんなところは全く速さに影響しないと思うよ

**デフォルトの名無しさん** · 2022/03/17(木) 21:43:21.73

>>553
その種類のイテレータを2段は最適化前はもちろん速さに影響するけど
最適化により最終コードが同一コードになることを確認したということ？

**デフォルトの名無しさん** · 2022/03/17(木) 21:49:32.84

お前は速くなることを確認したんかい？ｗ
俺は出来るけど速くならないことを確認する必要がないと判断したｗ
お前は恐らく出来ないｗ

**デフォルトの名無しさん** · 2022/03/17(木) 21:58:49.13

コードそのままならイテレータ2つより1つの方が速いと明白なので
速さが同じと主張する>>555が最適化で同じコードになることを示す必要がある

**デフォルトの名無しさん** · 2022/03/17(木) 22:05:07.99

明白じゃねーよｗｗｗｗｗ

**デフォルトの名無しさん** · 2022/03/17(木) 22:19:03.24

たぶん>>557氏はイテレータの動作原理を知らないのだと思う
例えばfilterは構造体Filterを返しそのメソッドnext()がイテレータを進めるごとに呼ばれる
同様にmapは構造体Mapを返しそのメソッドnext()がイテレータを進めるごとに呼ばれる
最適化前はそれら二重のオーバヘッドがある

**デフォルトの名無しさん** · 2022/03/17(木) 22:24:52.40

速さに関して議論するなら最適化のコードがどうなるかを確認すべきでは
特にイテレーターアダプターを何度も噛ませてもfor文相当のコードが生成されるというのはrustの売りのひとつだよね

**デフォルトの名無しさん** · 2022/03/17(木) 22:29:02.79

もし最適化後に有意に速度差があるなら、それは性能バグとしてIssueにあげるべき問題だと思う

**デフォルトの名無しさん** · 2022/03/17(木) 22:31:57.85

>>559
その通りで最適化で非常に効率な最終コードとなる
ただし今回のケースでfilter().map()がfilter_map()と同一コードになるかどうかは自明ではない
したがって>>553に立証義務がある

**デフォルトの名無しさん** · 2022/03/17(木) 22:36:47.68

立証義務なんてねーだろｗｗｗｗ
できないからって他人に頼るなｗｗｗｗｗ

**デフォルトの名無しさん** · 2022/03/17(木) 22:38:48.81

意味的に同じことやってるんだから、理想的な最適化コンパイラは全く同じバイナリを吐くはずで
遅くなるはずってのも別に自明ではないのでは

**デフォルトの名無しさん** · 2022/03/17(木) 22:46:51.69

>>563
意味の同じプログラムが最適化で常に同じコードになるかどうかは自明ではない
そしてそれを期待することはよいが前提としてはいけない
自明ではないことを同じと主張する側に立証義務がある

**デフォルトの名無しさん** · 2022/03/17(木) 22:48:42.58

できないんだねｗｗｗｗ
rustの吐くコードすげー見にくいしなｗ
それ以前にアセンブラ読めなそうｗ

**デフォルトの名無しさん** · 2022/03/17(木) 22:52:00.13

>>564
ん？別に同じになるのが自明とは言ってないよ
どちらも同程度に自明でないって言ってるだけ
立証はまぁやりたい人がやればいいんじゃない

**デフォルトの名無しさん** · 2022/03/17(木) 22:57:38.05

>>565
> rustの吐くコードすげー見にくいしなｗ

無知っぷりを曝け出してるな

**デフォルトの名無しさん** · 2022/03/17(木) 23:14:09.53

お前が無知なだけｗ

**デフォルトの名無しさん** · 2022/03/17(木) 23:29:12.99

>>565
LLVMがアセンブリを吐いてることも知らないのか

**デフォルトの名無しさん** · 2022/03/17(木) 23:31:17.03

ビビリ単発IDが何もかもを証明しちゃってるｗ
お前は何も分かってないｗ

**デフォルトの名無しさん** · 2022/03/17(木) 23:50:47.22

>>529
C++ではそんなに簡単には書けない

**デフォルトの名無しさん** · 2022/03/17(木) 23:59:39.29

C++でも簡単に書けるよｗ
C++20で導入されたrangeでも使ってみｗ
より古い規格でもユーザーライブラリを使えばRxっぽい記述は簡単に出来る
自分で書くと難しくはないが骨が折れるタイプの実装
並列化を意識しない限りだけどｗ
まあ並列化を意識しないで簡便さを意識すれば無理にRxを使う必要もないけども・・・

**デフォルトの名無しさん** · 2022/03/18(金) 00:00:49.69

>>572
無理でしょ
実際に書いてみ

**デフォルトの名無しさん** · 2022/03/18(金) 00:03:10.42

加えて言えばRxでなければ上限を意識したループで書けるのでメモリ確保が最適化できるし、手でinlineにする部分を選べる分より速く書ける可能性もあるｗ

**デフォルトの名無しさん** · 2022/03/18(金) 00:03:27.72

>>573
いくらくれる？

**デフォルトの名無しさん** · 2022/03/18(金) 00:10:24.15

>>574
無理だ

**デフォルトの名無しさん** · 2022/03/18(金) 00:13:29.40

君にはそうなんだねｗ可哀想にねｗ

**デフォルトの名無しさん** · 2022/03/18(金) 00:37:03.66

前スレの時からそうだけどRustのコードばかり出てくるスレ
C++で同じコードを書くと長く見難くなってしまうからだろうけど

**デフォルトの名無しさん** · 2022/03/18(金) 00:49:14.78

C++20なら普通に同じくらいｗ
あるのはRustの不慣れな部分コードねｗまあこのレベルの作業に良い悪いもないけどｗ
君等のお勉強()にはいいんじゃないのｗ

**デフォルトの名無しさん** · 2022/03/18(金) 03:33:36.54

>>524のC++バージョン教えて

**デフォルトの名無しさん** · 2022/03/18(金) 06:33:28.96

これだけヒント出してやったのにまだ書けないのやばくね？ｗ

**デフォルトの名無しさん** · 2022/03/18(金) 08:39:50.87

>>542
変数の型を必要最低限の小さいインタフェースで宣言するのが嬉しいのに

とか言っているのに、使わない部分も含めてインターフェイスを制限する変数の型制限を有難がるのは笑いどころでしょうか？
「変数の型を固定して、コーダーの想定外の動きをしないように限定する」なら、そういう考えをもあるよね、となるけど。

**デフォルトの名無しさん** · 2022/03/18(金) 19:44:54.15

>>580
手間がかかって分かりにくいのでC++でやるのは不向き

**デフォルトの名無しさん** · 2022/03/18(金) 21:03:36.45

>>583
この人も出来ないタイプなんだねｗそういうことは全くないよｗ

**デフォルトの名無しさん** · 2022/03/18(金) 21:36:44.00

>>584
Rustのように楽にコード書けるの？

**デフォルトの名無しさん** · 2022/03/18(金) 21:41:42.97

>>585
楽かどうかは主観なので、まず自分でやってみれば？
このレベルなら俺はどちらが楽とかはないよｗ

**デフォルトの名無しさん** · 2022/03/18(金) 22:10:37.73

9割9分はRustの方が楽にプログラミングできる

**デフォルトの名無しさん** · 2022/03/18(金) 22:13:55.40

単発IDは自作自演だから信用ならんのだよねｗ

**デフォルトの名無しさん** · 2022/03/18(金) 23:01:40.37

ほとんどのケースでC++よりRustが簡潔になることは皆承知

**デフォルトの名無しさん** · 2022/03/18(金) 23:44:11.33

お前がC++使えてないだけｗ
変わらないよｗ
単発IDは自作自演

**デフォルトの名無しさん** · 2022/03/19(土) 06:24:53.41

>>590
あちゃ、痛いところつかれましたわ

**デフォルトの名無しさん** · 2022/03/19(土) 08:29:04.12

変わらないと連呼するだけの簡単なお仕事ですw

**デフォルトの名無しさん** · 2022/03/19(土) 08:34:00.61

単発IDが皆承知というだけで、ヒントも出したのにC++書けないバカが悪いｗ

**デフォルトの名無しさん** · 2022/03/19(土) 08:35:31.99

Rust信者がたくさん居るかのような見せかけのIDコロコロ

**デフォルトの名無しさん** · 2022/03/19(土) 14:50:55.94

公平に見てここまでに
Rustでの実装コードはある>>522 >>524
C++での実装コードはない
不利なのはC++側

**デフォルトの名無しさん** · 2022/03/19(土) 15:08:06.66

必要だと思うなら自分で書けよｗｗｗｗ
書かなくても分かるから書いてないだけでｗ
両方分かる人はちゃんと言葉で説明できるからｗ

**デフォルトの名無しさん** · 2022/03/19(土) 15:10:45.07

そもそも分からない言語があるのにこういうスレに来る方が間違いなんだがｗ

**デフォルトの名無しさん** · 2022/03/19(土) 15:57:28.84

>>595
やめたれｗ

**デフォルトの名無しさん** · 2022/03/19(土) 16:01:08.28

口だけでコードとか全然書けないヤツってよくいるよね

**デフォルトの名無しさん** · 2022/03/19(土) 16:04:54.04

単発ID君悔しいのねｗ
俺は永遠に返事し続けるよｗ君がC++使えるようになる日が来るといいねｗ

**デフォルトの名無しさん** · 2022/03/19(土) 16:11:35.17

>>599
いるよなｗ
コード書いたようが早いような言い訳はいっぱい書けるのになｗ
言い訳だけはいっぱい書けるんよｗ

**デフォルトの名無しさん** · 2022/03/19(土) 16:12:10.15

>>547
互換性が壁になるのは、長く広く使われてる言語ではどうしようも無いしなぁ。
だから言語も新しく作られるわけだけど、新しいものは認めません！という奴はいつだっている。

**デフォルトの名無しさん** · 2022/03/19(土) 16:13:51.10

もう少しわかりやすくして
このsubsetsイテレータをC++で実装すればいいんだよね

fn subsets<T>(input: &[T]) -> impl Iterator<Item=Vec<&T>> {
let len = input.len();
(0..(1 << len))
.map(move |bits| (0..len)
.filter(|index| bits & (1 << index) != 0)
.map(|index| &input[index])
.collect())
}

fn main() {
let input = ["a", "b", "c"];
for s in subsets(&input) {
println!("{s:?}");
}
}

出力結果
[]
["a"]
["b"]
["a", "b"]
["c"]
["a", "c"]
["b", "c"]
["a", "b", "c"]

**デフォルトの名無しさん** · 2022/03/19(土) 16:30:53.75

>>602
置き換えのためのテスト手順なんかも考えずに新しいものにすればいいって言い張る老害も
たくさんいるんでその辺はどっちもどっちだがな。

**デフォルトの名無しさん** · 2022/03/19(土) 16:40:18.91

filter_mapがfilterとmapに分かれただけじゃんｗｗｗｗ
マジでそんなのを何度もブラッシュアップするレベルでは俺には一生追いつけないぞｗ
どうでもいいけどクロージャ(ラムダ)の引数を次のクロージャで使うのは気持ち悪いのと結局collectしちゃうのはイマイチだねｗ
あと生成コードの比較、もしくは時間測定は出来たのか？ｗ
何度も言うが、誰でもどちらの言語でも同じように書けるぞｗ

**デフォルトの名無しさん** · 2022/03/19(土) 17:31:22.77

>>603
やってみたがC++の従来のイテレータ仕様が悪すぎることが敗因
なのでC++20からのstd::rangesでかなり改善できる
ただしRust版ほどシンプルに仕上がらないな

>>605
勘違いで詰まらない言いがかりを付けてくるな
そこまで言うならばC++版のコードはおまえに任せる

**デフォルトの名無しさん** · 2022/03/19(土) 18:10:48.21

単発IDがたまに連続させたって意味ないんだけどｗ
その辺はとうに>>572に書いたよね？ｗまだ出来ないの？ｗｗｗｗｗ

**デフォルトの名無しさん** · 2022/03/19(土) 18:22:18.16

>>605
> クロージャ(ラムダ)の引数を次のクロージャで使うのは気持ち悪い

意味不明すぎ
クロージャを理解できていない？

> 結局collectしちゃうのはイマイチだね

わかりやすくcollectしてるだけだろう
collectを外せばイテレータを返すイテレータとなるのは自明

**デフォルトの名無しさん** · 2022/03/19(土) 18:31:58.03

またID変えて忙しいやつだなｗｗｗ
1つ目の点は細かいが、クロージャを外に出したいと思ったときに不自由なんだよｗ
2つ目の点は遅延評価をわざわざ使うなら、collectしちゃうとロスが発生するのは分かるだろｗ
例えばコンソールに出力する場合、そのままiteratorをぶん回したらメモリ要らないのに、最初にcollect付けちゃってるから問題なんだよｗ
後から付ける事はできても、取り外すことは出来ないからｗ

**デフォルトの名無しさん** · 2022/03/19(土) 18:34:23.73

エアプC++erの言い訳無限に出てくるよｗ

**デフォルトの名無しさん** · 2022/03/19(土) 18:37:48.37

もういいから正解書いてくれ。

**デフォルトの名無しさん** · 2022/03/19(土) 18:38:41.55

ありゃりゃココで複垢まで使っちゃうと他で使えなくなっちゃうよ？ｗいいの？ｗ

**デフォルトの名無しさん** · 2022/03/19(土) 18:39:15.88

書けないのに書けるフリして可哀想やわ