Rust part20

**デフォルトの名無しさん** · 2023/03/03(金) 00:45:28.73

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

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

**デフォルトの名無しさん** · 2023/06/14(水) 23:43:12.09

構造体とか要unsafeとか何をしたいのかわからないが
上限を決めてもよい用途ならば
ヒープを使わずともArrayVec<u8, CAPACITY>がスタック上のみで動く

**デフォルトの名無しさん** · 2023/06/14(水) 23:49:13.19

データの一部だけ可変長とかブロック構造の個数が
可変(ブロックの中身は固定)とかね

**デフォルトの名無しさん** · 2023/06/14(水) 23:54:41.98

staticは消滅しないから実質参考にならんので無視して短い方をaとする
これは対象が2つだからであって
static 1
その他　2
ならその他2の長い方になると言う考えでいいのかな？

**デフォルトの名無しさん** · 2023/06/14(水) 23:58:17.85

もう何言ってんだよ

**デフォルトの名無しさん** · 2023/06/14(水) 23:59:42.49

>>655
ライフタイムに関しては&も&mutもcovariantなので違いはありません

**デフォルトの名無しさん** · 2023/06/15(木) 00:08:38.46

Tに対して&Tはcovariant
Tに対して&mut Tはinvariant

**デフォルトの名無しさん** · 2023/06/15(木) 08:25:03.26

>>547
OptionとOnceCellの違い

&Tを得ることをgetと呼ぶようになった
【Option】fn as_ref(&self) -> Option<&T>
【OnceCell】fn get(&self) -> Option<&T>

&mut Tを得ることをget_mutと呼ぶようになった
【Option】fn as_mut(&mut self) -> Option<&mut T>
【OnceCell】fn get_mut(&mut self) -> Option<&mut T>

空にしてTを得ることをtakeと呼ぶのは同じ
【Option】fn take(&mut self) -> Option<T>
【OnceCell】fn take(&mut self) -> Option<T>

空(default)を作成することをnewと呼ぶこともできるようになった
【Option】fn default() -> Option<T>
【OnceCell】fn default() -> OnceCell<T> または fn new() -> OnceCell<T>

**デフォルトの名無しさん** · 2023/06/15(木) 11:48:36.10

トヨタの車載OSってRUSTなんだ

**デフォルトの名無しさん** · 2023/06/15(木) 18:17:26.02

ライフタイムもtraitも難しすぎてマジでわからん

**デフォルトの名無しさん** · 2023/06/15(木) 18:21:52.25

ライフタイムの質問してたものだけど
コードを書いてて完全に誤解していたことに気が付いた
コンパイル時に範囲をチェックするために引数のライフタイムを最小限に揃える仕組みなんだな
多分一般向けには流行らないわな

**デフォルトの名無しさん** · 2023/06/15(木) 18:38:09.80

ライフタイムって該当のメモリがいつまで確保されているかって話であって難しいところはなくね？
所望のタイミングまで開放してほしくないがどのようにするのが望ましいか？って話ならまだわかるが

**デフォルトの名無しさん** · 2023/06/15(木) 18:40:44.72

自明なときに省略できるせいで理解しづらくなってる気はする

**デフォルトの名無しさん** · 2023/06/15(木) 18:44:18.80

日本語がおかしかった
関数では引数に依存する戻り値の寿命がわからない
それで基本的に指定した複数の引数のライフタイムの一番短い奴に合わせて解釈する
そのライフタイムを元にコンパイル時にチェックしてダングリングを防いでる

一番寿命が短い奴に合わせてチェックしたら他はそれより長いのでダングリングが起こらないだろうと
こういうふうに言う人間があまりいないのが現状

**デフォルトの名無しさん** · 2023/06/15(木) 18:47:34.83

普通にコードを書いた時点でスコープや借用の関係で寿命は決まってる
それが範囲外になるかどうかボローチェックしてるんだけどそいつのためにライフタイムを明示してる

ライフタイムを明示してもコード上の寿命は伸び縮みしないけどエラーを見てコードを書いた人は修正ができる

**デフォルトの名無しさん** · 2023/06/15(木) 18:52:46.39

と言う解釈なんだけど今のところ
普通に違ってるかもしれない

**デフォルトの名無しさん** · 2023/06/15(木) 18:57:24.57

