Rust part16

**デフォルトの名無しさん** · 2022/06/27(月) 08:17:03.45

公式
https://www.rust-lang.org/
https://blog.rust-lang.org/
https://github.com/rust-lang/rust

Web上の実行環境
https://play.rust-lang.org

日本語の情報
https://rust-jp.rs/

※Rustを学びたい人はまず最初に公式のThe Bookを読むこと
https://doc.rust-lang.org/book/

※Rustを学ぶ際に犯しがちな12の過ち
https://dystroy.org/blog/how-not-to-learn-rust

※Rustのasyncについて知りたければ「async-book」は必読
https://rust-lang.github.io/async-book/

※次スレは原則>>980が立てること

前スレ
Rust part15
https://mevius.5ch.net/test/read.cgi/tech/1652347700/

**デフォルトの名無しさん** · 2022/07/08(金) 12:39:17.46

>>249
アンチは実際にプログラミングしたことがないのかね
Rc<T>自体は書き換えできないのでRc<T>だけでは循環参照を作ることができない
Rc<T>とWeak<T>は互いに対称ではないため直接置き換える対象ではない
例えばnewもRc::new(T)とWeak::new()で引数Tの有無からして異なる
さらに多人数で作業するから強い循環参照を知らぬ間に作ってしまうとの言い訳も意味不明だ

**デフォルトの名無しさん** · 2022/07/08(金) 12:42:18.47

>>255
Rustは所有者がいなくなると自動的に即座にメモリ解放されるため他の言語と比べて高速かつ安全で合っている

**デフォルトの名無しさん** · 2022/07/08(金) 14:56:50.59

>>257
メモリを解放しないCopying GCの方が高速なんだけどなぁ。

Rustもメモリ解放しない実装なのかね？RAIIならスタック領域しかメモリを確保しないとか。

**デフォルトの名無しさん** · 2022/07/08(金) 16:11:26.76

>>258
C++もRustも仕組みは同じ
RAIIによりスコープを外れた対象のスタック部分が解放される時にそのデストラクタによってヒープ部分が解放される
汎用的にはこれが最も高速かつ利便性>>253が高い

Copying GCは特殊な環境で特殊な使い方に限定する場合は速いこともありうるがデメリットも多く一般的には使われることが少ない
使用メモリが多くなるとかコピーで値を移動させるため非常に遅いなどのデメリットの他に
そこを指す全てのポインタ値をGCのたびに全て修整しなければならないという致命的な欠陥がある
C/C++/Rustなどでスタック上に置かれたポインタ値の全てを的確に書き換えるのは不可能なので使えない

**デフォルトの名無しさん** · 2022/07/08(金) 16:24:07.17

短時間で終了するプログラムはfree呼ばずにexitした方が高速な場合がある
copy gcも条件付きだが高速な場合がある
常にRAIIによるメモリ解放が他の手段より高速というのは誤り

100%正しいという風に断言するから枝葉の議論になるし最初から論理的に厳密な文章書いた方が良いよ

**デフォルトの名無しさん** · 2022/07/08(金) 16:35:35.79

>>260
これは特殊な使い方限定の話を持ち出したら意味がない話
既に書いたようにCopying GCは汎用的には使いものにならない
一般的にはRAIIによる解放が最も高速かつ利便性が高い
そのためC++でもRustでもその方法がとられている

**デフォルトの名無しさん** · 2022/07/08(金) 17:23:29.15

copying GCはJavaで使われているのだが

解放しない、以外でスタックの解放(malloc的なものに対する)freeより速いものはあるの？

**デフォルトの名無しさん** · 2022/07/08(金) 18:32:33.29

>>246
C++にもweak_ptr<>あるけど。

**デフォルトの名無しさん** · 2022/07/08(金) 18:32:40.38

RAIIがGCより高速なら
RAIIの一例であるshared_ptrはGCの一例であるARCより高速ということになるが
どういう原理で高速になるの？

**デフォルトの名無しさん** · 2022/07/08(金) 18:42:02.74

でも、Firefox良く落ちるじゃん。

**デフォルトの名無しさん** · 2022/07/08(金) 18:45:00.33

でも、JavaはC++も20倍速いってサイト無くなったじゃん。

**デフォルトの名無しさん** · 2022/07/08(金) 18:50:36.37

>>261
だって、RustはC++0xのパクリじゃん。

**デフォルトの名無しさん** · 2022/07/08(金) 18:52:55.66

