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/15(金) 14:27:53.37

>>701
OSなんて書いたこともないくせに語るなド素人

**デフォルトの名無しさん** · 2021/10/15(金) 15:04:44.50

>>702
ソースコード読むことすらしてないバカは黙ってて。

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

なんか低レベルな話で盛り上がってるな

**デフォルトの名無しさん** · 2021/10/15(金) 15:16:50.75

そんなことよりシステムコールの呼び出しにCの知識は必要ないっていうコメント対して>>701のレスが噛み合ってないんだが、何を言いたかったのか解説してくれないか

**デフォルトの名無しさん** · 2021/10/15(金) 15:20:05.89

なるほど、レジスタからメモリ書き込みの同期タイミングなどが必要とかそこまで具体的に言わないと理解できないレベルなのか。
すげー馬鹿しかいないのなら仕方ないな。

**デフォルトの名無しさん** · 2021/10/15(金) 15:33:44.29

システムコールの呼び出しとはまったく関係ないな

**デフォルトの名無しさん** · 2021/10/15(金) 15:40:54.74

OS書いたことも無いのに恥ずかしい奴

**デフォルトの名無しさん** · 2021/10/15(金) 15:45:02.58

>>705
それな

> OSプログラムしてるとレジスタ内容をメモリに載せるなんて普通にあることなんだが。

何でいきなり一人だけ見当ハズレなこと言い出したのかだけでも説明してほしいわ

**デフォルトの名無しさん** · 2021/10/15(金) 16:38:42.56

>>701
Rustはインラインasmできるので好きなレジスタと好きな変数(メモリ)の行き来演算できるしRustだけでOSも書ける

**デフォルトの名無しさん** · 2021/10/15(金) 17:41:49.92

>>710
どうせunsafeなんだろ

**デフォルトの名無しさん** · 2021/10/15(金) 18:11:50.56

寒色は人権すらないからな

**デフォルトの名無しさん** · 2021/10/15(金) 18:54:33.37

>>711
そりゃアセンブリですから
safeにするには不変条件を満たすように自分でやらなきゃいけない

**デフォルトの名無しさん** · 2021/10/15(金) 18:55:28.40

Rust？　人気らしいね、でもオイラやらないよ
Cは嫌いだし、その後釜狙いの言語はどうせ肌に合わないさ
大半の人には必要ない言語だよね、だからオイラGoをやるよ

**デフォルトの名無しさん** · 2021/10/15(金) 18:58:20.72

GoのほうがよっぽどCの後釜感あるがな
GCのあるCという感じ

**デフォルトの名無しさん** · 2021/10/15(金) 19:22:21.57

>>711
unsafeを誤解しているようだけど
CやC++と同じ状況すなわちその部分のメモリ安全性は自己管理となるだけ
だから論理的に安全な操作でそれがローカルに閉じ込められて他に影響を及ぼさないならば使われうる
例えば標準ライブラリのVecもその内部実装の一部でunsafeが使われているが我々はVecを安全に使うことができる

>>715
つまりGoはCやC++の代替になれない

**デフォルトの名無しさん** · 2021/10/15(金) 19:27:43.08

rustの強みである静的メモリ安全性っていうのが活かせてないやんって意味で言ったんやけど
cやc++と同じ状況ならむしろrustよりcやc++使うよね？

**デフォルトの名無しさん** · 2021/10/15(金) 19:36:00.75

量の概念がないやつが定期的に現れるな
コード全域がunaafeなのと局所的なのは全然違うでしょ

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

>>717
例えばVecは実装内部でunsafeを用いているが
Vecはメモリ安全性を保証する
そしてVecを用いたプログラムもRustコンパイラが通ればメモリ安全性が保証される

**デフォルトの名無しさん** · 2021/10/15(金) 19:48:51.64

それならC++も同じでは？

**デフォルトの名無しさん** · 2021/10/15(金) 19:49:28.65

>>719
unsafeなのにメモリ安全性どうやって保証してるの？

**デフォルトの名無しさん** · 2021/10/15(金) 19:52:54.07

C++の場合は、vector自身がメモリーの所有権を持ってるので安全性が保障されるんだけど。

