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/09/13(金) 16:22:57.80

>>313
何が？
完全にRust初心者なんだからしょうがない
多分外部ファイルに依存してるだろう事は何となく分かってきたけど、まだ解決には至らず

**デフォルトの名無しさん** · 2019/09/13(金) 17:00:45.98

正直釣りにしか見えないが…。
なぜ初心者がいきなりcoreライブラリいじろうとしてるの？
あとcoreはmallocとかもない環境で動く必要があるから
とてもprintlnなんて無理だと思うけど。

**デフォルトの名無しさん** · 2019/09/14(土) 18:11:14.79

　(V)　　　　　(V)
　　ヽ∧∧∧ 丿
┌＜┌ ﾟ ∀ ﾟ＞┐　ﾗｽﾀｼｱｰﾝ!!

**デフォルトの名無しさん** · 2019/09/14(土) 18:17:32.07

https://www.atmarkit.co.jp/ait/spv/1909/13/news133.html

**デフォルトの名無しさん** · 2019/09/15(日) 00:25:56.87

ヌルポチェック境界チェックしてたら遅くなるに決まってるやん
Cはそんなことしなくて済むから爆速な訳で

**デフォルトの名無しさん** · 2019/09/15(日) 11:32:00.80

絶対にめくれないからパンツいらないスカートで
アスレチックでもスカイダイビングだもなんでもするのがCだわな

**デフォルトの名無しさん** · 2019/09/15(日) 11:37:40.55

素晴らしい例えだ
感動した

**デフォルトの名無しさん** · 2019/09/15(日) 12:03:39.49

いいねｗ

**デフォルトの名無しさん** · 2019/09/15(日) 12:40:15.54

そして落っこちて死ぬと
http://peaceman.jugem.jp/?eid=2290

**デフォルトの名無しさん** · 2019/09/15(日) 12:41:41.15

何だこのストレートに脳天に突き刺さる説明！？

**デフォルトの名無しさん** · 2019/09/15(日) 14:06:50.28

風呂でもセックスでもパンツ脱がないのがRustだわな

**デフォルトの名無しさん** · 2019/09/15(日) 14:41:05.29

スカートも不要なのがC

**デフォルトの名無しさん** · 2019/09/15(日) 15:51:33.74

デバッガー「見えたぁ！！！」

**デフォルトの名無しさん** · 2019/09/15(日) 17:00:20.75

パンツ履かないC言語
鉄壁のパンツRust

**デフォルトの名無しさん** · 2019/09/15(日) 22:55:46.82

Rustはむしろ貞操帯

**デフォルトの名無しさん** · 2019/09/16(月) 01:53:49.38

Rust勉強し始めたんだけど、公式ドキュメント読み終わったら何しよう

**デフォルトの名無しさん** · 2019/09/16(月) 02:52:51.25

その貞操帯鍵穴錆びてるよ…

**デフォルトの名無しさん** · 2019/09/16(月) 08:18:42.11

何をするにも貞操帯外したり付けたりガチャガチャして複雑になるんだよなあ

**デフォルトの名無しさん** · 2019/09/16(月) 08:35:42.66

>>331
これ

**デフォルトの名無しさん** · 2019/09/16(月) 08:38:49.73

そんなふうに考えていた時期が俺にもありました
でも今はderef coercionでハッピーな毎日です

**デフォルトの名無しさん** · 2019/09/17(火) 05:38:58.62

これ読んでたんだけど
https://stackoverflow.com/questions/50786894/rust-trait-and-its-default-implementation

やっぱ回答みたいに impl 側でがちゃがちゃやるしかないん？
おまいらならもっとうまくヤりそう

**デフォルトの名無しさん** · 2019/09/17(火) 08:51:01.90

Tのままでチェックするからこうなるんでu32にしてチェックしていいならそうする
TもCopy + Into<u32>でトレイト拘束するだけですむ

**デフォルトの名無しさん** · 2019/09/17(火) 08:53:25.78

