Rust part12

**デフォルトの名無しさん** · 2021/08/24(火) 22:55:27.78

公式
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/

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

**デフォルトの名無しさん** · 2021/09/10(金) 01:38:58.21

>>352
なるほど
勉強になりました
ありがとん

**デフォルトの名無しさん** · 2021/09/10(金) 01:44:26.77

>>351
Stringはヒープ上なのでstructの中でCopyは無理

>>352
そのStringも使わずにこれでいけますね
#[derive(Clone,Copy,Debug)]
struct St {
s: &'static str,
}
fn main() {
let ar = [St {s: &"str"}; 10];
println!("{:?}", ar);
}

**デフォルトの名無しさん** · 2021/09/10(金) 05:44:54.18

もはやご希望のものかどうかはわからんが

#[derive(Clone)]
struct St{
s: String
}

fn main(){
let ar = vec![St {s: String::from("str")}; 10];
}

CopyをCloneして配列をvecにしただけ

**デフォルトの名無しさん** · 2021/09/10(金) 06:59:27.65

>>355
vec!は単なるマクロでVec作ってるだけなので
それだと動的にヒープにString作って
そのVecを動的にヒープに作ってる
一方で>>354はヒープを全く使わないという差ですね

**デフォルトの名無しさん** · 2021/09/10(金) 07:55:51.69

>>354
>そのStringも使わずにこれでいけますね
それ>>352に書いてるのと同じじゃんw

**デフォルトの名無しさん** · 2021/09/10(金) 13:58:45.81

>>351
その後の用途によって7通りのやり方がある

let st = St {s: &"str"}; の場合は
let ar = [st; 10];
let ar = [&st; 10];
let ar = vec![st; 10];
let ar = vec![&st; 10]; の4通りが使い分け可能で
1番目はまとめて let ar = [St {s: &"str"}; 10];
3番目はまとめて let ar = vec![St {s: &"str"}; 10]; と省略可能
2番めと4番目が省略できない理由は参照なのに実体が変数にバインドされていないため

let st = St {s: String::from("str")}; の場合は
let ar = [st; 10]; の1番目だけは出来なくて
let ar = [&st; 10];
let ar = vec![st; 10];
let ar = vec![&st; 10]; の3通りが可能
3番目はまとめて let ar3 = vec![St {s: String::from("str")}; 10]; と省略可能
1番目が出来ない理由はヒープ上に作られるStringを暗黙的にコピーできないため

**デフォルトの名無しさん** · 2021/09/10(金) 15:18:43.49

無駄な長文乙

**デフォルトの名無しさん** · 2021/09/11(土) 02:12:58.97

数百行程度で、Rustらしいコードの例ってありませんか？

**デフォルトの名無しさん** · 2021/09/11(土) 02:31:10.17

>>360
何に使うん？
紹介プレゼンとか？

**デフォルトの名無しさん** · 2021/09/11(土) 02:47:02.21

>>361
学習のために自分で読むだけです

**デフォルトの名無しさん** · 2021/09/11(土) 02:58:05.44

現状はどのレベル？
とりあえず入門書は読み終わったって感じ？

**デフォルトの名無しさん** · 2021/09/11(土) 03:10:01.40

>>362
例えば>>3と>>4にあるRust各book十数個のうちどれくらい読んでみましたか？

**デフォルトの名無しさん** · 2021/09/11(土) 04:59:53.97

ただのコード例ってのとは違うけどこれ読み進めるとかどうだろう
https://rust-unofficial.github.io/too-many-lists/index.html

Linked Listを色々頑張るやつ

**デフォルトの名無しさん** · 2021/09/11(土) 05:21:08.84

>>365
それはあまりにも偏った特殊ケースであることと
初心者向けではないということと
その件だとむしろ標準ライブラリとして提供されているリンクリストや双方向キューを覚えた方が実用的かなーhttps://doc.rust-lang.org/std/collections/