**デフォルトの名無しさん** · 2021/10/15(金) 20:08:04.69

>>721
え？何を言ってるの？
Vecに限らずRustの各型を含めた標準ライブラリの内部はもちろんunsafeだらけだけど
論理的に安全な操作のみ、かつ、内部に閉じ込められていて外部に影響を及ぼさないもののみ
だからそれら型を含めた標準ライブラリを我々は安全に使うことができる
そしてそららを用いた我々のプログラムはコンパイラが通ればメモリ安全性を保証される

**デフォルトの名無しさん** · 2021/10/15(金) 20:14:36.90

>>723
じゃあC++と変わりませんね。

**デフォルトの名無しさん** · 2021/10/15(金) 20:15:19.52

>>723
だからアスペか？
論理的に安全な操作のみ、かつ、内部に閉じ込められていて外部に影響を及ぼさないってことをどうやって保証してるのか聞いてんだけど？
国会の答弁みたいな返答やめろよ
というか外部にメモリ及ぼさないはメモリ安全性が保たれるの必要条件じゃないんだけど

**デフォルトの名無しさん** · 2021/10/15(金) 20:15:56.65

外部にメモリ及ぼさないじゃなくて外部に影響及ぼさないだった

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

>>724
C++はコンパイルが通ってもメモリ安全性は保証されません
Rustはコンパイラが通ればメモリ安全性が保証されます
全く異なります

>>725
論理的にそれらを満たす操作かどうかです
Rustコンパイラが通ればメモリ安全性を保証するかどうかも論理的に基づいて保証されます

**デフォルトの名無しさん** · 2021/10/15(金) 20:33:33.14

>>727
メモリ安全性を保証することを諦めればコンパイル通るのは当然だよね？
こんな基本的なこともわからないんですか？

**デフォルトの名無しさん** · 2021/10/15(金) 20:36:47.57

Cしか知らない人ってプログラミング言語の仕様とコンピュータのアーキテクチャが区別できないってマ？
型理論も知らないってマ？

**デフォルトの名無しさん** · 2021/10/15(金) 20:40:52.58

>>728
その通りでC++はコンパイルが通ってもメモリ安全性が保証されない言語
一方でRustはコンパイルが通ればメモリ安全性が保証される言語

**デフォルトの名無しさん** · 2021/10/15(金) 20:50:24.31

>>730
>unsafeを誤解しているようだけど
>CやC++と同じ状況すなわちその部分の>メモリ安全性は自己管理となるだけ
って自分で言ってるよね？自分の過去の発言と言ってること矛盾してない？
rustのunsafeはメモリ安全性を保証することを諦めてるって言いたかったようだけど今は言ってること無茶苦茶じゃない？

**デフォルトの名無しさん** · 2021/10/15(金) 20:51:16.86

>>722
これが一般的なC++erの認識だとしたら恐ろしいな

**デフォルトの名無しさん** · 2021/10/15(金) 20:58:34.88

unsafeなコードが周りを滅茶滅茶にしない保証は無いよ

**デフォルトの名無しさん** · 2021/10/15(金) 21:01:02.97

unsafeを使った場合の安全性の保証を機械的にやりたければ↓みたいなので契約プログラミングする手はあるね
https://crates.io/crates/contracts

**デフォルトの名無しさん** · 2021/10/15(金) 21:10:23.11

>>731
もちろんRustの標準ライブラリの実装内部には多数の細かい小さなunsafeがあってその部分はコンパイラによるメモリ安全性保証の範囲外
それそれの内部ローカルのunsafe使用が論理的にメモリ安全であるか否かの保証はコンパイラではなく人間が行ないunsafeはそのためにある
その上でRustコンパイラはプログラム全体のメモリ安全性を保証する

**デフォルトの名無しさん** · 2021/10/15(金) 21:17:10.00

>>735
人間がどうやって行うの？

**デフォルトの名無しさん** · 2021/10/15(金) 21:31:51.20

