Rust part37

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

公式ドキュメント
https://www.rust-lang.org/learn

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

※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 part36
https://mevius.5ch.io/test/read.cgi/tech/1779974768/

ﾜｯﾁｮｲスレ
プログラミング言語 Rust 4【ﾜｯﾁｮｲ】
https://mevius.5ch.io/test/read.cgi/tech/1514107621/

ライフタイムについて真面目に勉強したい人向け資料

https://github.com/pretzelhammer/rust-blog/blob/master/posts/translations/jp/common-rust-lifetime-misconceptions.md

>>585
Rust製ブラウザとかあったっけ？

Rust製ブラウザと言えばServo
そもそもRust自体がFirefoxを改善するために生まれた言語

>>592
>>594
複おじまだいたのか

>>597
FirefoxにもChromiumにも入ってるよｗ
FirefoxなんかもろCSSのレンダリングに使ってる

アンチはやたら「100%RustじゃなかったらRustの意味はない」ってゼロヒャクを言いたがるよな

>>594
Rustの言語仕様として受け取った参照を返すことができるのはもちろん正しい
一方で論争になっていたのはこちら
「なぜ関数が受け取る引数には型やライフタイムに制約があるものが存在するのか？」
結局これは関数が提供したい機能に依って受け取れる型やライフタイムに制約が生じる
こちらはRustの言語仕様とは関係ない

>>594
これで何かを証明したつもりになっているらしい草

>>602みたいな主語抜けアスペ文で誰かに何かが伝わると思ってるほうが草だよ

>>602
まあそうなんだけど
'staticしか受け取らない関数なんて無数にあるのにspawnに固執してた人いたな

もうみんなclone()して幸せになろう

Linux全面AI推進へ

リーナス・トーバルズが「LinuxはアンチAIではない」「気に入らないならフォークすればいい」などLinuxカーネル開発におけるAI利用について意見を述べる
https://gigazine.net/news/20260717-linux-linus-torvalds-ai/

貼る場所ちがくね

>>605
まだやってんのか
「ライフタイムの制約はない」とかほざいてる奴がいただけだろ

>>607
AI全面推進なんて書いてないしRustの話でもないし無茶苦茶

>>602
提供したい機能によってライフタイムの制約が生じるというのは間違ってないけど、言語仕様と関係ないというのは間違いだね
提供したい機能を言語仕様の制限の中で提供するにあたって、ライフタイムの制約を受けているので

>>611
それは言語機能による制約ではない
特殊な機能を提供するための各関数の固有の制約

>>612
じゃあ言語仕様の制約はどの言語にも一切ないって主張になるな
そんな前提をぶち壊すラディカルな話をしろって言ってるわけじゃない

> 各関数の固有の制約

Rustにライフタイムの制約がないのに各関数が勝手にそれをつけてるって、流石にそんな嫌がらせはしないと思うが

>>611
これよな

>>612の理屈をC言語の標準ライブラリで考えるとおかしさがわかりやすくて、malloc() で確保した領域を free() で解放しなきゃいけないのは標準ライブラリの仕様ではなくそれを使うコードのせい、みたいな話になってるんだよな
当然そんなわけはなくて、malloc() を使うことまではそのコードの問題だけど、free() を使う必要があるのは標準ライブラリの仕様に縛られているから

同じように、'static しか受け取れない機能を作ることまではその関数の問題であったとして、'static しか受け取れないという仕様の原因になっているのはライフタイムの制約を言語側が仕様として定めているからに他ならない

こういう区別のつく人間って希少なんだよな……

>>612
その区別が重要だな

###なぜ 'static やライフタイムの制約が存在するのか？

​Rustには**「ガベージコレクタ（GC）を持たずに、メモリ安全性と高いパフォーマンスを両立する」**という根本的な設計思想があります。これをコンパイル時の静的解析だけで実現するために編み出されたのが、ライフタイムのシステムです。

>>620
GC言語でGC対象はヒープ領域に格納されるのに対して
Rustはスタック領域にある関数ローカル変数に値を置いたままそこへの参照を安全に使うことができる点が大きい
取り扱う参照がスタック領域を指しているかヒープ領域を指しているか区別することなく全く同様に扱えるようになった
つまりGC言語と比べてRustは自由を得た

>>619
区別ついてない側なの笑う

>>621
×取り扱う参照がスタック領域を指しているかヒープ領域を指しているか区別することなく全く同様に扱えるようになった
別に参照はこれまでの言語でもどちらの領域を指すか区別して用いるものではない
また、変数自体はスタック領域を指しているかヒープ領域を指しているか区別して扱う必要がある

>>620
まあ、せやな

Goで書き直されたTypeScript 7.0が正式リリースされてるね
自由度高くて安全で高速なGo実装を簡単にRustに移植出来たら良いのに

