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/

**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

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

**デフォルトの名無しさん** · 2023/07/18(火) 13:02:43.58

公式のスタイルガイドはrustfmtに実装するフォーマッティング以外はスコープ外
フォーマッティングガイドラインと改名したほうがいいわな

**デフォルトの名無しさん** · 2023/07/19(水) 11:14:31.27

関数呼び出しの質問です
私の認識では
「rustは関数呼び出しは基本call by valueで呼び出され、呼び出し時の“値”は基本コピーして渡される、ただしimmutatibleな呼び出しでは関数側が値を変更しないのにコピーするのは無駄なのでコピーされない」
であってますか？
それでお聞きしたいのはrust compilerって呼び出した関数側が実際引数を変更するかしないか判定して“immutatibleな変数を変更しようとした、なめとんかボケ”って怒ってくることがあります
コレ逆に言えば例えプログラマが変更しない変数をmutableで呼び出しを指定してもcompilerはどうせ変更されないんだからコピーもしないでいいよねと気を利かせてコピーしないとかしてくれると考えて大丈夫ですか？、

**デフォルトの名無しさん** · 2023/07/19(水) 11:21:25.92

>>758
言ってることが意味不明なので回答できない。
何か根本的に勘違いしていると思う。
コードで説明してみて。

**デフォルトの名無しさん** · 2023/07/19(水) 11:41:04.52

すいません
具体的なコーどはちょっと用意します
別件なんですけど

let mut i : u64;
let p : u64 = 2u64.pow(32)-2u64.pow(10)+1;
for i in 2..100000 {
if i.pow(524288)%p != 1 && i.pow(1048576)%p == 1 {
println!("{}",i);
}
}
と書いたところ
error[E0689]: can't call method `pow` on ambiguous numeric type `{integer}`
--> compiler.rs:136:8
と怒られます
u64って指定するだけではダメなんでしょうか？
どう書いたら通してもらえますか？
よろしくお願いします

**デフォルトの名無しさん** · 2023/07/19(水) 11:47:10.22

unsafe { 引数のポインタ拾って描き替えたら }
呼び出し側も描き換わってたでござる

**デフォルトの名無しさん** · 2023/07/19(水) 11:49:41.95