>>264
shared_ptrではRAIIによって解放しない
RAIIによってデクリメントするだけ

SwiftなどでのARCが遅い理由は参照型の全てにおいてshared_ptrを使用しているような状況であるためコストが高い

**デフォルトの名無しさん** · 2022/07/08(金) 18:54:07.09

じゃあ、unique_ptr<>でいいじゃん。

**デフォルトの名無しさん** · 2022/07/08(金) 19:10:19.78

>>269
unique_ptrとshared_ptrの役割の違い、動作の違いを理解できていない君が
間違えて用いてもC++ではコンパイルが通ってしまったりして実行時に問題を引き起こす
Rustは間違えて用いるとコンパイルエラーとなり通らないから安全側に救われる

**デフォルトの名無しさん** · 2022/07/08(金) 20:02:01.67

>>268
参照型の全てにshared_ptrを利用したら何で遅くなるの？

**デフォルトの名無しさん** · 2022/07/08(金) 21:48:50.65

>>257
即座に開放というのがOSに返却とか認識してたらアウトだぞ。
アロケーターなに使うかで実際の挙動は変わってくるからな。
普通しないがクソアロケーター使ったら、OSからみたらリーク同然になったりするし。

**デフォルトの名無しさん** · 2022/07/08(金) 21:53:34.22

所有者がいないとメモリ解放って間違ってるよね？

所有者がいてもブロックから出たら解放されるからコンパイルエラーが出てコンパイルされない

**デフォルトの名無しさん** · 2022/07/08(金) 22:05:32.56

OSSでうっかり強循環参照作ってしまってた例が過去スレにあったようなと掘り返してみたところ、Part11にて発見

https://github.com/DataDog/glommio/commit/677fe1dfbaf911245fbc5c3eef75532d08d784bf
https://github.com/KWARC/rust-libxml/commit/bd4b120b90b2568ca6d5bfaa368a200573b87d09

**デフォルトの名無しさん** · 2022/07/08(金) 22:23:05.26

>>272
そんなバカな認識するのはオマエだけだろｗ

**デフォルトの名無しさん** · 2022/07/08(金) 22:38:42.99

>>273
所有者がいなくなるとメモリ解放であってるよ
スコープを抜けると所有者がいなくなりデストラクタが呼ばれて管理していたヒープ領域があれば解放される

**デフォルトの名無しさん** · 2022/07/08(金) 22:51:41.26

所有権とは？の話に戻っちゃうな
複製おじさんネタで散々繰り返したやつ

**デフォルトの名無しさん** · 2022/07/08(金) 23:06:47.48

お前ら何回同じ話ループさせたら気が済むの？

**デフォルトの名無しさん** · 2022/07/08(金) 23:08:26.12

なんか合ってるのか分からんけど最近思うこと

Rustの言語仕様内に明確に含まれているのはlifetimeだけで
所有権とか所有者ってのは実はただのメタファーでしかない？

**デフォルトの名無しさん** · 2022/07/08(金) 23:12:47.70

C++はコンテナのアロケータと積み荷のアロケータが別とかできるくらい柔軟ですよ。

**デフォルトの名無しさん** · 2022/07/09(土) 00:08:13.16

コンセプトをコンパイラにハードコーディングして変えられないようにしたのがRustってこと？

**デフォルトの名無しさん** · 2022/07/09(土) 03:43:55.29

>>256
こいつのような気持ち悪い反吐が出る輩がいるからRustがいまいちメジャーにならない。公式ドキュメント書き換えてこいゴミ
上の文章読んでどの辺が「アンチ」だ？ゴミのくせにイキって恥かいてんじゃねーわｗ

The Rust Programming Language 日本語版
循環参照は、メモリをリークすることもある
循環参照を回避する: Rc<T>をWeak<T>に変換する
https://doc.rust-jp.rs/book-ja/ch15-06-reference-cycles.html

**デフォルトの名無しさん** · 2022/07/09(土) 06:36:52.71

>>276
間違ってることを合ってると強弁するのいい加減辞めなよ

**デフォルトの名無しさん** · 2022/07/09(土) 07:31:04.73

認める事を全くせず、大したコードも書いてないのにRustやってる事だけが自尊心だから勝手にアンチだの決めつけて
いつも人を見下して偉そう。プロジェクトチームの雰囲気はそいつがいるだけで常に最悪、チームの重荷・会社の害悪。
口癖は「意味不明」

