Rust part29

**デフォルトの名無しさん** · 2025/05/03(土) 00:47:30.13

公式
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 part28
https://mevius.5ch.net/test/read.cgi/tech/1742805420/

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

**デフォルトの名無しさん** · 2025/05/17(土) 22:10:30.09

extract_if()はむしろretain()＋捨てる分を取り出し(extract)と考えた方がいい
ただし残すをtrueか取り出すをtrueかで判定関数の真偽が逆に注意
ついでに判定関数の引数が&vec[i]から&mut vec[i]に変わってるため残すものも値書き換え可のおまけ付き

**デフォルトの名無しさん** · 2025/05/17(土) 22:46:26.94

返されたイテレータを使い切らないと全部削除されないからretainとも微妙に違う
nextで取った分だけ削除だからpeekableとの取り合わせが悪そう

あと関数名はextract_ifじゃなくextractだけでよかった気がする
extractがないのにextract_ifがあるのは何かバランス悪い
drain_filterから紆余曲折あったみたいだから仕方ないけど

**デフォルトの名無しさん** · 2025/05/17(土) 23:12:09.74

>>558
書いた通り、retain()＋捨てる分を取り出し(extract)
だから取り出さないと削除されない
イテレータが進んだ分だけretainと一致する

名前の_ifはすぐに類似のpop_ifが想起される
pop_ifでも条件判定の引数が可変参照で同じだからrangeをlastにしたものと見なすことができる
ifの付かないpopは無条件だから
ifの付かないextractも無条件となる
だからextract_ifというメソッド名が正解で一貫している

**デフォルトの名無しさん** · 2025/05/18(日) 00:31:27.80

すでにドレンフィルタって名称の一般的なものがあるけど…
排水管などのフィルター

**デフォルトの名無しさん** · 2025/05/18(日) 00:55:22.32

coffee extractionはコーヒー豆の方を取り除いているのか液体(エキス?)を抽出しているのか

**デフォルトの名無しさん** · 2025/05/18(日) 01:05:08.64

extract は語源的には ex (外へ) - tract (引っ張る) だから、「取り出す・抽出する」といった意味合いが強い

**デフォルトの名無しさん** · 2025/05/18(日) 01:06:15.76

コーヒー豆とコーヒーが混ざった物からコーヒーを抽出するよね
それをコーヒーを捨てているとは言わない

残ってる方は最後まで濾さないとコーヒー豆とコーヒーが混ざった物でしかないので無価値
一方で抽出したほうはコーヒーなので価値がある
この意味が判るかどうか？

**デフォルトの名無しさん** · 2025/05/18(日) 07:46:36.17

企業献金、結論先送りへ　自公国法案、提出取りやめ [蚤の市★]
2025/05/17(土) 21:17:14.36
https://asahi.5ch.net/test/read.cgi/newsplus/1747484234/

全国1万1155の企業・団体の政治献金「97％」が自民へ、シンクタンク調査 [おっさん友の会★]
2025/05/14(水) 11:12:39.51
https://asahi.5ch.net/test/read.cgi/newsplus/1747188759/

**デフォルトの名無しさん** · 2025/05/18(日) 09:41:45.81

Vecに含まれる構造体を参照しながら、別の構造体に変更を加える処理ってどれがベストでしょうか

**デフォルトの名無しさん** · 2025/05/18(日) 10:17:55.24

これは任意の方苦に向けて電波攻撃可能ということでしょうか？
プログラムの改造で下記が可能になるのでしょうか

「Xperia」が電波法違反、ソニーに行政指導--総務省
2024年12月13日 15時23分
https://japan.cnet.com/article/35227306/
>>スマートフォンにおいて「工事設計認証を受けた工事設計にない空中線を使用しての電波発射が可能な仕様となっている状態にあった事実が認められた」という。

**デフォルトの名無しさん** · 2025/05/18(日) 11:19:10.16

>>565
色々方法があってどれがベストかは状況による

a. 変更内容を作成する処理と変更を適用する処理を分離する
b. split_mut系で更新部分と参照部分のスライスに分割する
c. takeとかreplaceで変更対象の構造体を一旦Vecから取り外す
d. Vec内の構造体を全部RefCellに入れる

