Rust Part7

**デフォルトの名無しさん** · 2019/07/14(日) 23:31:47.54

Mozilla発のRust言語のスレ

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

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

前スレ
Rust Part6
http://mevius.5ch.net/test/read.cgi/tech/1532714678/

**デフォルトの名無しさん** · 2019/11/11(月) 19:57:31.41

てかメモリ安全なスクリプト言語さえまともに使えないやつに限ってrustとか騒いでんだよね。。
バカバカしい。。

**デフォルトの名無しさん** · 2019/11/11(月) 20:07:59.59

コンパイラより自分の腕を信じるって…
やっぱりジャップにはかなわねえや

**デフォルトの名無しさん** · 2019/11/11(月) 20:20:19.17

てか　で始める
限って　によるガバガバなレッテル貼り

クソバカ

**デフォルトの名無しさん** · 2019/11/11(月) 20:48:06.84

Cなら3で済みことを馬鹿に合わせてRustで20かけて作ることの意味があるのかどうかが問題だ

**デフォルトの名無しさん** · 2019/11/11(月) 21:23:31.49

3で済みこと

**デフォルトの名無しさん** · 2019/11/11(月) 21:42:08.98

あれｗ

**デフォルトの名無しさん** · 2019/11/11(月) 22:00:50.85

いきなりコント始めんなや

**デフォルトの名無しさん** · 2019/11/11(月) 22:28:55.57

イニシャルコストだけ論じても意味ないしょ
作って終わりの製品もあるのは確かだだけど

**デフォルトの名無しさん** · 2019/11/11(月) 22:30:05.95

>>633
ない

**デフォルトの名無しさん** · 2019/11/11(月) 23:21:00.62

>>641
ランニングコストも同じだよ
何をするにもコンパイラの機嫌伺いから入る必要があるんだから

**デフォルトの名無しさん** · 2019/11/12(火) 01:23:13.19

そんなこと言うなよ
コンパイラちゃんはどこが悪いかいつも教えてくれてるんだぞ
コンパイラちゃんの気持ちも考えろよ

**デフォルトの名無しさん** · 2019/11/12(火) 01:50:34.68

Item1とItem2で同じ構造しててそれぞれに似たような処理をしているのにItem2にだけCloneつけろとエラー出るんですが
理由がわかりません

エラーが出るコード
https://play.rust-lang.org/?version=stable&;mode=debug&edition=2018&gist=39e9b4899374d1aca90c64836d71c161

Item2にだけCloneつけて動くコード
https://play.rust-lang.org/?version=stable&;mode=debug&edition=2018&gist=568c3f827c59a417f8d1c0f91b6bc9e4

**デフォルトの名無しさん** · 2019/11/12(火) 03:38:31.37

>>645
vec!マクロで要素数指定する形はその型がClone実装してないとだめ

Item1も要素数指定すればCloneを要求される
let mut vs = vec![Item1 {a: 0, b: 0};10];

**デフォルトの名無しさん** · 2019/11/12(火) 05:17:14.07

>>646
説明ありがとうございます
理解しました！

**デフォルトの名無しさん** · 2019/11/12(火) 07:41:14.54

>>643
そんな短絡的なことを言っているんじゃないよ

**デフォルトの名無しさん** · 2019/11/12(火) 12:52:39.30

コンパイラがやかましければプログラムの質が上がるっていう
短絡的なこと言ってるのはどっちだか

**デフォルトの名無しさん** · 2019/11/12(火) 12:56:25.17

安全な言語を開発するようメーカーの方に心がけていただき、
kidsが安心してプログラムできるような、コンパイルできるような世の中になってほしい。

**デフォルトの名無しさん** · 2019/11/12(火) 14:55:56.85

「Rust言語」をWindowsプロジェクトに適用してみた、Microsoftの事例
https://www.atmarkit.co.jp/ait/articles/1911/12/news050.html

欲しい機能がまだまだある、Rustコミュニティーとも協調

Rustは比較的歴史が浅いため、Microsoft社内の開発に使うことを考えると、よく使う言語機能であっても欠けているものがあるという。
その最たるものは、安全な変換(“プレーンな古いデータ”型をrawバイトと間で相互に安全にキャストする)やCスタイルの共用体の安全なサポート、誤りを許容する割り当て(割り当ての失敗でパニックに陥らず、所定の手順で停止する)だ。

