Rust part38

公式
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/
（コミュニティによる日本語翻訳版もあります: https://doc.rust-jp.rs/book-ja/）

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

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

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

前スレ
Rust part37
https://mevius.5ch.io/test/read.cgi/tech/1784283151/

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

constで

Rustのconstはコンパイル時に確定する値しか扱えないよ
staticは実行時に確定する値も扱えるね

複おじってOnceLock/LazyLockネタ好きだよね

プログラム実行中に決まる値だけどその後はプログラム終了後まで変わらない値はよくあるけど
それを関数呼び出しするたびに引数として渡して持ち回る方法と
static変数に入れてしまう方法
どちらが便利でコストも低いかという話だよな

起動引数程度ならどっちでもいいよ
問題はコンパイル通すためにstaticにしたがるやつ

不変staticは安全で良い方法だが、staticに親でも殺されたかのように嫌ってる人がいる

Rustって、ROM化出来るん？

できる
むしろRustができない理由が存在しない

opencode重すぎだからgooseに頑張ってほC

>>813
起動引数や設定ファイルのデータだけでなく
他のサーバから読み込んだデータなどあらゆる含む
巨大なデータまで全てが対象

・プログラム実行中に必要とするデータ
・プログラム実行中は変化しないデータ
この2点を満たすならばstatic変数に格納することで利便性が高まることが多い
コンパイルを通すために関数の引数として全てを毎回渡して引きずり回すと不利になりがち

>>808
⓪Stringを&strとして共有

これが第一選択肢

>>819
それは不可能

>>819
それはString側のスレッドが先に終わって解放されちゃったり誰にも解放されないままになったり事故多発物件で禁忌だけど
Rustはコンパイルエラーにしてくれる

しょうがないにゃあ
https://crates.io/crates/argv

>>822
こっちはちゃんとメモリリークと明記しているのが好感もてる

量が分かってるメモリリークは別に問題ないだろ

昔の、main()を抜ける前にfree()すべき論争みたい

>>823
勘違いしてるようだがそのクレイトはargvデータを利用できる環境で直接そのデータを利用することでリークなんか一切せずに&'staticを提供するクレイトだぞ
ただしunsafeだらけ

ただしとは？

ほんとだ
static mutまで使ってやがる

大した需要が無い事が判明したね
ダウンロード数からして

普通にstd::env使えばunsafe使わずに3行で書けるからなあ

Box::leakで取った参照ってBox::from_rawで戻していいのかな
&strとかスライスだと無理そうだけど&Stringなら大丈夫そうな気がする

どのAIも本質的に同じコードを出してくる
once_cell使ったり細かな違いしかない

fn args() -> &'static[&'static str] {
static ARGS_STRING: LazyLock<Vec<String>> = LazyLock::new(|| std::env::args().collect());
static ARGS_STR: LazyLock<Vec<&'static str>> = LazyLock::new(|| ARGS_STRING.iter().map(|s| &**s).collect());
return &**ARGS_STR
}

>>825
>>831だとヒープ領域にメモリ確保してリークしてるけど

メモリリークとはプログラムを動かし続けていると使っていない使用メモリが増え続けていくことだよ
増え続けないものをメモリリークとは言わない

メモリリークの定義はいろいろあります

確保したままなのに使われていないメモリ領域が増えていくとメモリリーク
これ以外に定義はない

増えていくなんて条件はプログラミング素人過ぎないか？

信仰告白みたいでかっこいいですね

https://valgrind.org/docs/manual/mc-manual.html#mc-manual.leaks

>>820>>821
草ｗ草ｗ

>>837
それは狂信的なので完全に無視していい
少なくともRustの方針とは真逆
Rustは「プログラム終了時にすべてのヒープメモリを返す」という無駄なことをしない方針をとっている
そしてIT大手各社そのRustの方針に賛同しているため現状がある

はあ？ 狂信的？ 方針？ 何の話？

>>824の話だよな
Rustは「main()を抜ける前に全てfree()すべき」というキチガイをガン無視

単にRustがメモリリークについて大した方針も用語定義も持っていないだけでは？

ところで、某「IT大手各社」が言うメモリリークも「増え続ける」なんて条件はない
https://learn.microsoft.com/en-us/cpp/c-runtime-library/find-memory-leaks-using-the-crt-library