可能ならaがベストかな

**デフォルトの名無しさん** · 2025/05/18(日) 11:30:08.35

よくそんな意味不明な質問に答えられるなと思う
自分がアホなのか、予定された質問に予定された答えなのかわからない
本当にわからない

**デフォルトの名無しさん** · 2025/05/18(日) 11:41:01.25

>>567
かなり曖昧な質問に答えてくれてありがとう。
他の言語だとリストから参照で構造体を取り出して、他の構造体を変更したり色々できたけどRustだとかなり制限がキツくて躓いた。ChatGPTにも聞いたりだけどイマイチ納得できなくて、実際使ってる皆さんに聞きたくなったんだよね。

**デフォルトの名無しさん** · 2025/05/18(日) 11:44:13.33

ChatGPTに聞いたなら質問を清書してくれただろ？
そっちを貼ればいいだろ？
謎すぎる

**デフォルトの名無しさん** · 2025/05/18(日) 11:45:25.47

意味不明な質問というのには完全に同意
質問と回答が矛盾してるので
さすがにこれは発達オジの自作自演ではないだろう

**デフォルトの名無しさん** · 2025/05/18(日) 11:47:57.87

あ・・・
自分の中では矛盾してなかったみたいww

自作自演発達オジの日本語能力の問題だったか

**デフォルトの名無しさん** · 2025/05/18(日) 11:48:09.03

やりたいことは、構造体には関数も実装ししていて、その関数に大元のVecを渡してそれぞれの要素に変更をかけるみたいなやつだけど、ミニマムで質問してみた。一旦教えてもらったcに近い実装でコンパイル通ったけど、モヤモヤしたので聞いてみました。

**デフォルトの名無しさん** · 2025/05/18(日) 11:48:46.66

>>570
確かに、、、すまぬ

**デフォルトの名無しさん** · 2025/05/18(日) 11:52:57.81

「別の構造体」というのは「同じVecの別の位置にある要素」という意味？
values[0] を参照しながら values[1] を変更するみたいな

**デフォルトの名無しさん** · 2025/05/18(日) 11:57:42.82

>>565
一般的にそういう時は困っていることが成立している最小構成例を具体的に出す
何通りにも解釈できる意味不明な曖昧な文章では答えてくれる人も減るだろう

>>568
意味不明な文章だがRustのプログラミング経験があるならば
質問者の脳内の仮定を補完して最も可能性の高い質問ケースとして回答者が応じている状況を観察できるはずだ

**デフォルトの名無しさん** · 2025/05/18(日) 11:58:51.15

書き方が回りくどいね　わかりやすく

**デフォルトの名無しさん** · 2025/05/18(日) 12:05:59.38

>>575
そうです、言葉足らずでした。。。

**デフォルトの名無しさん** · 2025/05/18(日) 12:21:21.33

>>578
それはRustだと面倒なパターンなので仕方ない
{} でブロックを作って借用のスコープを短くする等でなんとかする
ここはボローチェッカーの気持ちの理解が必要
(なぜダメなのかはエラーメッセージが教えてくれてるから、そこは既に分かってるかもしれないけど)

同じことは構造体の別のフィールドを参照する場合も言える
構造体のフィールドaを可変借用しつつ別のフィールドbを参照するなど

**デフォルトの名無しさん** · 2025/05/18(日) 12:26:55.54

う～ん
　何が言いたいかわからる人にはわかるだろ？

**デフォルトの名無しさん** · 2025/05/18(日) 12:29:43.83

何がやりたいのか全然わからん。
コードで示してよ。
コンパイル通らなくてもいいから Rust 風擬似コードって感じで。

**デフォルトの名無しさん** · 2025/05/18(日) 12:54:12.76

複おじちゃんは今日もやらかしてるね
特有の癖が出てるのに自分ではバレてないと思ってるから面白い

**デフォルトの名無しさん** · 2025/05/18(日) 13:00:12.37

困ったことが起きたらその問題が再現する最低限の最小構成コードを書いてみる
すると本質的な構造が見えてくる
その過程で自己解決することも多いだろう
わからなくてもその最小構成コードを貼って質問すればよい