**デフォルトの名無しさん** · 2021/09/11(土) 17:59:37.96

>>349
なるほど

**デフォルトの名無しさん** · 2021/09/11(土) 21:06:20.65

Rustは可読性をもう少し良くできなかったのかな
後発なのにJavaより読みにくいってのは問題だろ

**デフォルトの名無しさん** · 2021/09/11(土) 21:16:46.98

>>368
どのあたりが？

**デフォルトの名無しさん** · 2021/09/11(土) 22:08:56.74

>>368
どうすれば良くなると思う？

**デフォルトの名無しさん** · 2021/09/11(土) 22:10:09.25

>>370
専用フォントを開発

**デフォルトの名無しさん** · 2021/09/11(土) 23:22:27.41

Javaより読みにくいとはさすがに思わんけど、
ジェネリクスが<>囲いなところとか、
そもそも中かっこ＋セミコロンってのもどうなんだ、とか
Haskell並にとは言わんがもうちょっとかっこ少なくかけないのか、とか
思うところはいろいろとある

**デフォルトの名無しさん** · 2021/09/11(土) 23:44:46.13

>>372
ジェネリクスが<>囲いなところ、ってメジャーなプログラミング言語のほとんどがそうだよね？

**デフォルトの名無しさん** · 2021/09/11(土) 23:48:51.34

>>373
その通りだけどあんまり筋がよくないことでもちらほらごく一部の界隈で話題になってるような

**デフォルトの名無しさん** · 2021/09/12(日) 00:05:19.01

変にRubyの影響受けてる部分は変えて欲しいなあ

**デフォルトの名無しさん** · 2021/09/12(日) 00:20:02.96

>>374
コンパイラ実装の問題なら承知した上で敢えて <> 採用してる
曖昧性の問題は turbofish で解決するなどコンパイラ実装を複雑にしない範囲で慣例的な記法に近づけている

>>375
Rubyの影響ってクロージャの記法のことかな？

**デフォルトの名無しさん** · 2021/09/12(日) 00:39:47.78

それはSmalltalkじゃないの？

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

https://doc.rust-lang.org/reference/influences.html
ここによるとクロージャの記法はRuby由来

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

クロージャの記法は各言語で様々だから大して気にならないけど
こう書きたいのに書けないのが悲しい

fn make_counter_closure(init: i32) -> impl FnMut() -> i32 {
　let mut counter = init;
　move || counter--
}

この件はRustやRubyだけでなくPythonやScalaやSwiftなどでも同じで
Swiftでは昔は出来たのに後から削除されたようだから最近はそういう傾向なの？

**デフォルトの名無しさん** · 2021/09/12(日) 01:35:25.37

>>378
RubyのクロージャがSmalltalk由来だからどうなんだろ

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

>>379
++と―はバグの温床だからそういう傾向
Swiftから削除されたのもRustでrejectされてるのも同じ理由

**デフォルトの名無しさん** · 2021/09/12(日) 08:11:23.50

だッさw

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

>>380
起源をたどればそうかもしれないけどRustが直接的に影響を受けたのはRuby

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

ベストなジェネリクスの書き方ってなんだよ
Scalaみたいなのがいいの？

**デフォルトの名無しさん** · 2021/09/12(日) 14:11:08.78

Scalaみたいに[]にするのもアリだけど配列がちょっとアレになるからさすがに避けたい気がする
D言語みたいに、例えば定義時には
struct(T) Foo { foo: T }
impl(T) Foo {
fn(T) new(foo: T) { Self { foo } }
}
みたいな感じにして、使用時には
let bar = Foo!i64::new(42);
って感じにするとか・・・？
実際に書いてみるとこれはこれで微妙な気もするが

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

>>379
そこは
{ let result = counter; counter -= 1; result }
または
{ counter -= 1; counter + 1 }
になるの？

**デフォルトの名無しさん** · 2021/09/12(日) 15:54:09.04

