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/08(水) 08:14:48.98

>>332
そんなことはない
スマホアプリならKotlinとSwiftの2種類を無駄に覚えずともJavaScriptだけで両OS向けスマホアプリ作成が可能
もちろんスマホでもウェブアプリが動きアプリの種類によってはウェブアプリで十分なためスマホアプリを作らないケースも出ている

一方でRustで書いてAndroid上でツワモノもいるがそれはおいとくとして
Rustをこの件で使うケースはウェブブラウザで動くWasmのプログラミングする時かサーバーサイド側
あとはGoogleがAndroid OS開発にRustを使い始めた

**デフォルトの名無しさん** · 2021/09/08(水) 14:35:34.40

めっちゃWasm使ってるわ、使い心地としてはgoのが良いのだが
てか絶対JS書きたくない勢以外は勧められないけどな
エントリーポイントで4～5行JS書かざるを得ないが、そこはコピペだから俺は1行も書いてない

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

>>335
javascriptからwasmにディスパッチする際のオーバーヘッドってどう？

**デフォルトの名無しさん** · 2021/09/08(水) 19:45:38.33

getopt()みたいなのでRust標準はどのクレイト？

**デフォルトの名無しさん** · 2021/09/08(水) 20:27:20.45

clapだけど、それを使ったさらに便利なstructoptのほうがおすすめかも

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

clapはv3でstructoptの機能を取り込むから、今ならclapの3.0.0-beta4を使うのでもいいかも

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

>>339
その後、structoptはどうなるの？

**デフォルトの名無しさん** · 2021/09/08(水) 23:46:53.75

>>339
なるほど
v2のビルダー方式に加えて
v3でマクロ多用で見やすく書きやすくすっきりしたという感じ？

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

マクロは見やすさだけじゃなくてコンパイル時に諸々チェックされるのが嬉しい

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

数値の並びがある時に
その中の一番大きなものがある場所(index)が欲しいのですが
Rustではどう書くとよいでしょうか？

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

>>343
たとえばこう
https://play.rust-lang.org/?version=stable&;mode=debug&edition=2018&gist=c7a0d0459c540d7b373b124d7faf239a

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

>>344
copied()っているっけ？

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

ありがとうございます
無しでもいけました

別の質問です
Vecにスライス(の各値のコピー)をappendしたいのですが
append()メソッドはVecしか引数に取れず困っています
どうすればいいでしょうか？

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

ちったあググれよ
教えて君は嫌われるよ

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

>>346
https://doc.rust-lang.org/std/vec/struct.Vec.html

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

>>346
append()はその名前から想像しにくい実はムーブで引数側のVecは空になるｗ
じゃあappendはどうすればいいかというと
1つだけappendするpush()の複数版のpush_all()が元々あって
それは名前変更で今はextend_from_slice()になった
がその中身はより一般化したExtendトレイトのextend()を呼んでるだけになったので
結論としてはv.extend(&a)が正解

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

Rust 1.55.0 リリース

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

faqのような気がするんだが、以下のようなコードって
どうすればコンパイル通る？

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

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

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

参照を配列に格納するか
let st = St{s: String::from("str")};
let array = [&st; 10];

Stringじゃなく&strにするか
#[derive (Debug, Clone, Copy)]
struct St{
s: &'static str
}

かな？

**デフォルトの名無しさん** · 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を
イキって書いたんだろうけど
煽り返された上にクソコードが掲示板に一生残るのは辛いよなあ