**デフォルトの名無しさん** · 2025/05/18(日) 13:58:46.67

>>579
やはりそうなんですね。ありがとうございます。

>>581
>>583
助言ありがとうございます。
ChatGPTにサンプルコード作ってもらいました。コンパイルは通らないですが、やりたいイメージはこんな感じです。

struct Unit {
id: usize,
hp: i32,
}
impl Unit {
fn act(&mut self, all_units: &mut Vec<Unit>) {
// 自分以外のユニットに攻撃したい
for unit in all_units.iter_mut() {
if unit.id != self.id {
unit.hp -= 10;
}
}
}
}
fn main() {
let mut units = vec![
Unit { id: 0, hp: 100 },
Unit { id: 1, hp: 80 },
Unit { id: 2, hp: 60 },
];
for unit in units.iter_mut() {
unit.act(&mut units); // ❌ コンパイルエラーになるが、やりたいことはこんな感じ
}
}

**デフォルトの名無しさん** · 2025/05/18(日) 14:03:53.58

>>584
これも追加

// 自分以外のユニットに攻撃したい
↓
// 自分以外のユニットから奪い取る

if unit.id != self.id {
unit.hp -= 10;
self.hp += 10;
}

**デフォルトの名無しさん** · 2025/05/18(日) 14:16:39.01

自作自演スレ

**デフォルトの名無しさん** · 2025/05/18(日) 16:37:58.98

>>585
こんなのでどうだろう
https://play.rust-lang.org/?version=stable&mode=debug&edition=2024&gist=871e0b5209dab043741c765000be6e5a

他言語からすると面倒に感じるかも
「要素 i への可変参照を持ちつつ、Vec全体への可変参照を持つ」のは借用チェッカーに引っかかるパターン
if unit.id != self.id の判定が必要なように「all_unitsの中にunitがいるかもしれない」という状況をそもそも借用チェッカーは防ぎたいので

なので、 split_at_mut() を使って参照範囲を ([i] への可変参照, 他の要素への可変参照) に分けてみた

他には Cell (内部可変性) を使うパターンもあるけど、このケースでこれを使うのはちょっと微妙な気がする

**デフォルトの名無しさん** · 2025/05/18(日) 16:40:13.34

>「all_unitsの中にunitがいるかもしれない」という状況
訂正:「all_unitsの中に自身がいるかもしれない」という状況

**デフォルトの名無しさん** · 2025/05/18(日) 16:59:42.16

あんまりアドホックな対応で頑張ってもまた同様の問題でいちいち詰むよ
エンティティなんだから素直に内部可変性を使っておいた方が無難
僅かに遅くはなるだろうが、メモリアクセス効率まで気にするならECSパターンでも覚えた方がいい

**デフォルトの名無しさん** · 2025/05/18(日) 17:43:23.59

スライスを(init, mid, tail): (&[T], &T, &[T])に分割するsplit_midがほしいな
何かで似たような戻り値の型を見た記憶があるけど

**デフォルトの名無しさん** · 2025/05/18(日) 18:24:32.38

1つだけ外したい場合はOption+mem::take/replace使うのが自然だと思う
https://play.rust-lang.org/?version=stable&mode=debug&edition=2024&gist=a84a532ace40d2bb6603510ca1307756

**デフォルトの名無しさん** · 2025/05/18(日) 19:24:49.27

590だけど1.86で追加されたget_disjoint_mutが使えるかもしれない
少し癖があるけどsplitの代替になるかな

fn main() {
let mut v = vec![1, 2, 3, 4, 5];
let len = v.len();

for i in 0..len {
let Ok([init, [mid], tail]) = v.get_disjoint_mut([0..i, i..i + 1, i + 1..len]) else {
panic!();
};
*mid *= 2;
println!("{init:?} {mid} {tail:?}");
}
}

**デフォルトの名無しさん** · 2025/05/18(日) 21:02:54.43

>>584-585程度でこんなんか
安全パターンをプリミティブに単体分離しようと頑張るのは無駄なんだな
結局は要素還元できなくて逆に組み合わせ爆発しそう

**デフォルトの名無しさん** · 2025/05/18(日) 21:12:32.00

