Rust part26

**デフォルトの名無しさん** · 2024/09/20(金) 22:18:38.38

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

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

**デフォルトの名無しさん** · 2024/11/11(月) 23:31:21.84

>>774
Static items do not call drop at the end of the program.
https://doc.rust-lang.org/reference/items/static-items.html

Drop types placed in statics WILL leak.
https://github.com/rust-lang/rfcs/pull/1440

**デフォルトの名無しさん** · 2024/11/11(月) 23:46:08.88

>>782
ありがと、これで回避できた
けど借用のルールはまだいまいち分かってない…

**デフォルトの名無しさん** · 2024/11/11(月) 23:52:53.38

staticはモジュールアンロードする可能性があるなら始末する時に手動dropできるように対処するしかないな
アンロードしないなら問題なし

**デフォルトの名無しさん** · 2024/11/12(火) 00:02:28.18

>>782
えーとOptionがnoneのとき値を入れたいという場合はもっと簡単に書けて

fn do_something()->&mut [u8] {
self.get_or_insert(vec![1,2,3])
}

という感じ。

**デフォルトの名無しさん** · 2024/11/12(火) 00:12:38.06

>>781
&mut self.dataにも所有者がある
この匿名の所有者の寿命を'a
型を&'b mut T
とする
'bは'aより長いから'aがいくら短くても、借用された状態が続く

匿名をやめて名前をつければその名前でアクセスできる

**デフォルトの名無しさん** · 2024/11/12(火) 00:13:32.91

なるほど、リークしちゃうんだ。

**デフォルトの名無しさん** · 2024/11/12(火) 00:50:59.75

get_mut OR (insert AND get_mut)を
1ステップにまとめるのは気持ち悪いな

1ステップにまとめていいなら
最初からデフォルト値を入れといてもいいのでは？

**デフォルトの名無しさん** · 2024/11/12(火) 02:10:28.31

>>787
さすが複オジ
ぶっ飛んでるな

**デフォルトの名無しさん** · 2024/11/12(火) 03:23:50.67

>>781
この辺のルールかなって思ったけど正直分からん
https://doc.rust-lang.org/reference/destructors.html

return x;をpanic!()に変えるとコンパイル通ってしまうのはどこかに明確な説明があるかね……

**デフォルトの名無しさん** · 2024/11/12(火) 03:24:11.27

>>781
drop scopeの決定時に制御フローは考慮されないってことなのかなって思ったけど正直分からなくなってきた
https://doc.rust-lang.org/reference/destructors.html

return x;をpanic!()に変えるとコンパイル通ってしまうのはどこかに明確な説明があるかね……

**デフォルトの名無しさん** · 2024/11/12(火) 07:26:38.88

>>789
複おじの発想が気持ち悪い

**デフォルトの名無しさん** · 2024/11/12(火) 10:15:49.34

>>781
省略せずに書くと
fn do_something<‘a>(&’a mut self) -> &’a mut [u8]

return xするとxのライフタイムは’a
xは&mut self.dataの一部なので&mut self.dataのライフタイムも’a
‘aのライフタイムに渡って&mut self.dataを借りておく必要があると解釈されるので
self.data = Some(vec![0u8; 10]);はエラーになる

マッチしない場合は借りないようにしてくれよと思うのはわかるが
これは今のバージョンのボローチェッカーの制約
nightlyで使える新しいボローチェッカーならエラーにならない

詳しいのは↓ここ
https://rust-lang.github.io/rfcs/2094-nll.html#problem-case-3-conditional-control-flow-across-functions

**デフォルトの名無しさん** · 2024/11/12(火) 10:22:11.79

if self.data.is_some() {
return self.data.as_mut().unwrap();
}
や
if let Some(ref mut x) = self.data {
return x;
}
でも
エラーにならない

**デフォルトの名無しさん** · 2024/11/12(火) 10:23:41.85

>>793
複おじではないよ

**デフォルトの名無しさん** · 2024/11/12(火) 11:06:54.00

>>794
新しいボローチェッカーって-Zpolonius=nextのことでいいの？
付けても通らなかったけど、これが通せることを目標にしてるって意味？

