Rust part13

**デフォルトの名無しさん** · 2021/11/07(日) 10:04:59.35

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

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

日本語の情報
https://rust-jp.rs/

※Rustを学びたい人はまず最初に公式のThe Bookを読むこと
https://doc.rust-lang.org/book/

※Rustのasyncについて知りたければ「async-book」は必読
https://rust-lang.github.io/async-book/

※C++との比較は専用スレへ
C++ vs Rust
https://mevius.5ch.net/test/read.cgi/tech/1619219089/

※次スレは原則>>980が立てること

前スレ
Rust part12
https://mevius.5ch.net/test/read.cgi/tech/1629813327/

**デフォルトの名無しさん** · 2021/11/28(日) 00:58:02.64

>>204の続き
初期値ToDoで開始してセットされたらDoneに変える
impl<SetA: State, SetB: State> Builder<SetA, SetB> {
　fn new() -> Builder<ToDo, ToDo> {
　　Builder { a: 0, b: 0, _a: PD {}, _b: PD {}, }
　}
　fn set_a(self, a: i32) -> Builder<Done, SetB> {
　　Builder { a, b: self.b, _a: PD {}, _b: PD {}, }
　}
　fn set_b(self, b: i32) -> Builder<SetA, Done> {
　　Builder { a: self.a, b, _a: PD {}, _b: PD {}, }
　}
}

全部がDoneになった時だけ実行可能にしておく
impl Builder<Done, Done> {
　fn execute(&self) {
　　println!("OK: {:?}", self);
　}
}

最初の呼び出しをわかりやすく用
fn new_builder() -> Builder<ToDo, ToDo> {
　Builder::<ToDo, ToDo>::new()
}

あとは両方がセットされると実行できる
fn main() {
　new_builder().set_a(123).set_b(456).execute();
}
片方でもセットを忘れるとコンパイル時にexecute()が解決できず失敗する
自分でこのコードを毎回間違えずに書くのは面倒なのでマクロ化されるなら採用

**デフォルトの名無しさん** · 2021/11/28(日) 01:06:31.53

またチラ裏コードの垂れ流し
いい加減やめてほしい

**デフォルトの名無しさん** · 2021/11/28(日) 02:33:07.17

>>201
こういうのは手書きするのではなくて derive で良い感じに実装してほしい
あとrustdocの出力がごちゃつきそうなのが気になる

**デフォルトの名無しさん** · 2021/11/28(日) 02:38:47.39

自己満足コード見せられても困るよな

**デフォルトの名無しさん** · 2021/11/28(日) 02:48:11.47

config部分が静的に決まってるならいいけど
UIやコマンドラインから動的にconfigしたい場合Builder traitを用意してtrait objectとして持ち回して
.execute()するためにdowncastする必要が……とかで二度手間になりそう

**デフォルトの名無しさん** · 2021/11/28(日) 02:53:52.09

>>201のコードがいいと感じる感性が理解できないよ

**デフォルトの名無しさん** · 2021/11/28(日) 10:39:31.01