単にv1.0相当のコードをマクロで生成するのでいい気がするが。

**デフォルトの名無しさん** · 2019/09/17(火) 23:28:59.67

なんだかんだマクロ最強か

**デフォルトの名無しさん** · 2019/09/18(水) 00:07:56.14

数年後、Rustの世間的な評価はマクロが濫用されてるからクソ
になってる気がする

**デフォルトの名無しさん** · 2019/09/18(水) 08:28:44.98

そりゃ言語拡張性からいったらマクロは最強だよ。
そんなことは30前にlispが示してる。

**デフォルトの名無しさん** · 2019/09/18(水) 08:40:04.21

何をマクロにするかだよね

**デフォルトの名無しさん** · 2019/09/18(水) 10:23:10.82

マクロ最強
https://mevius.5ch.net/test/read.cgi/tech/1565187727/

**デフォルトの名無しさん** · 2019/09/18(水) 10:47:59.35

✗ Rustのマクロが汎用されているからクソ
○ プリプロセッサで単純に置換する不健全なマクロを汎用するからクソ
Rustはまだましなほう

**デフォルトの名無しさん** · 2019/09/18(水) 11:34:11.09

ライブラリで定義するのはいいがプロジェクト内ではレビューの時に面倒だからなるべく書きたくないな

**デフォルトの名無しさん** · 2019/09/18(水) 13:02:58.98

頻出パターンならマクロになってる方がレビューしやすい

**デフォルトの名無しさん** · 2019/09/18(水) 13:03:25.81

Cのマクロと違って見た目からマクロであることが明らかだし害は少ない

**デフォルトの名無しさん** · 2019/09/18(水) 13:41:17.68

汎用する？

**デフォルトの名無しさん** · 2019/09/18(水) 14:40:03.73

直接依存するクレートのfeatureはdependenciesに記述できますが、依存するクレートが更に依存するクレートのfeatureをセットしたいときはどうすれば良いんでしょうか

**デフォルトの名無しさん** · 2019/09/18(水) 15:00:15.00

エアプだからよく知らんけど依存クレートが依存x2クレートのfeature使うなら依存クレートのtomlにfeature書いてあるし、
依存クレート経由しないで依存x2クレート使うなら自クレートが直接依存してるわけだから自クレートのtomlにfeature書くだけじゃないの？

**デフォルトの名無しさん** · 2019/09/21(土) 22:48:09.77

TRPLのPDF版10章まで読んだけど挫折しそう

**デフォルトの名無しさん** · 2019/09/21(土) 23:26:15.34

アホに良いコードは書けないのだ
アホでも書けるとかいう奴は、アホかアホな組織に属してるかその両方かだ

その両方かだ、って一度言ってみたかったんだ

**デフォルトの名無しさん** · 2019/09/21(土) 23:27:32.62

書くところ間違ったアホです

**デフォルトの名無しさん** · 2019/09/21(土) 23:54:56.27

世の中アホが書いたコンパイラの教科書が広く出回っているから紛らわしいな

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

アホじゃなくてエイホだっつーの

**デフォルトの名無しさん** · 2019/09/22(日) 12:22:35.80

ajo ← スペイン語で発音しろ

**デフォルトの名無しさん** · 2019/09/22(日) 13:20:45.75

AWK

**デフォルトの名無しさん** · 2019/09/25(水) 16:41:02.11

ローカル変数を意図的に snake_case じゃなく書きたいんだが、警告を出さない方法ある？
例えば win32 API 関連を扱う時にやはり camelCase がスマートに思えるシーンがあるんだ

**デフォルトの名無しさん** · 2019/09/25(水) 16:56:24.39

allow(non_snake_case)
を使いたまへ

**356** · 2019/09/25(水) 18:23:59.57

>>357
怒られなくなりました
ありがとうございます

```
#[allow(non_snake_case)]
pub fn dummy() {
let hWnd = 0;
}
```

**デフォルトの名無しさん** · 2019/09/25(水) 18:52:38.83