move || { counter-=1; counter }では？？？

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

>>387
それは後置デクリメントになっていない

**デフォルトの名無しさん** · 2021/09/12(日) 16:29:00.55

後置であるということをそもそも認識できていなかった、やっべえ

**デフォルトの名無しさん** · 2021/09/12(日) 16:37:25.63

まさにバグの温床となりうることが示されたな

**デフォルトの名無しさん** · 2021/09/12(日) 16:48:32.00

>>385
初期Rustは [] だったけどまさに配列と被るからと言う理由で <> にした
C++と親和性のある構文を目指しているので <> 以外は採用されにくいと思う

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

>>387
見ろ！Rustがゴミのようだ！

**デフォルトの名無しさん** · 2021/09/13(月) 00:58:36.15

型変数を明示しなきゃならないのは汎用プログラミング言語の欠点だよな

**デフォルトの名無しさん** · 2021/09/13(月) 01:54:16.68

何言ってんだこのバカ

**デフォルトの名無しさん** · 2021/09/13(月) 11:03:41.66

let mut counter = init + 1;
move || { counter -= 1; counter }

これが普通だと思うのは俺だけか？

**デフォルトの名無しさん** · 2021/09/13(月) 16:07:27.15

>>395
Rubyだと普通にそういう書き方するから特に違和感はないな

**デフォルトの名無しさん** · 2021/09/14(火) 21:41:07.14

配列がusizeだけなのを何とかして欲しい
i32 as usizeとかいちいち面倒

**デフォルトの名無しさん** · 2021/09/14(火) 21:52:21.64

>>397
普通に開発していればむしろusizeという別の型になってるおかげでミスなどに気付けて助かったことある人多いと思う
i32と別になっていることは非常に重要

**デフォルトの名無しさん** · 2021/09/14(火) 23:13:54.76

usizeだとうっかりマイナスにしちゃって死ぬことがある
デバッグビルドならぱにくって気づくけど、
テストすり抜けちゃうとやばい

**デフォルトの名無しさん** · 2021/09/14(火) 23:25:50.44

i32は流石にどうかと思うけど
グリッドの4-隣接とか8-隣接をforで回すときに中心からの差分で表現したくて、
isizeとusizeでガチャガチャ変換したときはちょっとウザいなーとは思った

**デフォルトの名無しさん** · 2021/09/14(火) 23:35:48.81

impl From<u16> for usize はあるのに u32 はないのが面倒
usize のサイズがプラットフォーム依存なのは分かるけど毎回 trt_from().unwap() したくない

**デフォルトの名無しさん** · 2021/09/15(水) 06:35:42.54

Rustの難しさってある程度マスターしたあとは納得の難しさなんですか？

面倒だなー。でも（メモリ安全のためには）しょうがないか～、みたいな

**デフォルトの名無しさん** · 2021/09/15(水) 07:06:01.76

バカ矯正用補助輪付言語の難しさ

**デフォルトの名無しさん** · 2021/09/15(水) 07:55:49.68

補助輪なし言語でバグなしプログラム作れたらどこに行っても採用されると思うよ

**デフォルトの名無しさん** · 2021/09/15(水) 08:36:21.78

>>401
asでいけないっけ

**デフォルトの名無しさん** · 2021/09/15(水) 09:04:47.19

>>405
asでも良いけどreleaseだとオーバーフローチェックしてくれないから心許ない
constの文脈だとunwrap使えないからas使わざるを得ないけど

**デフォルトの名無しさん** · 2021/09/15(水) 09:15:01.47

オーバーフローの懸念がある文脈ならtry_fromはしょうがないのでは
usizeがu32以上のプラットフォームだけ想定するならasでいいように思えちゃうんだけど

**デフォルトの名無しさん** · 2021/09/15(水) 09:44:19.90

asを使うとu32から別の型に変更したときに修正漏れのリスクがあるのが気になってしまう
まあfrom相当のユーティリティ関数自分で用意すれば良いか

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

