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/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] つけたら

**デフォルトの名無しさん** · 2019/10/01(火) 22:05:50.22

>>412
大抵は最適化でコピー省略だろうけど
寿命の短い変数から長い変数へmoveする場合は面倒な予感

**デフォルトの名無しさん** · 2019/10/01(火) 23:19:08.32

め、memmove()はmemcpy()、、
moveが真にmoveになるのはハンドルや参照やFATで指し示されたﾌﾞﾂだけなのではないか
bittableなオブジェクトでcopyメソッドの付加をケチっても仕方が無い
bittableなコピーは所有権フリーでふつくしい

**デフォルトの名無しさん** · 2019/10/02(水) 00:51:11.12

>>413
今や言語を超えてもLTO出来るので#[inline]を付ける意味ないんじゃないかな

**デフォルトの名無しさん** · 2019/10/02(水) 09:53:31.95

LTOは重い

**デフォルトの名無しさん** · 2019/10/02(水) 09:56:56.52

LTOってよく分からん
.soとかどうなるの？

**デフォルトの名無しさん** · 2019/10/02(水) 10:06:07.00

その境界は当然越えられないよ
静的なリンクのものだけ

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

Result<(),Box<dyn Error>>を返す関数の中で、Errorトレイトを実装していない外部のクレートのエラーFooErrorを返す関数
fn f() -> Result<(),FooError>{}
に対して f()? のように?演算子を使いたい場合どうすれば良いんでしょうか？

**デフォルトの名無しさん** · 2019/10/02(水) 13:43:42.50

Errorトレイトが自分で作ったものならFooErrorにimplする
そうでないならenun MyErrorを作ってErrorをimplし、From<FooError> for MyErrorを実装する
規模が大きいなら後者のパターンで全てのエラーを包んでResult<(), MyError>を返すようにした方がよいっぽい

**デフォルトの名無しさん** · 2019/10/02(水) 14:03:30.89

https://play.rust-lang.org/?version=stable&;mode=debug&edition=2018&gist=7e31f88718f5c8a1e9a11cdda48e91e4
>>421
ありがとうございます
Foo::f()?の部分はどうやって書けば良いんでしょうか…

**デフォルトの名無しさん** · 2019/10/02(水) 14:19:47.22

すまん不完全な解答だった
外出ちゃったからコードいじれないんだすまん
はintoを自動的に発行するので対応するFromを書けばいけるはず
ただBoxだとどうかな、やってみて

**デフォルトの名無しさん** · 2019/10/02(水) 14:24:05.29

>>423
いえ、ありがとうございます
もうちょっと試行錯誤してみます

**デフォルトの名無しさん** · 2019/10/02(水) 22:03:54.08

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

帰ってきたよ
これでいけたよ

**デフォルトの名無しさん** · 2019/10/02(水) 23:45:01.99

moveってしゃろーこぴー？

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

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

**デフォルトの名無しさん** · 2019/10/05(土) 11:22:10.79

LTOって何ですか？
long transfer object? great teacher Onizuka?

**デフォルトの名無しさん** · 2019/10/05(土) 11:41:40.70

レズ・トランスジェンダー・おっぱいの略。

**デフォルトの名無しさん** · 2019/10/05(土) 11:45:44.92

磁気テープ

**デフォルトの名無しさん** · 2019/10/05(土) 15:31:30.78

DebugとDisplayってどう使い分けたり実装すれば良いんでしょうか

ドキュメントには前者はプログラマ向け、後者ははユーザー向けの出力とかって書いてあるので例えば数値なんかは
前者は｢99u8｣、後者はただ｢99｣みたいに表示されるのかと思ったんですが実際はどっちも同様にただ｢99｣としか表示されないですよね？