Cargoには優れた単体テスト機能が組み込まれているため、開発者が本番コードと同じファイルにユニットテストを記述して、開発中に簡単に実行することができる。だが、Microsoft社内の大規模で複雑なビルドシステムでは、Cargoをビルドツールとして利用できない。
そこでCargoチームとの間で、複雑なビルドシステムを持つ大企業がCargoを利用できるようにするための話し合いを開始している。

**デフォルトの名無しさん** · 2019/11/12(火) 15:08:35.31

「誤りを許容する割り当て」ってなんだ？
malloc失敗した時になんか処理したいって話？

**デフォルトの名無しさん** · 2019/11/12(火) 15:54:18.41

要約すると今のcargoはクソで落ち着く

**デフォルトの名無しさん** · 2019/11/12(火) 16:32:19.58

>>652
fallible allocation (fail gracefully from allocation failure, rather than panic).

https://msrc-blog.microsoft.com/2019/11/07/using-rust-in-windows/

**デフォルトの名無しさん** · 2019/11/12(火) 20:55:32.21

>>649
そんな短絡的なことを言っているんじゃないよ

**デフォルトの名無しさん** · 2019/11/12(火) 21:02:47.09

口で説明できないことは
大体は説明するとすごくろくでもないことだ

**デフォルトの名無しさん** · 2019/11/12(火) 21:04:03.04

おまえが理解してると信じ込んでるものが真実だという保証は一切ない

**デフォルトの名無しさん** · 2019/11/12(火) 21:07:52.77

欠点を論うだけの雑魚に対し、フィードバックして改善しようとするMS様は立派だな
現場でも文句ばかり垂れてるお爺さんいるよな

**デフォルトの名無しさん** · 2019/11/12(火) 21:09:26.54

何にも言わないで偉そうにしてるだけのやつが言うセリフじゃねえええええええ

**デフォルトの名無しさん** · 2019/11/12(火) 21:19:42.81

＞何にも言わないで偉そうにしてるだけ

なぜバレた！？

**デフォルトの名無しさん** · 2019/11/12(火) 21:46:17.93

茶々入れ小僧がわめくなよ

**デフォルトの名無しさん** · 2019/11/12(火) 21:49:03.55

MSはCargoでどういう場合困るんだろ
小さいものしか作ったことないし技術力も低いからわからない…

**デフォルトの名無しさん** · 2019/11/12(火) 22:11:56.20

俺も。。

**デフォルトの名無しさん** · 2019/11/13(水) 00:32:15.20

GoogleのBazelみたいな分散環境でスケールする独自のビルドシステムを持ってるから
cargo testとかやった時にcargoのインクリメンタルビルドの仕組みじゃなく
自分たちの仕組みと連携させたいってことなんじゃないかと

**デフォルトの名無しさん** · 2019/11/13(水) 03:04:21.12

>>651
「使ってみたけどやっぱダメだったわ」をオブラート10枚くらいに包んだ
奥ゆかしい日本語の記事って感じだな

**デフォルトの名無しさん** · 2019/11/13(水) 05:44:21.88

Copyトレイトはプリミティブ型のように値としてコピーされるのが自然な型に付ける

コピーされるのは自然でない型でコピーをしたい場合にCloneトレイトでコピーを行なってると明示できるclone()メソッドを使ってコピーする

**デフォルトの名無しさん** · 2019/11/13(水) 07:36:30.61

あっちの企業って大企業でもOSSプロジェクトが使えると判断されたら支援もするけど日本じゃさっぱりだよな

**デフォルトの名無しさん** · 2019/11/13(水) 08:07:59.49

くれくれが多いと難しい

**デフォルトの名無しさん** · 2019/11/13(水) 08:59:29.70

>>665
ほとんど英語記事の翻訳なんだが日本語訳された結果も
配慮してくれるなんてすごいな～

**デフォルトの名無しさん** · 2019/11/13(水) 09:00:49.38

近いうちにマイクロソフトはMustを発表するんだろ

**デフォルトの名無しさん** · 2019/11/13(水) 09:15:39.91

>>666
せめてCopyトレイトのドキュメントぐらい嫁や