**デフォルトの名無しさん** · 2024/11/12(火) 11:26:31.07

仇討ちして英雄になりたいのか
とんでもねえ話だなこれ

**デフォルトの名無しさん** · 2024/11/12(火) 13:38:59.51

>>797
-Z poloniusで通る

**デフォルトの名無しさん** · 2024/11/12(火) 14:07:23.60

>>799
おっいけたわありがとう
-Zpolonius=[legacy|next]だと思ってたらいつの間にやらon/offフラグになってたのね

**デフォルトの名無しさん** · 2024/11/12(火) 18:29:56.22

>>781
左右の型が一致しない(右だけ参照)この部分を
if let Some(x) = &mut self.data {
昔からの正規にrefを使って左右の型を一致させて
if let Some(ref mut x) = self.data {
こう書けばコンパイル通る点は興味深いな

**デフォルトの名無しさん** · 2024/11/12(火) 22:58:43.29

どうしてこのプログラムがコンパイル通るのかがわからん
明らかにyの寿命はxより短いはずなのに、xより長生きすることが仮定された引数にyを渡したらエラーになるはずでは？
x,yの型をどういうのに変えたらこれをエラーにすることができる？
fn test<'a, 'b:'a> (_x:&'a (), _y:&'b ()) {
}
fn main() {
let x = ();
{
let y = ();
test(&x,&y);
}
}

**デフォルトの名無しさん** · 2024/11/13(水) 00:44:01.02

貸し借りの実態を操作したつもりが、「借りられるのに誰も借りてない」状態が続いただけで
実態が変わらなければエラーも起きない

**デフォルトの名無しさん** · 2024/11/13(水) 01:07:05.96

Rust信者って、説教くさいよね。

**デフォルトの名無しさん** · 2024/11/13(水) 01:22:28.48

急にどしたの？

**デフォルトの名無しさん** · 2024/11/13(水) 02:11:38.53

>>802
test画最適化されて消えてるんだろう

**デフォルトの名無しさん** · 2024/11/13(水) 08:18:30.90

>>803
変更を加えるとしたらどうしたらいいですか？

**デフォルトの名無しさん** · 2024/11/13(水) 08:30:57.78

国内では生成AIに話題を奪われてハイプがめっきり落ち着いた感があるな
世界的には中華圏を中心にまだまだ上昇の余地がありそうだが、国内では残念ながら一部のアーリーアダプタが騒いだだけの言語で終わりそうだ

**デフォルトの名無しさん** · 2024/11/13(水) 08:46:31.60

米ホワイトハウス「ソフトウェアはメモリ安全でなければならない」との声明を発表：「C」「C++」よりも「Rust」などの言語を推奨
https://atmarkit.itmedia.co.jp/ait/articles/2403/18/news045.html

米国国防総省のDARPA、CからRustへのコード変換を自動化する「TRACTOR」プログラムを開始
https://atmarkit.itmedia.co.jp/ait/spv/2408/14/news045.html

**デフォルトの名無しさん** · 2024/11/13(水) 09:16:26.38

お
refの出番あるじゃん
コンパイラのsuggestちゃんとしてくれよ

**デフォルトの名無しさん** · 2024/11/13(水) 09:17:25.81

>>807
変更を加えるには変更を加えれば良い

**デフォルトの名無しさん** · 2024/11/13(水) 09:19:24.12

>>808
國内の外注プログラマは二次請け三次請けで
コーディングの実態はインドやバングラ
日本人需要はもう無いかもな

**デフォルトの名無しさん** · 2024/11/13(水) 09:22:11.31

>>807
出題者の期待を裏切るような変更しかなさそうだね

微調整だけで解決してほしいとかリセットはやめてほしいとか
そういうのを裏切る

**デフォルトの名無しさん** · 2024/11/13(水) 09:43:08.15

>>802
x,yのスコープと&x,&yのライフタイムを混同してるように見える

fn test<'a, 'b: 'a>(x: &'a (), y: &'b ()) -> (&'b (), &'b ()){
(x, y)
}
とすれば’a: ‘bがなければ関数単体でエラー

