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/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で安全なラッパーを被せてやれれば意味がある

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

unsafe fn vec_t_n(n: usize) -> Vec<T> {
let mut v: Vec<T> = Vec::with_capacity(n);
v.set_len(n);
v
}

fn vec_t_n(n: usize) -> Vec<T> {
let mut v: Vec<T> = Vec::with_capacity(n);
unsafe { v.set_len(n); }
v
}

unsafe fnにするかfnにするか
例えばutf-8を保証するStringのようにTがなにかを保証する型だとして
Vec<T>の中身がTでないかもしれないからunsafe fnが良いRustでOK?

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

>>455
1文字ずつ文字間開いてるとucs2で書かれてるように見える

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

>>458
そのコードだけで言えばset_len()を使うことで保証されなくなるlengthの正しさを
呼び出し側が保証する必要があるのかどうか

from_utf8_uncheckedみたいな別のunsafe fn使ってればそれによって壊される安全性があるなら
その安全性を呼び出し側が保証する必要があるのかどうか

**デフォルトの名無しさん** · 2019/10/15(火) 20:37:26.43

https://keens.github.io/blog/2015/09/23/rustwokakutokinochiken/
move semanticsのお陰でGCがないので本当に小さい。hello, worldが277KBだった。

Javaででかいのが当たり前で大昔の感覚を忘れてしまったんだが
ちいさい？

**デフォルトの名無しさん** · 2019/10/15(火) 21:56:51.61

その千分の一でもまだでかい

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

バイナリゴルフが流行ってんの？

**デフォルトの名無しさん** · 2019/10/15(火) 22:36:57.07

たった13バイトの文字列をコンソールに出力するだけで283648バイトを浪費ｗｗｗｗｗ

**デフォルトの名無しさん** · 2019/10/15(火) 22:39:45.49

minimal runtimeってタイトルなんだからランタイムが小さいって話だろ。比較対象はGoとかHaskellとかであって、Cが小さいなんてのは当たり前。

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

270kBは何が入ってるの

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

>>465
nim
https://mevius.5ch.net/test/read.cgi/tech/1519896738/

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

ファミコン版のスターフォースのROMは16KBやったんやで

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

一方ルーストはhello, worldとコンソールに表示させるだけで277KBｗｗｗ

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

ファミコンのドラクエ3が256KBだっけ

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

Kbitじゃない？

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

エミュROMでぐぐったら出てきた
ドラクエ3が256KByte
ドラクエ3が128KByte
ドラクエ1が64KByte
どれもKbitではない

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

N88-BASICとかディスク拡張命令とか考えなければ32 KBに収まってた
数十KBというのは広大な情報量
人間の遺伝子もジャンクDNAを除けば10 KB強ぐらいなのではないか

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

https://www.tel.co.jp/museum/magazine/news/042.html
だってさ
ジャンク含めてもＣＤ一枚分の模様

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

go だと Hello, work! だけで 2MB でした本当にありがとうございました

**デフォルトの名無しさん** · 2019/10/17(木) 18:57:57.40

日本は欧米と比べてココがダメ！
↓
韓国のほうがもっとダメなのでセーフ！

**デフォルトの名無しさん** · 2019/10/17(木) 20:26:17.00

>>475
デバッグ情報をストリップしてください

**デフォルトの名無しさん** · 2019/10/17(木) 20:41:23.80

https://www.atmarkit.co.jp/ait/articles/1910/17/news088.html
「Rust」言語を採用したAWS、Rustプロジェクト支援を開始

Amazon Web Services（AWS）は2019年10月14日（米国時間）、オープンソースのシステムプログラミング言語「Rust」について、開発プロジェクトをスポンサーとして支援することを発表した。

　Rustは、高速で信頼性が高く、効率的なコードを作成、保守できるように設計されている。2015年に最初の安定版がリリースされて以来、実システムへの導入が大きく進んでおり、GoogleやMicrosoft、Mozillaのような企業がいずれもRustを使用している。

　例えばMicrosoftは自社製品の脆弱（ぜいじゃく）性の約7割を占めるメモリ安全性の問題を解決するためにRustが役立つと指摘している（関連記事）。

　AWSでもRustの利用は大幅に拡大しており、「Lambda」「EC2」「S3」のようなサービスにおいて、パフォーマンスに敏感なコンポーネント用の言語として採用している。