>>587
>>591-592
ありがとうございます！大変ためになります。
可変借用ルールの影響を受けないように分離するのが良いのですね。

>>585
私はこの方ではないが、これはこれで知りたかったので、それも解決出来る書き方にもなってるので助かります。

>>589
確かに複雑になってくるとまた沼りそうな気はしますね、内部可変性というのも調べてみます。

**デフォルトの名無しさん** · 2025/05/18(日) 21:37:30.85

借用チェッカの気持ちとしては、同じオブジェクトへの可変参照が複数ある状態を防ごうとするんだよね

fn act(&mut self, others: &mut [Unit]) { }

の中で、 self を操作しただけで others に影響が出たり、 others への操作が self に影響したりするというのは
潜在的なバグの原因になり得る (読み手にとって意図せぬ動作になり得る) から、そうならないことをコンパイル時に保証しようとする

なので >>587 では、act に渡された時点で self と others は確実に違うものだと分かるコードにすることで、借用チェックの条件をクリアしている

内部可変性は逆に、コンパイル時はいったん不変参照ということにしておいて、実行時に可変借用として取り出すための型
これは「同じオブジェクトへの可変参照は同時に一つまで」というルールを、借用チェッカーではなく自己責任で行うという考え
(「可変参照は同時に一つまで」というルールは変わらないし、実行時にこれを検査する動作になるので、若干のオーバーヘッドはある)

個人的には >>589 も納得できる考えで、エンティティ (idで同一性を検査するオブジェクト) ならそれでいいよねとも思う

Async が絡むと Mutex という別の型 (これも内部可変性と関係する) が出てくるけど、これはまた別のトピックになるので割愛

**デフォルトの名無しさん** · 2025/05/18(日) 22:38:23.16

なにかへまったら話題変更のために自演を始めるんかな？
と思ってしまう

いつも大体そんな流れだし急にポップしてくるこのスレの話題は理論寄りが多いのも変な感じする

**デフォルトの名無しさん** · 2025/05/18(日) 22:57:08.60

>>592
使えるけど今回のような用途だと分けた後に前後を足してから処理するところがちょっと重く感じる
https://play.rust-lang.org/?version=stable&mode=debug&edition=2024&gist=9d999080fc4b58f68252699e3ba79edf

**デフォルトの名無しさん** · 2025/05/18(日) 23:29:42.52

>>597
left.iter_mut().chain(right)
はflatten使って
[left, right].into_iter().flatten()
にすれば多少は軽い感じになるかな
処理的には変わらないと思うけど

**デフォルトの名無しさん** · 2025/05/19(月) 10:12:45.15

レスパオジはGoスレに引っ越したらしい

**デフォルトの名無しさん** · 2025/05/19(月) 10:30:17.58

>>596
私も同じ匂いを感じます

**デフォルトの名無しさん** · 2025/05/19(月) 10:33:51.23

>>596
だよなあ

**デフォルトの名無しさん** · 2025/05/19(月) 10:55:55.29

言語が変わっても複オジは変わらんな
自分勝手な間違った解釈を正しいと思い込む病気なのか
間違ってるとわかってもマウントを取り続けないと自我が崩壊する病気なのか

**デフォルトの名無しさん** · 2025/05/19(月) 11:52:44.35

>>602
前者が発達トレイトで
後者が糖質トレイトだね

**デフォルトの名無しさん** · 2025/05/19(月) 12:49:02.69

Rustといえどもある程度大きな規模のプロジェクトになってくると、スマポの使用が増えてきてJava/C#/C++あたりとの差異が縮まってくる印象はある
人間の認知能力の限界なんだろうけど、AIによってボローチェッカーが積極的に大域的に活用されるようになったら、人間がついていくのがだんだん厳しくなりそう

**デフォルトの名無しさん** · 2025/05/19(月) 16:44:14.27

Rustで100万行クラスの規模のコード書いたからって別に破綻せんよ
依存関係整理して注意して使わないといけないのは規模に関係ない

**デフォルトの名無しさん** · 2025/05/19(月) 17:30:52.93