話は簡単だ
C/C++はプログラム全てがRustのunsafe状態
つまりC/C++はプログラム全てを人間がメモリ安全であると保証しなければならないが人間なので複雑化するとミスも生じる
GAFAM各社はメモリ安全に関するバグが全く減らずセキュリティ脆弱性の多くがこの問題に起因することに気付いた
そこでコンパイラがメモリ安全であると保証するRustを採用して少しずつC/C++から移行させていってる段階

**デフォルトの名無しさん** · 2021/10/15(金) 21:34:04.93

unsafe blockはマーが全力で頑張ります！ゾーンだからな
アルゴリズムにおいてあるアルゴリズムが正当であると判定するアルゴリズムは存在しないんだからラストコンパライでも完全なセーフティは保証は出来ないけどな
ただ完全ではないものの他の注意すべき所をランコンに任せてunsafe部にヒューマンリソース限定出来るのはc++を遥かに優れた点よね(´・ω・｀)

**デフォルトの名無しさん** · 2021/10/15(金) 21:39:33.56

布教しようとしなくたっていいんだよ
めんどくせえから

**デフォルトの名無しさん** · 2021/10/15(金) 21:42:55.26

>>737
GAFAがその体たらくとは信じがたいけど、resource管理は所有権ベースでほぼ解決するし、逆に所有権以外で解決することは出来ないと思う。

**デフォルトの名無しさん** · 2021/10/15(金) 21:45:54.09

>>738
チューリングマシンの停止性問題のこと言ってるんだろうけど違うよ
あるアルゴリズムじゃなくて任意のね
「あるプログラムが正当であると判定するプログラムは存在しない」じゃなくて「任意のプログラムを正当であると判定するプログラムは存在しない」が正しい
これが5chクオリティか

**デフォルトの名無しさん** · 2021/10/15(金) 21:58:02.76

Rustコンパイラによるメモリ安全性の保証は信頼してても、unsafe使ってる標準ライブラリを信頼しない話おもしろいね。
実際に問題なく動いてるんだから仕様を信頼すればいいのに。

**デフォルトの名無しさん** · 2021/10/15(金) 22:06:00.13

>>742
人間が局所的に注力すれば済むのがRust
人間がプログラム全般に注力しなければならず破綻したのがCとC++

**デフォルトの名無しさん** · 2021/10/15(金) 22:07:41.72

>>741
うーんまぁ日本語で論理学考える事なんてあんましないから間違えてるのかもしれんが
あるアルゴリズム、ある整数等々で俺はある集合(=アルゴリズム全体で構成される集合)の元の任意性を表してんたんだけどな(´・ω・｀)

**デフォルトの名無しさん** · 2021/10/15(金) 22:11:36.31

>>743
勝手に破綻したことにするのやめな？
そういうとこやぞお前マジ

**デフォルトの名無しさん** · 2021/10/15(金) 22:18:09.07

>>744
その言い訳は厳しいよ
まあワイもまともに勉強するまでもそこあたりあやふやだったしそんな気にすんなや

**デフォルトの名無しさん** · 2021/10/15(金) 22:39:44.83

>>740
C/C++に限界を感じたGAFAMたち大手IT企業がRustに結集
特定の言語がIT業界を挙げて支持されるのは初めて

プログラミング言語「Rust」のための「Rust Foundation」設立 -- AWS(Amazon)、Microsoft、Google、Mozilla、Huaweiが創設
https://japan.zdnet.com/article/35166267/

Facebookが「Rust Foundation」に参加
https://japan.zdnet.com/article/35170192/

**デフォルトの名無しさん** · 2021/10/16(土) 00:08:25.70

>>717
それどこの0か100しか無い世界？

**デフォルトの名無しさん** · 2021/10/16(土) 00:34:25.94

C++はこれで鼻から悪魔出るから

vector<int> hoge {0};
int& fuga = hoge[0];
for (size_t i = 0; i < 5; ++i) {
hoge.push_back(i);
}
cout << fuga;
}

nsafeがどうたらぬ気にしてRustはこういうのが防げるってだけでもそれなりの価値はある

ちなみにunsafeブロックは本当に慎重に作らないと、unsafeの外部をちょっといじっただけで鼻から悪魔が出たりする
https://doc.rust-jp.rs/rust-nomicon-ja/working-with-unsafe.html
unsafeブロック外のidx < arr.len()をidx <= arr.len()にしただけで死ぬ