**デフォルトの名無しさん** · 2022/07/09(土) 10:34:16.63

>>282
実際にコードを自分で書いて理解したほうがいいよ。
その公式Bookに書かれている内容はもちろん正しいし、
その相手>>256の書き込み内容も正しくて、
両者に矛盾はないよ。

**デフォルトの名無しさん** · 2022/07/09(土) 11:42:59.26

理解してないと書いてる人間が理解してないことは多いですよね

**デフォルトの名無しさん** · 2022/07/09(土) 11:50:07.31

どちらにしてもRust使っても気楽にコーディングできるわけでもなく
メモリ構造考えなければいけないんですね

**デフォルトの名無しさん** · 2022/07/09(土) 13:10:56.08

結局、C++0xのパクリじゃないですか。
C++はそこからさらに10年以上進んでるのに。

**デフォルトの名無しさん** · 2022/07/09(土) 13:14:26.15

それはないかな…
どっちも一長一短で視点がぼやけます

**デフォルトの名無しさん** · 2022/07/09(土) 13:41:18.89

>>279
説明用に作った概念ではあるけどRustの根幹に関わる重要な概念なので
「ただのメタファーでしかない」という言い方は微妙
自分の好き勝手に解釈した内容を公式見解かのように流布する輩を助長することになるから

**デフォルトの名無しさん** · 2022/07/09(土) 14:19:07.01

パクリ元のC++で所有権と呼ばれてるからでしょ。

**デフォルトの名無しさん** · 2022/07/09(土) 14:21:22.91

C++は高機能すぎて分けワカメなので、初心者用に出来ることを減らしますという、ジェネリクス界のPythonがRustでは？

**デフォルトの名無しさん** · 2022/07/09(土) 14:57:08.15

>>283
見たけど正しいやん
間違ってる！とウソをつくけど間違ってる点を指摘できないいつもの人かね？

**デフォルトの名無しさん** · 2022/07/09(土) 15:04:05.66

誰も所有してないのに解放されないなら意味ないじゃん。

**デフォルトの名無しさん** · 2022/07/09(土) 15:25:00.91

>>294
ヒープ領域に対して誰も所有(利用)しなくなった時に
・自動解放しない(要手動解放)　←　C　C++(下記除く)
・即座に自動解放する　←　Rust　C++(unique_ptrなど使用時)
・GCする時になってから自動解放する　←　ほとんどのGC言語

**デフォルトの名無しさん** · 2022/07/09(土) 15:36:21.95

Cで書くにしても、今時のCLIツールならヒープなんか解放せず放置しても実用上問題ないよね

**デフォルトの名無しさん** · 2022/07/09(土) 16:18:04.20

そもそも間違ってるとは何と照らし合わせて間違ってるという主張なのか
「そうあるべきではない」というべき論なら前提を明確にしない限り知らんがなとしか言えん

**デフォルトの名無しさん** · 2022/07/09(土) 16:36:33.54

>>295
いや、C++はアロケート時にアロケータを選択するから。
デフォルトが準備されてるだけで。
当然、GCもあり得るから。

**デフォルトの名無しさん** · 2022/07/09(土) 16:39:05.20

だめだ、こいつに聞いても無駄だ。
誰かわかるやつ居ないのか。

**デフォルトの名無しさん** · 2022/07/09(土) 16:52:06.76

この板で最も勢いのあるスレになりましたな

**デフォルトの名無しさん** · 2022/07/09(土) 17:15:21.88

>>284
アンチ君は皆に論破されると毎回
思い込みの仮想敵を作り人格攻撃を始めて逃避するようだが
そんな下らないことはアンチスレでやってほしい

**デフォルトの名無しさん** · 2022/07/09(土) 17:29:07.29

自分より詳しいやつは全部アンチか。
それじゃダメだろ。

**デフォルトの名無しさん** · 2022/07/09(土) 17:45:35.96

Rust信者スレ作ったらそっちに移動してくれますか？

**デフォルトの名無しさん** · 2022/07/09(土) 17:54:41.59

つまり、C++0xをパクって機能限定して簡単にしたのがRustだろ？

**デフォルトの名無しさん** · 2022/07/09(土) 17:58:46.63

>>295
プログラミング言語の進化の中で、
そのメモリ自動解放における高速性と安全性の両立をRustが初めて実現したってことになるのかな

**デフォルトの名無しさん** · 2022/07/09(土) 18:04:41.00