>>398
じゃあunsafe時には許可して欲しい

**デフォルトの名無しさん** · 2021/09/15(水) 15:24:13.77

暗黙の型変換が増えるのはやだよ

**デフォルトの名無しさん** · 2021/09/15(水) 20:24:30.93

緩く簡単に書きたい人向けの言語じゃないよね全体的に

**デフォルトの名無しさん** · 2021/09/15(水) 21:01:30.58

それはそう
緩く簡単に書けるせいで起きていた全てのバグを撲滅したい、的な執念を感じる

**デフォルトの名無しさん** · 2021/09/15(水) 21:30:37.23

IntelliJ Rust pluginの新バージョン、関数とかの補完を機械学習でやるんだってさ
すごいね
試してないけど

**デフォルトの名無しさん** · 2021/09/16(木) 00:03:22.08

誰も見ていなければ海や川でも裸で泳ぐCちゃんと
温泉の女湯でも深夜一人で水着で入るRustちゃん

**デフォルトの名無しさん** · 2021/09/16(木) 00:56:52.16

エラーハンドリング可能な形ですっきりしたルールを定義できるならやればいいんだけど
現実にそういう上手い方法がないなら煩雑でも変換の手順を書くしかない。

**デフォルトの名無しさん** · 2021/09/16(木) 01:12:36.12

低レイヤーいじる言語のエラー処理内容の粒度はそれこそプログラムごとに違うとしか言いようがない。
だから仕方ない。

**デフォルトの名無しさん** · 2021/09/16(木) 05:10:39.16

>>414
泳いでるのをDQNに見つかって乱暴されるCちゃん
そもそもDQNに覗かれるような温泉には入らないRustちゃん

**デフォルトの名無しさん** · 2021/09/16(木) 05:50:12.68

おっきしてきた

**デフォルトの名無しさん** · 2021/09/16(木) 06:27:10.25

椎ちゃんの方逝くわw

**デフォルトの名無しさん** · 2021/09/16(木) 18:55:26.69

as usize祭り絶賛開催中

unsafe fn calc(a_index: isize, b_index: isize) -> isize {
　if a_index == a.len() as isize { return 0; };
　let mut res: isize = 0;
　for i in b_index..b.len() as isize {
　　if a[a_index as usize] == b[b_index as usize] {
　　　res = res.max(calc(a_index + 1, b_index + 1) + 1);
　　}
　}
　res
}

**デフォルトの名無しさん** · 2021/09/16(木) 19:34:21.47

>>420
関数に定義されていない変数が使われまくり
forループの中に変動変数がなく毎回同じ実行
キチガイのコードを読むべきでなかった

**デフォルトの名無しさん** · 2021/09/16(木) 19:36:15.88

unsafeだしな

そして、その指摘にas usizeを擁護（容認）する意見は皆無だっていう

**デフォルトの名無しさん** · 2021/09/16(木) 19:38:22.07

あと祭り発生中の実況だったので稼働するコードではなく、

if a[a_index as usize] == b[i as usize] {
}

と修正した

**デフォルトの名無しさん** · 2021/09/16(木) 20:03:32.03

なんでunsafeなのかもわからないしなんでusizeじゃなくてisizeを受け取るのかもわからん

**デフォルトの名無しさん** · 2021/09/16(木) 20:06:54.23

ああ、aとbグローバル変数なんかこれ？

**デフォルトの名無しさん** · 2021/09/16(木) 20:47:15.02

引数がマイナスになることもあるので条件判断の必要からisizeなんだよね
もしusizeを引数にするとしても、引数に渡すところでisize as usizeになるので、やっぱりusize祭りが大発生

お祭りワッショイワッショイ

**デフォルトの名無しさん** · 2021/09/16(木) 21:30:12.52

引数がマイナスになるならチェックしないと範囲外アクセスするだろ馬鹿か？