**デフォルトの名無しさん** · 2021/10/16(土) 03:36:57.11

unsafeなコードが1行でもあったらRustで書く意味ないと主張する人が定期的に現れるのはなぜなのか

**デフォルトの名無しさん** · 2021/10/16(土) 03:54:24.52

>>750
C++が劣ることを認めたくない人が「unsafeがあるならC++と同じだからRustの存在意義はない。」という間違った主張をしてるみたい

**デフォルトの名無しさん** · 2021/10/16(土) 04:04:47.91

C++との対決は別の専用スレがあるのでそっち使ってくださいね

**デフォルトの名無しさん** · 2021/10/16(土) 04:11:16.75

>>752
同感
C++な人はここでやらずに
向こうの専用スレでやってほしい

C++ vs Rust
https://mevius.5ch.net/test/read.cgi/tech/1619219089/

**いつもの光景** · 2021/10/16(土) 07:19:55.59

Vec型の質問に高卒が答える
　↓
当然の如く高卒がバカにされる
　↓
高卒発狂
　↓
パソコンがどうの、C++がどうの、いつもの大先生問答に発展

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

>>749
ちなみになんでこれで悪魔がでるんですか？
無学ですみません

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

>>755
fugaがhogeのメモリ参照を取った後にhoge.push_back()でデータを追加している。
データ追加ではhogeの内部で確保していたメモリ領域が足りなくなると
新しいアドレスに確保しなおす（元の領域は開放する）ので、
fugaが指しているアドレスはアクセスしてはいけない領域になってる。（ダングリングポインタ）
その状態でcoutでfugaを使ってるから。

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

>>756
なるほど
ダングリングポインタになっているんですね
教えてくださってありがとうございます

**デフォルトの名無しさん** · 2021/10/16(土) 10:29:54.02

unsafeなtraitとそうでない通常のtraitってどう違うんでしょうか
implにunsafeって書かないといけない点以外で

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

バカは実際にバグが起きるかどうかを考えてなくて
バグを誰かのせいにできるかどうかしか考えてないんだろ。
だからこんなしょーもないものが持て囃されるってわけだ。

**デフォルトの名無しさん** · 2021/10/16(土) 13:08:52.57

東アジア圏は原因の究明と再発防止より責任の追及と処罰を優先する文化だからな
気をつければ問題ないみたいな精神論が平気で唱えられるのも同様
システム工学先進国のアメリカあたりと比べたらかなり後れている

**デフォルトの名無しさん** · 2021/10/16(土) 20:42:26.55

それは東アジア人の性質ってか東朝鮮の性質だろ(´・ω・｀)

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

CargoでC/C++のコードをビルドするときにヘッダファイル等の依存関係って何処まで面倒を見てくれるんだろ？
自分で全部記述しないとダメなのか、自動的に追跡してくれるのか・・・
ググってもCのコードも一緒にビルドできます以上の情報が見つからん

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

面倒見るわけねーじゃん。
ヘッダーファイル依存をまともに解決しようと思うと、ビルド速度に影響がモロに出る。
解決するには暗黙のキャッシュ使うことになって問題が起きやすくなる。

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

>>762
一番基本的なやり方だとcc crate使うことになると思うけど
このやり方だとヘッダやライブラリは自分で指定する必要ある
使ったことないけどpkg_config crateとか使えば多少は楽になるのかもしれない

C/C++コードが別プロジェクトからの流用ならそのプロジェクトのビルドツールに乗っかるのが楽かも
例えば cmake や autocfg/autotools といった crate はあるみたい

**デフォルトの名無しさん** · 2021/10/18(月) 12:25:26.72

>>749
vectorじゃなくて、listを使うと大丈夫。
C言語は、もともと、linked list が代名詞の様な言語。
それを引き継いだC++もstd::listこそが主役。
ところが、stroustrupがvectorを推奨するから混乱してる。

**デフォルトの名無しさん** · 2021/10/18(月) 12:39:56.60