**デフォルトの名無しさん** · 2019/11/13(水) 16:05:23.57

「トレイト」って訳語はないの？

**デフォルトの名無しさん** · 2019/11/13(水) 16:14:33.46

特徴

**デフォルトの名無しさん** · 2019/11/13(水) 19:27:48.53

確かにマイクロソフトならこのくらいの言語なら勝手に作りそうではあるな。
そもそもの実装系がカスだし。

**デフォルトの名無しさん** · 2019/11/14(木) 08:40:42.25

MSがネイティブでゼロオーバーヘッドのF#を出したら用済みだね

**デフォルトの名無しさん** · 2019/11/14(木) 11:58:42.24

トイレット

**デフォルトの名無しさん** · 2019/11/15(金) 00:00:29.64

https://i.imgur.com/aACmbKf.png

**デフォルトの名無しさん** · 2019/11/17(日) 22:19:43.87

D言語のdebugブロックみたいなデバッグビルド時のみ有効になるコードブロックってRustにあります？

**デフォルトの名無しさん** · 2019/11/17(日) 22:53:19.86

#[cfg(debug_assertions)] か cfg!(debug_assertions)を使う

https://doc.rust-lang.org/reference/conditional-compilation.html

**678** · 2019/11/18(月) 00:08:28.84

>>679
ありがとうございます！

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

&strに含まれる各文字のUTF-8のバイナリ表現を
文字単位でprintしたいんだけどもう少し簡単な方法ない？

https://play.rust-lang.org/?version=stable&;mode=debug&edition=2018&gist=95162e453b679ff50c779695e9b545bf

&strをchars()でイテレートすると
char.encode_utf8でUTF8に戻するのがなんとも気持ち悪い

**デフォルトの名無しさん** · 2019/11/18(月) 19:16:24.62

>>681
char_indicesでイテレートすればposと(char.len_utf8で)lenが取れるから、それで元のスライスにアクセスする、とかかな。
そんなに短くはならないけど、bufferはいらなくなるはず。

**デフォルトの名無しさん** · 2019/11/18(月) 22:15:40.78

>>682
なるほど
このやり方のほうが素直な気がするね
とりあえずありがとう

let baz = "aあ🦀";
for (pos, char) in baz.char_indices(){
println!("¥n{}:", char);
for byte in baz[pos..pos + char.len_utf8()].bytes() {
println!("{:b}", byte);
}
}

**デフォルトの名無しさん** · 2019/11/19(火) 00:27:09.27

rustも32bitのwindows向けのメンテやサポートは終了が確定してるよね…

**デフォルトの名無しさん** · 2019/11/19(火) 16:20:24.11

2次元配列から最大値を有するデータ(with index)を取り出したいとき
イテレータのmax_by等を二段がけにするのと
従来プログラミング言語のように二重のforループで取り出すのと
どっちがおすすめ？

**デフォルトの名無しさん** · 2019/11/19(火) 17:18:54.68

>>685
読んだ人に意図が明確に伝わる方

**デフォルトの名無しさん** · 2019/11/19(火) 17:44:40.62

forでやるとmutな変数の更新を自分でやることになるから安全性が落ちる
更新ミスによるデバッグコストのリスクがある

**デフォルトの名無しさん** · 2019/11/20(水) 21:08:08.17

変なやり方するより自然なfor使った方が
結局は可読性によって安全性やデバッグコスト低下になる。

**デフォルトの名無しさん** · 2019/11/20(水) 22:09:44.36

こういうお爺ちゃんはほんと迷惑
長いというだけで関数に切り出したりするし

**デフォルトの名無しさん** · 2019/11/20(水) 22:18:02.26

え？長いのわけたらいかんの？

**デフォルトの名無しさん** · 2019/11/20(水) 22:22:05.63

いかんからもうやらないでね

**デフォルトの名無しさん** · 2019/11/20(水) 22:42:01.28

テストが書きやすい単位で分ければそう長くもならんだろ

**デフォルトの名無しさん** · 2019/11/20(水) 22:42:36.59

テストが書きやすい単位で分ければそう長くもならんだろ

**デフォルトの名無しさん** · 2019/11/20(水) 22:44:50.09

専ブラが荒ぶった
連投スマソ