Region-based Memory Management の構想は Cyclone から始まってる。
この段階では実用化したとは呼びにくいが、実現は出来ていた。

**デフォルトの名無しさん** · 2022/07/09(土) 18:22:19.04

>>304
C++以外からもいろいろパクってるからその言い方だと不正確に思う

**デフォルトの名無しさん** · 2022/07/09(土) 18:46:05.22

正確にはこうだな

プログラミング言語の進化の中で
メモリ自動解放における高速性と安全性の両立を実現した初めての実用的な言語がRust

**デフォルトの名無しさん** · 2022/07/09(土) 18:55:55.38

実用的の定義が無いので不正確です

**デフォルトの名無しさん** · 2022/07/09(土) 18:58:45.49

C++0xがなかなか標準化されないので、それなら自分で作ろうと立ち上がったと本人が言ってるじゃん。

**デフォルトの名無しさん** · 2022/07/09(土) 19:05:24.90

>>309
そこは常識の範囲内で実用的をどのように定義しても>>308を満たすのはRustだけだから問題ない

**デフォルトの名無しさん** · 2022/07/09(土) 19:22:48.72

別にC/C++でもちゃんと作れば高速性と安全性は両立してるよ
ちゃんと作るのが難しいかどうかの話でしかないだろ

**デフォルトの名無しさん** · 2022/07/09(土) 19:29:47.99

>>312
C/C++では不可能
うっかり危険なコードを書いてもコンパイラが通してしまう
Rustはコンパイラが指摘して通さないため安全

**デフォルトの名無しさん** · 2022/07/09(土) 19:30:20.48

難しさを度外視してちゃんと作ればいいと言うならアセンブラでも同じわけで。

**デフォルトの名無しさん** · 2022/07/09(土) 19:36:03.58

>>312
残念ながらCとC++は安全性を満たしていない
現状Rustだけが安全性と高速性を両立させている

**デフォルトの名無しさん** · 2022/07/09(土) 19:48:49.13

>>315
rustだけが満たしている根拠教えて

**デフォルトの名無しさん** · 2022/07/09(土) 19:51:24.99

じゃあChromeやSafari、Edgeじゃなく、お前のブラウザーふぁいあーふぉっくすにしろよ？安全じゃないんだろ？ぷゲラ

**デフォルトの名無しさん** · 2022/07/09(土) 19:52:51.29

うっかり前提条件が保証できていないunsafe fnの呼び出しを書いてもRustコンパイラは通してしまうではないですか

**デフォルトの名無しさん** · 2022/07/09(土) 20:07:34.54

>>313,315
ああ、Rustが決めた安全性か
まあ>>274みたいなのには目をつぶるならそれでいいんじゃねw
はたから見たらオナニーにしか見えないけど

>>314
そうだよ、突き詰めたらレベルの違いでしかない
普通のひとは突き詰めること自体が馬鹿らしいって思うからこんなことで揉めたりしないけど

**デフォルトの名無しさん** · 2022/07/09(土) 20:08:04.55

>>318
うっかりunsafe関数を呼び出しのは不可能
Rustコンパイラが通さない

**デフォルトの名無しさん** · 2022/07/09(土) 20:29:03.57

C++が敗北した理由が安全性を疎かにしたことは事実だけど
当時は安全性なんてそこまで重視されていなくて速ければよい時代だった
さらに安全性と速さを両立させる使い物になるプログラミング言語が出てくるとは想像できなかった
ここ数年でC++がようやく退場する時代となったたけでありそれ以前はC++の天下であった

**デフォルトの名無しさん** · 2022/07/09(土) 20:47:42.85

― フクオジ書 12:4-5

**デフォルトの名無しさん** · 2022/07/09(土) 21:21:56.68

>>319
そのレベルの違いが重要なわけじゃん

**デフォルトの名無しさん** · 2022/07/09(土) 21:26:07.86

>>318
実際にプログラミングをしたことがないからアンチはそんな間違った発言をうっかりしてしまう

**デフォルトの名無しさん** · 2022/07/09(土) 21:36:29.93

>>319
天と地ほどの差がある
コンパイル時点でエラーとして弾いてくれてコンパイラが修整すべき点をアドバイスしてくれるRust
コンパイラは何も言わずに通してしまい実行運用中に問題が発覚するC/C++

**デフォルトの名無しさん** · 2022/07/09(土) 21:37:18.68