>>201
難しい話をすると
ビルダはディレクタに対して抽象化されており
一個のディレクタが複数のビルダをケアできることを考えると
必須パラメータというのをビルダ実装ごとに準備するなら
ビルダというインタフェースがディレクタに対して実質破綻してると思う
でも
ビルダインタフェースが正しい呼び出し順を想定してたりするのをアリとするなら
必須パラメータも同じように勝手に想定しておいて
使う側にはドキュメントなりなんなりで勝手に指示だしとけば十分とも思う
そんで
呼び出し順や必須か否かに想定を置きたくない
呼び出し側に完全な自由度を与えたビルダインタフェースを提供したいなら
インタフェース Fooビルダ {Fooビルダ a(); Fooビルダ b();}
クラス　実際のビルダ implements Fooビルダ {
Foo(必須な何か x) {略} // コンストラクタで与えるとか
Fooビルダ必須なc() {略} /* 実際のビルダ固有のメソッドとして与えて
new 実際のビルダ().必須なc().a() などと呼ぶか
Fooビルダ a() {略}
Fooビルダ b() {略}
Foo create() {略}
}
のようにして、ビルダインタフェース側だけはクリーンに守っておけばスッキリかも？
元のURLにあるように何が必須かをパラメータ化したいという欲求は解消してないのは認める

**デフォルトの名無しさん** · 2021/11/28(日) 11:48:41.93

インタフェースとかクラスとか意味不明すぎ

**デフォルトの名無しさん** · 2021/11/28(日) 23:35:20.49

ここまで意味不明な文章書けるのって逆に凄いよ
このレベルは久々に見たわ

**デフォルトの名無しさん** · 2021/11/29(月) 01:53:08.06

Javaコードの識別子の部分を日本語で書いて
GoFのオリジナルのBuilderパターンを説明しただけっぽい

なんでRustスレでそんな話をしたのかだけは完全に謎だが……

**デフォルトの名無しさん** · 2021/11/29(月) 02:06:35.83

普通のBuilderであまり困ったことないからなあ

操作によって遷移していく状態があって、状態ごとに可能な操作が違う(呼び出せるメソッドが違う)とかなら意味あると思う(Socketのbind->accept->read/writeみたいな)
ただこういうものはもはやBuilderと呼ぶべきものではないと思う

**デフォルトの名無しさん** · 2021/11/29(月) 09:45:31.17

それはStateパターンでしょ

**デフォルトの名無しさん** · 2021/11/29(月) 15:25:28.77

https://play.rust-lang.org/?version=stable&;mode=debug&edition=2021&gist=ebfd22dd62614e127bb3dbf0e57e5651
sもmutにしてDerefMutもimplしてるのになんでgの方は通らないんでしょうか？

**デフォルトの名無しさん** · 2021/11/29(月) 16:49:12.44

>>217
もっと単純に let z: *mut i8 = *s; も通らないので
これはDerefMutの条件であるmutable contextを満たしてないのではないか
そしてもちろん let z: &mut i8 = *s; は通るし **s = 88; も通るからDerefMut自体は機能している

**デフォルトの名無しさん** · 2021/11/29(月) 18:03:30.09

PR出てるけどどうなるかわからない
https://github.com/rust-lang/rust/pull/86647

現状は
let s = &mut *s;
g(*s);
するか
g(&mut **s);
するか

**デフォルトの名無しさん** · 2021/11/29(月) 18:58:43.82

>>218>>219
おお、そのものズバリが
あざます！

**デフォルトの名無しさん** · 2021/11/30(火) 18:31:42.77

ifの閉じカッコにセミコロンが必要となる条件を教えてください
以下のプログラムはそれが足りないと指摘されてコンパイルエラーとなり
セミコロンを付けると通って動作するのですがどういう原理なのでしょうか？
fn main() {
　for line in BufReader::new(io::stdin()).lines() {
　　let line = line.unwrap();
　　if let [first, second, rest] = line.splitn(3, ' ').collect::<ArrayVec<_, 3>>()[..] {
　　　println!("{}:{}:{}", first, second, rest);
　　}
　}
}

**デフォルトの名無しさん** · 2021/11/30(火) 18:58:54.86

戻り値？

**デフォルトの名無しさん** · 2021/11/30(火) 20:27:35.13

ブロック式最後の式の値は、ブロック式の値として返るので drop されるタイミングがブロックの末尾よりも後の箇所になるということかな
for のブロックは値を返さないけど、ブロック式と同じ扱いをされているっぽい
https://play.rust-lang.org/?version=stable&;mode=debug&edition=2021&gist=b5639623c9a0dff8426f1d38b7123fdc

**デフォルトの名無しさん** · 2021/11/30(火) 21:12:32.45

>>223
>> ブロック式最後の式の値は、ブロック式の値として返るので

もちろんおっしゃる通りでその例でも>>221の例でもif式の値は明瞭に()ですね

>> drop されるタイミングがブロックの末尾よりも後の箇所になるということかな

ブロック式の値として返るのは()ですから変数lineのdropタイミングが後にはならないように思うのですがどうなのでしょう？

**デフォルトの名無しさん** · 2021/11/30(火) 21:32:53.10

help: consider adding semicolon after the expression so its temporaries are dropped sooner, before the local variables declared by the block are dropped

↑エラーメッセージに理由書いてるよ

**デフォルトの名無しさん** · 2021/11/30(火) 21:55:20.40

>>225
そのエラーメッセージでは理由になっていないのではないでしょうか？

例えば(for文を使わない)>>223の以下の部分を
if let [_first, _second, _rest] = line.splitn(3, ' ').collect::<ArrayVec<_, 3>>()[..] {}

このように2行へ書き換えても同じくセミコロンを付けろエラーとなりますが
let x = line.splitn(3, ' ');
if let [_first, _second, _rest] = x.collect::<ArrayVec<_, 3>>()[..] {}

このように2行へ書き換えるとコンパイルが通ります
let x = line.splitn(3, ' ').collect::<ArrayVec<_, 3>>();
if let [_first, _second, _rest] = x[..] {}

この差をどう見るのか教えていただけますでしょうか

**デフォルトの名無しさん** · 2021/11/30(火) 22:02:05.25

>>224
・lineの寿命はif-let式の寿命と一致する
・ブロックの最後の文の寿命はブロックを囲む文の寿命と一致する
という仕様になっていると思われる
型は関係なくてブロック内の最後の式か否かが重要

**デフォルトの名無しさん** · 2021/11/30(火) 22:26:55.08

>>226
>このように2行へ書き換えるとコンパイルが通ります
>let x = line.splitn(3, ' ').collect::<ArrayVec<_, 3>>();

line.splitnでborrowしたものを使ってるtemporaryは
let xで受けたタイミングでtemporaryじゃなくなる
(エラーメッセージにあるdropped soonerの状態になってる)

if式がブロックの最後の式でそのif式の一部がborrowを使ってるtemporary
セミコロンがないとtemporaryが解放される前にローカル変数のlineが解放されるからライフタイムのエラー

そのうち修正されるかもしれないけど今はそういう動きってこと

**デフォルトの名無しさん** · 2021/11/30(火) 22:31:28.50

>>226
>let x = line.splitn(3, ' ');
>if let [_first, _second, _rest] = x.collect::<ArrayVec<_, 3>>()[..] {}

**デフォルトの名無しさん** · 2021/11/30(火) 22:35:06.87

すまん、投稿ミス。

値を返したいときはセミコロンを追加するだけじゃだめだから
一旦変数で受けてからその変数をブロックの最後に書く

**デフォルトの名無しさん** · 2021/11/30(火) 22:39:09.24

ふむむ
lineがヒープにあると以下の2行だけでセミコロン付けろエラーになりますね
let line = String::from("A B C D E");
if let [_first, _second, _rest] = line.splitn(3, ' ').collect::<ArrayVec<_, 3>>()[..] {}

このif let文を例えば以下のように変えるとセミコロンを付けなくても通るのはどうしてでしょう？
if let Some(_s) = line.get(3..6) {}

**デフォルトの名無しさん** · 2021/11/30(火) 22:41:34.40

なんでセミコロン付けると一時オブジェクトの寿命変わるんだって思ったけどそういえばC++にもそんな仕様あったな……
完全式じゃなくて戻り値に使うから破棄されないってことか

**デフォルトの名無しさん** · 2021/11/30(火) 23:55:05.80

>>230
ブロックの最後で返す値は変数に入れなくても複雑な式でも大丈夫ですよ

**デフォルトの名無しさん** · 2021/12/01(水) 12:41:12.28

なんでBufReadトレイトはあるのにBufWriteトレイトは無いんですか？

**デフォルトの名無しさん** · 2021/12/01(水) 13:25:08.66

>>231
詳しく知りたければまずはここ↓だけど
https://doc.rust-lang.org/reference/destructors.html

言語自体をいじりたいわけじゃなければ
あんまり深追いしても役に立たないよ

**デフォルトの名無しさん** · 2021/12/01(水) 16:06:22.55

>>234
BufReadはReadに対して追加の機能(行単位の読み込みなど)があるけど
Writeに対して追加すべき機能がないからBufWriteは存在しないのではないかと思われる

**デフォルトの名無しさん** · 2021/12/01(水) 21:58:24.00

flushしなけりゃ下のレイヤのどこかで勝手にバッファリングされることがほとんどだから用意する意味がないんだろな。

**デフォルトの名無しさん** · 2021/12/01(水) 23:34:44.63

>>237
いやBufWriteトレイトが存在しないだけであってBufWriterはちゃんとある
そしてBufWriterがバッファリングする最後の要
誰かが勝手にバッファリングしてくれることはない
例えば何行もファイルに書き込む時にBufWriter使わずに各行毎にwriteしてたら遅くなる

**デフォルトの名無しさん** · 2021/12/03(金) 14:04:46.92

https://crates.io/crates/rust-script
とか
https://crates.io/crates/runner
みたいなの使ってる人おる？

これ使うくらいならLL使うとは思うが

**デフォルトの名無しさん** · 2021/12/03(金) 14:45:17.46

REPL的にコードスニペットの実行確認するために使ったりはできるのかな
今はplaygroundで事足りているが

**デフォルトの名無しさん** · 2021/12/04(土) 15:22:12.31

Read::read_to_end()に空のVecを渡した時に戻り値のusizeとVecのlen()が違う値になる事って有り得ますか？

**デフォルトの名無しさん** · 2021/12/04(土) 23:32:14.41

同じと思う
let file_size = file.metadata().map(|m| m.len())?;
let file_pos_before = file.stream_position()?;
let read_buf_size_before = read_buf.len();
このようなfileとread_bufがある任意の状況で
let read_size = file.read_to_end(&mut read_buf)?;
とread_to_end()すると以下が常に成り立っていると思われる
assert_eq!(read_buf_size_before + read_size, read_buf.len());
assert_eq!(file_pos_before + read_size as u64, file_size);

**デフォルトの名無しさん** · 2021/12/05(日) 23:43:02.39

＞ loop式はbreakで指定した値を返せるのに
＞なぜwhile式やfor式は値を返せないの？
＞ Option型にしてbreakで値を指定した時だけSome(値)としてそれ以外はNoneとすれば便利なのに

そのloopと組み合わせればよい
(例)
let r = 'result: loop {
　for x in 1..100 {
　　for y in 1..100 {
　　　if x * y > 1234 {
　　　　break 'result Some((x, y));
　　　}
　　}
　}
　break 'result None;
};
assert_eq!(r, Some((13, 95)));

**デフォルトの名無しさん** · 2021/12/06(月) 12:54:15.14

>>243
forよりイテレータを繋げた方が単純でわかりやすいよ！と言おうとしたら
let r = (1..100)
　.map(|x| (1..100)
　　.map(|y| (x, y))
　　.find(|(x, y)| x * y > 1234)
　)
　.find(|o| o.is_some())
　.map(|oo| oo.unwrap());
assert_eq!(r, Some((13, 95)));
むしろ複雑でわかりにくくなってしまったw
まさかの>>243のダミーloop使用がベストアンサーなのか！？

**デフォルトの名無しさん** · 2021/12/06(月) 13:12:38.43

>>244
flat_mapを使えば良い
let r = (1..100).flat_map(¦x¦ (1..100).map(¦y¦ (x, y))).find(¦(x, y)¦ x * y > 1234);

**デフォルトの名無しさん** · 2021/12/06(月) 13:28:57.99

どれもこれも分かりやすいとは思えない

**デフォルトの名無しさん** · 2021/12/06(月) 15:59:22.06

結局見やすくこう書けるといいんだよね
let r = pair(1..100, 1..100).find(|(x, y)| x * y > 1234);
assert_eq!(r, Some((13, 95)));
これでassertも通ったけどyのイテレータとx自身の2ヶ所にCloneが必要となってしまった
避けられないような気がするけどどうでしょうか？
fn pair<IX: Iterator<Item=X>, IY: Iterator<Item=Y> + Clone, X, Y>(ix: IX, iy: IY) -> Pair<IX, IY, X, Y> {
　Pair { cur_ox: None, cur_iy: iy.clone(), ix: ix, iy: iy, }
}
struct Pair<IX: Iterator<Item=X>, IY: Iterator<Item=Y>, X, Y> {
　cur_ox: Option<X>, cur_iy: IY, ix: IX, iy: IY,
}
impl<IX: Iterator<Item=X>, IY: Iterator<Item=Y> + Clone, X: Clone, Y> Iterator for Pair<IX, IY, X, Y> {
　type Item = (X, Y);
　fn next(&mut self) -> Option<Self::Item> {
　　loop {
　　　if let None = self.cur_ox {
　　　　self.cur_ox = self.ix.next();
　　　}
　　　if let Some(ref x) = self.cur_ox {
　　　　if let Some(y) = self.cur_iy.next() {
　　　　　break Some((x.clone(), y));
　　　　} else {
　　　　　self.cur_ox = None;
　　　　　self.cur_iy = self.iy.clone();
　　　　　continue;
　　　　}
　　　} else {
　　　　break None;
　　　}
　　}
　}
}

**デフォルトの名無しさん** · 2021/12/06(月) 16:01:51.04

最近知ったボクの大発見書いていい？
let a: Option<i32> = None;
これは
let a = None::<i32>;
と書ける
関数のパラメータとして渡そうとして
f(None)で怒られたとき
f(None::<i32>)として怒られない

しょうもないレス失礼いたしました

**デフォルトの名無しさん** · 2021/12/06(月) 16:21:14.38

>>248
曖昧性を確定させる::<型>の指定は色々なところで出てくるね
例えばcollect::<Vec<_>>()とか
ブロックやクロージャの返り値でOk::<(),std::io::Error>(())とか

**デフォルトの名無しさん** · 2021/12/06(月) 16:35:36.71

>>247
itertoolsのcartesian_productがほぼそれ

**デフォルトの名無しさん** · 2021/12/06(月) 17:07:16.47

iproduct!

**デフォルトの名無しさん** · 2021/12/06(月) 17:09:45.91

>>248
型パラメータは Option のパラメータなので順当に考えれば Option::<i32>::None と書くべきだし実際にそれで通るんだけども、
歴史的経緯でバリアントにも付けられるようになってる。

短く書けるから習慣的にはバリアントに型を付けるほうが多いかな……？

**デフォルトの名無しさん** · 2021/12/06(月) 17:31:38.25

>>250
なるほど直積集合かぁ
同じくyのイテレータとxはCloneを要求してますね
fn cartesian_product<J>(self, other: J) -> Producfgt<Self, J::IntoIter>
where
　Self: Sized,
　Self::Item: Clone,
　J: IntoIterator,
　J::IntoIter: Clone,

**デフォルトの名無しさん** · 2021/12/06(月) 20:06:32.13

>>249
> Ok::<(),std::io::Error>(())とか

正直見たことなかったです

>>252
> 歴史的経緯でバリアントにも付けられるようになってる。

（´･∀･`）ﾍｰ
そういうわけなんですね

**デフォルトの名無しさん** · 2021/12/06(月) 21:47:08.33

>>254
例えばlet x = spawn(async { ... });して裏で何か処理をやらせといた結果を
後でもしエラーが出ていたら進めちゃいけないタイミングでx.await?;で確認するわけだけど
spawnが返す型をxに律儀に記述するのは面倒なのでそこは略すとして
asyncブロック内で?とOk(())だけ書くとコンパイラが文句を言うので仕方なく記載

**デフォルトの名無しさん** · 2021/12/06(月) 22:11:44.75

なるほど勉強になりました

**デフォルトの名無しさん** · 2021/12/07(火) 21:26:04.18

12次元までならiproduct!が使える
use itertools::iproduct;
let r = iproduct!(1..100, 1..100).find(|(x, y)| x * y > 1234);
let r = (|| {
　for (x, y) in iproduct!(1..100, 1..100) {
　　if x * y > 1234 {
　　　return Some((x, y));
　　}
　}
　return None;
})();

**デフォルトの名無しさん** · 2021/12/08(水) 14:18:48.01

ARM版のWindowsでRustのコードを書くのってめんどくさいな
生のWindowsで使用する場合、VisualStudioに付属するx86用のリンカーが非推奨警告を無視すれば使えたものの、次期バージョンからx64専用になってしまうっぽい
一方、仮想環境等+VSCodeでは、RustAnalyzer等が機能せず苦労する・・・・
持ち運び用にケチってMacを買わなかったのが大問題だった、なんかいい方法ないのかな？そもそもARM Windowsで動くリンカーってVisualStudio付属のものしかないのかな？
ケチったって言ってもよくよく考えてみると大して金が浮いてもないし、変なもん買っちまった

**デフォルトの名無しさん** · 2021/12/08(水) 14:36:22.94

>>258
i686ターゲットのバイナリをバイナリ変換で動かしてるってこと？
aarch64-windowsターゲットとARM用のリンカ使えばネイティブのARMバイナリできるんじゃないかと思うけど

**デフォルトの名無しさん** · 2021/12/08(水) 20:15:10.58

バイナリバイナリルルルルルー。

**デフォルトの名無しさん** · 2021/12/08(水) 21:25:01.32

rustはどんどん新しい機能が追加されていくのはいいけど、
後方互換性を気にして過去に追加された「間違った」機能を削除するという
思い切ったこともやって欲しいな

これまでの言語は後方互換性にとらわれて滅茶苦茶になってるから

**デフォルトの名無しさん** · 2021/12/08(水) 21:29:04.83

>>261
C++かな？

**デフォルトの名無しさん** · 2021/12/08(水) 21:44:15.05

>>261
editionでは物足りない？

**デフォルトの名無しさん** · 2021/12/08(水) 21:50:49.56

実際2021editionではレンジパターンの ... が削除されて ..= に一本化された

**デフォルトの名無しさん** · 2021/12/09(木) 08:53:14.94

>>258
今どきDocker使うのはデフォだから何の問題もない、因みにRustAnalyzerも使える
使えないのは、復数のプロジェクトが見える状態にしてるから
今どき復数ウィンドウ立ち上げても何の問題もない、ルートフォルダを固有にしたら解決
つまり、調査不足が原因

**デフォルトの名無しさん** · 2021/12/09(木) 10:59:17.60

ARM は安物のイメージがある。
WSL2, Linux, Docker, VSCode とか使えるのかな？

Mac も、M1 に変わったから

**デフォルトの名無しさん** · 2021/12/09(木) 11:10:00.09

原理的には ARM のほうがインテル系 (もはや AMD 系と呼ぶべきか) よりも高速化できる可能性があるとは言われている。
今以上に回路を細かくするのは無理というところまできてしまっているのでアーキテクチャのほうで見直しが必要なんだが
インテル系は互換性が足かせになってしまっていてあまり思い切ったことが出来ない。

現時点はインテル系向けにチューニングされたソフトウェア資産が多いから上手くいっているけど将来もそうとは限らない。

**デフォルトの名無しさん** · 2021/12/09(木) 11:45:18.26

>>267
スレチだけどその話の出展あったら教えてほしい

**デフォルトの名無しさん** · 2021/12/09(木) 14:22:31.39

CISCRISCの話じゃなくてメモリモデルの話ならそうかなって思う
今のx64って実質中身RISCって聞いたことあるし
Rustで言うとx64では全部SeqCstとして扱われるみたいな話

**デフォルトの名無しさん** · 2021/12/09(木) 17:42:03.96

リソースの話だけなら命令デコーダーとか？
x86_64は拡張や互換性とか可変長命令だったりで無駄にトランジスタ消費するのが電力性能比的に足かせみたいな

**デフォルトの名無しさん** · 2021/12/09(木) 20:39:08.00

今どきのプロセッサだと分岐予測器やキャッシュが支配的でデコーダなんて誤差だと思う
あと可変長は命令側の帯域やキャッシュ効率が良くなるという面もあってRISC系でも採用してることが多い
結局両者とも長年の改善で似たようなとこに落ち着いてるわけで、ISAが違うからどうこうみたいな話は結構眉唾

**デフォルトの名無しさん** · 2021/12/11(土) 19:08:58.23

こういうことをしたいのですがコンパイルエラーとなってしまいます
const DEFAULT_NAME: &str = "namae";
let arg1: Option<String> = std::env::args().nth(1);
let name: &str = arg1.map_or(DEFAULT_NAME, |s| s.as_str());
どう直せばよいでしょうか？

**デフォルトの名無しさん** · 2021/12/11(土) 19:10:55.89

namaeじゃなくてnameな
aが余計
この程度の英語のスペル書けないとかプログラミング向いていないしやめた方がいいよ

**デフォルトの名無しさん** · 2021/12/11(土) 19:21:25.94

自演ボケか？

**デフォルトの名無しさん** · 2021/12/11(土) 19:35:01.57

>>272
そのままだとarg1が消費されてなくなるのに参照だけ残ることになるからエラー
Stringで受ければいいよ
let name: String = arg1.unwrap_or(DEFAULT_NAME.to_string());

**デフォルトの名無しさん** · 2021/12/11(土) 20:19:05.99

>>273
すげーな。してはいけないレビューの典型例じゃねーか。
すげーな

**デフォルトの名無しさん** · 2021/12/11(土) 20:24:40.06

いやネタでしょ

**デフォルトの名無しさん** · 2021/12/11(土) 20:29:51.18

>>275
これだとarg1がSomeの時もto_string()が呼び出されて無駄なヒープアロケーションが走るのでunwrap_or_elseにすべき

**デフォルトの名無しさん** · 2021/12/11(土) 22:35:07.46

みなさんありがとうございます
Stringにする方法は無事にこれで動きました
let name: String = arg1.unwrap_or_else(|| DEFAULT_NAME.to_string());
元の質問>>272のように&strにする方法は無いのでしょうか？
もし可能ならばto_string()のヒープアロケーションを減らせるかなという質問です

**デフォルトの名無しさん** · 2021/12/11(土) 22:59:59.99

>>279
Cowかな
let name: Cow<str> = arg1.map_or(Cow::Borrowed(DEFAULT_NAME), |s| Cow::Owned(s));

**デフォルトの名無しさん** · 2021/12/11(土) 23:20:49.43

場合によってはこれでもいいのかな？
let name: &str = &arg1.as_ref().map_or(DEFAULT_NAME, |s| s.as_str());

**デフォルトの名無しさん** · 2021/12/11(土) 23:54:40.62

>>281
それでもよいけど正解はシンプルなこれ
let name: &str = if let Some(ref arg1) = arg1 { arg1 } else { DEFAULT_NAME };
まずarg1を消費しないようにrefで受ける
2代目のarg1は&Stringなので自動的に&strへderefされる

**デフォルトの名無しさん** · 2021/12/12(日) 02:10:02.51

1.40からas_derefっつうのがあるんだってさ
let name = arg1.as_deref().unwrap_or(DEFAULT_NAME);

でもコマンドライン引数の場合は消費しないメリットがほぼ無いのでCowのほうがいいかな

**デフォルトの名無しさん** · 2021/12/12(日) 04:28:54.46

どの型で統一すべきかは
(1) その後に加工伸長などするならString　(arg1をここで&strに統一するのは無駄)
(2) 参照するのみなら&str　(DEFAULT_NAMEをここでto_stringするのは無駄)
(3) その後に判明する条件次第で両ケースありうるならCow　(ただし常にCow利用はCowコストが無駄)
って感じ？

**デフォルトの名無しさん** · 2021/12/12(日) 10:07:32.08

おそらくその通りだけど、CLIツールの初回一回だけのアロケーションにそこまでこだわるのがそもそも無駄って気もする
ループ内とかでもなければ雑にString作っちゃっていいかもね

**デフォルトの名無しさん** · 2021/12/12(日) 10:31:14.68

んだ

**デフォルトの名無しさん** · 2021/12/12(日) 10:46:59.45

>>285
今回のケースはそうだね
ただしヒープ割り当てをなるべく避ける様々な手法を把握しているか否かは色んな局面で効いてくるから
今回6通りも動くコード例が示されたことは多様に対応可能な柔軟性の良さかな
気にしなくても書けるし気にすれば効率を上げることができる点で

**デフォルトの名無しさん** · 2021/12/12(日) 18:38:25.33

>>284
Cowと&strに揃える場合の一番の違いはライフタイム管理
Stringを&strにするとライフタイム管理がつきまとうから
すぐ使いきる場合以外はCowに比べてメンテナンスしにくいコードになる

**デフォルトの名無しさん** · 2021/12/12(日) 18:59:43.58

文字列についてはStringにするかCow<str>にするか迷うくらいならinternしちゃうのも手かと
どのライブラリが定番なのかよく知らないけど

**デフォルトの名無しさん** · 2021/12/12(日) 19:49:57.76

>>281
> let name: &str = &arg1.as_ref().map_or(DEFAULT_NAME, |s| s.as_str());

それarg1の前の&は不要でこれで動く
let name: &str = arg1.as_ref().map_or(DEFAULT_NAME, |s| s.as_str());

さらにas_str()使うより短く書けて&**sで&strになる
let name: &str = arg1.as_ref().map_or(DEFAULT_NAME, |s| &**s);

さらに&Stringのsのままでもderefされるため大丈夫
let name: &str = arg1.as_ref().map_or(DEFAULT_NAME, |s| s);

クロージャが何もしてないからといって無くしてしまうとderefが効かず型不一致コンパイルエラー
× let name: &str = arg1.as_ref().unwrap_or(DEFAULT_NAME);

そこで明示的にderefしてやればよい
let name: &str = arg1.as_deref().unwrap_or(DEFAULT_NAME);

**デフォルトの名無しさん** · 2021/12/13(月) 21:23:25.03

ken okabeのqiitaの記事がまた炎上してるよ
mod_poppoにボコボコにされてる

**デフォルトの名無しさん** · 2021/12/13(月) 22:30:34.09

あれ、Qiitaには垢バンされて投稿できないんじゃなかった？

**デフォルトの名無しさん** · 2021/12/13(月) 23:00:30.90

ググってもよくわからないのですが、どういった方なんですか？

**デフォルトの名無しさん** · 2021/12/13(月) 23:30:17.26

盛大な時間の無駄になるだけなので調べてはいけない

**デフォルトの名無しさん** · 2021/12/13(月) 23:59:51.20

>>291
poppoとかいうやつも多様な定義や多様な解釈が存在している中で不要なイチャモンばかりだな
さらに冒頭のこれも

> JavaScriptで演算子オーバーロードを実現しようとするのは筋が悪い

たまたま例としてJavaScriptを用いているだけなのにそれすら理解できていない
okabeは使用言語と無関係に成り立つ話をしてるだろ

> reduceは二項演算ではなく三項演算として捉えるべき

これも些細なことであって例えばRustなら
fold()は『入力列・初期値・演算関数』の三項演算だけど
reduce()は『入力列・(初期値は入力列の先頭なので無指定)・演算関数』の二項演算

とはいえokabeの方もイテレータすら扱っていないからイマイチ

**デフォルトの名無しさん** · 2021/12/14(火) 00:07:08.47

Rust関係ねーだろ
二度とその名前を口に出すな

**デフォルトの名無しさん** · 2021/12/14(火) 10:41:11.49

P2P方式の2D対戦ゲームを作りたいと考えています。
おすすめのゲームエンジンやライブラリはございますか？

**デフォルトの名無しさん** · 2021/12/14(火) 11:46:02.04

>>297
あくまでゲームを作ることが目的なんだったら普通にUnityとかでいいんじゃない？
どうしてもRust使いたいならサーバー側で使えばいい

**デフォルトの名無しさん** · 2021/12/14(火) 12:45:44.37

>>298
個人的にRustが好きなので技術向上のためにもRustで作りたいと考えています。
現在はAmethystとlibp2pを用いて開発しようと考えているのですが、如何せん知識が浅くこれで目的のものが作れるのか分かりません。
是非先人の知恵をお貸しください。
Rustでの開発にロミオとジュリエットの恋ほどの壁があるという場合は、大人しくC++かUnityで作成します・・・

**デフォルトの名無しさん** · 2021/12/14(火) 13:10:49.68

そんだけの情報ではなんともいえん。

見通しが立たないものを試行錯誤で作る場合には
モジュールではなくレイヤで分割したほうがいいという考え方がある。
要するに機能不足でもバグだらけでもコードが整理されてなくてもいいからとにかく「動くもの」を作って
その上に足りないものをどんどん足していくという方法論だ。

よくわかってないなら小さいもので色々やってみて知識を積み重ねるべきで、
よくわからんまま目的に向かって邁進してもあんまり技術向上にはならんよ。

**デフォルトの名無しさん** · 2021/12/14(火) 13:22:32.10

>>300
ありがとうございます
色々試してみます

**デフォルトの名無しさん** · 2021/12/14(火) 13:53:41.90

>>299
Amethystは開発中止になったから今からやるのは微妙かも
gamedev.rsに今アクティブなエンジンやゲームがスクショ付きで載ってるから
そこからイメージにあうものを探すといいかもしれない

**デフォルトの名無しさん** · 2021/12/14(火) 15:30:19.02

>>302
そうだったんですね・・・
時間は掛かるかもしれませんが、色んなものを試して自分に合う物を探すことにします

**デフォルトの名無しさん** · 2021/12/15(水) 07:48:40.06

技術を高める目的なら windows-rs や wgpu-rs みたいな一段下から積み上げるのも楽しいよ。

ゲーム作る道のりは遠くなるけど、画面に三角形出したり、キーの入力受け付けたりするだけで達成感が出てくる。