**デフォルトの名無しさん** · 2021/09/16(木) 22:25:53.04

今どきIndex使って回すとか化石脳かよ

**デフォルトの名無しさん** · 2021/09/16(木) 22:48:14.07

ボロクソワロタ

**デフォルトの名無しさん** · 2021/09/16(木) 23:11:45.54

>>425
グローバル変数を使うのはありえないな
staticは使ってもモジュール内に閉じ込める
どの言語でも常識

**デフォルトの名無しさん** · 2021/09/17(金) 01:14:24.53

グローバル変数小文字にしたら警告出なかったっけ

**デフォルトの名無しさん** · 2021/09/17(金) 03:56:57.86

そもそもusizeで受け取って呼び出し側でケアすべきやろ

**デフォルトの名無しさん** · 2021/09/17(金) 13:27:45.55

>>412
経験的に、縛れば縛るほど最終的にはラクできるようなのを皆知ってると思う
ラクに書けるような言語は一見いいのだが
人間が生まれ持って自堕落であるのを伴って
最終的には苦しみをもたらすことになるコードを書いてしまう

**デフォルトの名無しさん** · 2021/09/17(金) 15:13:45.88

>>420も煽りのつもりで普段書いてないrustを
イキって書いたんだろうけど
煽り返された上にクソコードが掲示板に一生残るのは辛いよなあ

**デフォルトの名無しさん** · 2021/09/17(金) 15:20:07.79

3歩あるけば忘れるからヘーキヘーキ

**デフォルトの名無しさん** · 2021/09/17(金) 16:32:00.60

いきなり unsafe fn とか書いてるあたり普段からrust書いるが競プロとかでついた変な癖を引きずってる人だと思う
余計悪いが

**デフォルトの名無しさん** · 2021/09/17(金) 17:02:49.25

>>420
これって何するコードなの？

**デフォルトの名無しさん** · 2021/09/17(金) 18:51:16.87

>>437
ゴミカスコード力を披露するコードだよ
Rustどうこう言うやつはこのレベルが多い

**デフォルトの名無しさん** · 2021/09/17(金) 20:36:20.90

usize祭り絶賛発生中

while !next_pos.is_empty() {
　let mut tmp_next_pos: Vec<(i32, i32)> = Vec::new();
　for &(n_yr, n_xc) in &next_pos {
　　map[n_yr as usize][n_xc as usize] = 2;

　　for (a_yr, a_xc) in around(n_yr, n_xc) {
　　　if a_yr >= 0 && a_yr < m_yr + 2 && a_xc >= 0 && a_xc < m_xc + 2 {
　　　　if map[a_yr as usize][a_xc as usize] == 0 {
　　　　　map[a_yr as usize][a_xc as usize] = 2;
　　　　　tmp_next_pos.push((a_yr, a_xc))
　　　　}
　　　　if map[a_yr as usize][a_xc as usize] == 1 {
　　　　　total += 1;
　　　　}
　　　}
　　}
　}
　next_pos = tmp_next_pos;
}

**デフォルトの名無しさん** · 2021/09/17(金) 21:04:31.14

>>439
しつこいなw

**デフォルトの名無しさん** · 2021/09/17(金) 21:09:35.15

isize ってどういう時に使います？
添字は基本的に usize しか使いませんし符号付き整数が欲しくなったらi32かi64で大体事足りるのでいまいち使い所が分かってません

**デフォルトの名無しさん** · 2021/09/17(金) 21:43:47.45

添え字に使う値を算出する途中計算で負数が必要になったら isize が妥当という場合もある。

**デフォルトの名無しさん** · 2021/09/17(金) 21:44:59.72

can isize and usize be different in rust?
Can isize and usize be different? Both of them can be used for memory size, index, offset.
Since usize is used for arrays why don't we just have usize
I am new to Rust so this might be a basic question.

