Rust part12

**デフォルトの名無しさん** · 2021/08/24(火) 22:55:27.78

公式
https://www.rust-lang.org/
https://blog.rust-lang.org/
https://github.com/rust-lang/rust

Web上の実行環境
https://play.rust-lang.org

日本語の情報
https://rust-jp.rs/

※Rustを学びたい人はまず最初に公式のThe Bookを読むこと
https://doc.rust-lang.org/book/

※Rustのasyncについて知りたければ「async-book」は必読
https://rust-lang.github.io/async-book/

※C++との比較は専用スレへ
C++ vs Rust
https://mevius.5ch.net/test/read.cgi/tech/1619219089/

前スレ
Rust part11
https://mevius.5ch.net/test/read.cgi/tech/1623857052/

**デフォルトの名無しさん** · 2021/10/02(土) 07:25:57.30

VSCodeか何かで、編集中のファイルを（保存する度ではなく）リアルタイムで構文チェックしてもらうことってできないの？
目が悪いもので、C#みたいに間違えたら即指摘みたいなのがすごく助かるんだけど・・・・

**デフォルトの名無しさん** · 2021/10/02(土) 08:17:40.16

rust-analyzer入れれば若干のラグはあるけどそんな感じでやってくれると思うが

**デフォルトの名無しさん** · 2021/10/02(土) 08:21:40.61

すまんオートセーブもつこうてたわｗ

**デフォルトの名無しさん** · 2021/10/02(土) 09:01:16.43

>>581
IntelliJRustにon the fly analysisあるぞ

**デフォルトの名無しさん** · 2021/10/02(土) 15:27:53.04

普通にVscodeでRustの拡張入れたらやってくれん？
俺が思てる構文チェックとかの支援とは違うんかな

**デフォルトの名無しさん** · 2021/10/02(土) 15:48:21.44

vscode+rust-analyzerでオートセーブ無効でもリアルタイム構文チェックしてくれるよ

**デフォルトの名無しさん** · 2021/10/02(土) 17:14:40.18

いつrust-analyzerに移行するか悩み中。

**デフォルトの名無しさん** · 2021/10/02(土) 17:43:54.53

>>586
Auto Saveオフだと、指摘してくれないやつ結構ない？
セーブして初めて指摘されるやつが結構あるような

**デフォルトの名無しさん** · 2021/10/02(土) 17:45:45.06

rust-analyzerってvimでも使える？
流石にvim捨てるべきかなあ

**デフォルトの名無しさん** · 2021/10/02(土) 18:12:12.35

vimでもneovimでも使えるよ

**デフォルトの名無しさん** · 2021/10/02(土) 21:14:54.36

rls から rust-analyzer の移行なんて躊躇するもんじゃないぞ。
試して合わなければすぐに戻せばいいだけだし、戻りたいと思う可能性は俺はゼロだと思う。

**デフォルトの名無しさん** · 2021/10/02(土) 21:57:31.81

>>588
構文チェックとrust-analyzerの検知できる型エラーは保存しなくても指摘されるはず(前者は即時、後者は少しラグがある)
rustcじゃないと検出できないものは確かに保存時しか出ないかもね
特に害あるものじゃないしauto save有効にしても良いのでは？

**デフォルトの名無しさん** · 2021/10/02(土) 23:35:42.15

>>589
実際にビルドしてみてそのエラーメッセージをエディタに反映するという仕組み (いわゆる flycheck) は昔からあったんだが、
頻繁に実際にビルドするんじゃなくて処理系の構文解析プロセスとエディタを連携させればもっと効率的なんと違うか？という
のがマイクロソフトによって LSP (Language Server Protocol) として標準化されたという経緯がある。

エディタにとっては場当たり的なエラーメッセージの解析をせずによくなったので昔より楽になってるんだよ。
昔から flycheck をやってるようなエディタはだいたい LSP にも対応してる。

**デフォルトの名無しさん** · 2021/10/04(月) 23:18:59.60

https://thenewstack.io/linus-torvalds-on-community-rust-and-linuxs-longevity/
> “Probably next year, we’ll start seeing some first intrepid modules being written in Rust, and maybe being integrated in the mainline kernel.”

**デフォルトの名無しさん** · 2021/10/05(火) 01:50:58.24

統合早いな。多言語プロジェクトでcargo面倒くさい問題はなんかやってんだろうか？
統合されたらソース読んでみよ。

