Rust part25

**デフォルトの名無しさん** · 2024/07/31(水) 00:46:26.17

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

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

**デフォルトの名無しさん** · 2024/09/07(土) 10:03:49.93

チューニングするなら結局境界検査とかオフにすることになるしなぁ

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

低レイヤ、ベアメタルってのも何故か一連のRust関連スレで見かける印象

**デフォルトの名無しさん** · 2024/09/07(土) 10:37:53.70

>>757
レスバトラーなら絶対言うだろうなと思ったら案の定で笑っちゃった

**デフォルトの名無しさん** · 2024/09/07(土) 11:14:10.87

>>761
境界検査は不要なところではそもそも行われないのでそんなことする必要がない
例えば回数的にほとんどのケースはループ内だがそれはループの終端検査に集約されるため消える

**デフォルトの名無しさん** · 2024/09/07(土) 11:33:41.32

ランダムアクセスは思ったより少ないけど必要なところでは性能的に割とシビアなことも多いぞ。

**デフォルトの名無しさん** · 2024/09/07(土) 11:44:43.13

>>757
その反論するならまず
「著作物のGPL配布には『著作権上コンパイルは翻訳として扱われる』ことを否定する要因がある」
ことを明らかにしなきゃ話にならんわな。

そもそも>747で「GPLに限定した話は知らんけど」と言っているのにその反論は無能すぎるかと。

**デフォルトの名無しさん** · 2024/09/07(土) 11:58:50.25

>>760
unsafeだからですよ

**デフォルトの名無しさん** · 2024/09/07(土) 12:14:44.55

>>759,760,767

Rust書き換えに裏の目的があったとはね

低レイヤRustプロジェクトの数は少なくて
更にわざわざRust使ってますアピールするから
絞り込んだら見つかるかもしれない

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

C++とCがまるで嫁と姑のように同居する設計はLinuxに採用されなかった
Rustなら同居にはならない
本来の目的はそんな感じだろう

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

LinusがC++を嫌ってるのはCとの関係性でなくC++独自の部分だと思うぞ
「レベルの低い開発者がクラスとかオブジェクトを使ってどうしようもない壊れたコードを容易に作れる」といった感じだったと思う
これはC++ 11すら登場してない時代の批判だから、今も同じように思うかどうかは分からないけど
あと「C++の例外機構はカーネル開発に向かない」というのもあって、これは今も同じだと思う

**デフォルトの名無しさん** · 2024/09/07(土) 13:45:37.17

RustやGoなどの例外ではなくエラー値を返していくやり方いいね

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

返されたエラー値をスルーする事例が多発したから例外が作られたと思う
Rustはmust_useがあるけどGoはよく分からん（特に戻り値がエラーだけの関数）

**デフォルトの名無しさん** · 2024/09/07(土) 14:10:48.96

ハイプ期に流行った言説をいつまでも言い続けていくこの感じ

**デフォルトの名無しさん** · 2024/09/07(土) 14:34:40.97

東京オリンピック、大阪万博、不動産バブル

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

>>763>>766
スレ違うだし判例無いならもういいよ

**デフォルトの名無しさん** · 2024/09/07(土) 16:51:05.14

ゲームサーバーもRustで書く時代か

> 業務内容
> 経験・志向に応じて、以下のような分野でお仕事をしていただきます。
> ・ゲームサーバー構築およびバックエンド開発(Rust、C++、etc)
> ・運用補助のためのフロントエンドおよびバックエンド開発(Rust、React、TypeScript、etc)

> 今までゲームサーバーの開発ではC++がメインでしたが、近年少しずつRustに移行しつつあります。
> 実績としてARMORED COREⅥのゲームサーバーはRustで作られ、稼働しています。
> Rust、C++のいずれかの経験者を歓迎していますが、他の言語経験者でRust、C++に興味ある方も歓迎しております。

**デフォルトの名無しさん** · 2024/09/07(土) 17:01:27.84