そんなことで警告出るのか

**デフォルトの名無しさん** · 2019/09/25(水) 18:54:51.99

ノンスネークケースを表す識別子がスネークケースとはいかがなものか。
allow(non_snake_case)
これ自身を
allow(nonSnakeCase)
と書きたいものである

**デフォルトの名無しさん** · 2019/09/25(水) 20:08:08.16

そんなことって言うけど大事なことだよね

**デフォルトの名無しさん** · 2019/09/25(水) 20:21:48.81

ErrorやWarningを出力するときにHelpやNoteで解説も出力してくれてすごく助かる

**デフォルトの名無しさん** · 2019/09/25(水) 22:38:57.35

IEEE top programming language 2019が公開
https://spectrum.ieee.org/computing/software/the-top-programming-languages-2019

Rは5位や

**デフォルトの名無しさん** · 2019/09/25(水) 22:53:25.25

えっ

**デフォルトの名無しさん** · 2019/09/25(水) 23:26:32.08

どういうことなの…

**デフォルトの名無しさん** · 2019/09/25(水) 23:55:26.38

ここはRはRでもRustスレだぞ

**デフォルトの名無しさん** · 2019/09/25(水) 23:57:15.10

ほとんどいっしょじゃん

**デフォルトの名無しさん** · 2019/09/26(木) 16:03:54.65

ジェネリクスとPhantomData使って特定の関数呼んだかとかの条件付けるんならせめてエラーメッセージもちゃんとして欲しい(´・ω・`)

**デフォルトの名無しさん** · 2019/09/26(木) 16:19:41.45

要らない何も捨ててしまおう君を探し彷徨うマイソウッ！

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

関数呼んだかチェックを実行時でなくてコンパイル時にできるってこと?

**デフォルトの名無しさん** · 2019/09/26(木) 23:30:20.63

Rust 1.38.0リリース！

**デフォルトの名無しさん** · 2019/09/27(金) 02:38:10.86

ｷﾀ━━━━(ﾟ∀ﾟ)━━━━!!

**デフォルトの名無しさん** · 2019/09/27(金) 13:19:26.24

RustとRの違い

R
データサイエンティストが仕事で使う
言語として結果を出している
速度は残念ながら遅い

Rust
陰キャが気持ちよくなるために使う
実績ナシ
速度は速いらしい（ソース無し）

**デフォルトの名無しさん** · 2019/09/27(金) 13:24:28.05

R指定

**デフォルトの名無しさん** · 2019/09/27(金) 14:09:17.54

RustとRubyの違い

とか書くとスレが荒れる時代はもう過去なのかな

**デフォルトの名無しさん** · 2019/09/27(金) 15:06:25.40

RubyとRustの違い

Ruby
陽キャのおもちゃ
負債作成の実績がある
遅い

Rust
陰キャのおもちゃ
なにも作られてないので負債も作られていない
さすがにRubyよりは速い

**デフォルトの名無しさん** · 2019/09/27(金) 15:10:10.66

FirefoxのCSSエンジンとかFirecrackerとかDropboxとかnpmとかあるけど見たくないヤツには見えないからなあ

**デフォルトの名無しさん** · 2019/09/27(金) 18:38:35.49

自分では書きたくない言語
確定申告のようなコーディングスタイル

**デフォルトの名無しさん** · 2019/09/27(金) 19:04:11.92

>確定申告
わかる

**デフォルトの名無しさん** · 2019/09/27(金) 20:01:19.53

dieselなんかこれじゃない感あるなと思ったらアクティブRecord作った人が作ってるのか
代替ないのかね

**デフォルトの名無しさん** · 2019/09/28(土) 13:12:58.36

>>376
プログラマーな時点で陽キャはない
ウェイかつオタクという最悪な種族

**デフォルトの名無しさん** · 2019/09/28(土) 19:09:22.19

RustネイティブでQtやGtkレベルのツールキットがほすぃ(´・ω・`)