**デフォルトの名無しさん** · 2021/10/05(火) 03:19:27.62

言語を組み合わせる場合を含めてビルドプロセスの記述はなんだかんだで make が万能なんだよな。
クソみたいに場当たり的だけど必要だから機能を追加してきたという現実の前には
どんな美しいパラダイムも砂上の楼閣という印象だわ。

**デフォルトの名無しさん** · 2021/10/05(火) 11:23:44.05

cargoが勝手にクレートダウンロードしてくれるのは便利だけどね
セキュリティ的には……どうなんかなー

**デフォルトの名無しさん** · 2021/10/05(火) 11:55:21.23

ビルドはmakeからrustc呼ぶ形になってたはず
カーネルに関してはクレートのダウンロードなんかもしないならそれで問題ない

**デフォルトの名無しさん** · 2021/10/05(火) 12:47:41.98

余計なことするツールに限ってモジュラリティ低い

**デフォルトの名無しさん** · 2021/10/05(火) 12:55:43.82

>>596
既存のものがクソだから俺が全く新しいクールな奴を作ってやるぜ！っていって新しいクソが1つ増えるのはもはや伝統芸やね

**デフォルトの名無しさん** · 2021/10/05(火) 15:46:57.33

>>597
そのための --offline オプション

**デフォルトの名無しさん** · 2021/10/05(火) 18:59:42.65

>>600
makeの機能を持つprologは欲しいなぁ。

論理プログラミング言語を拡張したmakeとか堅牢そうな気がするけど、誰もやらないのかしらん。

**デフォルトの名無しさん** · 2021/10/05(火) 20:24:54.05

>>602
prolog難しいから流行らない

**デフォルトの名無しさん** · 2021/10/05(火) 21:06:12.38

宣言的なものの依存がゴタゴタしたもののデバッグのしずらさを知らんのだろう。呑気なもんだ。

**デフォルトの名無しさん** · 2021/10/06(水) 17:08:43.54

rust-analyserだかに移行しようとうおもったけどemacs とは相性悪過ぎて結局rlsに戻した
analの方はcodeいれんとインストール出来んかったりとほぼvs用だなあれ(´・ω・｀)

**デフォルトの名無しさん** · 2021/10/06(水) 18:10:02.17

>>605
lsp-modeとの組み合わせで普通に使えるが

**デフォルトの名無しさん** · 2021/10/06(水) 19:54:44.67

マジかeglot使ってたからかも
何かfunction defとかの問い合わせ方法間違ってんのか知らんが常にno docみたいのがmessage表示されて使いもんにならんかった
lspってマジで全然分からんちんで小鳥の餌待ち状態で微塵も弄れないのよね俺(´・ω・｀)

**デフォルトの名無しさん** · 2021/10/06(水) 23:28:27.48

rlsもlspだよ
rlsのlsはlanguage serverのls

**デフォルトの名無しさん** · 2021/10/06(水) 23:40:35.33

>>607
標準ライブラリのソースコードがないとか？
rustup component add rust-src
で入ると思う

**デフォルトの名無しさん** · 2021/10/07(木) 00:12:56.69

あんま多くは試しでないがrust-analyzerインストールする時に入れさせられたvscodeではanal pluginで動いてたしanal自体はインストール出来てると思うんだがな

>>608
そのfuckin msの策定したlspを部分的にとか言語ごとに異なるoverrideてかimplで構成するプロジェクト群がrust-analyzerとかclangdだかとかgoplzとか
ただこれらだけじゃ意味不明のjson object返したり読み込んだりするだけのdaemonで役に立たないから
仲介者としてのeglotとかlsp-modeが必要になる
ここらまでも簡単に弄れるというか(弄れる必要があると言うのか...)がemacsの良いところ(´・ω・｀)

**デフォルトの名無しさん** · 2021/10/07(木) 06:40:58.97

anal plug?

**デフォルトの名無しさん** · 2021/10/07(木) 11:35:48.71

インストールもなにも実行ファイルのパス通すだけだからね
~/.vscode/ 配下にあるはずだからそれを使うか GitHub からダウンロードしてくれば良い

**デフォルトの名無しさん** · 2021/10/08(金) 22:14:06.47

べき剰余をオーバーフローさせずに作る関数を作ったヽ(´ー｀)ノ