ゲームサーバーは低レイヤRustプロジェクトじゃないから
Linux等からのGPLロンダリングは関係なさそうだね

低レイヤ、ベアメタル、Rustがポイントなのかな？

**デフォルトの名無しさん** · 2024/09/07(土) 18:01:33.85

>>775
判例という難しそうな言葉を使いたいお年頃なのね

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

>>778
お前のお気持ち表明に何の意味も無いのよ

**デフォルトの名無しさん** · 2024/09/07(土) 18:41:33.85

表明されたエラーを無視されない確実な方法はプロセス全体を終了すること
終了を回避する方法があれば無視される可能性がある

**デフォルトの名無しさん** · 2024/09/07(土) 18:57:47.65

>>775
判例は>>756。
GPLの著作物と違いから無いからそのまま適用可能。

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

逆コンパイルとGPLプログラム見たことがある人がプログラム書く行為が同じってマジ？

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

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

なぜ実験すればいいと思った
自分は科学的だと思ってるのかな
科学って暴走するんだな

**デフォルトの名無しさん** · 2024/09/07(土) 23:03:30.32

>>782
んなわけない
逆コンパイルはコンパイルに近い扱い

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

当たり前だが「見た == パクった」とはならない

ただ万が一の訴訟リスクも避けたいなら
GPLのソースを見て仕様を起こす組織/人間と
GPLのソースを見ず起こされた仕様をもとに
コードを書く組織/人間を完全に分けておけばよい
これで完全にパクリを否定できる

**デフォルトの名無しさん** · 2024/09/08(日) 00:01:36.02

そもそも、特許取れてないものをパクることは、歴史的には許されてきた。
また、著作権法も契約も、作家や著作権者が作品を売って暮らしていけることを目的と
していたものであり、GPLのように社会全体を構造的に変化させることを目的としたものでは
なく、法令の目的外使用と言える。

**デフォルトの名無しさん** · 2024/09/08(日) 02:29:49.31

パソコンのキーボードでフリック入力できるものはありますか？

**デフォルトの名無しさん** · 2024/09/08(日) 07:57:18.94

相場が乱高下することは許される
ということは昨日は無罪だったものが今日は有罪になっても
相場が間違っていることにならない

**デフォルトの名無しさん** · 2024/09/08(日) 21:59:24.16

shared_ptrはRustではArcだと思うけどこれ本当？

447 デフォルトの名無しさん 2024/09/07(土) 20:17
むしろshared_ptr<T>でスレッド間共有オブジェクトを保持するのは
生ポに対するshared_ptr<T>のメリットが無い……
可能な限りスレッド間共有なんてことはやめてconstオブジェクトのコピーにするのが正義……

**デフォルトの名無しさん** · 2024/09/08(日) 22:20:14.30

C++スレでやれって感じだけど、自分ははその説明は適切でないと思う
shared_ptrを使う理由はちゃんとある
寿命を適切に管理してるなら片方がunique_ptr等で所有して他方に生ポインタ渡すのも駄目ではない

可能ならデータ共有よりもスレッドごとに所有させる方が安全というのは分かるけど、共有が必要な場面って普通にあるはず

**デフォルトの名無しさん** · 2024/09/08(日) 23:25:28.71

>>791
スレッドの寿命に依存するからunique_ptr使用でポインタ渡しはリスキーだね
Rustならthread::scopeで安全に参照を渡せる
もちろんArcを使うのもよくて
追加コストはclone時と終える時の加減算
スレッド内での参照にコストはかからないからArcを避ける必要はない

**デフォルトの名無しさん** · 2024/09/08(日) 23:59:54.41

自分も推奨とまでは思ってなくて、「寿命の問題がないことが明らかであれば許容する」くらいの感じで書いた
クラスのコンストラクタでスレッド立ち上げて、デストラクタの中でjoinするような作り (よくあると思う) ならスレッドの寿命 < 参照先のデータの寿命は明らかだし
shared_ptrの方が意図は分かりやすいとは思うけど、必須までとは思わない

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

