問題タブ [lifetime-scoping]

次のようなコードがあります。これは、websocket から読み取り、JSON の結果を構造体に解析し、その構造体をVecバッファーにプッシュしようとします。ただし、構造体には有効期間があり、借用チェッカーは JSON 文字列の有効期間が不十分であると不平を言うため、コードはコンパイルに失敗します。

正確なエラーは、borrowed value [&resp_raw] does not live long enough.

借用チェッカーを満たすために、このコードをどのように再構成する必要があるのか​​ 疑問に思っています。ライフタイムを持つ構造体をパラメーターにプッシュする正しい方法は何Vecですか?

それとも、&'a str解析されたMyTypeものが実際にはまだ元の JSON 文字列への参照を保持しているため、これを安全に行う方法はありませんか?

Programming Rustの 465 ページには、コードと説明があります (強調は私が追加しました)。

用語集のタイプを変更しました。分析を並行して実行するには、呼び出し元は を実行して、ヒープに移動されたArc<GigabyteMap>へのスマート ポインターである を渡す必要があります。用語集.clone() を呼び出すと、全体ではなく、スマート ポインターのコピーが作成されます。これは、参照カウントをインクリメントすることになります。この変更により、参照の有効期間に依存しなくなるため、プログラムはコンパイルおよび実行されます。スレッドが を所有している限り、たとえ親スレッドが早期にベイル アウトしたとしても、マップは存続します。のデータは不変であるため、データ競合は発生しません。GigabyteMapArc::new(giga_map)ArcGigabyteMapArc<GigabyteMap>Arc

次のセクションでは、これをレーヨンで書き直したものを示します。

&GigabyteMapではなくレーヨンを使用するように書き直されたセクションで確認できますArc<GigabyteMap>。ただし、これがどのように機能するかについては説明していません。なぜレーヨンは必要ないのですArc<GigabyteMap>か? Rayon はどのようにして直接参照を受け入れることを回避しますか?

それで、私は Python で書いた文字列トークナイザーを Rust に移植することに取り組んでいますが、ライフタイムと構造体で乗り越えられないように見える問題に遭遇しました。

したがって、プロセスは基本的に次のとおりです。

1. ファイルの配列を取得する
2. 各ファイルをVec<String>トークンの
3. ユーザー aCounterとUnicase、それぞれからトークンの個々のインスタンスの数を取得するvec
4. そのカウントを他のデータとともに構造体に保存します
5. (将来) ファイルごとのデータと一緒に合計データを蓄積するために、一連の構造体に対して何らかの処理を行う

ただし、返そうとCorpusPartすると、ローカル変数を参照しようとしていると不平を言いますtokens。これにどのように対処できますか/対処する必要がありますか? 生涯アノテーションを追加しようとしましたが、わかりませんでした...

基本的に、 はもう必要ありませんが、カウンター用に含まれていた のVec<String>一部が必要です。String

どんな助けでも大歓迎です、ありがとう！

tokio::sync::mpsc::Senderタスクに入力を送信するタスク、tokio::sync::mpsc::Receiverタスクからの出力を受信するタスク、および最後に参加できるハンドルを使用して、Tokio タスクを管理する構造体を作成しようとしています。

これをコンパイルしようとすると、次のエラーが発生しB、他の 2 つの型パラメーターについても同様のエラーが発生します。

ライフタイムのどこに問題があるのか​​ 理解するのに苦労しています。私が理解しているように、寿命の問題は通常、十分に長く生きていない参照から発生しますが、参照を使用せずに値を移動しています。b、、rx_inputおよびtx_outputをクロージャに移動しtx_input、、、rx_outputおよびをhandle呼び出しスコープに保持します。この場合、コンパイラを満たす方法を知っている人はいますか?