>>623
嘘つくな
区別して扱う必要ない

###なぜGoなのか
Rustの厳格な所有権や借用規則の世界へいきなりジャンプしようとすると、その「TS寄りの複雑な構造」そのものを根本から完全再設計しなければならず、難易度が跳ね上がってしまいます。
​つまり、移行元のコードベースの性質や、プロジェクトを現実的な期間でゴールさせるための「距離感」として、Goがちょうどよかったということですね。

>>626
じゃあスタックに巨大構造体置きまくっても安心だな！

>>625
常に動き続けるホットパスでもないし、Rustである意味がないからなあ

>>628
草

>>626はVecと配列の使い分けとかわかってなさそう
「どうしてサイズが決まってるのにVec使うんだ！」とか怒るのかなｗ

wasmあるのにうんこスクリプトとかどうでもよくね

>>623
逆だよ
スタック領域を指しているかヒープ領域を指しているか区別して扱わなくても安全になったのがRust

>>633
スタックとヒープの区別を free() するかどうかだけだと思ってそう

えっ、違うんですか！？

>>632
うーむ...🤔

Rustではスタック領域/ヒープ領域に正式な名称がないはずだから、Cの自動記憶域/割り当て記憶域って言葉を使うけど、自動記憶域は関数に入る時に関数の戻り先アドレス、引数、ローカル変数などをスタックフレームに積むプログラム自身の管理のための機能になってる
だから変数を置く領域の広さはそこまでなくて、OSによって違うけどデスクトップやモバイルなら1MiB〜8MiBくらいしかない
したがって、大きなデータは割り当て記憶域に置く必要があるので、たとえばさっきの配列とVecの例なら、大きな配列はサイズが固定されていても割り当て記憶域を確保するVecで作りましょう、という使い分けが必要になる

最後のここはおかしい

>>623
>>また、変数自体はスタック領域を指しているかヒープ領域を指しているか区別して扱う必要がある

>>638
この書き方あの荒らしじゃん
めちゃくちゃなこと言って反論が来たら大喜びで荒らすだけの奴だからスルーでいい

>>637
それはスタックに置くかヒープに置くかの使い分け
そちらは使い分けすること

>>637
なるほどー

>>640
区別せずに使い分けるのか
面白いこと言うねｗ

>>639
どこが荒らしだよ

>>623は間違っている
>>637は正しい

荒らしはスルー、これ基本

間違えたことを書いた>>637が俺を荒らし扱いかよ

そもそもチェリーピックの連鎖だから読んでない😅

>>637
話の本筋からはそれるけど、Cでは自動記憶域がスタックじゃない可能性ってあるけど、Rustだとどうなんだろう
どっちみちスタック領域って言葉だと混同するから自動記憶域でいいとは思うんだけど

ごめん
>>645はミス
間違えたことを書いてるのは>>623

どうやったらケチつけられるかだけ考えてる荒らしもいるってだけ
相手にしなければ消える

###まとめてみると
「意識する必要がない」というのは**
「メモリリークや解放漏れ、ポインターの不正参照の心配をコンパイラが肩代わりしてくれるため、安全かつ自動で処理される」**という意味において非常に正確です。

​ただし、パフォーマンスの観点からは、**「データのコピーコスト（スタック）」と「ヒープアロケーションのコスト（動的確保のオーバーヘッド）」**の違いを理解しておくことが、高速なコードを書く上で重要になる場面もあります。

>>647
Rustではローカル変数(local variable)と呼ぶ

>>651
ローカル変数のある領域の話をしているのでは？

>>647はどう呼ぶか聞いてるんじゃなくて、スタックで実装されてるかどうかを聞いてるんだと思うが、>>651は何が言いたいんだ

>>652
変数はローカルつまりスタックか
あるいはstaticのどちらかにしかないためそこを区別する必要はない
変数はヒープに置くことができないため

>>647
Cと同じく意味論として挙動が決まっているだけだから、実装がスタックを使う保証はない
実際にはほぼ確実にスタックが使われるところまで、Cと同じだよ

>>653
スタックで実装されているかどうかは機種アーキテクチャに依る

>>654はちゃんとした話はする気ないからやっぱりスルーでいいんだよ
荒らしは放置安定

何聞かれてるか回答見るまで理解できてなかったのか

>>657
正しいことしか言ってないが何が気に入らない？
>>623が間違っていると指摘したことを逆恨みかね？

もうこの荒らしについて言及するの禁止な
ID:2WiNYKUyにレスすんな

>>637
Windowsが1MiB、Unix系が8MiBなんだっけ？

>>660
意味のないことを一つも書いていないおまえが荒らしだろ

