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/

**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｣としか表示されないですよね？

**デフォルトの名無しさん** · 2019/10/05(土) 16:20:44.53

Debug は
ID: 530, name: "ほのおのつるぎ(売却可)", attack: 63, equippable: "戦士、勇者"
みたいにユーザーに見せるもんじゃない詳細とかを適当なフォーマットで含むじゃろ。
Display は
ほのおのつるぎ
みたいにエンドユーザーにフォーマルにみせる情報を、変にフォーマットせずに含むのが普通じゃろ

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

RustでVulkanを使いたいのですが、現状非公式のバインディングを使うしか無いのでしょうか…？

**デフォルトの名無しさん** · 2019/10/06(日) 16:42:20.66

デバッグビルドの時に、リリースビルドした依存クレートを使う簡単な方法はありますか?
target/release/depsをtarget/debug/depsに名前を調整して移すとできてる感じですが
もっと簡単にできないでしょうか。

**デフォルトの名無しさん** · 2019/10/06(日) 19:52:43.72

Nightly向けには実装されてるね
俺も早くこれ欲しい
https://github.com/rust-lang/rust/issues/48683#issuecomment-483665255

**デフォルトの名無しさん** · 2019/10/06(日) 21:45:30.41

なるほど
当面自作のスクリプトでdebug/depsいじります

**デフォルトの名無しさん** · 2019/10/07(月) 19:36:11.62

Rustに限った話じゃないんだがGUIツールキットもゲームエンジンもC++が主流
でもC/C++以外でC++の呼び出しが出来る処理系はほとんどない。うぼあー

**デフォルトの名無しさん** · 2019/10/07(月) 19:40:49.20

スマホゲームとか一時はUnityだらけだと思ったけど今は違うの？

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

「C/C++以外で」ってCで呼べるんだ・・・

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

CどころかC++同士の異コンパイラ間ですら呼べなかったと思うけど。

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

(´・ω・｀)

**デフォルトの名無しさん** · 2019/10/08(火) 00:43:17.33

ウィンドーズホンだとC#からC++/CXを経由してネイティブなC++が呼べたお

**デフォルトの名無しさん** · 2019/10/08(火) 00:45:06.10

なるほど。開発環境が決まっててABI決めうちできるならいけるのか。

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

Dがあるじゃん

**デフォルトの名無しさん** · 2019/10/09(水) 11:04:16.03

ここの住民の低レベルさが確定した

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

レベルの高い話題くれ

**デフォルトの名無しさん** · 2019/10/09(水) 17:58:10.09

Cは社交界のオキテを知らない村娘だから
不用意に呼ぶとズッキュウウウンしちゃったりするのよ
だから簡単に呼べなかったりするけど呼べるときはシャワーも浴びずにすっ飛んでくる、そんな子

**デフォルトの名無しさん** · 2019/10/09(水) 19:00:00.88

C++のライブラリへのバインディングでほとんどのAPIがunsafe&unsafeって書いて無い奴もunsafeかもしれんから自分で気をつけてね☆
みたいのがあるんやが

これってRustで書く意味無くね…？

**デフォルトの名無しさん** · 2019/10/10(木) 00:27:32.81

貴方がRustで書き直せば喜ぶ人もいるんじゃない？

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

ま～つもと
いけいけまつもと
がんばれまつもと

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

>>448
C++のライブラリ使うからだろ。
Rustで書かれたもの使うか、Rustで書き直せ。

**デフォルトの名無しさん** · 2019/10/10(木) 13:45:05.68

Box<T>のTを初期化せずに返すunsafe fn box_t() -> Box<T> があったとして
let mut t;
unsafe {
t = box_t();
// Tの初期化
}
にするのと
let mut t = unsafe { box_t() };
// Tの初期化
ですますのとどっちが良いRust?

**デフォルトの名無しさん** · 2019/10/10(木) 14:05:19.62

Rustプログラミング入門
https://www.ohmsha.co.jp/book/9784274224355/

**デフォルトの名無しさん** · 2019/10/10(木) 14:59:57.87

>>452
unsafeで囲む範囲はどの言語でも最小限にしろよ
初期化にunsafe要らんのなら囲むな

**デフォルトの名無しさん** · 2019/10/10(木) 19:40:43.29

なんでＵｎｓａｆｅメモリ領域にしなかったんだ…

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

ﾑﾝｯ

**デフォルトの名無しさん** · 2019/10/11(金) 09:08:20.83

>>448
unsafeなAPIに対してrustで安全なラッパーを被せてやれれば意味がある