>>605
C/C++からコンパイルされたマシンコードが一切入らないやつってPascal/Delphiは一定数あるけど
100% Rust 製ので100万行規模のソフトなんて何がある？

**デフォルトの名無しさん** · 2025/05/19(月) 19:00:04.76

Rust標準ライブラリがcore+alloc+stdで現在34万行
クレイトだと例えばtokioが12万行

**デフォルトの名無しさん** · 2025/05/19(月) 19:20:41.87

rust-lang/rustのrsファイルだとsrc/（ツール系）が91万行でcompiler/（内部ライブラリ）が69万行
rustcとかrustdocとか混在してて多分同じライブラリ共有してるから個々の正確な数字は出せないね

**デフォルトの名無しさん** · 2025/05/19(月) 19:34:29.26

新設のmozilla-firefox/firefox内はFF固有コードだとして
>>466の外部crateで実質FF固有なものだけ集めると実は大したこと無いのでは

**デフォルトの名無しさん** · 2025/05/19(月) 20:02:00.34

100万行はたとえだろ
何の言語でも100万行になると設計を極限まで綺麗にしないと地獄だわ

**デフォルトの名無しさん** · 2025/05/19(月) 20:11:56.59

>>604
> ある程度大きな規模のプロジェクトになってくると、スマポの使用が増えてきて

コンパイラやCLIツールなど比較的短時間でプロセス終了するプログラムなら
life timeを'staticにして逃げる場合があるけど
pure Rust GUIアプリでメモリー使用量を考慮したアプリだとスマポの使用が多そうね

**デフォルトの名無しさん** · 2025/05/19(月) 22:29:21.37

なんか怪しいので自分でも計測してみた

rust/library/core+alloc+stdは18.6万
tokioは8.4万
rust/srcは81.6万
rust/compilerは57.1万

.mdファイルの行数やドキュメントコメント行・ブランク行・コメント行とか水増ししずぎじゃない？

**デフォルトの名無しさん** · 2025/05/19(月) 22:41:19.70

>>605
これには完全に同意

1万行でも100万行でも個々のコードの複雑さが変わるわけじゃない
どちらもも数十行～数百行のモジュールの寄せ集め

**デフォルトの名無しさん** · 2025/05/19(月) 22:52:59.01

C/C++製のソフトウェアたちがプログラマのうっかり見逃しミスによるセキュリティホールなどのレポートが常に絶えない原因はその規模と関連がある
かなり小規模なものを除いて人間の手でチェックしている限り一定のミスが入り込む
コンパイラが全体の安全性を保証してくれるRustは規模が大きくなっても有利だろう

**デフォルトの名無しさん** · 2025/05/20(火) 00:32:14.76

普通に規模が大きくなれば一般的に設計と実装の複雑度は変わるよ
どのアプリでも言語でも変わらない
rustはメモリ関連のバグが起こりにくいだけ

**デフォルトの名無しさん** · 2025/05/20(火) 05:04:51.52

>>614
Rustを使えばプログラマのうっかり見逃しミスが100%無くなるんだね
RustのコンパイラってAIみたいだね

**デフォルトの名無しさん** · 2025/05/20(火) 06:00:38.75