**デフォルトの名無しさん** · 2019/09/28(土) 22:50:10.69

どれもやる気なくてダメポ
ttps://gitlab.com/bloom42/research/rust_gui_ecosystem

**デフォルトの名無しさん** · 2019/09/29(日) 02:52:49.38

>>382
ぼくも(´・ω・｀)

**デフォルトの名無しさん** · 2019/09/29(日) 13:43:42.91

人それぞれだと思うんであくまで参考に聞かせて欲しいんだけど
どれくらいのサイズまで#[derive(Copy)]つけます?

**デフォルトの名無しさん** · 2019/09/29(日) 15:19:26.29

Copyって所有権の話であってサイズとは関係なくない？

**デフォルトの名無しさん** · 2019/09/29(日) 16:30:03.01

所有権の観点からCopy実装してはならないケースはあるだろうけど、
してもしなくてもいい場合に考慮するのはサイズと意味だろ。
サイズに関して言えば、自分はu64の10倍くらいまでって感じ。

**デフォルトの名無しさん** · 2019/09/29(日) 18:25:18.99

Rust Language Cheat Sheet
15.09.2019
https://cheats.rs/

**デフォルトの名無しさん** · 2019/09/29(日) 19:21:30.01

極力付けないな
ぱっと見分かんないから

**デフォルトの名無しさん** · 2019/09/29(日) 20:25:18.89

いろいろ感謝

よく例題にありそうな
struct Point { x: i32, y: i32 }
みたいなのなら#[derive(Copy)]しても害はないかなと思って聞いてみた
速度を考えてサイズがusizeの3～4倍ぐらいまでが相場かなと思ったんだけどね

**デフォルトの名無しさん** · 2019/09/29(日) 20:46:09.39

俺が間違ってんのかな、どうもCopyとMoveの意味を勘違いしてるような…

https://doc.rust-lang.org/std/marker/trait.Copy.html
こことかにも書いてあるけどMoveでもCopyでも構造体の値自体は(所有権の意味ではなくmemcpyとしての意味での)コピーされるんだから一緒じゃないの？

**デフォルトの名無しさん** · 2019/09/29(日) 21:03:36.26

例えば
let x = y;
と
let x = y.clone();
があったときに前者はノーコストで後者は結構重いかもしれないって感覚があると思うけど、
大きなstructにCopyを実装すると前者で大きなmemcpyが発生してびっくりする、という話。

**デフォルトの名無しさん** · 2019/09/29(日) 21:26:23.34

イメージした状況は違うけどそんな感じ
参照経由で扱いたい大きなデータなのに
うっかりコピーされる状況にしちゃって勝手にコピーされるのはちょっと
でも小さいデータならコピーされてもいい

**デフォルトの名無しさん** · 2019/09/29(日) 21:30:49.24

MicrosoftのC#のドキュメントに何バイトまでstruct (C#における#[derive(Copy)])使う方がいいか
書いてあるのを見た気がする
値は忘れた

**デフォルトの名無しさん** · 2019/09/29(日) 21:33:28.20

Sizedなのは当然としてクリッピーなりラストシーが怒ってくれれば気軽に使えるだけどな

**デフォルトの名無しさん** · 2019/09/29(日) 22:03:15.24

>>394
クラスまたは構造体の選択
https://docs.microsoft.com/ja-jp/dotnet/standard/design-guidelines/choosing-between-class-and-struct

> インスタンスのサイズは 16 バイト未満である。

C#では16byte (128bit) か

**デフォルトの名無しさん** · 2019/09/29(日) 23:57:00.22

使用頻度にも依るんだから計測しろよ
別に難しいことじゃ無いし

**デフォルトの名無しさん** · 2019/09/30(月) 00:27:00.93

>>392>>393
Copyを実装してようがいまいが(=Move)
let x = y;
したのならどちらも同様にその構造体自体のmemcpyによる複製は行われてるよ？
(もちろんフィールド内の参照が指す先の話じゃなく)

