Rust part11

**デフォルトの名無しさん** · 2021/06/17(木) 00:24:12.56

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

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

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

**デフォルトの名無しさん** · 2021/07/30(金) 16:42:36.73

>>483
なんともなあ。

**デフォルトの名無しさん** · 2021/07/30(金) 16:53:36.97

せっかくだしこっち使ってくれよ
https://mevius.5ch.net/test/read.cgi/tech/1619219089/

**デフォルトの名無しさん** · 2021/07/30(金) 16:58:32.68

>>476
コピーが生じないように最適化される。
つまり、スタック上の一時オブジェクトをヒープにコピーするのではなく、ヒープ上に直接オブジェクトを作成する。

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

>>480
具体的にこのように書きたいけどエラーになるというRustのコードを示してください。（他の言語のコードは不要）
それによりようやく初めて、何を問題としているのか、何が問題なのか、がはっきりします。

**デフォルトの名無しさん** · 2021/07/30(金) 17:29:20.46

VeqDequeに二分探索実装されてるけどそもそもソートできなくない？？？

**デフォルトの名無しさん** · 2021/07/30(金) 18:21:23.96

>>488
make_contiguousかas_mut_slicesで中身の可変スライスを受け取って
そのスライスのsortかsort_byを使えばソートできそう（試してない）

make_contiguousが本線っぽいからリファレンス読んでくれ

**デフォルトの名無しさん** · 2021/07/30(金) 18:33:31.64

make_contiguousするならそのあとのas_mut_slicesに対して二分探索でよくない？？？？

**デフォルトの名無しさん** · 2021/07/30(金) 19:00:01.19

その辺はもう「お好きにどうぞ」としか言えない

**デフォルトの名無しさん** · 2021/07/30(金) 20:35:47.56

contiguousじゃないがsortされてることが保証されてるケースで使いたいのかね

**デフォルトの名無しさん** · 2021/07/30(金) 21:37:49.30

sort順を壊さない位置に要素を挿入するのにbinary_searchを使う

**デフォルトの名無しさん** · 2021/07/30(金) 21:46:04.82

https://github.com/vojtechkral/rfcs/blob/vecdeque-binary-search/text/0000-vecdeque-binary-search.md#motivation

**デフォルトの名無しさん** · 2021/07/30(金) 23:01:01.92

>>486
オブジェクトを返す関数を Box::new()のパラメータの位置に書いてもそうなるの？

**デフォルトの名無しさん** · 2021/07/30(金) 23:11:44.30

>>477
explicitでなければな

**デフォルトの名無しさん** · 2021/07/31(土) 16:04:12.94

配列の添え字はusize以外も許容してほしいなー

**デフォルトの名無しさん** · 2021/07/31(土) 16:11:02.83

std::ops::Index を実装すればええんちゃう？

**デフォルトの名無しさん** · 2021/07/31(土) 16:31:36.36

>>498
おお、こんなのあるのか。知らなかった。

**デフォルトの名無しさん** · 2021/08/02(月) 06:51:52.57

Tokio @tokio_rs
Announcing Axum - An ergonomic and modular web framework that takes full advantage of the Tokio, Hyper, and Tower ecosystem.
https://tokio.rs/blog/2021-07-announcing-axum

**デフォルトの名無しさん** · 2021/08/02(月) 10:51:16.95

Rocketが統一するんじゃなかったんかい

**デフォルトの名無しさん** · 2021/08/02(月) 11:07:27.91

axumはシンプルかつ洗練されており柔軟性もあって、よりRustっぽい
それでいてtokio直轄だから今後の主流になりそう

**デフォルトの名無しさん** · 2021/08/02(月) 11:09:36.24

actix-webと比較するとどう？

**デフォルトの名無しさん** · 2021/08/02(月) 11:22:47.21

asyncも結局Tokioが覇権になるんかな？

**デフォルトの名無しさん** · 2021/08/02(月) 11:40:06.27

高収入エンジニアは「ラスト」に注目、ファインディ調査：日本経済新聞
https://www.nikkei.com/article/DGXZQOUC312180R30C21A7000000/

**デフォルトの名無しさん** · 2021/08/02(月) 11:52:00.11

tokio、名前がダサすぎて無理w
async-std勢にもっと頑張ってほしい

**デフォルトの名無しさん** · 2021/08/02(月) 13:37:03.39

どうしても沢田研二を思い出すからな