「Xperia」が電波法違反、ソニーに行政指導--総務省
2024年12月13日 15時23分
https://japan.cnet.com/article/35227306/
>>スマートフォンにおいて「工事設計認証を受けた工事設計にない空中線を使用しての電波発射が可能な仕様となっている状態にあった事実が認められた」という。
※全携帯とスマートフォンのプログラム改造で人の場所に照射可能になる？
※場合にもよりますがAIと併用して個人を追跡しているのなら24時間商社可能
6Gの候補であるテラヘルツ帯の電波を脳の神経細胞に照射すると細胞が異常な成長を遂げたことが明らかに
2022/08/15
https://gigazine.net/news/20220815-terahertz-radiation-boosts-brain-cell/
携帯電話の使用で「精子の数が減少」の可能性、スイスの研究者が指摘
2023/11/27
https://forbesjapan.com/articles/detail/67083
携帯電話の電磁波が神経や細胞の損傷を引き起こすと主張するロバート・F・ケネディ・ジュニア保健福祉長官が学校での携帯電話の規制を称賛
2025年03月25日 06時00分
https://gigazine.net/news/20250325-rfkjr-kids-cell-phone-schools/
>>ケネディ・ジュニア氏は子どもが携帯電話を使用することについて独自の視点から語り、携帯電話やソーシャルメディアの利用と、うつ病、学業成績の悪さ、薬物乱用との関連性について言及。その中で、「携帯電話は電磁波を発し、一日中携帯電話を身近に置いていると子どもたちの神経にダメージを与え、細胞損傷やがんを引き起こすことが示されている」と指摘しました。
設立 1998年
テクノロジー犯罪の撲滅
Https://media.toriaez.jp/s2972/32686.pdf
P77-身体・運動機能が遠隔から操作される P78-五感が遠隔から操作される
上記が本当だった場合統合失調症操作
統合失調症のう動きがわかるエリアの人はそれを体験中
平衡感覚は別のふらつき缶
視覚感覚なら別の何かを見ている
聴覚感覚なら別の何かの声を聴いている
味覚なら別の味を感じている
触覚なら別の感触を感じている
温覚冷覚なら別の温冷覚感じている
このようになるのですよ

**デフォルトの名無しさん** · 2025/05/20(火) 08:02:42.80

幻聴で悪用していると話していました

オープンソースでアニメ動画を自動生成できるAIツール「AniSora」を中国・bilibiliの開発チームが発表
2025年05月19日 19時00分
https://gigazine.net/news/20250519-anisora/
1枚の画像からアニメーションを作成するAIツール「AniSora」を発表しました。

Microsoft CopilotがついにGPT-4oの画像生成をサポート
掲載日 2025/05/19 18:56
https://news.mynavi.jp/techplus/article/20250519-3327017/
Microsoftの公式Xアカウントによる投稿では、2025年5月16日に「4o Image Generationがついにリリースされました」というコメントと共に、Copilotで次のことができるようになったと伝えている。
• 正確で読みやすいテキストをレンダリングする
• 作成したものを編集する
• 複雑な指示に従う
• 既存の画像のスタイルを変換する
• フォトリアリスティックな画像を作成する
同アカウントは、実際にテキストによる指示で画像を微調整していく様子も投稿している。

**デフォルトの名無しさん** · 2025/05/20(火) 09:44:44.40

>>457,466
設計さえしっかり出来ていればどんなに低く見積もっても5~10万行/人年は固い

車輪の再発明(移行プロジェクト)はすごい勢いでコード量が増えていくはずなんだけどね...

**デフォルトの名無しさん** · 2025/05/20(火) 10:54:31.93

車輪の再発明は再発明であって作り直しのことじゃないよ。
「丸くしたらめっちゃ速く移動できることを発見したぞ！」って今の世の中で言うやつがいたらアホじゃん (そこらにいくらでもあるものが見えてないから) ということを説明してるのが車輪の再発明という言い回し。

「俺も車輪を作れるようになったぞ」とか「別の素材で車輪を作ってみた」みたいなのは再発明ではない。

**デフォルトの名無しさん** · 2025/05/20(火) 11:19:42.09

FirefoxのRust化は本体よりServoあたりを見とけばいいんじゃね？
実用化の目途が立ったら乗り換えるでしょ
ブラウザエンジンはCSSもスクリプトも動画再生も全部面倒見るから１から作るのは大変そう

**デフォルトの名無しさん** · 2025/05/20(火) 11:21:03.24

>>466
そのレポを挙げてよ
別のところに100万行ある、見たいな思わせは良くないよ

**デフォルトの名無しさん** · 2025/05/20(火) 11:34:05.86

>>620
関係ないけど、「別の素材で車輪を作ってみた」は発明じゃね？

**デフォルトの名無しさん** · 2025/05/20(火) 11:36:15.63

>>622
Firefoxにそんなに興味があるくせにプロジェクト名すら知らないとは異常だな
見上げてごらん

**デフォルトの名無しさん** · 2025/05/20(火) 12:25:37.28

servoの努力を馬鹿にはしないけど
experimentalよりもアリバイ作りに見える位なので
servoの成果を当てにするのはどうかと思う