**デフォルトの名無しさん** · 2019/09/30(月) 06:40:12.68

それはわかってるつもり
関数定義で引数を参照にしそこねた場合とかをイメージしてた
Copyつきだとmoveされずに残るから気づきにくい

**デフォルトの名無しさん** · 2019/09/30(月) 08:53:42.19

それで問題なく動いてるならどうでもいいだろ
遅かったら直せば？
どれだけ速かろうが、なんら価値を産まないプログラムの価値はゼロだよ

**デフォルトの名無しさん** · 2019/09/30(月) 09:35:07.62

動くのは前提で最初（ >>385 ）から速度の話をしてるんですよ
流れで所有権の有効性の一面がでてきたわけですがね
他の人はどれくらいの速度低下を許容しているのか知りたいってのが発端

**デフォルトの名無しさん** · 2019/09/30(月) 09:49:38.90

呼び出し規約でレジスタに乗る範囲は意識するかな
大きいのは論外だとして、小さいのは
プロファイルとっても表面化しないまま積み重なっていくだけだから
遅かったらあとで直すってのはまず実施されないよね

**デフォルトの名無しさん** · 2019/09/30(月) 10:10:48.53

価値を生まないプログラムの価値はゼロ
とかいうひどい重言

**デフォルトの名無しさん** · 2019/09/30(月) 10:27:48.78

でも速いソフトウェアは価値があるよね、一般的に

**デフォルトの名無しさん** · 2019/09/30(月) 10:45:45.14

>>399
しつこくてごめんね、でも分かってるようには思えないなぁ
CopyだろうがMoveだろうがメモリの使用量も速度も何も変わらないよ？
>>391に書いてあるけど複製前の値が使えるか使えないかっていう、所有権の違いだけ

It's important to note that in these two examples, the only difference is whether you are allowed to access x after the assignment.
Under the hood, both a copy and a move can result in bits being copied in memory, although this is sometimes optimized away.

CopyとMoveの違いはassign後のxにアクセスできるか出来ないかの違いしかない
内部的にはどちらもビット単位のコピーが行われる

When should my type be Copy?
Generally speaking, if your type can implement Copy, it should.
Keep in mind, though, that implementing Copy is part of the public API of your type.
If the type might become non-Copy in the future, it could be prudent to omit the Copy implementation now, to avoid a breaking API change.

一般的にCopyが実装可能ならするべき
将来的に非Copyになる予定ならAPIが変わることになるので実装しないべき

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

moveのmemcpy()って最適化でだいたい消えるんじゃないの？

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

>>405
だからcopyもmoveもしたくないんですよ
勝手にcopyを渡されるのでなく参照を渡してアクセスすべきstructのサイズがありますよね
copy vs move でなく copy/move vs 参照ということ
勝手にcopyされないようにCopyを実装しないサイズについて
他の人の考えを聞きたかったんです

たぶん >>393 にそんな感じって書いたのが良くなかったんだろうな
>>392 の問題点を指摘するべきでした

**デフォルトの名無しさん** · 2019/09/30(月) 12:46:09.32

>>382
X.orgとWin32はいいとしてCocoaが厄介だな

**デフォルトの名無しさん** · 2019/09/30(月) 13:02:43.26

128bitくらいまでならコピーでいいんじゃね
ttps://www.forrestthewoods.com/blog/should-small-rust-structs-be-passed-by-copy-or-by-borrow/

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

although this is sometimes optimized away.
の部分も訳してよ

**デフォルトの名無しさん** · 2019/09/30(月) 16:59:35.99

じょぶじょぶ～
とりま、場合によっては最適化されるっしょ

**デフォルトの名無しさん** · 2019/10/01(火) 20:25:14.82

moveでも何かコピーされるの知らんかった。どうしてなの？

**デフォルトの名無しさん** · 2019/10/01(火) 20:50:44.63

このレベルの高速化が必要な処理なら #[inline] つけたら