プログラミング言語 Rust 4【ﾜｯﾁｮｲ】
Mozilla発のプログラミング言語「Rust」のスレです
■公式
https://www.rust-lang.org/
https://blog.rust-lang.org/
https://github.com/rust-lang/rust
■ワッチョイ
スレ建て時、一行目に
!extend:on:vvvvv:1000:512
を入れること
■派生元スレ
プログラミング言語 Rust 4
https://mevius.5ch.net/test/read.cgi/tech/1507970294/
VIPQ2_EXTDAT: default:vvvvv:1000:512:----: EXT was configured >>210
それは予め領域を確保しておく関数で、確保できなかった場合には、
Result<(), TryReserveError>
という戻り値を返す関数と言うことですか？
そして、関数呼び出しの直後に ? を書くと、エラー発生時にそこで
アプリをダウンさせると言うことですか？ >>211
事故レスですが、? 演算子は、x ? と書くと、x の値が Err(y) だったら、
return Err(From::from(y)),
というような動作をする関数のようですね。 いろいろ違う
落としたいならpanicさせとけばいい メモリ不足を検出した場合に何をしたいかで適切な対応は変わってくるけど、何をしたいの？ >>214
メモリー不足の時にメモリー不足である旨のエラーメッセージを出して、
なんらかの自作の処理コードを動かしたいです。 >>215
なお、Vecに追加する動作を行なった関数の中で処理をしたいです。 重要:
メモリ不足だからと言ってmallocが失敗するとは限らない 今の Linux カーネルだとアプリケーションからオーバーコミットを無効にすることは出来るようになってるぞ。 try_reserveの戻り値がErrだったら処理を実行するだけだよ
この説明で分からないならenumやResult型について勉強した方が良いよ
あとtry_reserveの失敗要因はメモリ不足だけじゃないけど、エラー種別はnightlyじゃないと取得できないみたいね RefMut <-> Ref にも Rc <-> Weak みたいな相互変換メソッドがあればいいのに >>220
RefCell自体を取り回して必要なところで都度RefやRefMutを作れば良いのでは >>221
実際今はそれでやってて、別に問題になるほどじゃないんが、ちょっと無駄だよなあと
Ref/RefMutってあんまりあちこち取り回す用にできてないよね >>222
RefやRefMutはMutexのGuardみたいなもんなんだから取り回す範囲は極力狭くするべきなんじゃね Rust for Linux updates! More pin-init and refactoring! - YouTube
https://www.youtube.com/watch?v=jAanHvcuYtA The RustConf Keynote Fiasco, explained
https://fasterthanli.me/articles/the-rustconf-keynote-fiasco-explained
一連の事件は結局不幸な伝言ゲームの結果だったということだろうか 以前からCodeLLDBでたまに値がちゃんと表示されないことがあるなーと思ってたら再帰型が原因だったんですね
今ほとんど再帰でできてる部分触ってるせいで困ってる……
dbg!書けばいいだけではあるんだけど泥臭くて嫌だわね
https://github.com/vadimcn/codelldb/issues/605 いつのまにかrust-specがマージされてる。まだ作業終わってないけど。
ttps://github.com/rust-lang/rfcs/pull/3355
ttps://github.com/rust-lang/rust/issues/113527
rustにもようやく仕様が。 これから編集者雇うみたいだからまだまだ時間は掛かりそうだけど、前進だね Hugging FaceがPyTorch的なRust製フレームワークを作り始めたらしい
https://github.com/huggingface/candle githubにrustupのソースコードあるから読めばいいよ。 Debugを上位トレイトに持たないトレイトのオブジェクトをなんとかしてdbg!する方法は無いもんじゃろか 構造体フィールドの中身を知りたいという事ならAnyを継承させてダウンキャストするかDebugを継承したtraitにするしかないね intellij rustからRustRoverギリギリ燃えてないな。プラグインもIDEAもバグが増えたのが懸念とか言われてるけど。 RustのコンパイルターゲットはTierで分けられているけど
x86_64-pc-windows-msvc ←Tier1
x86_64-unknown-none ←Tier2
この違いって何？
Tier1の条件を見るとすべてのテストに合格すること的な事が書いてあるしプラットフォームが不明の状態でそれは不可能はなず
組み込み向けなどの低レイヤー用途を想定したターゲットにTier1のものはなくすべてTier2以下になっている
もしこれが理由なら自分が書いたコードはTier1と同レベルに翻訳される(実行できなかったり実行結果が不正なコードは生成されない)事が
期待できるけどそう考えて問題ないのだろうか >>241
x86_64なら現実的にはほぼ動くとは思う
ただ、あくまでもrust側ではコンパイルが通ることしか確認してなくて、生成されたコードが正しく動作するかは未確認の状態
利用者側が動作確認をきちんとやる必要があるよ >>242
例えばベアメタル開発用などでOSとインターフェイスしないコードのみほしい場合
x86_64-pc-windows-msvc(x86_64-unknown-linux-gnuとかでも可)でスタティックリンクのライブラリとしてビルドしてカスタムリンク
x86_64-unknown-noneでビルド
の二択だと出力物の信頼性はどちらの方が高いのだろうか。どちらも適切なローダーを用意すれば動作するはず
特に低レイヤーの開発で翻訳不良があるとトラブルシュートが沼りやすいし、前者の方が有利なら
ゴミが付いたりビルドが複雑化するなどのデメリットを考慮しても検討する価値があるはず より正確にはtier2はwith/without Host Toolsに分かれる。
withの方はtarget環境扱いだけじゃなくてネイティブなhost toolsを使用して開発環境として使える。
*-*-none-*はベアメタル向けだからHost Toolsのサポートはない。
言い換えるとtier2 with Host Toolsはセルフホストできる。
Tier 1にもwith/withoutの分類があるけど事実上withoutの方がない。
これは今のところHost Toolsをサポートしてないtier 1が存在しないから。
だからビルド環境に指定したいならx86_64-unknown-none。 x86_64-unknown-noneが吐くコードをどのくらい信用して良いのかって話ね
Tier2＝十分にテストされていない＝不正命令例外を吐いたり意図しない演算結果になる可能性がある
とかだと開発に重大な影響が出るし勘弁してほしい。Tier1のターゲットならそんな可能性は無視できるはずだし テスト云々はlibstdが主なんでは？
そもそもコード生成するのはLLVMなんだし機械語レベルじゃRust側のTierは関係ない気がする x86_64-unknown-noneがTier2の理由がstdのテストができないからならそれでいいんだけどね
Platform Supportを見ても
>x86_64-unknown-none * Freestanding/bare-metal x86_64, softfloat
としか書いていない。hardfloatが使えない？のはよくわからないが Tierはrustcのコードベースがビルドできるかどうかの保証であって吐くバイナリの質の保証じゃない。
そもそもrustcはフロントエンドだからどういうバイナリ吐くかは無関係。
tier 1/2の違いは自動テストが常に実行されるかどうかの違いだけ。
全部Platform Supportに書いてあるからこの説明でわからんならどこが理解できないのか言ってくれ。 Tier表記がアテにならないならコードの質を比較するにはどうしたらいいんだろ
x86_64とavrが同じ品質、同じ最適化レベルなわけないよな rustに限らずコンパイラの生成コードの品質はアセンブリ見て判断するしかないんじゃね
LLVM IRもプラットフォームごとに差があるのかね？ Rust製ブラウザエンジンの「Servo」、アプリに組み込み可能なクロスプラットフォーム対応WebView化を目指す。Electron代替を目指す「Tauri」への組み込み実現へ － Publickey
https://www.publickey1.jp/blog/23/rustservowebviewelectrontauri.html
期待 https://rust-lang.github.io/rfcs/3192-dyno.html
気づいたらポシャっててstd-1.73.0からProvider/Demandも消えてた
やっぱりRTTIとかそういうのはあんまり乗り気じゃないのかな？？ RubyのYJITって仕組みはRustで実装されてるんだな
ソース見てビビった >>253
へぇ、Node.jsもあちこちが遅いからと
ちょこちょこ便利ライブラリの中身がRustに置き換わり始めてるし
今後こういう流れは加速しそうだな 遅い部分を Rust でなおそうというよりは、
Rust へ置き換わる流れに乗るついでに駄目なところをそろそろなんとかしようぜという感じじゃないかな。
イマイチなのがわかっててもちゃんと動いてるなら何かきっかけがないと重い腰が上がらないのはよくあること。 YJITのコード、相当面白いな
RustでJITしてるよw
マシンコードゴリゴリ生成してる rustってJavaやpythonみたいに爆発的に流行るわけじゃなくてじわじわ広まっていく感じなんだろうな YJIT、最初はCで実装されてたがRustに変えたみたい
bindgenでCRuby側のAPIをRust側に持ってきて
それを使いながらJITでマシンコード生成してる
面白すぎる
コードもめちゃくちゃ読みやすいぞ RustのRTOSはTockがあるけどFreeRTOSやTOPPERS/SSP、μT-Kernelなど既成のRTOSとの比較レビューってある？ 
