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(金) 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

メッ

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

そんなくだらない疑問より誰か>>758に答えてくれませんでしょうか

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

>>802
implにunsafeって書かないといけないのと同じことだけど
implを書くやつが要求されてるsafetyルールを担保しないといけない

そのためのマーカー

**デフォルトの名無しさん** · 2021/10/21(木) 16:35:52.56

うんこすれっど

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

>>791
sync_channelってのがあるのか。ありがと。
ちゃんとランデブーもできるって書いてあるな。

**デフォルトの名無しさん** · 2021/10/23(土) 00:54:23.67

Rust 1.56.0 リリース！
https://tech-blog.optim.co.jp/entry/2021/10/22/080000

**デフォルトの名無しさん** · 2021/10/23(土) 01:45:44.26

let x = f64::cos(3.14);
みたいなのをf64::を省略して書きたいのですがどうすればよいですか？
use f64::cos; みたいなことはダメなようです

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

1回はf64と言わないと伝わらないので
let p = 3.14_f64;
let x = p.cos();

**デフォルトの名無しさん** · 2021/10/23(土) 14:40:08.49

すみません、p.cos()の記法がなんかイヤでcos(p)みたいな記法をしたいってことでした

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

use f64
でだめなら無理じゃね

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

modなら確かにuseで省略できるけど
Box::newのBox::を省略したいみたいな話だしなあ

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

fn cos(x: f64) -> f64 {
f64::cos(x)
}

cos(3.14)

素直にp.cos()のほうがいいとは思う

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

let cos = f64::cos;
ならいける

https://play.rust-lang.org/?version=stable&;mode=debug&edition=2021&gist=3c7b96b61723e46d132c9e0f2d46911b

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

fn main() {
println!("{}", cos(&32));
println!("{}", cos(&4.5))
}

trait GetDouble {
fn get_double(&self) -> f64;
}

fn cos(num: &dyn GetDouble) -> f64 {
f64::cos(num.get_double())
}

impl GetDouble for f64 {
fn get_double(&self) -> f64 {
*self
}
}

impl GetDouble for i32 {
fn get_double(&self) -> f64 {
f64::from(*self)
}
}
https://play.rust-lang.org/?version=stable&;mode=debug&edition=2021&gist=cb0e5606622069ca33b0ef0971fa94b4
これでいこう

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

ジェネリックにしたいならIntoでいいんじゃないかな

fn cos(x: impl Into<f64>) -> f64 {
f64::cos(x.into())
}

**デフォルトの名無しさん** · 2021/10/23(土) 20:49:05.66

ジェネリックにしたいなら戻り値も引数に合わせたいのでは
num_traits::Float::cos など使うべき
https://docs.rs/num-traits/0.2.14/num_traits/float/trait.Float.html#tymethod.cos

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

文法でrustとc++/cが似ているって言うやつは何をもって似ていると言っているだろう
ムーブセマンティクスがデフォだし、classはない、for文はイテレータだし、変数と関数の宣言の違いがはっきりしているし
何よりも型は前置じゃないし

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

C++とスクリプト言語ぐらいしか知らないんじゃないの？

**デフォルトの名無しさん** · 2021/10/24(日) 14:55:21.00

>>817
誰がもなにもオフィシャルなドキュメントでC++に似せたと言っている
型引数が<>だったりブロックが{}だったりそういうレベルで似てると言っている

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

C/C++というよりC familyに似せたと言っていたからちょっとニュアンスは違ってくるか

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

>>819
ソースをくれ
公式で構文を似せたとか言っていないと思うが

C++: references, RAII, smart pointers, move semantics, monomorphization, memory model

https://doc.rust-lang.org/reference/influences.html

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

型名がintならc++ぽいというのはなんか違うんだよね
->とか<<<とか気持ち悪いことをし始めたらc++感が出てくる

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

>>821
http://web.archive.org/web/20150401014855/http://doc.rust-lang.org/nightly/intro.html
> you may find the syntax easier if you've used a "curly brace" programming language before, like C or JavaScript

確かに似せたとまでは言ってなかった