　AWSは先ごろ、軽量のマイクロ仮想マシン（microVM）を数秒で起動できる安全な仮想化技術「Firecracker」をオープンソースとして公開したが、ここでもRustが採用されている（関連記事）。

**デフォルトの名無しさん** · 2019/10/18(金) 01:27:06.30

それでも数秒かかるんか…
コールドスタートの悪夢未だ醒めず

**デフォルトの名無しさん** · 2019/10/18(金) 08:13:39.39

＞例えばMicrosoftは自社製品の脆弱（ぜいじゃく）性の約7割を占めるメモリ安全性の問題を解決するためにRustが役立つと指摘している（関連記事）。

これWindowsの脆弱性の話だろうけど、
静的解析ツールでは解決しないってことなのか？

**デフォルトの名無しさん** · 2019/10/18(金) 15:26:11.27

>>480
その関連記事は>>27。そのソースは>>190
静的解析ツール等を併用してもC/C++では無理があると指摘している

**デフォルトの名無しさん** · 2019/10/18(金) 17:46:16.42

mut をマットって読んでる人いる？

コアチーム含めミュート派が大勢なのは知ってるけど
eがないとミュートって読むのは不自然だし、時々eをタイプしそうになるから
マット派になろうかと思ってるんだが

**デフォルトの名無しさん** · 2019/10/18(金) 17:52:26.42

おれはミューツ派

**デフォルトの名無しさん** · 2019/10/18(金) 17:55:14.75

>>482
マット派
レットマットって発音が気持ちいい

**デフォルトの名無しさん** · 2019/10/18(金) 17:59:19.15

どう見てもムッと

**デフォルトの名無しさん** · 2019/10/18(金) 18:12:40.01

むーと

**デフォルトの名無しさん** · 2019/10/18(金) 18:29:52.38

結構いろんな読み方してんのね
マット派いたから安心して転向するわ

ちなみにドイツ語ではムートって読んで勇気って意味らしい

**デフォルトの名無しさん** · 2019/10/18(金) 20:27:28.69

Rustの単語のセンスだけはどうも好きになれん

**デフォルトの名無しさん** · 2019/10/18(金) 20:30:24.39

わかる
fnとかpubとかunwrapとか普通にわかりにくい

**デフォルトの名無しさん** · 2019/10/18(金) 21:57:09.28

pubはまあわかるけど
fnとunwrapは他言語でもあるし普通にわかりやすいと思ってたわ

IntoIteratorとかは素直にIterableでいいのにとは思う

**デフォルトの名無しさん** · 2019/10/19(土) 00:46:14.72

しかしRustでOS作ったらCより性能悪かったという記事があったはず
新しくOS用のプログラミング言語を作った方が良いのでは
RustはOS開発を主眼にしてるわけじゃないだろう

**デフォルトの名無しさん** · 2019/10/19(土) 01:22:54.66

OSの性能って曖昧過ぎて何測ってるのかわからん

**デフォルトの名無しさん** · 2019/10/19(土) 04:43:06.59

Redoxめっちゃマッハやった

**デフォルトの名無しさん** · 2019/10/19(土) 07:34:16.56

Rustは配列の境界値チェックがあるから普通に使うとCよりちょっと遅いよ

**デフォルトの名無しさん** · 2019/10/19(土) 13:01:40.81

>>494
分岐予測があるので理由はそこじゃない

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

は？

**デフォルトの名無しさん** · 2019/10/19(土) 13:43:06.95

OS組もうとするとRustの言語概念を無視するような書き方をしなきゃいけない
みたいに書いてあったんだけど

**デフォルトの名無しさん** · 2019/10/19(土) 13:44:39.15

「Rust」言語はCよりも遅いのか、研究者がベンチマーク結果を解説
ttps://www.atmarkit.co.jp/ait/articles/1909/13/news133.html
このソースは
A high-speed network driver written in C, Rust, Go, C#, Java, OCaml, Haskell, Swift, Javascript, and Python
ttps://github.com/ixy-languages/ixy-languages
これかな

**デフォルトの名無しさん** · 2019/10/19(土) 17:05:59.60

>>497
ケースバイケースだろ。
なんでも杓子定規にとらえるなって言ってやれ。

**デフォルトの名無しさん** · 2019/10/19(土) 18:07:21.38

いや普通にOSソース見ればそらrust向いてねーわってなるよ。
杓子定規にrust使おうってほうが気が狂ってるわ。