fn test<'a, 'b: 'a>(x: &'a (), y: &'b ()) -> (&'a (), &'a ()){
(x, y)
}
fn main() {
let x = ();
let result: (&(), &());
{
let y = ();
result = test(&x, &y);
}
println!("{:?}", result);
}
↑のように&yのborrowをyのスコープを越えて利用すればエラー
でもこの場合の関数定義は’bを使わず全部’aにしても何も変わらない

**デフォルトの名無しさん** · 2024/11/13(水) 17:49:14.41

>>727
最近上がった孫さんの動画だと最新のchatgptはいいみたいだよ

**デフォルトの名無しさん** · 2024/11/13(水) 19:43:07.11

コードの生成なら Claude ai にしておけって。

**デフォルトの名無しさん** · 2024/11/14(木) 00:17:38.18

>>815
こないだ試してみたら、さほど良くなってないみたいだったが。

**デフォルトの名無しさん** · 2024/11/14(木) 04:49:13.06

Claude ai 無料でも有能で笑った

**デフォルトの名無しさん** · 2024/11/14(木) 09:48:02.77

>>817
それはバージョン o1 だった？

**デフォルトの名無しさん** · 2024/11/14(木) 17:17:13.60

>>819
ChatGPTではなく、OpenAI o1 のことかいな?

**デフォルトの名無しさん** · 2024/11/14(木) 20:42:25.26

すまん、違うものだったか
孫さんの動画でGPTの次のバージョンのような扱いしてたので同じかと思ってた

**デフォルトの名無しさん** · 2024/11/16(土) 05:20:14.39

アメリカ政府が「安全な言語を強制する」姿勢は、
「規制」だね。それによりC/C++だけが排除される。
ずる賢い連中だ。日本の半導体もそれで駄目になった。

**デフォルトの名無しさん** · 2024/11/16(土) 06:03:12.01

>>822
C/C++のようなクズ言語は早く消えたほうがいい
今はZigやRustなど代替できる良い言語が色々ある

**デフォルトの名無しさん** · 2024/11/16(土) 06:40:57.58

時間ライブラリ、chrono使いにくいなーと思ってtimeに乗り換えたけど
メンテ状態がいまいちだし、変な仕様がいくつもあるなーと悩んでた

今日 jiff を見つけて試してみたら、とても使いやすい
設計のベースがjsのTemporalということもあり、変な独自仕様が少なそう
作者が有名人だし、今後も期待できる
ただちょっとバイナリサイズが大きめかな

**デフォルトの名無しさん** · 2024/11/16(土) 09:37:53.01

>>822
規制と言うより新陳代謝。
c/c++にいくら新機能入れても無理が来てる。
ライブラリの都合上まだ仕方なく使ってるけど。徐々に置き換わって行くよ。

**デフォルトの名無しさん** · 2024/11/16(土) 14:25:13.85

プロが一番使っている言語であるところのC/C++だけが、
アメリカ当局の鶴の一声で潰されようとしている。

**デフォルトの名無しさん** · 2024/11/16(土) 14:55:20.01

欠陥言語C/C++が一掃されるのは良いこと
無知と怠惰が欠陥言語にしがみつく

**デフォルトの名無しさん** · 2024/11/16(土) 15:50:00.42

市場やソフトウェア業界のプログラマや個々の経営者が決める
べきであり、政府が強制すべきではない。

**デフォルトの名無しさん** · 2024/11/16(土) 16:25:18.89

サイコパスは「痛みを伴う失敗」から学習できない！
2024.11.15
nazology.kusuguru.co.jp/archives/165730
「パワハラ上司が生き残る条件」みんな●●だった！
2024.07.12
nazology.net/archives/156599

**デフォルトの名無しさん** · 2024/11/16(土) 16:50:05.47

>>828
アメリカ政府は顧客のひとつとして Rust の積極的導入を要望しているのであって市場に対する規制なんてしてないよ。
結果的に影響力が大きくはあるけどな。

**デフォルトの名無しさん** · 2024/11/16(土) 16:59:51.39