**デフォルトの名無しさん** · 2021/08/02(月) 13:48:07.46

客の入りが悪くてダサいヤツ

**デフォルトの名無しさん** · 2021/08/02(月) 14:35:12.33

Tokioの名前の由来って普通に東京の可能性があるのか

＞I enjoyed visiting Tokio (Tokyo) the city and I liked the "io" suffix and how it plays w/ Mio as well. I don't know... naming is hard so I didn't spend too much time thinking about it.

https://www.reddit.com/r/rust/comments/d3ld9z/how_tokio_crate_got_its_name_like_that/

**デフォルトの名無しさん** · 2021/08/02(月) 18:57:04.81

axumのimpl IntoResponseとかはaxcixより命名規則とかディレクトリ構造とかよかったけどappの組み立て方が微妙だなー
n-texとかがかなりいいよね

**デフォルトの名無しさん** · 2021/08/02(月) 21:06:18.53

tokioは問題のある挙動が発覚しそうで嫌

**デフォルトの名無しさん** · 2021/08/02(月) 23:22:29.33

async-stdなら発覚しない？

**デフォルトの名無しさん** · 2021/08/03(火) 05:46:07.98

ランタイムはasync-std, tokio, actixの3系統という認識であっていますか？
今回は組み込みとか除外で、ウェブ使う前提での根幹の非同期ランタイムに限る話として。
それぞれの系統のデメリットは何ですか？

**デフォルトの名無しさん** · 2021/08/03(火) 10:52:22.44

actixは内部でtokio使ってるから実質tokio

**デフォルトの名無しさん** · 2021/08/04(水) 05:06:56.84

ここ反tokio派が多いようなので
見習ってasync-std派になろうと思います
デメリットなどあれば教えてください

**デフォルトの名無しさん** · 2021/08/04(水) 13:06:46.39

ワタシはtokio派

**デフォルトの名無しさん** · 2021/08/04(水) 13:23:10.51

どうせ遊びコードだろうしどれでもいっしょだろ

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

遊びコードなら非同期なんか要らないだろ
同期処理のフレームワークにしとけ

**デフォルトの名無しさん** · 2021/08/04(水) 14:41:35.72

tokioは巨大な一枚岩になっていて方針がおかしくね？

**デフォルトの名無しさん** · 2021/08/04(水) 18:03:25.14

smolってどうなの

**デフォルトの名無しさん** · 2021/08/05(木) 00:05:10.42

>>520
smolはasync-ioやasync-fsやasync-netやasync-executorなどの親分だね
それらsmolのサブクレートであるasync-*シリーズはsmol以外のところでも使われてる

**デフォルトの名無しさん** · 2021/08/05(木) 06:32:52.89

RustではじめるWebAssembly入門～JavaScriptを超える高速なWebアプリ開発を実践しよう
https://codezine.jp/article/detail/14567

**デフォルトの名無しさん** · 2021/08/05(木) 22:19:57.77

昔はtokioも同じように多数のtokio-xxxから成り立っていた
しかしどんどん合併していき巨大な一枚岩tokioになってしまった

**デフォルトの名無しさん** · 2021/08/05(木) 23:44:46.85

最終的に各機能は連携するので整合性を維持したまま保守し続けることを考えたら
全体でひとつのパッケージにしてしまうのが楽というのはわかる。

**デフォルトの名無しさん** · 2021/08/06(金) 00:29:20.56

featureで機能on/offするtokio方式の方が使う側も楽では

**デフォルトの名無しさん** · 2021/08/06(金) 05:47:54.70

>>520
smolもasync-stdもStjepan Glavinaが立ち上げた
だからasync-ioなど両者共にベースとしている

**デフォルトの名無しさん** · 2021/08/07(土) 08:24:17.06

オライリーの本で勉強始めたんだが、説明なしにいきなりSomeとか出てきてもやもやしながら読み進んでいる。
索引にも見つからないし。この本のどこかにSomeの説明があるなら誰かページ数教えて。

**デフォルトの名無しさん** · 2021/08/07(土) 08:54:25.11

Somewhere
言いたかっただけだから叩かないで蹴らないで

**デフォルトの名無しさん** · 2021/08/07(土) 09:03:20.19

わいの持ってるオライリーの『プログラミング Rust』だと27ページ（§2.6.1）でOptionの説明してる

**デフォルトの名無しさん** · 2021/08/07(土) 09:03:35.46

索引に「Option<&T>」はない?