**デフォルトの名無しさん** · 2019/11/20(水) 22:48:38.35

組み込みのCだとアセンブラを意識して減算カウンタでdo...while使ったりするけど
PCでそれはないな。イテレータが使える状況なら使ったほうが安全だし

**デフォルトの名無しさん** · 2019/11/20(水) 23:40:48.65

>>689
いや長いならキリ出せよバカ。
こういうバカが一番迷惑。

**デフォルトの名無しさん** · 2019/11/20(水) 23:43:20.92

関数切り出しがダメなのかRustでは
おじいちゃん驚きだわ
理由を何なの？
シャドウイングあるからとか？

**デフォルトの名無しさん** · 2019/11/21(木) 00:12:22.19

競プロで見かける色んな人のコードでは
forループのほうが自然なとこを無理矢理イテレータのメソッドチェーンにしてたり、その逆があったり

**デフォルトの名無しさん** · 2019/11/21(木) 00:26:18.38

読みやすさが犠牲にならない範囲で短く書けるってことはよいことだけど
高階関数とかクロージャがまざるとトレースがめんどいのは確かだよね
デバッグ時にいらいらする

**デフォルトの名無しさん** · 2019/11/21(木) 01:07:26.22

>>685
1. 2重forループ
2. forループ + max系
3. fold + max系

の3択になると思うんだけど並列化も考えるような処理なら3がいい
そこまでの処理じゃないならメソッド抽出してテストを書いとけば中身はどれでもいいと思う

**デフォルトの名無しさん** · 2019/11/21(木) 07:10:43.84

>>696
長いだけで切り出すメリットがない

>>697
スコープが広くなるからだよ

**デフォルトの名無しさん** · 2019/11/21(木) 08:07:30.46

forの方が自然てどういうケースだろうね

**デフォルトの名無しさん** · 2019/11/21(木) 08:37:51.52

>>701
いやいや
若者よもっと経験積もう

**デフォルトの名無しさん** · 2019/11/21(木) 09:05:05.54

関数切り出しでスコープが広くなるとか、プログラミング言語として致命的な欠陥だろ

**デフォルトの名無しさん** · 2019/11/21(木) 09:32:00.36

切り出すと特定の関数から一度しか呼ばれない関数がででるから、
それが無意味というか、むしろ関数のシンボルが増えるし
上から下に連続的にソースコード読めなくなるしでダメだと言っているのだろう

でもそれってRust以外の言語でも同様の話であって、なぜそれでもなぜ切り出すべきかは語りつくされてる
それでもRust固有の事情で反論があるなら書いてくれ

**デフォルトの名無しさん** · 2019/11/21(木) 11:40:09.30

scanとかinspect使う処理はforの方が読みやすいこと多いように思う

**デフォルトの名無しさん** · 2019/11/21(木) 12:20:05.12

>>705
全くあなたの言う通り、そしてRust固有の話ではない

**デフォルトの名無しさん** · 2019/11/21(木) 13:17:36.82

>>705
関数切るとその分だけ借用とか生存期間とかの問題が増えるんよ
関数跨いだ変数の扱いが非直感的すぎる
関数に分けるとコンパイル通らなくなる事例が多すぎるから
関数分けないモチベに繋がる

**デフォルトの名無しさん** · 2019/11/21(木) 15:03:38.41

行儀の良くないプログラミングスタイルが
コンパイラに怒られてるだけに聞こえるなあ
例出してよ

**デフォルトの名無しさん** · 2019/11/21(木) 17:54:01.27

>>707
長い関数書いてるかうちは半人前
うちのプロジェクトなら即リジェクト
深いネストもリジェクト

**デフォルトの名無しさん** · 2019/11/21(木) 20:17:44.56

まあバカにrust使わせるとどうなるかってことがよくわかる事例だな。

**デフォルトの名無しさん** · 2019/11/21(木) 20:54:42.20

グローバルな型推論が無いのと型シグネチャが人に全然優しくないことに起因する、関数大きくなりがち問題はRust特有ですよ
最初から完成形があるわけでもないのに試行錯誤のコストを無視しちゃ駄目だ

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

>>710
小物臭すごいんで寄らないでください

**デフォルトの名無しさん** · 2019/11/21(木) 21:26:52.12