>>830
「メモリー安全で無い言語は使うべきではない」
などと言ったそうだが。

**デフォルトの名無しさん** · 2024/11/16(土) 18:31:49.86

欠陥言語使わないといけない世界は改善したほうが良い

**デフォルトの名無しさん** · 2024/11/16(土) 18:48:21.70

>>828
別に法律で何時までにどうしろと決めたわけでもないので好きにすればいいけど、技術力が無い会社は置いてかれる、それだけの事よ。

**デフォルトの名無しさん** · 2024/11/16(土) 20:55:43.27

全盛を極めていたプログラミング言語たちが情勢の変化により落ちていった
今回はC++の番

**デフォルトの名無しさん** · 2024/11/16(土) 21:01:25.26

特定の言語使うことを技術力と思うのは勘違いな
たいした価値を生まない

**デフォルトの名無しさん** · 2024/11/16(土) 21:26:15.37

Rustの採用って実のところ、既存の資産を捨ててゼロベースで書く、キャッチアップのためにコストをかける (慣れてる言語よりも時間がかかることを許容する) とかの思い切りの問題だと思う

**デフォルトの名無しさん** · 2024/11/16(土) 21:37:25.08

それはそう。
C++ が良い言語ではないことに C++ の設計者は自覚的で、それでもなお「今」目の前にある問題に対処可能であることを理念にしてる。
まだ不十分だけど良い言語だなんてのは実務者にはなんの救いにもならない。
汚くてもなんとかする方法はあるほうがありがたい。
ただ、無限に汚くなり続けることは許容できないのだから、どこかで新しいものが生まれてリセットする必要はあって今がその時なんだろう。
でもまあ現実に使われるものは汚いものだよ。
だって現実が汚いものだから。
Rust もいずれ汚くなって次のなにかに置き換わる。
それが半世紀くらい後だとよいね。

**デフォルトの名無しさん** · 2024/11/16(土) 22:52:16.06

C/C++しか使えないダメ人間だと他の言語に手を出したり習得したりするハードルも高くそんなスキルもないんだな
普通に色んな種類の言語をやってきていればすぐに対応できるようになる

**デフォルトの名無しさん** · 2024/11/17(日) 00:10:11.34

C/C++ を「ちゃんと」使えているならかなり能力は高いはず。
あの無茶苦茶なのを把握してるわけだからな。
でもちゃんと理解せずに使っているやつもそれなりに多いのもそう。

**デフォルトの名無しさん** · 2024/11/17(日) 01:01:11.07

アメリカ政府がRustが欠陥言語であることに気づいて無いだけだ。

**デフォルトの名無しさん** · 2024/11/17(日) 09:50:13.04

>>840
欠陥の無い言語教えれ

**デフォルトの名無しさん** · 2024/11/17(日) 10:45:30.77

RustはCの置き換えには最適だが
C++からRustはノーチャンス

**デフォルトの名無しさん** · 2024/11/17(日) 11:09:03.35

>>842
過去資産を除くと
C++の利点は無いと思う

**デフォルトの名無しさん** · 2024/11/17(日) 12:57:50.30

>>843
まあその過去資産がクソデカだって話なんだけどな。

**デフォルトの名無しさん** · 2024/11/17(日) 13:22:59.92

現実的なことを言うとRustの仕事は多くないからな
世の中的にはC++の方が多いし、それよりもC#やJava、JavascriptやPythonの方が多い
現状Rustを書ける人が少ないから組織としても採用しづらい、みたいなところもある

**デフォルトの名無しさん** · 2024/11/17(日) 14:04:38.06

Rustは欠陥が多すぎる。

**デフォルトの名無しさん** · 2024/11/17(日) 14:14:43.13

>>846
C++と比べても桁違いに欠陥ない

**デフォルトの名無しさん** · 2024/11/17(日) 14:17:04.13

>>342
>RustはCの置き換えには最適だが
そんなことない。むしろ置き換えに適さない。

>>843
そんなことない。

**デフォルトの名無しさん** · 2024/11/17(日) 16:20:28.69