**デフォルトの名無しさん** · 2021/08/07(土) 09:10:40.92

同じ本です。そこで使っているSome(T)の説明がなかったので。
文脈からするとT型の値を持っている何かなんだろうけど、正体がわからないのがもやもやして。

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

列挙型（enum）なら10章で取り上げてるね
Optionは出てこないかもしれないけど

**デフォルトの名無しさん** · 2021/08/07(土) 09:30:04.54

あ、なるほど。Some(T)とい型があるのかと思ってしまったけど、Some<T>じゃないですね。
Option<T>の値の一つとしてSomeがあって、それがTの値を持っていると。

**デフォルトの名無しさん** · 2021/08/07(土) 09:31:53.94

オライリー、はやく改訂してくれええあええぃ！

**デフォルトの名無しさん** · 2021/08/07(土) 11:16:06.74

Rustの特徴のうち今回の件だと以下の3つの側面を理解するまでが初心者あるあるですもんね

・Rustのenumは値付きenumすなわちタグ付きunionである
・enumのうちResultとOptionの時だけmatch/return構造のsyntax sugarとして? operatorがある
・そのためRustにはtry/catchの大域脱出機構が無いけども同様の利便性を途中の関数呼び出しに?の1文字付けるだけでスルー出来る

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

>>534
原著の新しい版持ってるけど26~27ページにあるOption<T>の説明は特に変わりないよ
サンプルコードのOption<u32>がOption<usize>になってるくらい

>>535
>そのためRustにはtry/catchの大域脱出機構が無いけども同様の利便性を途中の関数呼び出しに?の1文字付けるだけでスルー出来る
実際に書いてれば分かると思うけど受け渡しするための型を常に意識する必要があるからスルーとはちょっと違う
Javaの検査例外前提なら同様の利便性と言えるかもしれないけど

**デフォルトの名無しさん** · 2021/08/07(土) 12:23:21.41

>>536
エラー返す関数はResult<T,Error>で統一されているから、呼び出す自分もそれを見習うだけでしょ。
そしてエラーをcatchしたいところではmatchして、エラーをスルーしたいところでは『?』

**デフォルトの名無しさん** · 2021/08/07(土) 13:32:55.26

>>537
Result<T, Error>のErrorの部分の型が違うと?演算子は使えない

struct MyError; // 独自エラー型

fn task() -> Result<(), MyError> {
let file = std::fs::File::open("foo.txt")?; // std::io::Error ≠ MyError だから駄目
// ...
Ok(())
}

ただ型が違ってもFromを実装することで?演算子を使えるようになるのは知っておくと便利

// ↓があると↑はコンパイルできる
impl From<std::io::Error> for MyError {
fn from(error: std::io::Error)-> MyError {
MyError
}
}

**デフォルトの名無しさん** · 2021/08/07(土) 14:50:06.24

?はintoを呼び出してるから
まで知っているとモテる

**デフォルトの名無しさん** · 2021/08/07(土) 17:42:21.09

dyn で全部キャッチするようにするから大丈夫！

**デフォルトの名無しさん** · 2021/08/07(土) 18:01:27.03

不要なuse削除してくれる便利な機能ってもしかしてあったりしますか？

**デフォルトの名無しさん** · 2021/08/07(土) 19:24:08.57

>>541
Go使え

**デフォルトの名無しさん** · 2021/08/07(土) 19:33:00.30

cargo fixで消せたっけ？

**デフォルトの名無しさん** · 2021/08/07(土) 21:44:09.86

Optionすら知らない人が、いきなりオライリー読んでも分からんのでは…
無料で読めるBookから読んだ方が良くない？

**デフォルトの名無しさん** · 2021/08/08(日) 01:21:05.48

Rustlingsの構造体のところやってるんだけどさあ
↓この構造体があった場合に、なんで後に出てくるダメって方のじゃ動かないの？？？
struct ColorClassicStruct {
name :String,
hex :String,
}

//ダメ
//テキスト領域に"green"や"#00FF00"が書き込まれて、それに対する参照が渡されるからダメってこと！？
let green = ColorClassicStruct{
name: "green",
hex: "#00FF00",
};

//OK
let green = ColorClassicStruct{
name: "green".to_string(),
hex: "#00FF00".to_string(),
};

**デフォルトの名無しさん** · 2021/08/08(日) 02:00:43.05

"green"の型は&'static strで"green".to_string()の型はString
ただそれだけの話