std::thread::scope()は必然的にそういう挙動になるな
終了時のjoinが保証されるからスレッドの寿命 < 参照先のデータの寿命になる

実際の例は
https://doc.rust-lang.org/stable/std/thread/fn.scope.html
のExample参照

**デフォルトの名無しさん** · 2024/09/09(月) 05:07:18.49

>>792
>寿命を適切に管理してるなら
って描いてあるだろ

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

>>795
その考え方が既に詰んでいる
もし寿命を適切に管理できるならunique_ptrもRustも不要
しかし人間が100%適切に管理することは不可能だからC++でunique_ptr等が導入された
そしてさらにRust言語が導入された

**デフォルトの名無しさん** · 2024/09/09(月) 08:08:18.92

寿命を適切に管理できる時はあるんだけど、そうであるかそうでないかの境界くらいなコードをうっかり受け入れてしまうとその後ずっと負債になるんだよな

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

でもここでRustを持ち上げている一定数は
RustでGPLロンダリングしていると吹聴しているレベル

低レイヤ、ベアメタル、Rustってのがポイントみたい

**デフォルトの名無しさん** · 2024/09/09(月) 08:59:39.68

どうあっても完璧にはならないという前提で、ちょいちょいリファクタリングするくらいの運用ができればいいんだけどな。
ワヤになることがあっても戻せば少なくとも動きはするし。

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

またC++知らん人が出て来たでおじゃる

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

C++のスマートポインタは分かってる分かってないもあるがTの型や使われ方によって考えること多すぎて元々キツイやろ
Rustは継承無くしたり所有権複雑にしたことでスマートポインタの様々な機能が可能な限り単一責任に分散されててスッキリしてる
考えた奴の努力凄えと思う

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

あっちのスレﾜｯﾁｮｲ付いてるからわざわざこっちに持ってきたの？

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

Rust プログラミング 1 (全 5 回)
watch?v=6AiU6ncdUdk
出演
低レイヤーガール 1: 自作 OS を Rust で書いている
低レイヤーガール 2: 自作 browser を Rust で書いている

**デフォルトの名無しさん** · 2024/09/09(月) 21:35:49.10

>>801
継承の有無は関係なくて
C++ではヒープの解放責任が対象で
Rustはそれに加えてヒープかスタック上かに関わらず参照の有効性が対象

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

>>804
ArcやRcってスタックのデータを指せるっけ？
基本的にヒープに確保されると思ってた

**デフォルトの名無しさん** · 2024/09/09(月) 23:57:57.19

Rc/Arcは確保したヒープの解放責任者数だけをカウントしている
解放責任者数がゼロになると解放する
参照している人の数はカウントしていない
参照がいくつ増えようがRc/Arcの内部のカウンターは変化しない
まずこの区別ができているかどうかが基礎かな

**デフォルトの名無しさん** · 2024/09/10(火) 00:00:07.29

そしてスタック上のTであろうがヒープに確保したBox<T>やRc<T>であろうが
そのT部分への参照は同じ&T型となりその値は(スライスなどを除いて)アドレス値のみで構成される
そこでスタック領域かヒープ領域かの区別はない

そしてそこには参照のカウント値は当然なくてライフタイム値も存在しない
参照の有無やライフタイムの妥当性はコンパイル時のみ把握されて問題があればコンパイル時にエラーとなる

**デフォルトの名無しさん** · 2024/09/10(火) 11:45:49.01

>>804
すまんその通りや
継承関係ないわw
C++だとスマートポインタにするか生ポインタをクラスに隠すかみたいなことが頭をよぎってあぁぁぁってなるのよ

**デフォルトの名無しさん** · 2024/09/10(火) 13:35:20.41

>そこでスタック領域かヒープ領域かの区別はない

これもコンパイル時のみの話では

**デフォルトの名無しさん** · 2024/09/10(火) 18:55:33.96