>>760
for i in 2..100000u64 {

**デフォルトの名無しさん** · 2023/07/19(水) 11:51:21.32

>>762
あと mut i: u64 の i は for では使われてないし警告出てない？

**デフォルトの名無しさん** · 2023/07/19(水) 12:00:23.67

ダメでした

error[E0308]: mismatched types
--> compiler.rs:136:12
|
136 | if i.pow(524288u64)%p != 1 && i.pow(1048576u64)%p == 1 {
| --- ^^^^^^^^^ expected `u32`, found `u64`
| |
| arguments to this function are incorrect
|
note: associated function defined here
= note: this error originates in the macro `uint_impl` (in Nightly builds, run with -Z macro-backtrace for more info)
help: change the type of the numeric literal from `u64` to `u32`
|
136 | if i.pow(524288u32)%p != 1 && i.pow(1048576u64)%p == 1 {
| ~~~

となります
powってu64はダメなんでしょうか？

**デフォルトの名無しさん** · 2023/07/19(水) 12:07:25.53

ideoneでもダメです
https://ideone.com/FaBKXh

**デフォルトの名無しさん** · 2023/07/19(水) 12:11:42.11

エラーメッセージから「ダメ」かどうかの１ビットしか読み取らない人にプログラミングは難しい。

**デフォルトの名無しさん** · 2023/07/19(水) 12:12:42.07

あ、そもそもコレダメですね
仮にu64受け付けてくれてもダメやん
powは自作します
しかしu64版のpowってないんでしょうか？

**デフォルトの名無しさん** · 2023/07/19(水) 12:14:10.94

overflowは知らん自己責任でやれ
https://ideone.com/JR2FhX

**デフォルトの名無しさん** · 2023/07/19(水) 12:17:18.80

>>767
https://crates.io/crates/rust-gmp

**デフォルトの名無しさん** · 2023/07/19(水) 12:25:20.07

いろいろキッツいなぁー

loop-variableはfor-loopのブロックスコープ
u64::powはfn pow(self, exp: u32) -> u64
(u32以上の値をとってもオーバーフローするから)

>「rustは関数呼び出しは基本call by valueで呼び出され、呼び出し時の“値”は基本コピーして渡される、ただしimmutatibleな呼び出しでは関数側が値を変更しないのにコピーするのは無駄なのでコピーされない」
>であってますか？
もちろん間違ってます

**デフォルトの名無しさん** · 2023/07/19(水) 12:29:53.08

余りをとっているから繰り返し自乗法を適当に実装すればオーバーフローは回避できる

**デフォルトの名無しさん** · 2023/07/19(水) 12:30:35.45

>>770
間違ってるんですか？
どこが違いますか？

**デフォルトの名無しさん** · 2023/07/19(水) 12:41:14.04

>>771
そうなんですよ
毎回あまり取らないとダメですよね
pの値も間違ってたし
やりたかったのはバッファサイズが1048576の有限体のフーリエ変換のための素数と位数1048576の元zetaを見つける作業でpはすぐ見つけてたんですけどzetaで手こずりました
まだrust慣れてないもので
これで行けました
https://ideone.com/haw9t8
見つけたzetaの候補３つ
4293918721
1557
7183
8874

**デフォルトの名無しさん** · 2023/07/19(水) 15:49:39.29

やはりダメです
型の指定の書き方がわかりません
次のコードです
https://ideone.com/QLw12c
有限体上のFourier変換を書きたいんですけどmutの書き方がらみで怒られます
どうすれば通せますか？

**デフォルトの名無しさん** · 2023/07/19(水) 16:22:53.10

とりあえずmutを全部につけまくったら通りました
https://ideone.com/EF9EEJ

**デフォルトの名無しさん** · 2023/07/19(水) 17:34:17.58

>>774
>どうすれば通せますか？
The Bookを読んで基本を身につければ通せます。
https://doc.rust-lang.org/book/
まずはplygroundとエラーメッセージの読み方から学ぶことをお勧めいたします。

**デフォルトの名無しさん** · 2023/07/19(水) 17:52:11.79

ありがとうございます
コンパイルは無事通ったんですけどstack overflowで実行できませんでしたw
どうせならどでかいのでやってみようと欲張ったらダメでしたw
まぁ縮める分には見つけたpやzetaはそのまま使えるのでまた時間ある日に続きやります
やっぱり新しい言語挑戦するのは時間かかりますね
ついでにひとつお聞きしたいんですけど、今回は「Rustの売りのなるべくstuckでやる」でやってみたんですけど流石にこのサイズはstackにとれないようです
コレ同じ事ヒープでやってもRustコンパイラはフラグメンテーションが怒らないように良きにはからってくれますよね？
コードは>>775です、まだ作りかけですけど
Fourier変換でO(n log n)で掛け算するプログラムの実装の演習の自習中です

**デフォルトの名無しさん** · 2023/07/19(水) 23:54:55.34

>>758
>> rustは関数呼び出しは基本call by valueで呼び出され、呼び出し時の“値”は基本コピーして渡される

Rustは常にcall by valueでvalueをコピーする
大きなものをコピーされたくないならば
渡すvalueとしてその参照を指定する
すると参照すなわちポインタ値のみがコピーされて渡される

>> ただしimmutatibleな呼び出しでは関数側が値を変更しないのにコピーするのは無駄なのでコピーされない

immutatibleな呼び出しなんて概念はない
immutableな参照を渡すかmutableな参照を渡すかの選択肢はある
そのポインタ値は常にコピーされる

ポインタ値のコピーはどんな速い言語を作っても避けられずそれが最速
ただし例えば数値単体を渡すなら参照(ポインタ値)を渡すよりも速い

>>777
数MBのデータはスタック領域に入らないのでヒープ領域に開始時に確保すればよい

**デフォルトの名無しさん** · 2023/07/20(木) 15:25:39.14

>>778
>Rustは常にcall by valueでvalueをコピーする

何でもかんでも #[derive(Copy, Clone)] 描く習慣は良くないな

**デフォルトの名無しさん** · 2023/07/20(木) 16:14:28.16

古典的なcall by valueの定義におけるコピーと
そのCopyとはまた違う話

ついでに言うとRustにおけるcall by valueの定義と
古典的call by valueの定義は違うので要注意
現代では古典的定義でcall by valueかどうかを考えるのはあまり意味がない

**デフォルトの名無しさん** · 2023/07/20(木) 19:56:50.64

>>779
そのコピーはビットコピーの話でCopy実装型の話とは別
Copy非実装型でもムーブするとビットコピーされる
そもそもCPUやメモリにムーブなんてものは存在しなくてMOV (MOVE)命令ですらビットコピーが行われる

ただしビットコピーは最適化で消えうる
例えば別の変数にムーブしても最適化でビットコピーは消えうる
サイズの大きな値を関数でムーブ返ししてもRTO (Return Value Optimization)により呼び出し元スタックフレームに直接生成できるならビットコピーは消えうる
サイズの小さい値を関数でムーブ返しするとレジスタ返しとなる等

**デフォルトの名無しさん** · 2023/07/20(木) 22:07:49.98

call by valueのコピーはビットコピーなんて定義はない
ビットコピーかどうかはimplementation detail

**デフォルトの名無しさん** · 2023/07/20(木) 22:17:52.36

レジスタかメモリへのビットコピー以外に渡す手段はない
現行のコンピューターでは

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

メモリ管理について質問です
Rustは「GCをしない言語」を謳っています
一応「GCを心配する必要はない、フラグメンテーションなも起きない、メモリ不足になったらそれはフラグメンテーションではなくて元々のメモリ不足」と言い切れればいいんですけど、実際にはそうではなく、下手なデータ管理をすればフラメンテーションは発生するようです
まぁそりゃそうなんですけど
https://hackernoon.com/ja/Rust%E3%82%A2%E3%83%97%E3%83%AA%E3%82%B1%E3%83%BC%E3%82%B7%E3%83%A7%E3%83%B3%E3%81%A7%E3%83%92%E3%83%BC%E3%83%97%E3%81%AE%E6%96%AD%E7%89%87%E5%8C%96%E3%82%92%E8%A6%8B%E3%81%A4%E3%81%91%E3%81%A6%E5%9B%9E%E9%81%BF%E3%81%99%E3%82%8B%E6%96%B9%E6%B3%95
ということはプログラマ極力フラグメンテーションが発生しないように注意したいところですが、しかしRustのアロケータはどういう状況でフラグメンテーションを発生させるか、どうやれば防げるかの資料が見つかりません、なので先のリンクの人は自分で調べてたみたいです
これ誰かご存知の方いますか？
具体的には同じ型のSizedのデータA,を作成して先にAを消し、その後同じ型のCを作った場合、Rustシステムはその時点で開いてる穴のAの抜け穴を利用してそこにCを割り当ててくれるんでしょうか、
それともBが消えるまではAのあった場所も“欠番扱い”になるんでしょうか？

**デフォルトの名無しさん** · 2023/07/22(土) 02:40:42.91

>>784
アロケーションやフラグメンテーションはRustの言語システムの範囲外
例えばOSがない環境も含めてアロケータを自作もできるようになっている
普通にOSなどある環境を使うとRustはそこでの標準のアロケータをそのままグローバルアロケータとして用いる
つまり環境毎に異なるものが使われていてRustとは全く関係がない問題であることがわかる

もちろんRustでは自分でアロケータを変えることもできる
グローバルアロケータを丸ごと変える方法とBoxやVecなどで個別にアロケータを指定する方法がある
使用環境の標準のアロケータで何か問題が起きていると感じたらその例のように別のものと交換して比較してベストなアロケータを選べばよい

もう一つ全く別のアプローチとしてそれらアロケータに頼るのではなくプログラムのレベルでまとまったメモリの割り当て管理する方法もある
この方法は全て自分の制御下におけるため様々な特性のあるクレートがありもちろん自作もできる

**デフォルトの名無しさん** · 2023/07/22(土) 02:50:52.30

>>784
後半の質問はもちろん再割り当てしてくれる
どの環境の標準アロケータでもそのような普通のことは当然している
だからアロケータの変更などは何か問題が起きてから考えればいい
質問の挙動ならばアドレスを表示させればわかる

fn main() {
// aを割り当て
let a = foo(123);
println!("a: {:p}", &*a);
// bを割り当て
let b = foo(456);
println!("b: {:p}", &*b);
// aを解放
std::mem::drop(a);
// cを割り当て
let c = foo(789);
println!("c: {:p}", &*c);
// aとcは同じアドレスになっている
}

fn foo(init: i32) -> Box<[i32; 1000]> {
std::boxed::Box::new([init; 1000])
}

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

やはりそうですね
Rustはヒープエリアのメモリ管理は言語システムでは提供しない、その性能については規定しない立場なんですね
なので先の質問のような場合「Rustでは必ずうまいことやってくれる」とは言えず「コンパイラ××、実行環境××で実測したらうまく行った」程度しか言えず、同じソースを別の環境に持ってやったらダメだったもありうるんですね
結局ヒープを使わざるを得ない場合には「自分でメモリ割り当てをうまいことやる」しかないんですね
今やってる例だとスタックには入らないって怒られるし、ヒープ使うなら、うまくいくかはやってみるまでわからないというのはちょっと面白くないなぁ

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

>>787
OS環境などが提供するアロケータ(＝Rustのデフォルトのアロケータ)をそのまま使う時だけ環境依存になる
これはRustに限らずそれをそのまま使う全てのプログラミング言語で起こるためRustの問題ではない
しかもRustは次のように解決策がある言語だ

アロケータ含めて同じソースを持っていってそれを使うならば動作も同じになるので大丈夫
例えば先ほどのケースのようにjemallocをアロケータとして指定して使えば環境依存ではなくなる
よほど特殊なケースでの特殊な効率化を目指さない限り自分でアロケータを書く必要はない