>>842
それはダメ言語用
ちゃんと明記されてる

RustプログラムでもCRTはリンクするんじゃないの？
というか言語ごとにメモリリークの定義が違うとかないし関係ないでしょ

メモリー解放やってくれる言語でメモリーリークってあるの？

CRTってどの話
公開鍵暗号証明書のCRTか
AWSの共通ランタイムか

>>845
コンテナに詰めたまま今後使われることも無く放置されるオブジェクトというのは、言語機能も手が出せないからメモリリークということになる

>>819
他のスレッドへ渡すことができる参照は&'staticだけです

>>848
嘘おじ乙

なぜ他のスレッドへ&'static参照しか渡せないのかというと
渡した元のスレッドが先に終了したら参照が指している実体が亡くなってしまうためだよ
&'static以外の参照を渡せるようにするためには他のスレッドが動作中は元のスレッドをブロックして終了しないように制限するしかない

共有メモリでやりとりするんじゃ無くて？

お手軽な参照渡しは>>850
所有者はArcに包んで共同所有者になればcloneで共同所有者を増やすことができて他のスレッドへ渡せる

>>848
このレベルの嘘はしょぼいAIでもすぐに看破できるから
嘘つき複製おじさん注意報がなくてもみんなもう大丈夫だよね？

>>851
スレッドは全メモリ空間を共有するため全てが共有メモリ
だから共有メモリという概念は意味がなくて他から渡されたアドレス領域が参照なのか共同所有なのかという点のみ区別される

std::thread::scope

>>855
それは自分がブロックされて動作停止になることと引き換えに参照を渡す仕組み
自分が自由に動く場合は&'staticしか渡せない

相手のバッファに突っ込んでしまえばいいだけでは？

>>857
それはコピー
最もコストが高い
static変数に入れて&'static参照を共有するとコストが安い

コストより、相手のライフ状態気にしなくてし済む自由

AIともこんな調子でバトってるのかな

>>859
その通り
互いのライフを気にせず共有できる&'staticが自由でいいよ

> 問題はコンパイル通すためにstaticにしたがるやつ >>861

static変数はスレッド間で共有するために存在してるんだよ
だからこそstatic mutはunsafeでしか扱えないようにしてある
staticで可変にしたい場合は内部可変性を使うことでsafeに使えるよ

&'staticを得られるから自由に他スレッドに渡せるだけでなくシングルスレッドの利用でも利点が多い
ライフタイム気にしなくてよくなる

>>846
Cathode Ray Tube

>>862
ウケた
まさにこれだよな

関数の引数として渡すときにもstatic化は効果絶大だよ
直接もしくは連れ回す構造体に格納するとき
1. 所有型(VecやString)を使うと構造体のサイズが割り増しになる
2. 通常の参照を使うと構造体にライフタイム<'a>が付いて扱いが煩雑になる
3. 'static参照を使うと構造体がシンプルで済む
便利で効率も良いのはstatic化した時の 3. だよね

結局スレッド云々は全く関係がないんだよな
グローバル変数にして個別に受け渡しせず使いたいならstaticにする
それだけ

グローバル変数は
依存性が隠れやすい/テストしにくいなどのダウンサイドもあるので
用法用量には注意しましょうということ

複おじ節には耳をかすな
これだけでいい

static変数はグローバル変数ではありません
テストがしにくくなることもありません

>>868
基本的な違いをいくつも理解できてないな
まず指摘があるようにstatic変数はグローバル変数ではなくスコープは関数内やモジュール内に閉じて使える
次にstatic変数を直接使う話ではなくてそれが見えない場所からも使える&'static参照の話だろう

「バカは'static以外のライフタイム使わないほうがいい」はガチ

>>871
ライフタイムが難しいなんてことはないでしょ
ここでもライフタイム注釈付けたり面倒という声はあっても難しいとか見かけない

&str の lifetime に納得行かないのなら
&'static str より String 使え

>>873
参照を渡して共有したい話だから
String直接渡すならcloneになってしまうぞ
&'static strの方が何もかも良い

すべったね

しかもスレッドに渡すなら
文字列を渡したいだけなのに
&'static str vs. Arc<String>になってしまうもんな