**デフォルトの名無しさん** · 2021/08/08(日) 07:20:41.65

>>545
型が異なる
どちらも文字列実体はUTF8の[u8]配列だが

String
・Vec<u8>を利用
・つまり文字列実体は[u8]配列をヒープに領域確保(この場所は伸長により自動的に移動あり)
・そこへのポインタと確保メモリの長さと文字列の長さの『3つ組』を持つ
・文字列の長さは可変で確保メモリの長さを超えるとヒープ再割り当てが自動的に起きる

&str
・スライス&[u8]を利用
・つまり文字列実体の[u8]は既にどこかに確保されている
・そこへのポインタと文字列の長さの『2つ組』を持つ
・文字列の長さを変えるという概念はない

**デフォルトの名無しさん** · 2021/08/08(日) 14:26:56.33

Rustとかまだ生きてるのか

**デフォルトの名無しさん** · 2021/08/08(日) 14:30:32.33

逆にイキイキし始めた

**デフォルトの名無しさん** · 2021/08/08(日) 17:42:08.00

現状LLVM上でしか動かないらしいけど
将来的にC/C++並みにターゲットプラットホーム増やすって動きはないの？

**デフォルトの名無しさん** · 2021/08/08(日) 17:57:57.87

>>550
そのプラットホームって何を指して言ってる？

**デフォルトの名無しさん** · 2021/08/08(日) 17:58:17.99

それはLLVMの仕事です

**デフォルトの名無しさん** · 2021/08/08(日) 18:23:12.96

>>550
gccバックエンドとかのプロジェクトは進んでいる

**デフォルトの名無しさん** · 2021/08/08(日) 18:26:41.67

なんかあんまり順調に進んでないように見えるけど

https://github.com/Rust-GCC/gccrs

**デフォルトの名無しさん** · 2021/08/08(日) 18:34:13.86

gccrsはやってること考えたらすごい勢いで進んでるとは思うけどね
実用になるのはこっちが早いかと
https://github.com/antoyo/rustc_codegen_gcc

**デフォルトの名無しさん** · 2021/08/08(日) 18:37:27.80

JVMバックエンドで動くJRustも欲しい
あ、Rust.NETもいるな

**デフォルトの名無しさん** · 2021/08/08(日) 19:39:21.77

>>556
メリットは？

**デフォルトの名無しさん** · 2021/08/08(日) 19:46:05.12

>>557
豊富な既存ライブラリを利用できる

**デフォルトの名無しさん** · 2021/08/08(日) 20:10:03.36

聳え立つクソの山の間違えだろ

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

ランタイムを変える必要はなくて、FFIでいいんじゃないだろうか

**デフォルトの名無しさん** · 2021/08/08(日) 20:22:22.71

純粋に興味だけで言えば面白そうだけど
C++/CLIの二の舞になりそう

**デフォルトの名無しさん** · 2021/08/08(日) 21:30:40.77

JVM上で動かすなんて、既存資産扱うところでGC避けられなくなる訳だから嬉しさが皆無では。
JVM上で現代的なプログラミングしたいだけならScalaやKotlinのほうがよっぽどいい。

**デフォルトの名無しさん** · 2021/08/08(日) 21:30:47.94

>>546
>>547
どっちも参照っぽいのに何が違うのか全然わ買ってなかったよ
ありがとう！

**デフォルトの名無しさん** · 2021/08/08(日) 21:41:24.86

>>561
二の舞って、MSがサポートを投げだした以外は別に悪いところは無かったと思うが。

**デフォルトの名無しさん** · 2021/08/09(月) 00:22:56.88

Googleもサポートやめる

**デフォルトの名無しさん** · 2021/08/09(月) 00:45:05.35

C++/CLIのCLIってマイクロソフト.NETのでしょ

**デフォルトの名無しさん** · 2021/08/09(月) 16:05:33.35

LLVMのバックエンドがgcc並みになれば万事解決

**デフォルトの名無しさん** · 2021/08/09(月) 16:10:16.25

>>564
それが全てだろ。
開発コミュニティが長期的に維持されない (維持される見込みがない) なら
他の何が良くても産業的に使い難い。

**デフォルトの名無しさん** · 2021/08/09(月) 16:57:51.57

はぁ。
>>561はGCを持った仮想マシン環境に移植することがC++/CLIと似た状況だと言っていたのかと思ったが、
そこは全然これっぽっちも関係ない話なわけね。
開発コミュニティが途中で投げ出す恐れなんて言っていたらあらゆるものが当てはまりそうだが。

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