Windowsはそうだけど、Unix系と言っても広いからなあ
まあ、デスクトップとモバイルだけならmacOSとLinuxだけ考えればいいんだろうけど
macOSとLinuxだけなら8MiBであってたはず

Linuxでも組み込みだと違いそうだよな

> スタック領域を指しているかヒープ領域を指しているか区別して扱わなくても安全
そんなことはみんなわかってる

> 取り扱う参照がスタック領域を指しているかヒープ領域を指しているか区別することなく全く同様に扱える
それは全く別の話だぞおい

ってだけなんだよな

>>665
厳密に言えば区別せずにスタックに大きな構造体なり配列なりを置きまくってたらスタックオーバーフローすることはあるから、メモリ安全なだけで他の安全は保障されてないんだけどな

>>661
基本はそうだけど
特にRustの場合はメインスレッドと新規スレッドで異なる点が重要
メインスレッドはOSレベルで指定でLinuxなら8MBがデフォルトだがulimit -sで自由に変更できる
新規スレッドはRustの中で指定でデフォルトは2MBだがスレッドのビルダーで自由に指定できる
だからRustではサイズの大きなものをスタック上に置ける

>>667
まあ大きくしすぎてもでメリットがあるからあんまやらないし、新規スレッドだけの話だからどこでも自由なわけでもないし、使い分けを意識してない奴ができることでもないんだけどな

そいつは放置しろって言ってるだろ

>>668
スタック領域を大きくして使うことは
ヒープを使うことと比べて不利にならない
新規スレッドだけの話ではなくメインスレッドもスタックを大きくして使われている
ulimit -sで誰でも変更可能でその後に起動すればメインスレッドのスタックを大きく使えるため

>>670
スタック領域に大きなデータを置くと関数の壁を跨ぐ度にディープコピーになる
これは当然動作速度に悪影響を与える
ヒープ領域なら .clone() しない限りムーブになるので、シャローコピーして所有権を渡すだけなのでこの悪影響を回避できる

>>670
ulimitが必要な時点でデメリットあるやんけ

>>671
Rust初心者でもそんな間違いしないぞ

>>671
そっか、moveが標準だからヒープをわざわざコピーするわけないのか

また何が間違いなのかも言わずに間違いだと主張する荒らし仕草が出たな

>>675
自閉症スペクトラム総合スレ86【ASD】発達障害
https://mevius.5ch.io/test/read.cgi/utu/1782020264/

可変借用は元のところに返すわけじゃないならデメリットが大きいからなあ
わざわざ大きなデータを置いて寿命を気にして可変借用を引き回すより、ヒープに置いてムーブした方が素直な実装になって楽なんだよな

>>676
アンカー間違ってますよ

>>673
自閉症スペクトラム総合スレ86【ASD】発達障害
https://mevius.5ch.io/test/read.cgi/utu/1782020264/

自閉症はC#みたいなのを好む
馬鹿だから😂

大きなデータをスタックに置くと他所で書き換える用途が1つあるだけで可変借用が面倒なことになるよな
ムーブできないのはめんどくさい

😭
https://i.imgur.com/QdnVOt2.png

何も考えず上げるアホのせいで荒らしが増えたな

荒らしが仲間読んで増えちゃってるじゃん
だから話しかけんなって言ってんのに

>>677
本気か？
関数を呼び出すたびにその関数へムーブしていってを深く繰り返し戻る時は返り値で何度もムーブして返すのかね？
爆笑すぎて笑ってしまった

ageで荒らしが来るって5chをPCで操作してるのかな？いろいろ時代遅れ極まりない

【専ブラ】5ちゃんねるブラウザ「ChMate」part269
https://egg.5ch.io/test/read.cgi/android/1784035194/

>>685
無意味に可変借用し続けてライフタイム注釈書きまくる奴の方がアホなんだよなあ
C++とRustは違う言語だと理解した方がいい

ほら荒らしが来た

>>687
ギャグではなく本気かよ
関数の引数でムーブで渡して返り値でムーブして戻すなんて爆笑行為だろ

>>689
moveの意味知らなそう

ムーブとコピーの区別がついてるかも怪しい
こいつ言ってることがいちいちRust知識皆無なんだよな

mut self なんか日常的に取るだろ
ムーブしない設計に固執するのはバカ

>>677は
> 可変借用は元のところに返すわけじゃないならデメリットが大きいからなあ
って言ってるのに
>>689は
> 返り値でムーブして戻すなんて爆笑行為
とイチャモンをつけてる

荒らしは放置

ビルダーパターンもイテレータアダプタもムーブなんだが、知らないのかな？

>>695
それらは一階層のみ
しかもヒープを使わずにselfはスタック上で問題ないパターンなので今回の話とは全く関係がない