参照があるかないかライフタイムを満たしているかといった情報はコンパイルの時しか持たないけど
参照のアドレス値は実行時にも当然ある
ただしそれがヒープを指すかスタックを指すかは把握できないから区別しない
そして区別しなくてもよい方法をRustは導入した

**デフォルトの名無しさん** · 2024/09/10(火) 18:58:00.79

なぜどちらを指しているか把握できないのか？
それは次のようなコードも書けるため

fn bigger<'a: 'c, 'b: 'c, 'c, T: PartialOrd + ?Sized>(x: &'a T, y: &'b T) -> &'c T {
if x > y { x } else { y }
}

二つの引数にヒープを指す参照とスタックを指す参照を渡した場合
関数から返ってくる参照がどちらなのかは各実行毎のデータが揃うまでわからない
そして実は参照が指す領域がどちらなのかを把握する必要がないのが結論
ライフタイムさえ満たしていれば区別する必要がなくなった

**デフォルトの名無しさん** · 2024/09/10(火) 20:21:44.39

なるほど

**デフォルトの名無しさん** · 2024/09/10(火) 21:08:40.00

>>805の疑問とは何の関係もないよね
騙されてるやつが訳1名いるみたいでご愁傷様だけど

**デフォルトの名無しさん** · 2024/09/10(火) 21:31:43.71

Rcは参照の数を管理するものではない
Rcはヒープ領域を確実に解放するためにその所有者の数を管理する
当然Rcはヒープ領域だけを扱う
スタック領域はRAIIで確実に解放される

**デフォルトの名無しさん** · 2024/09/10(火) 22:01:22.00

誰かがArc/Rcはborrowの数を管理してると言ってる？
文脈によって意味が変わる「参照」とか「reference」という言葉を勘違いしてるだけじゃない？

Arc/Rcはreference counting pointerなんだから当然参照の数は管理してる
同じアロケーションを参照してるowning pointerの数を管理してる

**デフォルトの名無しさん** · 2024/09/10(火) 22:08:07.24

Rcのソースコード解説あったわ。
qiita.com/qnighy/items/5b2fbf27e3ee36e57b8d

誰かソースコード読んだ？

**デフォルトの名無しさん** · 2024/09/10(火) 22:23:36.52

>>815
そんな言葉遊びをして混乱させるのはよくない
Rustで参照といったらTに対する&T
一方でRcはヒープ解放責任の所有者を複数可にする
参照が複数あることと所有者が複数あることは全く別なのでこの違いをはっきりさせて理解するのが正しい

**デフォルトの名無しさん** · 2024/09/10(火) 23:01:44.78

>>817
The BookやRcの公式ドキュメントにも書いてること
例えばThe Bookには「The Rc<T> type keeps track of the number of references to a value」と書いてある
つまり「Rustで参照といったらTに対する&T」とは限らない
文脈次第

>参照が複数あることと所有者が複数あることは全く別なのでこの違いをはっきりさせて理解するのが正しい
その区別ができてないレスとかあった？

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

Rc/Arcはヒープの解放責任者が複数になるときに対応するものだが
>>805が「ArcやRcってスタックのデータを指せるっけ？」と言い出したのでちょっと怪しい

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

それで言うなら>>804のほうが明らかに言葉足りてないがなあ
まあよく分からんなら反応すんなってこった

**デフォルトの名無しさん** · 2024/09/10(火) 23:22:45.87

RcはC++にないけどArcがC++のshared_ptrだよ
だから複数所有者については新規性がなくて
Rustが強いのはスタック上かヒープ上かに関係なく両者への参照を混ぜても安全に扱えるようになったことだよ
これでスタック上の活用の幅が広がりさらに速くなった

**デフォルトの名無しさん** · 2024/09/10(火) 23:33:27.03

>>805は元々の認識の方が合ってて、>>804の説明で混乱したと思われる

**デフォルトの名無しさん** · 2024/09/10(火) 23:38:50.48

複オジの読解力不足&的外れはいつものことだろ
騙されるやつにも問題あるんだからもうほっとけよ