「前提条件が保証できていない」に触れていないのはうっかり読み飛ばしたのかな？それともわざとかな？

**デフォルトの名無しさん** · 2022/07/09(土) 21:40:36.28

マ板のコテハンが常駐するとどのスレも不毛地帯になるな

**デフォルトの名無しさん** · 2022/07/09(土) 21:51:31.23

>>323
レベルの違いは重要、90点より95点の方が良いのは確か
ただ100点かどうかを争ってもあんまり意味ないだろ

>>325
> まあ>>274みたいなのには目をつぶるならそれでいいんじゃね
オナニーは言い過ぎだけど自分の決めた範囲で100点だーって言うのはまあ勝手に言ってりゃいいので相手に無理強いしてもしょうがない

**デフォルトの名無しさん** · 2022/07/09(土) 22:07:58.78

アンチ連呼おじさんの主張は「おまえらはプログラミングしたことが無い」

**デフォルトの名無しさん** · 2022/07/09(土) 22:17:01.66

話は単純
RustはC++における問題のうちみんなが挙げてるような重要な部分を解決してしまった
それにプラスしてC++よりpRustの方がプログラミングしやすい点も非常に大きい

**デフォルトの名無しさん** · 2022/07/09(土) 22:18:10.11

コテハンとは一体

**デフォルトの名無しさん** · 2022/07/09(土) 22:29:14.97

>>330
そうだな
そしてRustが解決したという「問題」の範囲を大きく見せて誇大広告している人がいたのでぶっ叩かれたと
単純な話だ

**デフォルトの名無しさん** · 2022/07/09(土) 22:30:12.39

>>329
「おまえらはもうプログラミングしていないだろ」
じゃないのか
若い時はしていたんだろうが、おっさん・爺になって仕事ではもうプログラミングしていない
比較は必死にするが実際のRustプログラミング話が無いおじさん・爺のRustスレだからな

**デフォルトの名無しさん** · 2022/07/09(土) 22:36:53.48

年寄りはRustに構わないで欲しい
黙ってCでも書いてて

**デフォルトの名無しさん** · 2022/07/09(土) 22:44:39.49

>>332
Linus含めたLinux開発陣も同じ結論
C++はダメな言語なので不採用
Rustは良い言語なので採用

**デフォルトの名無しさん** · 2022/07/09(土) 22:46:38.67

>>334
歳をとってもうプログラミングしていないん(実質現役引退)だから
Cすら仕事で書いていないだろ

**デフォルトの名無しさん** · 2022/07/09(土) 22:59:01.59

> 287 名前：デフォルトの名無しさん　[sage]　投稿日：2022/07/09(土) 11:50:07.31 ID:lwwTn4Ql [2/3]
> どちらにしてもRust使っても気楽にコーディングできるわけでもなく
> メモリ構造考えなければいけないんですね

読んでなるほどなと思った
よくわかんないけどとりあえず動けばいいという人と、
ちゃんと理解して自分の思う通りに動かしたい人の違いだなと

**デフォルトの名無しさん** · 2022/07/09(土) 23:05:49.23

>>335
俺,win使っているが
そのよい言語のRustをコンパイルするのに(C/C++する気ないのに)駄目な言語のmsvcを入れないと
とコンパイルできないてのがな

で、なんでmsvc必要なんだ？
ひょっとしたら、linuxでもgccとかを入れないと駄目なのか

**デフォルトの名無しさん** · 2022/07/09(土) 23:15:33.27

>>337
その人があまりにも知識不足の可能性が高い
Rustでも他の言語と同様に(C互換FFIを除いて)メモリ構造なんて公開も保証もしていない
ほとんどのプログラミング言語はメモリ構造なんて低いレベルで使うものではなくもっと抽象度の高い部分でその定義と保証がなされるもの
だからRustでも他の言語と同様にメモリ構造は考えなくて良いし考えてはいけない
メモリ構造は言語として保証していないし保証しないからこそ大胆なコンパイル最適化を行なっている

話を戻してその人はメモリ構造ではなくデータ構造と言いたかったのではないか？
データ構造は他の言語と同様にRustでも考えなければならない
それがプログラミングの中心だから

**デフォルトの名無しさん** · 2022/07/09(土) 23:30:15.11

>>338
そんなこと知らずに、そういうレスしているところにドン引きだな
自分で調べた？
調べたら、その結果をここで報告よろしく

**デフォルトの名無しさん** · 2022/07/09(土) 23:45:37.10