・usize cannot be negative and is generally used for memory addresses, positions, indices, lengths (or sizes!).
・isize can be negative, and is generally used for offsets to addresses, positions, indices, or lengths.

https://stackoverflow.com/questions/55506647/can-isize-and-usize-be-different-in-rust
意識高い系がウンコードを量産し罵倒するクソスレ

**デフォルトの名無しさん** · 2021/09/17(金) 21:45:51.61

そして、その結果、as usize祭りにもなる場合もある

**デフォルトの名無しさん** · 2021/09/17(金) 21:51:17.48

>>432
経験的に縛れば縛るほど脱法行為が横行する。

**デフォルトの名無しさん** · 2021/09/17(金) 22:20:51.81

RustlingsをReplitで動かして学習したいのですが、これってrustlingsコマンドはどうやって動かすのですか？
https://github.com/rust-lang/rustlings
公式サイトが用意しているReplitの環境で学習をやりたいのです

よろしくお願いします

**デフォルトの名無しさん** · 2021/09/17(金) 23:24:24.54

>>446
ReplitのRustのバージョンが古くて(1.44）ビルド失敗するっぽい
見た感じローカルでやるのとそんな変わらん気がするから、
こだわりないならローカルでやるのが吉
この環境ビルドむっちゃくちゃ遅いし

**デフォルトの名無しさん** · 2021/09/17(金) 23:26:48.18

>>439
なぜそんなに下手なの？
配列のインデックスを取り出して配列をアクセスしてるだけなら
そのインデックスは最初からusize型にしておくだけてしょ

**デフォルトの名無しさん** · 2021/09/17(金) 23:34:57.92

>>445
脱法行為もなにも>>420のコードで負のindex渡されたらおかしくなるやんけ

**デフォルトの名無しさん** · 2021/09/17(金) 23:57:58.10

とはいえasﾅﾝﾄｶが一部のシチュエーションでめんどくさくなることはある（主に競プロ）

let (h, w) = (100usize, 100usize); // 多くの箇所ではusizeとして扱っている
let grid = vec![vec![0; w]; h]; // 横幅w 縦幅h 左上のマスの座標(0,0)のgrid

// 省略（なんかいろいろやる）

let (x, y) = some_func(); // 着目対象となるgridのマスの位置を(usize, usize)で取得

// (x, y)の上下左右のマスを対象になにかやる
for &(dx, dy) = &[(1i32, 0i32), (-1, 0), (0, 1), (0, -1)] {
let (x2, y2) = (x as i32 + dx, y as i32 + dy);
if x2 < 0 || x2 >= w as i32 || y2 < 0 || y2 >= h as i32 {
continue; // x2,y2がgridからはみ出してたら処理飛ばす
}
let (x2, y2) = (x2 as usize, y2 as usize); // できるだけusizeで処理したいので
// 省略（x2, y2を使っていろいろやる）
}

上下左右調べたいときに負の値が出てくるのがめんどくさい

一応workaroundはあって、for以下をこうする手がある
!0が2の補数的には-1として扱えるのでオーバーフローOKな足し算をする

for &(dx, dy) = &[(1usize, 0usize), (!0, 0), (0, 1), (0, !0)] {
let (x2, y2) = (x.wrapping_add(dx), y.wrapping_add(dy));
if x2 >= w || y2 >= h {
continue; // x2,y2がgridからはみ出してたら処理飛ばす
}
// 省略（x2, y2を使っていろいろやる）
}

**デフォルトの名無しさん** · 2021/09/18(土) 00:02:40.07

競技プログラミングは
正しいプログラミングスタイルから離れていく悪です
競技プログラミングスタイルな人と一緒に開発したい人は存在しないでしょう

**デフォルトの名無しさん** · 2021/09/18(土) 00:04:38.74

正当なスタイルが分かった上で競技としての割り切り方も分かっているなら問題ないんだけど、
競技から学ぶと変な癖が付きやすいというのは私も感じるなぁ。