Rust に (まだ) 足りないものはあるという意味では欠陥はあるが、設計が間違ってて改善の余地がないような欠陥は少ないだろ。
C の場当たり過ぎる設計に比べれば Rust はだいぶん綺麗だわ。

**デフォルトの名無しさん** · 2024/11/17(日) 17:47:06.07

C++は多段に増築して要らないものも多く
新しい仕様は良いけど広まっていなくて
標準ライブラリのインターフェイスを新たな仕様にすることもできなくて
初心者にとってC++はRustの何倍も複雑で学習難易度も高いのよ
Rustはシンプルに高機能でプログラミング効率もいいね

**デフォルトの名無しさん** · 2024/11/17(日) 21:11:05.44

C++はBoostあたりまでは良かったけどそれ以降は機能のゴミ箱
上品な言い方をすればキッチンシンク担当になった

**デフォルトの名無しさん** · 2024/11/17(日) 21:56:59.22

>>849
そうでもない。

**デフォルトの名無しさん** · 2024/11/17(日) 22:25:57.84

mordern c+で随分楽になったけど

**デフォルトの名無しさん** · 2024/11/17(日) 22:26:17.33

modern

**デフォルトの名無しさん** · 2024/11/17(日) 22:37:46.32

CをRustで置き換えたら劇遅になるから重要な部分は無理じゃね

**デフォルトの名無しさん** · 2024/11/17(日) 22:55:33.70

>>855
デバイスドライバを両方で実装して速度がほぼ変わらないことが立証されている

**デフォルトの名無しさん** · 2024/11/17(日) 23:02:46.96

>>856
それは、一般にデバイスドライバはシンプルなアルゴリズムしか使ってないからだよ。

**デフォルトの名無しさん** · 2024/11/17(日) 23:11:47.34

同じアルゴリズムでRustが遅い例プリーズ

**デフォルトの名無しさん** · 2024/11/17(日) 23:14:29.54

>>858
unsafeを使わない限り、ほとんどのアルゴリズムがそれに当たる。
なぜなら、ほとんどのアルゴリズムが使えないから。

**デフォルトの名無しさん** · 2024/11/17(日) 23:19:43.73

>>859
ウソつき

**デフォルトの名無しさん** · 2024/11/17(日) 23:25:29.83

安全側に寄せる部分でRustの方が基本的にコストかかるんじゃないの？
グローバルな可変状態はMutexが無いと書けない (アクセスの度にロックが必要) とか、Cellは実行時に借用チェックするとか、配列は基本的に範囲チェックされるとか

コンパイラは利用側を知り得ない (複数スレッドから呼ばれる可能性があると想定せざるを得ない) からMutexが必要だけど実際は無いと想定して良い、みたいなケースはありそう

**デフォルトの名無しさん** · 2024/11/17(日) 23:28:19.03

>>860
あなたも含めたここの連中は理解力が低い。
なお、俺には丁寧に説明する義務は無い。理解できない人はそのままでいい。
俺には関係無い。

**デフォルトの名無しさん** · 2024/11/17(日) 23:34:51.20

>>859
unsafe使えば同等になるなら、どこかの誰かさん以外はRustが遅いとは思わないのでは？
とりま、unsafe使わない遅いコードさらしてみては？

ここの優秀な方々が「unsafeでもこうすればCと同等の速さだ！」ってコードを返してくれるかもしれん。

**デフォルトの名無しさん** · 2024/11/17(日) 23:37:27.94

>>861
そこはどの言語でも同じ
スレッドローカル変数を使う
RustでもMutexの必要はない

**デフォルトの名無しさん** · 2024/11/17(日) 23:41:13.09

他のレスに「あなたは正しくない」とだけ書けば自分が賢いということになるなら、それほど楽なことは無いな
スマホさえ持ってれば小学生でも同じことはできるわけだし

**デフォルトの名無しさん** · 2024/11/17(日) 23:53:16.59

100点オジと複オジはいつまでたっても進歩がないな

**デフォルトの名無しさん** · 2024/11/18(月) 00:24:33.99