**デフォルトの名無しさん** · 2024/09/10(火) 23:41:27.35

C++ではヒープの解放責任が安全性の対象だった
Rustはそれに加えて複数の安全性を導入している
ヒープかスタック上かに関わらずそれらへの参照の有効安全性がその一つ

**デフォルトの名無しさん** · 2024/09/10(火) 23:48:29.99

真正アスペかな

**デフォルトの名無しさん** · 2024/09/10(火) 23:49:26.48

造語してる暇があったらちゃんとイチからC++学ぼうや、じゃないと他人に伝わる言葉で比較することもできんやろ

いや、別にできなくてもいいのか、なんとなくそれっぽい感じのこと書けるならそれで

**デフォルトの名無しさん** · 2024/09/10(火) 23:56:12.12

C/C++がダメなところでもっと重要な点はsingle writer xor multi readersのデータ競合安全性がないところだろ
例えばこれ

std::vector<int> v{0, 1, 2, 3, 4, 5, 6, 7};
int *p5 = &v[5];
assert(v[5] == 5); // OK

*p5 = 123;
assert(v[5] == 123); // OK

v.push_back(8);

*p5 = 456; // p5がまだ使えるので使おうとすると
assert(v[5] == 456); // NG このアサートは通らない

**デフォルトの名無しさん** · 2024/09/11(水) 00:27:46.41

１つのTの値に対するRc<T>はcloneすることで複数存在できるけど
特定のRc<T>を介したその値の参照（&T）はそのRc<T>の生存期間しか使えない
この&Tもいくらでもコピーできるけど同じRc<T>の生存期間に縛られる

T（ヒープ）
↑
Rc<T>（主にスタック上だけどヒープも可）
↑
&T（同上）

みたいに二段階で参照してて
TはRc<T>が全部消えるまで残り続けるけど
&Tは仲介してる特定のRc<T>が存在する間しか使えない

C++のshared_ptrに近いけど使われ方（コピーor複製の戦略）は微妙に変わるかもしれない

**デフォルトの名無しさん** · 2024/09/11(水) 00:51:54.05

>>828
正確にはRc<T>のDerefにより生じる&TがTを直接指すので参照を使うコストや利便性は普通の&Tと同じコストゼロ
そのDerefの時にRc<T>を借用しているため&Tはそれより長生きできず安全性が保たれる
C++で例えるとshared_ptr.get()で直接ポインタを取り出したのと同じなのでカウンタ増減もなくコストはかからない
C++でこれはリスクの高い要注意の行為だがRustでは上述のように安全性とコストゼロを両立させている

**デフォルトの名無しさん** · 2024/09/11(水) 01:53:23.49

声かけで特殊”複”詐欺を未然に防止
5ch有志らに感謝状

**デフォルトの名無しさん** · 2024/09/11(水) 07:05:44.53

>>827
vectorにpush_backして再配置でアドレス変わったんだから当たり前でしょ。それが嫌ならstd::listでも使えば

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

>>831
Rustではコンパイルエラーとなって未然に防いでくれるから
C++の欠陥の一つだと思うよ

**デフォルトの名無しさん** · 2024/09/11(水) 08:14:31.51

>>832
まともなプログラマはこんな処理書かねーよ
もっとありそうな例だしてくれないかな

**デフォルトの名無しさん** · 2024/09/11(水) 08:40:17.21

しかもasan出て久しいのに、この人ら>>827,832 時間止まってる?

**デフォルトの名無しさん** · 2024/09/11(水) 08:58:17.83

>>827は簡単な例だからデータ競合を起こしてp5がダングリングポインタとなってることに気づくけど
もっと複雑な状況だと気づかずに実行してしまいデバッグでハマるパターンでもある
それをコンパイル時点で指摘してくれるRustは開発効率いいね

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

>>835
本当にsanitizer知らないレベルだと言語以前の問題
全てが効率悪そう

とんでもないスキルイシューの塊だから
RustでGPLロンダリングしていると吹聴するレベルなんだな

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