抽象的な話じゃなくてコード出せよ

**デフォルトの名無しさん** · 2019/11/21(木) 21:32:48.48

関数内関数を活用しよう

**デフォルトの名無しさん** · 2019/11/22(金) 09:52:07.52

苦労ぢゃ

**デフォルトの名無しさん** · 2019/11/22(金) 10:24:47.28

メソッドチェーン万歳

**デフォルトの名無しさん** · 2019/11/22(金) 13:02:23.70

>>708と>>712でピンと来ないならRustエアプ

**デフォルトの名無しさん** · 2019/11/22(金) 14:48:50.24

確かにimpl traitなかった頃のクロージャ返しとか、asyncなかった頃のFuture返しとかは煩雑だったけど
現時点でそんな大変な型シグネチャってあるか？

**デフォルトの名無しさん** · 2019/11/22(金) 19:24:09.78

>>708
> 関数に分けるとコンパイル通らなくなる事例が多すぎるから

悲しいけどわかるｗ

**デフォルトの名無しさん** · 2019/11/22(金) 19:42:58.93

impl trait がない時代しか知らんのだろう

**デフォルトの名無しさん** · 2019/11/22(金) 20:26:37.15

バージョンアップごとにリリースノート確認するくらいの手間をかけろ

**デフォルトの名無しさん** · 2019/11/23(土) 00:04:27.77

んな手間かけるくらいならまともなテストコード書くほうが
よっぽど安全性上がるわ。
バランスがおかしい。

**デフォルトの名無しさん** · 2019/11/23(土) 00:14:14.42

>>708
C/C++では関数分離は大事なこと考えずにやってたのかな？バグバグバグ

**デフォルトの名無しさん** · 2019/11/23(土) 00:14:39.49

リリースノート一回読む程度もやらない人が
Rustコンパイラと同等な網羅テストを毎回書けるとは思えんけどな。

**デフォルトの名無しさん** · 2019/11/23(土) 00:39:42.82

関数に抽出するからというよりも
関数に抽出してジェネリックにしようとすると簡単にコンパイル通らないことが多々ある

例えば少し前に出てた2次元配列からmaxとindexを取得する例だけど
main関数から、配列やVecを受け取って結果だけをprintする関数を抽出したり
foldに渡すクロージャを関数として抽出したりするのに一苦労
https://play.rust-lang.org/?version=stable&;mode=debug&edition=2018&gist=160e0290cba2c67d8090326a54c7ab62

**デフォルトの名無しさん** · 2019/11/23(土) 03:05:15.71

>>726
デバッグしてあげました

https://play.rust-lang.org/?version=stable&;mode=debug&edition=2018&gist=31427b62cf0ac30ea340084d6b7e515e

**デフォルトの名無しさん** · 2019/11/23(土) 03:13:22.52

filter_mapしゃんを使って書き換えるのは諸君らへの宿題とする

**デフォルトの名無しさん** · 2019/11/23(土) 03:23:24.33

>>727
ま、ありがとう
超バグってたね

ちょっと手直し
https://play.rust-lang.org/?version=stable&;mode=debug&edition=2018&gist=be7300d6fb44b350f1b190fa79e88d6a

**デフォルトの名無しさん** · 2019/11/23(土) 03:39:19.44

filter_mapしゃんをご存知ないのでしゅか
バグを出しにくい安全設計とはこうしゅるものでしゅ

https://play.rust-lang.org/?version=stable&;mode=debug&edition=2018&gist=5c184061ecdc7537d8eb8ccc1c146238

**デフォルトの名無しさん** · 2019/11/23(土) 03:44:01.49

真の安全性はunwrap_or(init)なんて与えないことなんでしゅがね
取得したインデックスを使うことがある場合は空の2次元配列で死にましゅよ

**デフォルトの名無しさん** · 2019/11/23(土) 04:57:43.99

インデックスとして使わなくても嘘の結果が表示されちゃうからOptionのままにして適切に表示を分けないといかんでしょな

**デフォルトの名無しさん** · 2019/11/23(土) 12:05:56.79

Rust用にソース書くときに結局Cでどうなってるか意識しないといけないのなら
最初からCで書いた方が良くね？ってなるよね