**デフォルトの名無しさん** · 2025/05/20(火) 12:30:48.46

servoは、tauriで使うために開発再開したんじゃなかったっけ？
その後チェックしてないけど

**デフォルトの名無しさん** · 2025/05/20(火) 12:35:54.41

車輪の再発明/servoの話で想起されたけど時々、高校生がピタゴラスの定理の新証明を発見的なニュースがある
高校生だから良いけど素人オジだったら大分印象変わる

**デフォルトの名無しさん** · 2025/05/20(火) 12:43:24.47

>>620,623
>「別の素材で車輪を作ってみた」

特許は取れるだろう

**デフォルトの名無しさん** · 2025/05/20(火) 12:46:23.55

というかfirefoxのリポジトリを取ってきて*.rsの行数数えるだけで400万行超えるんだが…

**デフォルトの名無しさん** · 2025/05/20(火) 13:28:39.47

>>629
言う奴いると思ってたら...

tokei -C -t=Rust -e third_party
Language Files Lines Code Comments Blanks
Rust 1193 416629 348374 23629 44626

コンパイラ入ってら
tokei -C -t=Rust third_party/rust
Language Files Lines Code Comments Blanks
Rust 10915 3845860 3397959 148316 299585

**デフォルトの名無しさん** · 2025/05/20(火) 13:31:22.64

>>623
発明だが車輪を発明したわけではない。

**デフォルトの名無しさん** · 2025/05/20(火) 13:32:11.96

コンパイラ本体の実数は>>612

**デフォルトの名無しさん** · 2025/05/20(火) 13:35:06.85

>>631
面白いね

起源:
紀元前3500年頃、メソポタミア文明（現在のイラク地域）のシュメール人によって車輪が発明されたとされています。
初期の車輪:
固い木材を丸く削り出しただけの単純な構造で、主に陶器の製作や物資の運搬に使用されていた。
発明者:
車輪の発明者として特定の人物が特定されているわけではなく、シュメール文明における技術革新の成果として捉えられています。

**デフォルトの名無しさん** · 2025/05/20(火) 13:35:22.56

>>630
third_party/rustの中身をちゃんと見ろ
依存ライブラリであってコンパイラは入ってない

**デフォルトの名無しさん** · 2025/05/20(火) 13:38:36.14

なるへそ
でも趣旨は同じです

**デフォルトの名無しさん** · 2025/05/20(火) 13:41:23.89

散らかったのでまとめ直すと
>>629
> というかfirefoxのリポジトリを取ってきて*.rsの行数数えるだけで400万行超えるんだが…
は間違いで、正味35万行

**デフォルトの名無しさん** · 2025/05/20(火) 13:47:44.39

third_partyのソースも保持してるなら言語の比率は参考にならんな

**デフォルトの名無しさん** · 2025/05/20(火) 13:55:44.85

>>637
githubが賢くてgit-submoduleになってないけど除外しているっぽいから確かめてみて

**デフォルトの名無しさん** · 2025/05/20(火) 15:11:23.99

>>613
ライフタイムや借用チェッカーはそのモジュール同士の結合強度を強める傾向があるってことでしょ
大規模になるとスマポが増えるってのは事実で、後になって広範な修正が必要になるのを避けようとすれば厳密なチェックは狭い範囲内にとどめておいて、
大域的な依存関係はスマポで緩く扱えるようにしておく方向で妥協せざるを得ない

**デフォルトの名無しさん** · 2025/05/20(火) 15:43:54.81

インサイダー v談合マネロン電波音波攻撃をしているなどの悪の組織の考え化のシミレーションが可能

GPT-4は説得しようとしている相手に関する基本的な個人情報を与えられた場合に説得する能力が人間よりも高くなる
2025年05月20日 13時00分
https://gigazine.net/news/20250520-ai-persuasiveness/

AIエージェントは放っておくと独自の社会を構築し始めるという研究結果
2025年05月20日 12時30分
https://gigazine.net/news/20250520-ai-society/

**デフォルトの名無しさん** · 2025/05/20(火) 15:59:16.65

>>602-603
これが糖質タイプ(>>620からの>>631)
歴史上「車輪」の「発明」を何度も繰り返しているから「再」発明と言う