generics の angle bracket についてはコアメンバーが言及してるしC++の影響受けてると言って良いと思う
https://old.reddit.com/r/rust/comments/6l9mpe/minor_rant_i_wish_rust_had_gone_with_square/

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

C++ iostream の << 演算子をパクらなかったのは、やっぱりあれが失敗作だからだよね

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

>>823
thx、ソースまで探してくれてありがとう
個人的にはC++を感じるというエモーション(?)がどこなのかを聞きたかった

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

よくある質問
RustはLLVMの上に構築されており、LLVMから見てClangっぽく見えるように頑張っているので、LLVMの
性能が向上したらRustの性能向上にもつながります。
https://prev.rust-lang.org/ja-JP/faq.html

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

見た目はC++に似ているかも知れないけどML系列の方が近いんじゃない？
コンパイラがうるさいところとか「コンパイルが通れば大体動く」という感触はHaskellに近い
Vecに限定したくないなあとか関数に分けると型表記が面倒だなあとかはHaskellには無かったけど

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

move semanticsとかcall by ref(not call by val in terms of ptr)とかは他のスクリプトではないの多いしな(rakuぐらいじゃね？)
糞みたいに面倒なbig fiveとか書いて来てるc++ちゃんと理解してる連中はrustの基本部分の理解はかなり早そう

記法は全然似てないてかerror handlerの部分とか全くの別物になってるしな
比較的若いgoとかktとかの方が書いててなんとなく似てる様な気もする(´・ω・｀)

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

もう長いことC++書いてないけど、考えれば考えるほどC++つらいわ。昔の自分はよく書いてたな

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

本当はMLが好きな人がMozillaでC++書かされるのに疲れた結果生まれた言語なのでMLやC++の要素を併せ持つのは必然

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

>>828
GoやKotlinに似てたらc系列ぐらいの雑さでしょ

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

ChromeよりMozillaの方が性能良いことが、Rustを使うべきである証明になってるのでは？

**デフォルトの名無しさん** · 2021/10/24(日) 22:01:13.83

流石に乱暴すぎる

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

Chrome も Rust 使おうみたいな話なかったっけ

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

セルフホストされるまではOCamlで書かれてたので、Chromeより性能の良いMozillaを作ったRustを最初に実装したOCamlを使うべき証明になってるのでは？

**デフォルトの名無しさん** · 2021/10/24(日) 22:28:24.77

chromeユーザーだけどfirefoxの方が性能いいってマジなんか？

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

https://amethyst.rs/posts/amethyst--starting-fresh
アメジストが死んだ... ｴﾝﾀﾞｧｧｧｧｧｧｧｧｧｧｧｧｧｲﾔｧｧｧｧｧｧ
rustのゲームエンジンはbevy一強になるのか

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

GUIのツールキットはよ(｀･ω･´ )

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

ちゃんとリリースまでたどり着いたrustのゲームってあるの？

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

>>838
icedじゃだめなん?
>>839
今のところない
試作を含むならネット上に転がっているよ

bevyね...レンダラーがwgpuだからね
現状はレイトレーシングとか無理
ゲームエンジンに挑戦するいい機会かも

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

>>824
C++はシフト演算子をなぜ入出力に使いまわそうとしたのか未だに理解できない
見にくく＆わかりにくくなってる

**デフォルトの名無しさん** · 2021/10/25(月) 00:09:38.02

>>841
shellのリダイレクトに似てると思ったからだろ

**デフォルトの名無しさん** · 2021/10/25(月) 00:21:35.96

>>841
当時の C++ には可変長引数を現代的な型システムの枠組みで扱う方法がなかった。
(C++11 からは variadic template がある。これも今となっては現代的と言えるかどうか……。)
新しいオブジェクトを追加したときにオーバーロードが可能である必要など
の諸々の事情が積み重なって演算子オーバーロードの仕組みを使うのが妥当という結論になり、
オーバーロード可能な演算子の中で比較的それらしく見えるのが << だったという経緯。

記法だけなら printf で不満は出なかっただろうけど、
printf (というか C の可変長引数の仕組み) は型システム的な保護が全然できないぶっ壊れなので
それを是とすることも出来なかった。 (廃止もしなかったけど。)

良くはないが他にどうにも出来なかったんだよ。