fn calc(num: usize, pow: usize, m: usize) -> usize {
　let mut bit: usize = 1;
　let mut res: usize = 1;
　let mut tmp_pow: usize = num;

　while pow >= bit {
　　if pow & bit > 0 {
　　　res = (res * tmp_pow) % m;
　　}
　　bit = bit << 1;
　　tmp_pow = (tmp_pow * tmp_pow) % m;
　}
　res
}

**デフォルトの名無しさん** · 2021/10/09(土) 10:18:30.30

>>613
普通にオーバーフローするが
calc(usize::MAX, usize::MAX, usize::MAX-1);

**デフォルトの名無しさん** · 2021/10/09(土) 11:49:04.73

多分競プロのやつだから各数値は32bitなんだろう
そらオーバーフローしねえよって話

**デフォルトの名無しさん** · 2021/10/10(日) 09:49:29.12

都合のいい仮定置いてそうなのがらしい感じだわな

**デフォルトの名無しさん** · 2021/10/10(日) 11:17:36.59

↓これと同じアルゴリズムなのに>>613のは読みにくいね
https://ja.wikipedia.org/wiki/冪剰余#途中で剰余をとる

u64で受け取って内部ではu128で計算して
u64で返すようにしとけばオーバーフローしない

**デフォルトの名無しさん** · 2021/10/10(日) 11:36:29.13

u16ならu32、u32ならu64、u64ならu128みたいな関係をジェネリクスで表現できたりする？

**デフォルトの名無しさん** · 2021/10/10(日) 11:52:04.33

trait作ってassociated typeで表現するのはできるかな

**デフォルトの名無しさん** · 2021/10/10(日) 12:00:59.32

関連型使えよ

**デフォルトの名無しさん** · 2021/10/10(日) 12:15:12.30

Traitを各データ型に対して全部実装するのが面倒だから
対応する倍のサイズの型を表現する方法はないのかなって話だったんだけど
なさそうってことだね

**デフォルトの名無しさん** · 2021/10/10(日) 16:41:29.53

コンパイラを単純化（高速化）するためにプリミティブ型の型クラスはありません。例えば、Haskellに
あるような数値型全般を表す Num という型クラスは、数値型全般を表しますが実体は IntやDoubleなど。
またはtypescriptのtype Tree = Leaf | Nodeはサポートされません

**デフォルトの名無しさん** · 2021/10/10(日) 17:11:17.77

rustはどちらかと言えばほとんどをトレイトで表現しますが、技術的にはこれらは、Tagged unionと呼ばれ
昔はSum typeともバリアント型とも呼ばれていました。プリミティブ型ではありませんが、似た機能を実現
する技術はenum variantsでも表現できます。C20にあるstd:variantもTagged unionです
もちろんassociatedでも似たことは出来るでしょう
https://en.wikipedia.org/wiki/Tagged_union

**デフォルトの名無しさん** · 2021/10/10(日) 17:13:00.50

>>622
num-traitsとenum

**デフォルトの名無しさん** · 2021/10/10(日) 19:43:56.21

>>621
マクロの使いどころ

**デフォルトの名無しさん** · 2021/10/10(日) 19:46:17.72

>>622-623 の言ってることが何一つわからんのだが

**デフォルトの名無しさん** · 2021/10/10(日) 19:56:58.54

>>622
おっしゃる通りですがRustでは別の解決方法を取っていますね

まず前者の全般的なNum型がない件ですが
Rustでは単純な例だと以下のように1を足す関数add1ををジェネリックに書こうとすると
(注釈: 足し算の「+」はstd::ops::Add traitを満たせば使えて任意の型でオーバーロード可)
fn add1<T: std::ops::Add<Output=T>>(n: T) -> T {
　n + 1
}
これはコンパイラが通らなくて「1」を型Iにする必要があり「1::<T>」等とでも書ければいいのですが無理です
そこでnum craitのOne traitを使って以下のように書きます
fn add1<T: std::ops::Add<Output=T> + num::One>(n: T) -> T {
　n + num::one::<T>()
}
これで以下のようにジェネリックに1を足すことができました
assert_eq!(add1(36), 37);
assert_eq!(add1(5.0), 6.0);
assert_eq!(add1(1000i128), 1001i128);
さらにこの方式ならば自分で定義する構造体など任意の型もAddとOneのtraitを満たせばadd1()を使える利点があります
つまり最初の話に戻ると全般的なNum型があるよりももっと高度なことができるわけです

後者の件は一般的に代数データ型の直和をどう扱うかという話になりますが
Rustではenumがタグ付き共用体でもあるのでenumでサポートできますね