競プロでRustを使ってみようと思って勉強してたんだけど、
再帰関数がめっちゃ面倒なのね
関数の外のスコープの変数の読み取りができないから、
全部引数に記述しなくちゃいけなくて凄い面倒

処理速度が速かったので期待してたんだけどな(´･ω･`)

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

>>545
ダメの方で通るでしょ
宣言でStringを&'static strにする
"green"とだけ書けばプログラムコードのread onlyエリアに確保されて&'static strのライフタイムになる
Stringを使うとheapエリアを余分に使ってしまうので損
もちろん文字列が伸びたり一部書き換わったりなど対応したい時ならばStringを使う

**デフォルトの名無しさん** · 2021/08/09(月) 21:19:46.40

>>570
全部引数渡しは当然だろう
問題なのは末尾再帰が出来ない事

**デフォルトの名無しさん** · 2021/08/09(月) 21:26:05.96

>>570
グローバル変数使いたいなら static mut 使えば良いのでは
unaafe 必要だけど別に安全性欲してないでしょ？

**デフォルトの名無しさん** · 2021/08/09(月) 21:59:43.94

>>573
マジかそんなんあんのか！！！！

static mut test: i32 = 0;

fn main() {
　unsafe {
　　test = 1;

　　unsafe fn calc() {
　　　if test == 1 { println!("yes") }
　　}
　　calc();
　}
}

yes表示ｷﾀ━━━━(ﾟ∀ﾟ)━━━━!!
ありがとうありがとうヽ(´ー｀)ノ

**デフォルトの名無しさん** · 2021/08/10(火) 00:56:57.83

純粋なグローバル変数は仕方ないけど、thread_localは
もっと簡単な使い方にしてほしかったなー

コールバック関数みたいに引数で渡せないパターンが面倒

**デフォルトの名無しさん** · 2021/08/10(火) 01:04:05.56

引数だけで解決できないなら設計が悪い

**デフォルトの名無しさん** · 2021/08/10(火) 01:17:00.79

>>575
どうなって欲しいの？

**デフォルトの名無しさん** · 2021/08/10(火) 02:01:49.31

競プロに向いてるかって言われるとそうでもない気はする

**デフォルトの名無しさん** · 2021/08/10(火) 02:02:54.83

>>573-574
static mutは割とめんどくさい問題があるみたいだぞ
https://qiita.com/qnighy/items/46dbf8d2aff7c2531f4e

**デフォルトの名無しさん** · 2021/08/10(火) 02:13:08.50

>>570
グローバル変数の代わりに関数の引数を増やすと毎回連れ回す形で見にくくなるけれど
再帰関数ではなく再帰メソッドにしてしまえば引数を増やさずにいくらでもパラメータを使えます

例えば「再帰で1からnまでの和や積」を求める例で「差分diff」が可変パラメータとした場合
struct Arith { diff: i32 }
impl Arith {
　fn sum(&self, n: i32) -> i32 { if n <= 0 { 0 } else { n + self.sum(n - self.diff) } }
　fn mul(&self, n: i32) -> i32 { if n <= 1 { 1 } else { n * self.mul(n - self.diff) } }
}
fn main() {
　let diff1 = Arith { diff: 1 };
　assert_eq!(diff1.sum(10), 55); // 1+2+3+4+5+6+7+8+9+10
　assert_eq!(diff1.mul(7), 5040); // 1*2*3*4*5*6*7
　let diff2 = Arith { diff: 2 };
　assert_eq!(diff2.sum(10), 30); // 2+4+6+8+10
　assert_eq!(diff2.mul(7), 105); // 1*3*5*7
}
今回はdiffの部分が1個だけですが複数のパラメータにもできます
こうすることで「グローバル変数を使わず」＆「引数を毎回連れ回さず」に書けます

**デフォルトの名無しさん** · 2021/08/10(火) 04:53:07.24

>>574
キャプチャしたいだけならクロージャ使えばいいけど

let test = 1;
let calc = || {
　if test == 1 { println!("yes") }
};
calc();

再帰ならaccumulator的なものを連れ回すほうがいいと思う

**デフォルトの名無しさん** · 2021/08/10(火) 05:14:22.44

>>581
moveしなくていいの？

**デフォルトの名無しさん** · 2021/08/10(火) 05:38:40.18

struct使ってimplで&mut selfを持ち回せばいい気が