OnceCellってようやく俺たちの欲しいものが来てくれたか
RefCellもCellも複雑なデータ構造作ると面倒だったからな

**デフォルトの名無しさん** · 2023/06/15(木) 20:40:26.65

Cellの種類が増えるってのは悪い兆候だね

**デフォルトの名無しさん** · 2023/06/15(木) 20:43:39.64

Cellを使ったら負け
他の言語からの移植だと、なぜか増えてしまう

**デフォルトの名無しさん** · 2023/06/15(木) 21:23:13.49

>>669
結構何を言ってるか分からないが引数のライフタイムを省略した場合は全部同じライフタイムを持つことになるよ

**デフォルトの名無しさん** · 2023/06/15(木) 21:54:27.47

>>669
main()→sub()→...と呼ばれている時に
'mainと'subをそれぞれの関数で持っている分の寿命とすると
寿命の長さは'static＞'main＞'subだが
「'sub以上の集合」⊃「'main以上の集合」⊃「'static以上の集合」なので
実は'staticの方がサブタイプ(下位)

fn longest<'a>(x: &'a str, y: &'a str) -> &'a str において
寿命'aはジェネリックなパラメータなので
longest('main, 'static)と呼び出されれば'aは上位の'mainとなり
longest('main, 'sub)と呼び出されれば'aは上位の'subとなる

一方で
fn foo<'a, 'b>(x: &'a str, y: &'b str) -> &'b str という関数だと
foo('main, 'static)と呼び出されれば'bはそのまま'staticとなり
foo('main, 'sub)と呼び出されれば'bはそのまま'subとなる
この場合はもちろん引数の短い方の寿命になるわけではない

fn bar<'a, 'b>(x: &'a str, y: &'b str) -> Bar<'a, 'b> という関数は
返り型が構造体(か何か)のBarでその内部に寿命'aのものと寿命'bのものを持つ
このように様々なケースがある

**デフォルトの名無しさん** · 2023/06/15(木) 22:01:26.73

>>672
OnceCellは前からあって広く使われていて今回stdに採り入れられた
once_cell::unsync::OnceCell が std::cell::OnceCell となった
staticで使われてきたSyncなOnceCellの方は別名となり
once_cell::sync::OnceCell が std::sync::OnceLock となった

**デフォルトの名無しさん** · 2023/06/15(木) 22:08:16.03

>>669
データフロー解析を知らないのだろうか?

**デフォルトの名無しさん** · 2023/06/15(木) 22:11:21.57

>>666
>コンパイル時に範囲をチェックするために引数のライフタイムを最小限に揃える仕組みなんだな
この”揃える”っていう感覚になる理由がこんがらがってる原因と見た

**デフォルトの名無しさん** · 2023/06/15(木) 22:12:42.39

>>674
負けではない
むしろCell類は内部可変性を与えてくれる便利で良いもの

>>673
性質の異なるものを使い分けられるから良いこと
コードの自由度や可読性も上がる

**デフォルトの名無しさん** · 2023/06/15(木) 22:15:38.46

>>676
上位下位にサブタイプにsubて嫌がらせか！

**デフォルトの名無しさん** · 2023/06/15(木) 22:39:43.11

>>675
まずこれは間違いだよね？
ライフタイムを省力すると全部別扱い

>>679
こんがらがってはいない
違うなら違う個所を訂正したらいいけど君には出来ないとみた

引数側のライフタイムは戻り値のライフタイムの検証のためのヒント

**デフォルトの名無しさん** · 2023/06/15(木) 23:12:41.78

>>682
こんがらがってないならまずは他人に理解できる日本語とコード例を書いてくれよ
間違いを指摘するとか以前に何を言いたいのかわからないんだって
俺だけじゃなくて何人も君が何を言いたいのか分からないって書いてるでしょ？

**デフォルトの名無しさん** · 2023/06/15(木) 23:29:09.39

>>682
>まずこれは間違いだよね？
>ライフタイムを省力すると全部別扱い
コンパイルエラーになるケースを含めて言えば「省略したら」全部別扱いは正しい
コンパイルエラーにならずに「省略できるのは」基本的に入出力で同じライフタイム扱いになる場合だから>>675の感覚もよくわかる
&と&mut違いで推論できる場合だけ例外

**デフォルトの名無しさん** · 2023/06/15(木) 23:59:14.48