複おじ(2022)「可変性を気にしなくてよくなるからCell使え」
複おじ(2026)「ライフタイム気にしなくてよくなるから&'static使え」

1ミリも進歩してないｗｗｗ

令和最新版staticおじさん

どんなものでも用いることでコードがシンプルになったり速くなったりするなら使うのが正解
unsafeは除く

なんでもArcにすると扱いが楽！は遅くなるからダメだけど
>>877は問題ないと思う

CPUバウンドな処理をスレッドで回したいだけなら安直にrayonで書く
プロファイラかけてボトルネックだとなったらゼロコピーで書き直す
そうそうない

これ書き味悪すぎるだろ
https://github.com/hanabi1224/Programming-Language-Benchmarks/blob/main/bench/algorithm/coro-prime-sieve/3.rs

こんな風に書けないものか
https://godbolt.org/z/dEv1EPKT9

分割できるなんらかの計算処理以外にrayon活用無理だろ

>>882
非同期で書く課題だから他の言語は非同期を使ってるいるのに1人だけ非同期ではないのは恥ずかしい

generatorはコルーチンだよ

C++読む気ないのにこれだからなあ

>>884
もうちょっと詳しく書くと
>>882のC++コードはこれに対応している
https://github.com/hanabi1224/Programming-Language-Benchmarks/blob/main/bench/algorithm/coro-prime-sieve/2.py
ただしPythonは再帰呼び出しでスタックオバーフローする

ざっと見たところPythonもJavaScriptもC#もGoもRustも非同期タスクを使っているようだ
非同期タスクを使う課題なのではないか？

1.pyなど1.*しか見てなかったからasync使うベンチマークかと思ったら2.pyはasync出て来ないのな
出題が悪いのではないか

>>888
非同期機構のプリミティブは言語毎に違うけどC++はプロミスで
std::generatorはsingle threaded executorだからJavascriptよりかな

C++コードが登録されてないのはこれが流行ったのが昔だからでは

>>889
カラーレスのgoでチャンネルを使ったのがひな型

シングルスレッドの生成器でいいなら
C++の1つ目のジェネレータはRustでは「2..」
2つ目は「(2..).filter(|&i| i % prime != 0)」
しかしそのようなコードを期待されているベンチマークではないと思われる

>>892
それだと非同期機構が関与してない

https://play.rust-lang.org/?version=stable&mode=debug&edition=2024&gist=c97f4c4b1a3a952e5ac727c78bf8ffa3

なんかStreamってあったよなってヒントを与えつつローカルのQwen3.8に書かせてみたけどこんな感じでよか？

C++のそのco_yieldもそれだけでは非同期スケジューリングされる非同期タスクは生成されないぞ

>>894
これいい感じ

>>895
894も882と同じだし
言語毎に非同期機構のデフォルトがeagerがlazyか違うのでそこは関係ないかと

>>882
そのC++のコードのどこに非同期性があるんだよ
全て同期だ

>>897
>>896

非同期機構を使って書いたコードが実際にawaitなどで非同期タスクスイッチが起こるかどうかはこのベンチマークの主眼じゃないかと

>>893でRustのコードに対して非同期機構が関与してないと指摘してるようだが
C++のそのコードも同期のみで同じ

>>899
もう面倒なので自分で勉強してね

C++は非同期ランタイムの標準化に失敗して先送りになったままだったと思う
std::executionが決まらないとC++では無理かと

>>901
どうぞ
https://github.com/nvidia/stdexec

>>902
その非同期スケジューラーを使って非同期に書くといいんじゃね

コルーチンの比較ベンチで非同期かどうかは関係ないような
グリーンスレッドが標準化されてない環境だと重たくなるのはしかたない
RustはTokioがデファクトだからまああり

ID:nl5zGx1zの書き込みを見てると非同期に書いたつもりになってるようだけど非同期になってないですよね

>>905
だから勉強しなさいって

https://play.rust-lang.org/?version=nightly&mode=debug&edition=2024&gist=9a70f86f7c3c8f25cf743142489b882f

yieldで書きたければ今のnightlyだとこれくらいまではできるみたいね
gen {}はなんかCoroutine実装してないとか言われてだめだった…

単なるコルーチンだな
構成要素の一部にはなり得るけど非同期とは別