>>338
Rust批判派があまりにも知識不足で驚いた
ちなみにこちらはLinuxだがrustc(＝Rustコンパイラ)だけあればコンパイルできる

**デフォルトの名無しさん** · 2022/07/10(日) 00:12:02.83

>>339
SwiftとかABI stabilityを実現してるやつは仕様としてメモリレイアウトを定義して公開してるやろ

**デフォルトの名無しさん** · 2022/07/10(日) 00:13:44.27

>>341
["rust linker cc not found"] [検索]

**デフォルトの名無しさん** · 2022/07/10(日) 00:16:59.60

まあ>>287の書いてるメモリ構造という言葉はメモリレイアウトでもデータ構造でもないのは明らかだけどな

**デフォルトの名無しさん** · 2022/07/10(日) 00:18:51.99

隔離スレ復活させないとノイズだらけできつくなってきた

**デフォルトの名無しさん** · 2022/07/10(日) 00:30:08.21

>>342
そのABIはコンパイル後のバイナリのフォーマットの話だぜ
今回の『気楽にコーディングできるわけでもなくメモリ構造考えなければいけないんですね』はプログラミングの際の話だから関係ない

プログラミングする上でメモリ構造は考えなくていい
例えばRustの型VecやStringなども各々のがどんなメモリ構造になるかは規定も公開もない
もちろんソースコードを読めば内部のデータ構造までは分かるがそれに依存してコードを書いてはいけないし依存できないよう抽象化されたインタフェースのみ規定公開されている

**デフォルトの名無しさん** · 2022/07/10(日) 00:33:22.94

>>345
同感
アンチ活動は別のスレでやってほしい
ここ本スレでやるのはマナー違反だと思う

今後Rustへのアンチ活動は以下のスレへ書くこと
Rustアンチスレ
https://mevius.5ch.net/test/read.cgi/tech/1509028624/

**デフォルトの名無しさん** · 2022/07/10(日) 01:01:37.00

複オジに絡んだ俺がバカだったわw

**デフォルトの名無しさん** · 2022/07/10(日) 01:02:48.63

>>343
なるほど、
>341
>ちなみにこちらはLinuxだがrustc(＝Rustコンパイラ)だけあればコンパイルできる
は、比較的新しいrustを使えばgcc(リンカ)イラネってことか
rustでリンカ作った方がgccのリンカよりずっと良いものになるだろうからな

**デフォルトの名無しさん** · 2022/07/10(日) 01:09:37.70

https://mevius.5ch.net/test/read.cgi/tech/1657382429/

隔離対象をアンチに限定しない汎用隔離スレ立てた
もう全部こっちでやってくれ

**デフォルトの名無しさん** · 2022/07/10(日) 01:48:41.75

>>350
おまえ低能だな
そんな内容と設定ではそのスレは過疎って終わることくらい予測できるだろ？

**デフォルトの名無しさん** · 2022/07/10(日) 04:45:49.56

荒らしてるのはLinux板の連中か。

**デフォルトの名無しさん** · 2022/07/10(日) 08:32:10.98

Cellを使っていて思ったんだが例えば

trait CellUpdateWith<T> {
fn update_with(&self, f: impl FnOnce(&mut T));
}

impl<T: Default> CellUpdateWith<T> for Cell<T> {
#[inline]
fn update_with(&self, f: impl FnOnce(&mut T)) {
let mut inner = self.take();
f(&mut inner);
self.set(inner);
}
}

このようにメソッドupdate_with()を用意しておけば
内部更新もわかりやすく記述できるな

let foo = Cell::new(vec![1, 2, 3]);
foo.update_with(|v| v.push(7));

身代わりにself.take()でdefault値を入れてCellから取り出し
self.set()でCellへ戻すという無駄な操作は最適化で消えるようだ
https://godbolt.org/z/19c4EbErG

**デフォルトの名無しさん** · 2022/07/10(日) 12:00:25.54

>>351
それをわざと狙ってんだろうなww
いかにもやりそうなこと

**デフォルトの名無しさん** · 2022/07/10(日) 13:59:32.22

>>354
この手の人は自分が排除されることを最も恐れてるんだよ
そうならないための策ならなりふり構わず何でもやる

自分が排除される側にいる自覚がなければそんなことやらない

**デフォルトの名無しさん** · 2022/07/10(日) 19:54:18.59

>>308
糞言語で自意識過剰の公開オナニーをする信者、マジきもい