問題タブ [interior-mutability]

ほとんどの場合、Rust の内部可変性に実行時チェックが必要な理由 (例: RefCell) について考えてきました。ランタイム コストのない安全な代替手段を見つけたようです。タイプを呼び出しましたSafeCell(主に、それは安全なラッパーであるためですUnsafeCell)。これにより、参照がエスケープされるリスクなしに、ラップされた値に任意の関数を適用できます。

このタイプは、次のように内部可変性に使用できます。

または以下と組み合わせてRc：

遊び場

1. このタイプの安全性/健全性の問題はありますか?
2. そうでない場合、このような型が内部可変性を実現する標準的な方法ではないのはなぜですか? RefCellランタイムチェックではなく、静的ライフタイムチェックを提供するのと同じくらい使いやすいようです。

書店で販売されている本のデータを保存structするBookとしましょう。何らかのデータ構造の多くの場所で参照する必要があるため (例: を使用Rc)、通常の方法では変更可能に借用することはできません。ただし、価格などの属性があり、オブジェクトがすでに未解決の参照を持っている後、初期化の後で入力する必要があります。

これまでのところ、これを行う 2 つの方法を考えることができますが、どちらにも欠点があります。

• 内部の可変性:が初期化されるときに、どのフィールドが初期化されるかBookなどのフィールド を指定します。後で、本の価格を決定するときに、代わりにtoを使用して、その値を取得できます。price: RefCell<Option<i32>>RefCell::new(Option::None)Bookborrow_mutpriceSome(10)borrow

  私の感覚では、一般的に、必要でない限り内部の可変性は避けたいと考えています。Optionこの手法は、価格が後になるまで値を持たないために必要な のため、少しぎこちなくもあります (そして、それを0or-1に設定すると、Rust らしくないように見えます)、場所に多くのmatches またはunwrapsが必要になります。価格がすでに入力されていることを論理的に確信している場合があります。

• 別のテーブル: 内部に価格をまったく保存しないBookで、別のデータ構造を作成して保存しprice_table: HashMap<Rc<Book>, i32>ます。価格が決定されたときにこのテーブルを作成して入力する関数を用意し、書籍の価格を知る必要があるか変更する必要があるすべての関数に参照によって (変更可能かどうかに関係なく) 渡します。

  私と同じように C のバックグラウンドをHashMap持っているため、 は速度とメモリの両方で不必要なオーバーヘッドのように感じます。これは、データが存在する自然な場所 (内部Book) を既に持っており、単純なポインター チェイスを介してアクセスできるようにする必要があるためです。この解決策は、 への参照である追加の引数を使用して、多くの関数を混乱させる必要があることも意味しますprice_table。

Rust では、これら 2 つの方法のどちらかが一般的により慣用的ですか、それともジレンマを回避する他のアプローチはありますか? は見Onceましたが、初期化時にどのように入力するかを知る必要があり、それがわからないため、それは私が望んでいるものではないと思いますprice。

もちろん、他のアプリケーションではi32、目的の属性を表す以外のタイプが必要になる場合があるため、一般的なケースを処理できるようにしたいと考えています。