C++はそういう欠陥言語だから仕方ないかと

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

Rustは安全でC++は危険というきれいな比較図式が成り立たなくなるので、C++さんサイドは静的解析だの動的解析だの姑息な手段を使わないでください
同じ理由でunsafe Rustも自分で書くのは禁止です

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

「RustでGPLロンダリング」するのも禁止です

「RustでGPLロンダリング」と検索するのも禁止です

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

>>827
C++コンパイラはpushの後になぜp5を無効にできないの？

**デフォルトの名無しさん** · 2024/09/11(水) 10:26:06.00

予めreserveしてpush_back後も安全にアクセス出来る

**デフォルトの名無しさん** · 2024/09/11(水) 10:27:11.35

>「RustでGPLロンダリング」するのも禁止です

こっちは茶化すなよw

**デフォルトの名無しさん** · 2024/09/11(水) 10:30:47.07

それpushしまくってる途中でreserve超えてvectorが再配置されてダングリングになるバッドパターン

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

「境界検査は不要」とか「ループの終端検査に集約されるため消える」とか嘘バラまいてる奴が一番unsafeだよねー>>843

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

落とし穴だらけのC++

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

死ぬまでｾﾌｾﾌやってんのん

**デフォルトの名無しさん** · 2024/09/11(水) 12:23:08.35

808ですが
>>804の指摘は間違っていることに気づきました
ごめん…

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

>>847
どこが間違ってる？

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

人として間違ってる

**デフォルトの名無しさん** · 2024/09/11(水) 18:25:07.18

次スレよろ

**デフォルトの名無しさん** · 2024/09/12(木) 12:20:06.38

Rust の borrow を日本語で参照と
逝ってる人が多いのは木の精か

**デフォルトの名無しさん** · 2024/09/12(木) 12:20:42.74

木の精だな

**デフォルトの名無しさん** · 2024/09/12(木) 13:28:12.61

Primitive Type reference &T and &mut T
https://doc.rust-lang.org/std/primitive.reference.html
A reference represents a borrow of some owned value.
You can get one by using the & or &mut operators on a value, or by using a ref or ref mut pattern.
References have a lifetime attached to them, which represents the scope for which the borrow is valid.

**デフォルトの名無しさん** · 2024/09/12(木) 15:10:13.30

borrow は貸借

**デフォルトの名無しさん** · 2024/09/12(木) 16:35:38.17

いちいち漢語使うなよ
貸す、借りるでいいだろ

**デフォルトの名無しさん** · 2024/09/12(木) 16:59:56.29

borrow は桁借り

警備員[Lv.5][新芽] · 2024/09/12(木) 21:13:06.55

借りてboroboro。70年代のネタあるね

**デフォルトの名無しさん** · 2024/09/12(木) 21:33:10.32

Rustを学習していてよくわからなくて、大きく2点について教えて欲しいんだけどさ
1 参照型で含まれるポインタ相当部分を可変、参照先のデータを不変にすることってできるの？
2 構造体Aのフィールドに構造体Bがあるようなとき、(I)A可変・B不変だった場合、(II)A不変・B可変だった場合、それぞれどの範囲で可変・不変になるの？

**デフォルトの名無しさん** · 2024/09/12(木) 22:20:10.46

>>858
1. できる
let vec = vec![];
let mut xs= &vec;
xs.push(100); // Error

let vec2 = vec![1, 2, 3];
xs = &vec2; // OK

**デフォルトの名無しさん** · 2024/09/12(木) 22:39:45.93

>>858
2. 変数のmutabilityはownership treeの最上位にある変数(owner)のmutabilityに従う
なのでAが可変ならBも可変、Aが不変ならBも不変
ただし、RefCell等のinterior mutabilityの仕組みを使えばAが不変でもBを変更することは可能

&Tと&mut Tという参照の型のmutabilityと
let mut xのような変数のmutabilityと関連はあるけど別のものなので分けて考えたほうがいい