**デフォルトの名無しさん** · 2021/10/10(日) 19:58:36.14

>>617
rustは可変参照を基本的に好まないスタイルだから、ああなるのは仕方ないな

**デフォルトの名無しさん** · 2021/10/10(日) 21:20:06.28

他人のフリして自分のレスに返信してるやつなんなのwww

**デフォルトの名無しさん** · 2021/10/10(日) 21:23:34.82

>>628
可変参照は関係あるのかな？
どちらもbit処理を下から順にするアルゴリズムで変わりなく
>>613はbitマスクを大きく(左シフト)していく方法
>>617はbitマスクは常に1で本体を小さく(右シフト)していく方法の違いだけだよね
だから後者の方式でもRustでコーディングできて動くよね
両者の差分
　 fn calc(num: usize, pow: usize, m: usize) -> usize {
　-　let mut bit: usize = 1;
　+　let mut bit: usize = pow;
　　let mut res: usize = 1;
　　let mut tmp_pow: usize = num;
　
　-　while pow >= bit {
　-　　if pow & bit > 0 {
　+　while bit > 0 {
　+　　if bit & 1 > 0 {
　　　　res = (res * tmp_pow) % m;
　　　}
　-　　bit = bit << 1;
　+　　bit = bit >> 1;
　　　tmp_pow = (tmp_pow * tmp_pow) % m;
　　}
　　res
　 }

**デフォルトの名無しさん** · 2021/10/11(月) 00:12:55.43

>>630
アルゴリズムではなくて、ポインタを渡すのか、実数値を渡すのか
そこを明確にしているRustの仕様から引数を可変参照にするのは・・という意味では

そして>>617が何を読みにくいといっているのかも、よくわからんし

**デフォルトの名無しさん** · 2021/10/11(月) 00:34:40.68

>>624 >>627
がねがねその通りで、言った通りトレイトだが、「Num型があるよりももっと高度なことができる」これは弁明的。
近代的な言語はmixinもしくはアドホック多相で（高度なことが）出来る場合がほとんどであり、無いものを無いと
要求できず弁護をするのはちょっと違う。他にも角度のように、0-360まで制限したいプリミティブ型が欲しいのに
PascalのようなSubrange型も足りていない。範囲を表す表現、0..360はあるのに。些細な事だが、コンパイラを
速くする事を現在は主眼なので（仕様に矛盾が無ければ）いずれは拡張されるのかもしれないが

**デフォルトの名無しさん** · 2021/10/11(月) 06:54:36.68

mutをつけたベクター型について教えてください
これはまず、入っているのは参照なんですか？
また、参照が変わらない(?)のに、参照先を変更するにはmutがなぜ必要になってくるのですか？
(所有権概念のせいなのでしょうか？それともスマートポインタの仕組み上、参照するアドレスが変わるのでしょうか？)

**デフォルトの名無しさん** · 2021/10/11(月) 08:28:39.20

>>633
let mut x = vec![1,2,3];

xに入ってるのはVec<i32>、これはスマートポインタ(pointer, capacity, length)。
「参照」というのはRustでは&Vec<i32>のようにアンパサンドがついてる型のこと
なのでxに入ってるのは参照ではない

例えばx.push(10)するのにxがmutじゃなきゃいけないのは
直接的にはpushのシグニチャが&mut selfを要求してるからだけど
考え方としては「multiple readers or single writer」ルールをコンパイル時に強制するため

連続したバッファを確保できなければアドレスが変わる可能性も有るし
ゼロキャパシティなら具体的なアドレスを持ってない

**デフォルトの名無しさん** · 2021/10/11(月) 13:32:30.30

Cortex-M対応がClangよりRustの方が進んでいて草

**デフォルトの名無しさん** · 2021/10/11(月) 14:07:37.59

core::ptr::unique::Uniqueもalloc::raw_vecもただのdoc(hidden)なのに
Vecがスマートポインタってデタラメ広めてる奴らどこが出処だよ。

以下の関係で、
Vec has-a RawVec
RawVec has-a Unique

- Vecがrustの作法を強制するためのnewtypeパターン←composition
- RawVecが動的配列の低レベルapi←composition
- Uniqueがユニークポインタ←smart pointer

これだけだろ。
rustのコレクションはデータ構造上直接実装することになる型以外
Box含めて基本newtypeパターン(composition)だぞ。

>>633
GCのある言語しか触ったことない限りその発想にはならんから
まずアロケータの仕組みからやりな。

**デフォルトの名無しさん** · 2021/10/11(月) 14:34:19.59

ホラふきがあらわれた！

**デフォルトの名無しさん** · 2021/10/11(月) 14:44:50.63

また他人のフリして間違いを指摘するレスが来るから乞うご期待www

**デフォルトの名無しさん** · 2021/10/11(月) 15:28:05.06

compositionだからスマートポインタでないという理屈だと Rc も Arc も非公開な内部型の composition だからスマートポインタでなくなってしまう

**デフォルトの名無しさん** · 2021/10/11(月) 15:42:18.11

>>636
C++のことは一旦忘れて、Rustにおけるスマートポインタの意味を学ぶことをすすめる
https://doc.rust-lang.org/book/ch15-00-smart-pointers.html

**デフォルトの名無しさん** · 2021/10/11(月) 18:57:50.60

>>640
The concept of smart pointers isn’t unique to Rust: smart pointers originated in C++ and exist in other languages as well.
とあるけど？

**デフォルトの名無しさん** · 2021/10/11(月) 19:29:34.65

We’ve already encountered a few smart pointers in this book, such as String and Vec<T> in Chapter 8, although we didn’t call them smart pointers at the time. Both these types count as smart pointers because they own some memory and allow you to manipulate it. They also have metadata (such as their capacity) and extra capabilities or guarantees (such as with String ensuring its data will always be valid UTF-8).

というわけで Rust の定義では Vec<T> はスマートポインタ

**デフォルトの名無しさん** · 2021/10/11(月) 20:38:32.88

クイズ: この中にウソはいくつウソがある？

「またはtypescriptのtype Tree = Leaf | Nodeはサポートされません」
「rustはどちらかと言えばほとんどをトレイトで表現しますが、技術的にはこれらは、Tagged unionと呼ばれ昔はSum typeともバリアント型とも呼ばれていました。」
「rustは可変参照を基本的に好まないスタイルだから、ああなるのは仕方ないな」
「Vecがスマートポインタってデタラメ広めてる奴らどこが出処だよ。」

**デフォルトの名無しさん** · 2021/10/11(月) 23:52:58.48

>>633
pub struct Vec<略> {
buf: RawVec<T, A>,
len: usize,
}
pub struct RawVec<略> {
ptr: Unique<T>,
cap: usize,
alloc: A,
}
pub struct Unique<T: ?Sized> {
　pointer: *const T,
　_marker: PhantomData<T>,
}
push|insertの際にlen|capとアロケート先が変化するという事、上のは難しい事をわざと言ってる
スマートポインタ議論は無視でOK。しかしPhantomDataなんて理解してる人に会ったことない

**デフォルトの名無しさん** · 2021/10/11(月) 23:58:39.10

>>631
その冪剰余関数の引数は全て数値すなわちCopy traitを持つので
関数呼び出しに参照を渡す必要はありません

また、可変参照の数値を渡す必要がある別の関数がもしあったとしても
普通に値を渡して変更値は返り値とする方がわかりやすいでしょう

**デフォルトの名無しさん** · 2021/10/12(火) 02:02:02.32

>スマートポインタ議論は無視でOK。
他人のフリして我がフリ直せww

**デフォルトの名無しさん** · 2021/10/12(火) 02:33:26.85

>>633
初級者ならばこのスレで言及されている内部実装の話は知らずとも使えるので無視してもよい
それよりもmutableとimmutableの意味となぜ区別が必要かを理解したほうがいい
あと参照の意味も理解していないようだからそこもまず基本だからおさえるべき
それら基本を理解すればVecの中身が書き換わるならばmut指定が必要とわかるはず
Rustは簡素に理解しやすく出来ているのに他言語のポインタ周辺の概念を無駄に持ち出してきて難しく考えて失敗する人たちが一部いる

**デフォルトの名無しさん** · 2021/10/12(火) 07:19:09.45

これが基本を理解してないと指摘されたやつのレスw

**デフォルトの名無しさん** · 2021/10/12(火) 08:17:13.13

Rusterは他人を同一人物と思い込む素性の悪い病人しか居ないな

**633** · 2021/10/12(火) 08:42:15.75

初心者丸出しの質問で、なんでこうなった・・・・・

**デフォルトの名無しさん** · 2021/10/12(火) 10:28:07.94

>>647
>Rustは簡素に理解しやすく出来ているのに

それには賛同できない

**デフォルトの名無しさん** · 2021/10/12(火) 10:28:20.90

このスレにはアンチRustのC++爺さんと
間違った知識を上から目線でレスするRust初心者が各1名住み着いてるから

質問者は回答内容を自分で精査しないとダメだよ
特に後者はタチが悪いので注意して

**デフォルトの名無しさん** · 2021/10/12(火) 10:37:06.05

Rustに近々追加される機能で熱いものなにかありますか？

**デフォルトの名無しさん** · 2021/10/12(火) 10:43:27.65

Rustに関する質問はteratailで

**デフォルトの名無しさん** · 2021/10/12(火) 10:55:07.59

現時点でRustなんかどうでもいい
10年後に普及してたら一般プログラマーも使う程度

**デフォルトの名無しさん** · 2021/10/12(火) 11:09:47.63

653見る前に654書いちゃったのでちょっと訂正
Rustに関するまじめな質問はteratailでするのがよい

>>653
もうすぐRust2021がくるぞい
熱いのがあるかっていうと微妙かも

**デフォルトの名無しさん** · 2021/10/12(火) 11:23:31.59

>>650
mutの必要有無は他言語では一般的じゃないRustのルールに関連してるんだけど
それが少し難しいので回答する側にもそのルールを理解してない人がそれなりにいるということ

基本的にコンパイラが教えてくれるので深く理解してなくても使う分にはそこまで問題にはならない

**デフォルトの名無しさん** · 2021/10/12(火) 12:59:59.43

Rustを知るということは、弱点も知ることにつながる

**デフォルトの名無しさん** · 2021/10/12(火) 13:01:46.79

vlangもmutがあるが散々否定される、曰く「理論に沿ったコンピューター工学を元にしてない」だとか
「トランスコンパイラでしょ」とか、NoGCが過大広告でLobsterというのは分かるがリークするでしょとか

**デフォルトの名無しさん** · 2021/10/12(火) 13:21:05.00

async/awaitの追加で一旦大きな機能追加目標は終わって、以降は処理系の効率化にリソースを割いていく、みたいな話を読んだ気がする

**デフォルトの名無しさん** · 2021/10/12(火) 13:54:32.71

結局他の言語でのメモリモデルも理解してないとrustはまともに使えんよ。
そこを誤魔化すやつはクソだわ。

**デフォルトの名無しさん** · 2021/10/12(火) 14:51:47.32

>>633
Rustは書き換え競合を避けるために、書き換え可能な可変参照(for writer)と、書き換えられない参照(for reader)の区別をして、
書き換えられない参照は同時に複数を持てる(multiple readers)けど、可変参照は同時に一つだけしか許さない(single writer)とすることで、競合を避けている。
Rustではmutかどうかもその観点からなので、変数が別のVecになるだけでなく、同じVecのまま配列内容や長さの変化しても、内容長さ同じだが領域拡大で場所移動でも、書き換わりとしてmutが必要。
だから、Vecのメソッドでmutを要求してるのはそれらの結果論にすぎないし、Vecの内部構造がこうなってるからという説明は不要で筋違い。

>>661
それは違うな。
むしろ頭を一旦ゼロにする柔軟な人ほど理解が早い。
他言語での様々なモデル(メモリモデルやクラスモデルや…)をベースに難しく考える人ほど混乱して理解が遅い。

**デフォルトの名無しさん** · 2021/10/12(火) 14:59:49.12

>むしろ頭を一旦ゼロにする柔軟な人ほど理解が早い。
>他言語での様々なモデル(メモリモデルやクラスモデルや…)をベースに難しく考える人ほど混乱して理解が遅い。
これを本気で考えてるならバカとしか言いようがない。
C、もしくはアセンブラをバインディングした時に確実にぶっ壊れるコードになるわ。

**デフォルトの名無しさん** · 2021/10/12(火) 15:34:41.08

>>663
それはABIやFFIの話であってRustの話ではない。
Rustで完結するシステムでは一切考慮する必要ない。
他言語ライブラリなど利用の際も、適切な仲介モジュールがあれば、利用側で考慮する必要はない。
各言語との連携部分では、それぞれその言語の知識が不可欠なのは当たり前。
だが、それはRustの話ではなく、Rustにおいてはその知識は必要ない。

**デフォルトの名無しさん** · 2021/10/12(火) 16:09:45.89

メモリモデルって並行プログラミングやらないならあんまり関係なくない？？？

**デフォルトの名無しさん** · 2021/10/12(火) 16:12:51.35

アトミック操作のOrderingの話なんかはC++の定義に丸投げしてるから他の言語の知識が必要というのは一応正しい

**デフォルトの名無しさん** · 2021/10/12(火) 16:27:05.41

>>666
それは理解するのにC++の知識を一切必要としない。
なぜならC++言語仕様とは独立して定められている。
つまり、その件についてもRustを理解習得するために他の言語の知識は必要ない。

**デフォルトの名無しさん** · 2021/10/12(火) 18:24:19.63

>>662
「Vecの内部構造がこうなってるからという説明は不要で筋違い」うーん、それこそ趣旨が違うよ。
vec[0] = 2などとして内容長さ同じの場合の理解では、１つの可変参照と、複数の参照を持つ事を
知っているのは必要だが通常では長さや容量が拡張されるpushやinsertは内部構造により説明される。
mutatorであるpushを呼ばない限りはmutは必要なければ、「mutをつけたベクター型」では無くて
配列という質問になるのでは？

**デフォルトの名無しさん** · 2021/10/12(火) 19:12:36.47

>>668
公開(pub)されていないstruct Vecの内部構造や非公開のRawVecなどを持ち出してくる人たちがいるから、
「Vecの内部構造がこうなってるからという説明は不要で筋違い」と書いた。
そこは長さや容量を持っている等の概念の理解だけで十分であるし、実際に公表されている情報もそこまで。

**デフォルトの名無しさん** · 2021/10/12(火) 19:33:58.77

>>667
C++の知識を「あまり」必要としないのは確かだがC20/C22などの仕様を「参考」にしているのは明らか。
というかLLVMから見てClangっぽく見えるように頑張っていると公式が言っている

**デフォルトの名無しさん** · 2021/10/12(火) 19:37:41.99

>>669
なるほど言いたい事は理解してるが、長さや容量を持っている等の概念の理解ならライブラリソースを
示した方が明らかでしょう。親切だと褒められる事はすれど不要と切って捨てるほどではないのでは？

**デフォルトの名無しさん** · 2021/10/12(火) 21:00:30.83

>>664
rustが単独で使われるなんてことは絶対にない。
低レイヤーのことがまるでわかってないってことがよくわかったよ。

**デフォルトの名無しさん** · 2021/10/12(火) 22:00:42.97

>>662
「multiple readers or single writer」のセーフティルールは
参照だけに適用されるものではなくて参照の所有者を含めて適用されるもの

**デフォルトの名無しさん** · 2021/10/12(火) 22:09:23.38

>>672
Rustでプログラムを書くに当たってRustを構成する様々な低レベルのレイヤーのうちどこまで書き手は意識すべきと考えますか？

さすがにCPUを構成するシリコンひとつひとつの振る舞いを意識することは出来ないので、
これより先は気にしなくて良いという境界は存在すると思うのですが、それはどのあたりにあるとお考えでしょうか

**デフォルトの名無しさん** · 2021/10/12(火) 22:18:28.12

>>672
no_stdでさらにシステムコール(あるいは相当)はasmでレジスタ渡しで呼び出しに至るまでRust完全単独で既存OS(など)利用もあるしOS作成ならOS側もRust単独

**デフォルトの名無しさん** · 2021/10/12(火) 23:07:50.81

>>664
>Rustで完結するシステムでは一切考慮する必要ない。

それって議論の価値ある？　だって現実的じゃないじゃん
研究者のための言語だっていうなら、それもありだけど
ここにいる人間は実用を求めてるわけでしょ。多分……

**デフォルトの名無しさん** · 2021/10/12(火) 23:22:14.99

すまんが何を言っているかさっぱり分からない
自分が書いてるのは9割方Rustで完結したプロジェクトだけど、みんなFFIばっかり書いてるのか？

**デフォルトの名無しさん** · 2021/10/12(火) 23:52:39.59

Win32APIとリンクしたり、そういうプログラムは書かないってことね

**デフォルトの名無しさん** · 2021/10/12(火) 23:56:08.22

Win32API使いたいんなら単にwindows-rsクレート使えば良いだけで
その先のC ABIがどうなってるかとか気にする必要はないと思うが

**デフォルトの名無しさん** · 2021/10/12(火) 23:57:43.15

ああでもwindows-rs自体は割とunsafe あるから気にしないとダメかな