**デフォルトの名無しさん** · 2025/05/20(火) 16:14:32.72

>>613
「寄せ集め」があたかも独立であるかのように匂わせたいのか知らんけど違うぞ

>>639が示唆している通り、大きな相互依存の塊になっている場合が多い

**デフォルトの名無しさん** · 2025/05/20(火) 16:58:46.87

なんでわざわざID変えて書き込むの？

**デフォルトの名無しさん** · 2025/05/20(火) 17:39:14.41

>>639
>>大規模になるとスマポが増える

それは違うだろ
まずスマポは種類が多く各々の目的が全く異なる
どのスマポのことを指しているのか？
小規模でも各々の目的が必要であれば必要となる
大規模になるとスマポが増えるわけではない
具体的にスマポとはどれを指しているのか？

**デフォルトの名無しさん** · 2025/05/20(火) 17:40:45.69

>>639
>ライフタイムや借用チェッカーはそのモジュール同士の結合強度を強める傾向があるってことでしょ
参照を扱う面倒くささが付いて回るという面はあっても個々のボローチェックの範囲は関数内に閉じてるんだから結合強度は高まらないでしょ

**デフォルトの名無しさん** · 2025/05/20(火) 17:43:53.52

IDを変える時、IDもまたこちらを変えているのだ

**デフォルトの名無しさん** · 2025/05/20(火) 17:55:25.94

C++ とかでも原則としては参照先が参照より先に寿命を終えたら駄目なことにはかわりない。
Rust のライフタイムや借用規則 (のチェッカー) が結合を強めたりはしない。
存在していたものを見える形で書くようになっただけ。 (まあそれが面倒というのなら面倒なのは確か。)

**デフォルトの名無しさん** · 2025/05/20(火) 18:02:41.78

>>645
スマポを使ってもそれ自体をムーブ(やクローン)でもしない限りは必ずDerefで単なる参照を渡して使うことになる
スマポを用いていても参照を使えばライフタイムは必ずついて回る

**デフォルトの名無しさん** · 2025/05/20(火) 18:10:11.38

>>644-648

>>595の言う通り、「呼び出し側」で参照を「予め」分割しなければならない
つまりはそういう事

**デフォルトの名無しさん** · 2025/05/20(火) 18:14:41.60

>>647
おっしゃる通りC言語ですら明示されないだけでライフタイムは必ず守らないとダングリングポインタが発生してしまう
Rustでもライフタイムによりプログラミングが難しくなることはなく
ライフタイムがモジュール間の結合強度を変えることもない

**デフォルトの名無しさん** · 2025/05/20(火) 18:31:47.37

>>649
それはスマポではない
単なる可変参照の粒度分割だ
ましてやプログラムが大規模かどうかと一切関係がない

**デフォルトの名無しさん** · 2025/05/20(火) 18:32:55.28

自分の触る範囲でデータ構造に触ることは無くなったとしても他でも同じなのかどうかは
ただのポインタじゃ判らない

ライフタイム自身はコンパイラにヒントを出すためのただの記号だし

**デフォルトの名無しさん** · 2025/05/20(火) 18:34:04.55

>>595
>>Async が絡むと Mutex という別の型が出てくるけど、

asyncとMutexは一切関係がない
asyncでもシングルスレッドならMutexは必要ない
asyncを使わなくてもマルチスレッドならMutexが必要だ

**デフォルトの名無しさん** · 2025/05/20(火) 18:36:17.26

きな臭くなる予感しかしない

**デフォルトの名無しさん** · 2025/05/20(火) 18:49:05.28

>>605,636
なるほどFirefoxをよく見たら35万行でdead endという事か

>>466
別レポは嘘で本体レポにがっつりコピーしてるのバレたね

**デフォルトの名無しさん** · 2025/05/20(火) 18:51:58.25

いつ終わるともわからないただの置き換え作業を嬉々としてやれる人間はいないだろう

**デフォルトの名無しさん** · 2025/05/20(火) 18:59:32.26

>>605
規模に関係なく本当に一人で年間10万行置き換え出来るなら35万行dead endしてないよねぇ