>>765
それは初耳。誰が linked list が C の代名詞と言っているの？
経験上は配列使うことの方が多いように思うんだが

**デフォルトの名無しさん** · 2021/10/18(月) 15:20:57.34

>>765
std::listはn番目アクセス遅いよ
だからstd::vectorを利用するケースが圧倒的に多い

**デフォルトの名無しさん** · 2021/10/18(月) 15:29:58.26

listそんな使うことないやろ。挿入と削除が早いだけやんけ。何が言いたかったんだか。

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

確かにlistはあまり使った記憶がないなー
キャッシュのミスヒットを考えると、
vectorでリロケートした方が速い場合もあるし

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

listは敵キャラの弾幕なんかの座標管理なんかに使える

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

ほぼcだよねこれ。
https://github.com/Rust-for-Linux/linux

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

(Cで書かれてるLinuxカーネルのフォークなんだから当たり前やろ)

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

そもそも全部書き直すならLinuxを冠する意味が・・・

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

何で？
(全部書き直すなど誰も言ってないけど理由を聞いてみたい)

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

うん、それ、RustでLinuxを作り直してるんじゃなくて、元々のLinuxをベースにして、新しい機能をRustで開発しようとしているプロジェクトでしょ

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

嘘つき

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

日本語不自由どころか
頭が不自由だと拝察します

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

panicは無事無くなったんかな。

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

彡 ⌒ ミ
(´・ω・`) 頭が不自由という言葉が引っかかったので飛んできました

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

彡 ⌒ ミ
(´・ω・`) 飛ぶとかカッパの風上にも置けんな、泳げや

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

>>778
アロケーターのpanicのことなら7月に出たパッチでなくなったみたい
https://lore.kernel.org/lkml/20210704202756.29107-1-ojeda@kernel.org/

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

C++erはほんとゴシップ談義が好きやな
Rustスレにまでそのカルチャー持ち込まんで欲しいわ

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

ペチパーと大差ないからな

**デフォルトの名無しさん** · 2021/10/20(水) 10:48:38.28

ターゲットも開発者も丸かぶりだからしゃあない

**デフォルトの名無しさん** · 2021/10/20(水) 13:23:40.75

で、非同期ライブラリはどれが標準になるのよ？

**デフォルトの名無しさん** · 2021/10/20(水) 13:24:10.28

で、非同期ライブラリはどれが標準になるのよ？

**デフォルトの名無しさん** · 2021/10/20(水) 13:29:36.31

tokio

**デフォルトの名無しさん** · 2021/10/20(水) 16:05:21.56

std

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

どっちでもいいけど、インターフェースは統一して欲しいな。
今のところtokioか優勢みたいね。

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

std::sync::mpsc ってなんで send がノンブロッキングなんだろうなぁ。

**デフォルトの名無しさん** · 2021/10/20(水) 23:01:04.88

ブロッキングなSenderがほしいならchannel_sync使うんだべさ

**デフォルトの名無しさん** · 2021/10/20(水) 23:32:51.88

ブロッキングとかノンブロッキングとか何度か解説読んだ気がするけど意味がわからないわ

**デフォルトの名無しさん** · 2021/10/21(木) 00:05:01.15

迷惑な香具師だな

**デフォルトの名無しさん** · 2021/10/21(木) 02:48:53.14

おまいら mut のことを何て呼んでる？
俺は心の中でムットと呼んでいる

**デフォルトの名無しさん** · 2021/10/21(木) 02:53:24.97

ミュータブルの略なので……

**デフォルトの名無しさん** · 2021/10/21(木) 03:47:37.11

インテジャーはイント
キャラクターはチャー
なんだから、ムットでも何でも好きに呼べばよろし

ちなみに俺は心の中でムトゥと踊る^H^H呼んでる

**デフォルトの名無しさん** · 2021/10/21(木) 08:50:47.46

マッだろjk

**デフォルトの名無しさん** · 2021/10/21(木) 08:54:53.70

マットな

**デフォルトの名無しさん** · 2021/10/21(木) 11:02:50.76

cv::Mat は?

**デフォルトの名無しさん** · 2021/10/21(木) 13:03:22.69

>>799
メアット

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

メッ