基礎的なデータ構造に unsafe が必要になるのは本当だ。
基礎は std で提供されるのでその上では unsafe の仕様が少なくなるように巧妙に設計されている。
std を使えないときに std と同等なものを作らなければならないような状況だと C とあまり差はない。
逆に言えば unsafe を含む下回りをかっちり作りさえすれば Rust のほうが優秀だよ。

**デフォルトの名無しさん** · 2024/11/18(月) 02:14:46.19

あゝこんなときRustにもextern "C"があれば平和が訪れるのに

**デフォルトの名無しさん** · 2024/11/18(月) 04:44:45.38

>>840
「欠陥のない言語は存在しない。だがデバッグの不可能な言語もまた存在しない」

**デフォルトの名無しさん** · 2024/11/18(月) 07:01:58.78

おれの作った言語はデバッグ機能ないけど？

**デフォルトの名無しさん** · 2024/11/18(月) 07:06:12.01

【ナゾロジー】サイコパスは「痛みを伴う失敗」から学習できない！ [すらいむ★]
http://itest.5ch.net/egg/test/read.cgi/scienceplus/1731838156

**デフォルトの名無しさん** · 2024/11/18(月) 08:33:03.50

>>868
あるやる

**デフォルトの名無しさん** · 2024/11/18(月) 09:04:25.28

>>867
>逆に言えば unsafe を含む下回りをかっちり作りさえすれば Rust のほうが優秀だよ。
そんなことない。
unsafeがライブラリ関数の外に染み出てくるから。

**デフォルトの名無しさん** · 2024/11/18(月) 09:13:51.03

>>865
ここに書かないのは、「企業秘密的」な意味も有るんだよ。

**デフォルトの名無しさん** · 2024/11/18(月) 09:30:27.68

>>862
競プロでもやってんの？

**デフォルトの名無しさん** · 2024/11/18(月) 09:41:47.81

>>873
RustがC/C++に勝利した一番大きな要因は
メモリ操作など基本的にunsafeにたどり着く様々な操作を
中身でunsafeを使っていてもそれを外へ染み出さないsafeなインターフェイスを提供して実用的に使えることを示した点にある
これがRustの標準ライブラリの中核であり
同様にしてunsafeが外へ染み出さないsafeなライブラリを作ることもできる

**デフォルトの名無しさん** · 2024/11/18(月) 10:43:14.43

>>876
馬鹿発見。

**デフォルトの名無しさん** · 2024/11/18(月) 12:57:29.84

>>873
unsafeの何が悪い
unsafe{
下回りもunsafe
利用者側もunsafe
皆で使おうunsafe
}

**デフォルトの名無しさん** · 2024/11/18(月) 13:58:30.56

unsafeが染み出すとか言っているの本気？
意図的に出さないと出てこないよ？

// 意図的なunsafe
pub unsafe fn dangerous_operation() {
// 何らかの危険な操作
}

// 利用者側
unsafe {
dangerous_operation(); // ここでunsafeが必要
}

普通はこう書く

// ライブラリ側
pub fn safe_wrapper() {
unsafe {
// 内部で危険な操作を行うが、
// 安全性を保証する条件をすべて満たしている
}
}

// 利用者側
safe_wrapper(); // unsafeは不要

**デフォルトの名無しさん** · 2024/11/18(月) 20:31:59.79

>>877
事実を目の当たりにして具体的な反論や反例を出せない気苦労は理解するが
それでも具体的にRustのコードを示すのがよいかと

**デフォルトの名無しさん** · 2024/11/18(月) 21:05:40.46

>>874
説明は求めないけどね？
「自分は知ってるが説明する義理はない」なんて第三者からみれば「俺は分かりません説明できないです」と書くのと変わらないじゃない
分からないならスルーすればいいのに、それをわざわざ書くのはダサくない？

**デフォルトの名無しさん** · 2024/11/18(月) 21:41:56.71

実際にはunsafe使わないRustはCよりもいくらかオーバーヘッドが生じるとは思う
Cでなポインタのコピーで済むけどsafe RustだとArcが必要だからcloneの際にロックのコストがかかるとか、配列へのインデックスでのアクセスで境界チェックされるとか
Rustでは安全側に寄せる分のコストはかかるはず