>>682
ライフタイムの「仮引数」としては省略されると全部同じ扱いで合ってるよ。
https://doc.rust-lang.org/reference/lifetime-elision.html

一方で呼び出す側が認識しているライフタイムの「実引数」は違っていてもいい。
>>655の例で言えば、呼び出す側が x: &'b str と y: &'c str を渡して戻り値を z: &'d str に束縛するなら、'a は 'b: 'a, 'c: 'a, 'a: 'd を満たす最小のライフタイムに推論される。
そのような 'a があれば、&'b str <: &'a str etc. の部分型付け関係に基づいて、引数はすべて一度 &'a str にアップキャストされると思っていればいい。はず。
適切な 'a が無ければライフタイムに関するコンパイルエラーになる。
https://doc.rust-lang.org/reference/subtyping.html
https://rust-lang.github.io/rfcs/2094-nll.html

**デフォルトの名無しさん** · 2023/06/16(金) 00:20:26.24

Rustのコードが'まみれになるのはそういう理由だよね

**デフォルトの名無しさん** · 2023/06/16(金) 00:24:30.59

>>685
＞　パラメーター内の省略された各ライフタイムは、別個のライフタイムパラメーターになります。

**デフォルトの名無しさん** · 2023/06/16(金) 00:30:18.44

>>685
いや、全部別になる
参照引き数が2つあれば'aと'b別になる

ソース
https://doc.rust-lang.org/book/ch10-03-lifetime-syntax.html

The first rule is that the compiler assigns a lifetime parameter to each parameter that’s a reference.
In other words,
a function with one parameter gets one lifetime parameter: fn foo<'a>(x: &'a i32);
a function with two parameters gets two separate lifetime parameters: fn foo<'a, 'b>(x: &'a i32, y: &'b i32);
and so on.

(snip)

Let’s look at another example, this time using the longest function that had no lifetime parameters
when we started working with it in Listing 10-20:

fn longest(x: &str, y: &str) -> &str {

Let’s apply the first rule: each parameter gets its own lifetime.
This time we have two parameters instead of one, so we have two lifetimes:

fn longest<'a, 'b>(x: &'a str, y: &'b str) -> &str {

このようにコンパイラは解釈する
そして戻り値が一意に決まらないのでコンパイルエラーとなる
そのためコンパイラは改善提案の一つとして全部同じにする提案コードを出す
fn longest<'a,>(x: &'a str, y: &'a str) -> &'a str {
全部同じ扱いと思い込んでいる人はこの提案をコンパイラが解釈したと逆に思ってしまったのではないか

**685** · 2023/06/16(金) 01:37:43.97

ほんまや申し訳ねえ
>>685はelisionのくだりは無視して明示した場合の話のつもりで読んでくだせえ

**デフォルトの名無しさん** · 2023/06/16(金) 05:23:01.54

厳格な言語て嫌いでな
Verilogはなんの問題もなかったのに
VHDLはとうとう挫折した
てか予約後長いし,マクロがないのが許せなかったんだが
その意味でJavaも結局書く気にもならなんだわ

**デフォルトの名無しさん** · 2023/06/16(金) 14:09:49.37

>>675
だけど思い込みを書いてしまってごめん
勉強になりました

**デフォルトの名無しさん** · 2023/06/16(金) 14:58:22.19

水ノ都さんこんにちは

**デフォルトの名無しさん** · 2023/06/16(金) 17:51:24.52

組み込み向けの解説記事でよさそうなのってない？
The Embedded Rust Bookは有名だけどSTM32ありきで書かれているしリンカとか肝心な部分の説明もないように見える
日本の人が書いているっぽいEmbedded Rust Techniquesの方がマシだがこれでも最低限か・・・

**デフォルトの名無しさん** · 2023/06/16(金) 18:25:34.38

>>693
The Book以外のドキュメントなら https://docs.rust-embedded.org/ からいろいろ探せるよ
あるいはEmbedded Rust Techniquesの人が書いてる「基礎から学ぶ組み込みRust」って本とか

**デフォルトの名無しさん** · 2023/06/16(金) 18:39:22.38

Rust好きがまあまあ見てそうなこのスレでもこのレベルなんだから一般に広まるのは無理ゲーだと思うわ

**デフォルトの名無しさん** · 2023/06/16(金) 19:23:08.87

問題点を具体的に言えずに曖昧に批判してるつもりの人がいるね

**デフォルトの名無しさん** · 2023/06/16(金) 19:40:36.76

自分でスレを読めばいい

お前の足りない脳を誰かがフォローしてボローチェックまでしてくれるなんて思うなよ

**デフォルトの名無しさん** · 2023/06/16(金) 19:42:26.19

言語の良し悪し以上にライブラリの分量が効いてくるんだわ。
そんでその大量にあるライブラリが利用しやすければなお良い。

やりたいことにマッチするライブラリがあるなら
自分で書かなくてよい部分が多くなるわけだし、
書く部分が少なければ少々の面倒くささなんてどうでもよくなる。

C や C++ の歴史の長さ故の物量に対抗するのは難しいけど
Rust は利用しやすさではかなり上回ってると思うので時間の問題だろ。

**デフォルトの名無しさん** · 2023/06/16(金) 23:38:46.36

>>695
単に5chがオワコンなだけだぞ

**デフォルトの名無しさん** · 2023/06/17(土) 20:33:46.40

>>683
ときにアセンブラで書必要に迫られる組込でRustあ日の目をみることなんてない

**デフォルトの名無しさん** · 2023/06/17(土) 21:26:17.31

>>694
その人は本を出していたのか。今度都内へ行ったときに見てみるか

**デフォルトの名無しさん** · 2023/06/17(土) 23:07:17.38

今日たまたま本屋で見かけた
売れるんかこれと思ったけど買う人がいる

**デフォルトの名無しさん** · 2023/06/18(日) 01:17:21.64

Rustでlinuxに機能を追加するならどんな機能が欲しい？みんな自由に言ってみて。

**デフォルトの名無しさん** · 2023/06/18(日) 09:07:15.46

>>695
ほんそれ

**デフォルトの名無しさん** · 2023/06/18(日) 09:08:49.10

>>698
crates.io はゴミだらけのイメージ(もちろんゴミじゃないのもあるがSN比が絶望的に悪い)

**デフォルトの名無しさん** · 2023/06/18(日) 09:13:33.05

>>703
これと言って無いし今のlinuxで満足(不満もあるけどそれがRustで解決するとも思わない)
カーネルもシェルもAPIもRust化しないと意味無くね？
どうせ unsafe! unsafe!! unsafe!!!

**デフォルトの名無しさん** · 2023/06/18(日) 09:15:13.52

>>705
まぁそれは何を比較するかじゃない？
ディストリビューション配布のCライブラリだと厳選されてるから当然クォリティ高いけど
GitHub上から探すとC系の方がS/N悪い（そもそもビルドできないとか）と感じるし

**デフォルトの名無しさん** · 2023/06/18(日) 10:10:46.67

rustは他の言語からの移植性が著しく悪い
移植と言うより最初から作ってるのと変わらない

**デフォルトの名無しさん** · 2023/06/18(日) 10:29:41.24

c　→　rustの移植が楽ならほおっておいても全部rustになる
その視点が欠けてる

ライナスがLinuxやGit作ったときのようにその他の勢力がおバカさんで実質アシストしてる時と同じような状況
Cust作るためのおぜん立てをしてるようにも見える

**デフォルトの名無しさん** · 2023/06/18(日) 10:37:34.85

後世から見たらライナスはlinuxとgitとcustを作った偉人ですと言うことになるんだろう

**デフォルトの名無しさん** · 2023/06/18(日) 12:12:13.93

仮にkernelや主要コマンドが全部rustに移植されたらその部分は安全にはなるわな
しかし現状そこまで行くかはわからん
なんせffiで別言語で書かれたライブラリ呼び出す時は全部unsafeやからな
つまり主要なlibも全部rustで書き変えないとunsafeからは逃れられないけどものすごい作業量になりそう
いけるのかな？

**デフォルトの名無しさん** · 2023/06/18(日) 13:00:20.06

>>698
>Rust は利用しやすさではかなり上回ってると思うので
一部の需要に対してのみは、そういう傾向があるかもしれないとは思うが、
全般に対しては違う。

**デフォルトの名無しさん** · 2023/06/18(日) 13:12:59.30

>>700
Rustはインラインアセンブリが書けてRustの変数と連動できるため困ることはない
叩く前に勉強しよう

**デフォルトの名無しさん** · 2023/06/18(日) 13:26:34.81

>>712
個人的にRustはあれだけの実行速度、安全性の割にはかなり文法がシンプルで好きだけどね。

**デフォルトの名無しさん** · 2023/06/18(日) 14:02:54.81

>>714
蓼食う虫も好き好きだね。

**デフォルトの名無しさん** · 2023/06/18(日) 16:08:38.91

>>705
それ他の言語も同じだ
そういう宿命

>>708
だから安全なんだよ

**デフォルトの名無しさん** · 2023/06/18(日) 23:54:05.72

>>703
その発想からしてRustのパラダイムから逸脱しており反Rust

**デフォルトの名無しさん** · 2023/06/20(火) 17:00:50.46

>711
>なんせffiで別言語で書かれたライブラリ呼び出す時は全部unsafeやからな
これ知るとRust安全神話なんて嘘八百八町なんよね
金儲けのために保守気取ってましたーに通じる

**デフォルトの名無しさん** · 2023/06/20(火) 19:31:43.67

>>718
こういう言説聞くと甘えにもほどがあるって思うけど、
そういう不満から Pure Java みたいに Pure Rust なライブラリが発展していけばいいね。

**デフォルトの名無しさん** · 2023/06/20(火) 19:54:19.85

unsafe=危険=意味なしみたいな人はRustを使うことが目的だと思っているんだろうね
安全なソフトウェアやシステムを開発することが目的ならそういう発想にはならないはずだ

**デフォルトの名無しさん** · 2023/06/20(火) 20:03:45.82

純粋なRustのライブラリはまだ完成度が微妙なんだよな。PythonとかC,C++と比べると。勿論、他言語のバインディングのライブラリは結構豊富なんだけど、それだとRustを使う意義がないからな。

**デフォルトの名無しさん** · 2023/06/20(火) 20:20:14.97

>>718
部分的にでもマシになるなら意味あるやん。
論理的な破綻がないように定理証明器をベースにした言語とかもあるけど、
そのために既存のライブラリが使えないようだとそれこそ使い物にならんだろ。

結局はバランスおじさん「結局はバランス」

**デフォルトの名無しさん** · 2023/06/20(火) 20:41:02.57

>>718
それはunsafeとは何かを理解できていなくて初心者なのかも知れないけどかなりヤバイよ
ffiなんて例を出す必要はなくメモリ空間へのアクセスは最終的に生ポインタとなって当然unsafeになる

例えばslice[index]やslice.iter()の内部は当然unsafeな生ポインタを使って実装されている
ではunsafeで実装されているslice[index]やslice.iter()は危険か？となるがもちろん完全に安全だ
なぜならunsafeを内部に閉じ込めて安全なインタフェースを提供しているからである
これがRustの基本原理

ffiについても同様で例えばファイルのオープンや読み書きは通常OSへのシステムコールとなり通常ffiとなるため当然unsafe
しかしRustの標準ライブラリではそのunsafeを内部に閉じ込めて安全なインターフェイスとして提供している

このようにメモリアクセスもOS呼び出しもそれ自体は当然unsafeだがそれはモジュールの内部に閉じ込められている
そしてそれらを利用する側のプログラマーは安全なインターフェースのみを用いてsafeにプログラミングすることができる
そしてsafeな部分なコンパイラにより様々な安全性が自動的に保証されるという至上の恩恵をもたらすのがRust

**デフォルトの名無しさん** · 2023/06/20(火) 20:48:07.86

話の流れとは直接関係無いが、豆知識:
バグと言うものは、64BIT 整数を 32BIT 整数で受けたり、符号付きを符合なし
で受けたり(その逆でも)するだけでも起きるし、メモリ関連バグだけでは無い。

**デフォルトの名無しさん** · 2023/06/20(火) 20:50:12.42

例えば、OSの一度に行なえるファイル読み書きが10MBに制限
されている場合に、それを知らずにバイト数に20MBを指定して
しまったら、バグとなる。
テストでは10MBを超えるファイルを扱っていなかったら気付かない。

**デフォルトの名無しさん** · 2023/06/20(火) 21:06:06.55

>>725
テスト仕様が10MB超えるファイルを扱うパターン記載されてないなら仕様じゃん

その場合仕様ミスではあるがバグとは呼ばない
バグってのは仕様通りに動いてない事を指すんやで

**デフォルトの名無しさん** · 2023/06/20(火) 21:17:59.27

>>724
Rustは強い型安全性が保証されるためそれらのバグも起きない

>>725
それはプログラミング言語とは独立した無関係な話
制限があるのにエラーを返さないOSがあるならそれ自体の問題でありプログラミング言語は関係ない
エラーを返すならそのエラーの対処を正しくしていればバグは起きない

**デフォルトの名無しさん** · 2023/06/21(水) 20:47:56.17

Rustで最初に出したバグはデッドロックだったな
コンパイルエラーにしてくれるもんだと油断していた

**デフォルトの名無しさん** · 2023/06/21(水) 21:05:00.78

静的解析でデッドロックを検出するのは不可能
もちろんRustでも無理

**デフォルトの名無しさん** · 2023/06/26(月) 18:26:13.57

すいません、くだらない質問かもしれませんけど割り込ませて下さい
Haskellとかだと二項演算子(+)はNum classに属する型なら適用できます
自分が作った型でもその型において(+)をどう実装するか定義すれば(+)が利用できるようになります
例えば5元体の計算を行うF5 型を定義してそこで足し算とかをするには

data F5 = F5 Int deriving (Eq,Show) -- 型F5を作成
instance Num F5 where -- F5がNum classに属する宣言
　(F5 x ) + ( F5 y) = F5 $ mod (x+y) 5
...略...

のようなものを作れば例えば

print $ ( F5 3 )^4

でF5 1を得る事ができます
同じような事はRustでできますか？
自分でこのような5元体の計算を行うための型を自作しそれの計算を二項演算子(+),(*)を用いた表記を可能にする方法とかありますか？

**デフォルトの名無しさん** · 2023/06/26(月) 18:32:46.35

>>730
std::ops::Add を実装すれば + が使えるし
std::ops::Mul を実装すれば * が使えるよ。
https://doc.rust-lang.org/std/ops/trait.Add.html
https://doc.rust-lang.org/std/ops/trait.Mul.html

**デフォルトの名無しさん** · 2023/06/26(月) 19:00:39.37

>>731
ありがとうございます
やってみます

**デフォルトの名無しさん** · 2023/07/04(火) 01:09:18.95

神クラス的なArcMutexのstructをごっそり差し替えし始めたらrust analyzerが糞遅くなって書くのが辛い
コード戻したくなる
助けて

**デフォルトの名無しさん** · 2023/07/08(土) 03:39:28.67

キーボードの何かのキーが入力されてるか調べるけど
何もない場合は止まらずにそのまま次の処理を続けるはどうすればいいの？

**デフォルトの名無しさん** · 2023/07/08(土) 04:25:29.10

>>734
C言語の時と同じ
ノンブロッキング指定するだけでなく
cooked modeではなくraw modeをICANONに指定
これでバッファリングされることなくブロックされることなく読み出せる
libc叩かなくてもtermioなど好みのクレートを使う

**デフォルトの名無しさん** · 2023/07/08(土) 07:46:14.85

なるほど

**デフォルトの名無しさん** · 2023/07/08(土) 08:39:38.42

窓だからGetAsyncKeyState呼び出すのが楽っぽい

**デフォルトの名無しさん** · 2023/07/13(木) 13:31:51.91

Rust言語で開発したWindowsカーネル、Canaryチャネルで展開開始
https://news.yahoo.co.jp/articles/de16ce55a291d59f7364096690fd601c5ee2ece2

**デフォルトの名無しさん** · 2023/07/14(金) 11:16:58.08

値をコピーせずに参照を切り替えてFibonacci数列を計算したい

https://ideone.com/lnMyvH

はいけるんだけど

https://ideone.com/VerTGV

は

error[E0658]: destructuring assignments are unstable

と怒られます
どなたか対処法わかりますか？

**デフォルトの名無しさん** · 2023/07/14(金) 11:27:16.72

>>739
これでどう？
https://doc.rust-lang.org/std/mem/fn.swap.html

**デフォルトの名無しさん** · 2023/07/14(金) 12:09:03.76

>>740
おお、素晴らしい
あざっす

**デフォルトの名無しさん** · 2023/07/14(金) 12:17:12.18

ちなみにコレxとyの参照してる値を保持してる内容を入れ替えてませんよね？
xとyの参照してるアドレスの入れ替えをしたいんですけど
それどうやって確かめたらいいんでしょう？

**デフォルトの名無しさん** · 2023/07/14(金) 12:25:35.09

そもそもうまく行ってると思ってたほうもうまくいってなかったorz

https://ideone.com/rny4y8

xとyの参照が切り替わってるんではなくて値そのものこくかんしてやがる
xとyの値に触らずxとyの参照先アドレスだけ切り替えるのってできないんでしょうか？

**デフォルトの名無しさん** · 2023/07/14(金) 12:36:55.78

ちょっと長くなるけどやりたい事書きます
例えばFという処理があってそれを初期値a0に何度も適用したいとします
Fの値を計算する関数を入力バッファと出力バッファのアドレスをとって入力バッファ側のデータを読んで出力バッファに書き出す関数を作ったとします
それを何度も繰り返す場合、出てきた出力バッファの内容をもう一度入力バッファにコピーする作業はあまりにも無駄なので出てきた出力バッファを今度はそのまま出力バッファとして使用したいんです
でもx,yは参照型でy=xとしたら何故かxの内容をyの内容に置き換えてしまってるみたいですけどコレ何故なんでしょう？
なんとかならないんですか？

**デフォルトの名無しさん** · 2023/07/14(金) 12:57:26.91

自己レス

わかりました
こうですね

https://ideone.com/sl7Q9v

ここまではうまく行った

**デフォルトの名無しさん** · 2023/07/14(金) 13:20:43.04

そして教えていただいたsys::mem::swapで確認
うまく行ってる感じです
素晴らしい
あざっす

https://ideone.com/1pWNZ7

**デフォルトの名無しさん** · 2023/07/14(金) 13:21:19.50

そもそもE0658がideoneのrustcのバージョンが古すぎるせいだから>>1のPlayground使ってろ

**デフォルトの名無しさん** · 2023/07/14(金) 19:05:41.95

亀だが
>>694
>基礎から学ぶ組み込みRust
見てきた。あの内容じゃWebの記事読んでおけば十分な感じだった
肝心の低レイヤー(CPUやペリフェラルとのインターフェイス)の解説がペラい
特に現状ではメーカーのサポートが得られない以上HALやBSPに相当する部分を
自前で用意せざるを得ないケースは少なくないと思うけど
その辺が十分に解説されているようには見えなかった

**デフォルトの名無しさん** · 2023/07/14(金) 21:27:06.52

そりゃマイナーなチップのHALを自分で作るなんて
マニアックすぎる内容で商業出版は無理だろ
そこまでやるならもう既存の実装見に行ったほうが早いよ

**デフォルトの名無しさん** · 2023/07/17(月) 14:57:59.69

期待してたけどめちゃくちゃ頼りないスタイルガイドが出てきたな
「こういう場合はこうフォーマットしましょう」だけじゃなくもう少し踏み込んで欲しかった
https://doc.rust-lang.org/nightly/style-guide/statements.html

**デフォルトの名無しさん** · 2023/07/17(月) 15:40:03.84

スタイルガイドの目的はrustfmtの挙動を文書化して開発を進めやすくするってことだから
まさに「こういう場合はこうフォーマットしましょう」のための文書だよ

**デフォルトの名無しさん** · 2023/07/17(月) 17:17:17.76

もう少し踏み込んで欲しかった、と言ってる人にそれを言ってもどうもならないわな
別にスタイルガイドの定義の話あなたが勝手に始めただけですよね
論破ですよね

**デフォルトの名無しさん** · 2023/07/17(月) 17:39:41.44

なにいってだこいつ

**デフォルトの名無しさん** · 2023/07/18(火) 03:22:09.12

>>744
ポインタとポインタのポインタの違いだな

>>746
そう
ポインタのポインタをswapに渡せばポインタが書き換わる

**デフォルトの名無しさん** · 2023/07/18(火) 03:37:10.43

>>750
従来の言語のスタイルローカルルールの乱立やルール解釈の違いなどの反省から
Rustの標準ではrustfmtを使うことに尽きるわけだがそれ以上にどんな記述を求めているのだろうか

**デフォルトの名無しさん** · 2023/07/18(火) 09:14:53.67

一般的なスタイルガイドを知ってる人と知らない人の違いだね
常識だと思ってた