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/08/30(月) 08:46:37.85

じゃあワイはガリガリ君で

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

>>214
C++ vs Rustスレでやれと何度言っても聞かずにここでイライラしてるよな

**デフォルトの名無しさん** · 2021/08/30(月) 10:38:26.28

上のイテレータ関連の質問に便乗ですが、
二次元vecの各要素をv[i][j]としたときに、
jごとの総和を計算するやつをイテレータできれいに書く方法ありますか？

例えばこういうやつです

let v = vec![vec![0; n]; m];
// (vの各要素を設定）
let mut result = vec![0; n];
for i in 0..m {
for j in 0..n {
result[j] += v[i][j];
}
}

**デフォルトの名無しさん** · 2021/08/30(月) 10:46:23.34

>中間変数を使うか否かだけの問題だからどうでもいい話

Rustの場合、ライフタイムとオーナーシップの関係で
中間変数を使うか否かは結構重要な問題だったりする

**デフォルトの名無しさん** · 2021/08/30(月) 10:56:01.57

>>220
mapしてsumすればいいだけでは？
きれいかどうかは知らんけど

**デフォルトの名無しさん** · 2021/08/30(月) 12:15:23.57

>>212
これ競プロ用でしょ
一般的なプログラミングとは観点が違うから最初に競プロ用だと書いておいたほうがいいぞ

**デフォルトの名無しさん** · 2021/08/30(月) 12:35:22.36

>>222
mapとsumで書けます？
iごとの総和なら単純に
v.into_iter().map(|v| v.into_iter().sum()).collect()
みたいな感じでいけるとおもうのですが、jごとだとちょっとわからないです

>>223
そうですね（実はもともとの発端は競プロではなかったりするのですが

**デフォルトの名無しさん** · 2021/08/30(月) 13:18:46.38

(0..n).map(|j| (0..m).map(|i| v[i][j]).sum()).collect()

2重forをの親子を逆転してイテレータメソッドチェーンに変換しただけという感じ
こんなことよりもっと意味のあることに頭使ったほうがいい
イテレータでとあったから上を書いたが現実にはndarray入れてsum_axis使うのがいいだろう
https://docs.rs/ndarray/0.15.3/ndarray/struct.ArrayBase.html#method.sum_axis

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

こんなかんじかな

https://play.rust-lang.org/?version=stable&;mode=debug&edition=2018&gist=e302c841c8dd709418f923ea1ad07868

**デフォルトの名無しさん** · 2021/08/30(月) 13:33:43.06

ほぼかぶってたごめん

**デフォルトの名無しさん** · 2021/08/30(月) 13:38:15.69

>>225-226 インデックス自体のイテレータを作るって発想がありませんでした、ありがとうございます
競プロ用ではないしndarray使うのも考えてみます

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

汎用的には縦横入れ替えのtransposeを作っておけば色んな操作が楽かもね
イテレータ作成はサボってとりあえず関数版
fn transpose<T>(v: &Vec<Vec<T>>) -> Vec<Vec<T>> where T: Copy {
　(0..v[0].len()).map(|j| v.into_iter().map(|vv| (*vv)[j]).collect::<Vec<T>>()).collect()
}
fn main() {
　let v = vec![vec![1,2,3], vec![4,5,6], vec![7,8,9], vec![10,11,12]];
　let w = transpose(&v);
　println!("{:?}", v); // [[1, 2, 3], [4, 5, 6], [7, 8, 9], [10, 11, 12]]
　println!("{:?}", w); // [[1, 4, 7, 10], [2, 5, 8, 11], [3, 6, 9, 12]]
}

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

transposeみたいな関数用意すべきかは配列の要素数次第かなあ
たかだか1度しか読まないデータのためだけに配列全体をコピーするのはもったいないケースはありそう

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

性能気にするなら Vec<Vec<_>> の形で数値格納するのではなく
Vec<_> に格納して (i, j) -> j*n+i みたいにインデックスを変換してくれるラッパーを被せた方がよさそう

**デフォルトの名無しさん** · 2021/08/30(月) 20:40:55.84

>>231
それがndarrayなのでは?

**デフォルトの名無しさん** · 2021/08/30(月) 20:50:30.90

これ匙投げたな
https://lkml.org/lkml/2021/7/4/171

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

C++ドロップアウターの吹き溜まりスレ

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

>>223
競プロではむしろ回答時間や処理速度のほうが重要なので、
あえてこういうのをイテレータで実装しようとしないよ
おれなら間違いなくforで回す。わざわざイテレータで回そうと考える時間が無駄

だけど、後から振り返って、これをイテレータで1行で簡単に表示できるんじゃないかな？と思うことはよくあるんよ。
そして、ドキュメントを見返したり、他人のソースを見て、ああこういうやり方もあるんだなと学習する

競プロは実際のコーディングに役立たないという人もいるけど、
普段、自分が利用しないメソッドや方法を発見すること、実務で役立ちそうなアルゴリズムがあることを知る
という意味では意味があると思う

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

>>235
競プロに対する君の考えを急に述べられましても・・・
誰も興味ないよ

**デフォルトの名無しさん** · 2021/08/31(火) 00:14:29.47

>>236
逆にいうと、君が競プロはこういうものだろうという勝手な解釈で意見を言うことにも意味がないということよ
それこそ誰も興味がない

**デフォルトの名無しさん** · 2021/08/31(火) 01:03:24.14

今日もまたこのパターンw
ヤバいやつっすね

**デフォルトの名無しさん** · 2021/08/31(火) 01:24:07.51

たまにLKMLのURL貼られるけどURLだけ貼られてもなんもわからん

**デフォルトの名無しさん** · 2021/08/31(火) 09:11:07.02

>>235
最適化まで考えるならforなんだろうけど、iterやcollectなんかが最適化が効かないのは今昔で、いずれは
最適化されるんじゃないだろうかと希望的観測を述べてみたり。実際gccなんかだとリンク時の最適化なんて
オプションあるし、あんまり凝ったiter/map/collect/foldだと理解に時間が掛かることはいなめない

**デフォルトの名無しさん** · 2021/08/31(火) 09:16:05.39

ぼくのかんがえた最強のコードが見下されたと思って悔しかったんだろうな
図星だったからこそ競プロでは逆にこんな書き方しないとか競プロは役に立つとか自己正当化に必死になる

追い越されたらバカにされたと思って煽り運転をする人と心理と同じなのでどちらの側も少し気を付けたほうがいい

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

forよりイテレータのメソッドチェーンのほうが処理速度速かった気がするんだが

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

やっていることが同じなら (最適化などによって) 結果のコードもおおよそ同じところに着地するよ。

**デフォルトの名無しさん** · 2021/08/31(火) 12:44:14.75

C/C++でポインタを使うと速い(プラシーボ)

**デフォルトの名無しさん** · 2021/08/31(火) 13:28:16.71

せやな。素朴なコンパイラならともかく
いまどきの最適化能力を期待できるなら
ポインタはエイリアス解析を困難にするから
むしろ足を引っ張る要素になる。

**デフォルトの名無しさん** · 2021/08/31(火) 14:25:42.76

>>244
ポインタは適切に使えばデータ構造やアルゴリズム自体が根本的に変えることが
できるので使わない時と比べて計算オーダー自体が劇的に変化することがあり、
プラシーボではない。
Rustはその点でC/C++に勝てない事がある。

**デフォルトの名無しさん** · 2021/08/31(火) 14:28:10.16

例えば、動的配列であるところのVectorはポインタでアクセスしても余り
効率は良くならないが、LinkedListは構造的にポインタで連結されており、
首尾一貫して添え字アクセスを使わずに必ずポインタでノードを識別する
ようにすれば、Vectorに比べて劇的に効率アップできることがある。
それはRustではほぼ不可能。ベンチマークはこの点が反映されてない。

**デフォルトの名無しさん** · 2021/08/31(火) 15:24:34.70

続きはこちらで
https://mevius.5ch.net/test/read.cgi/tech/1619219089/

**デフォルトの名無しさん** · 2021/08/31(火) 21:08:01.25

>>240
最適化ではなくて、forを利用してindexで回さないとできないことが山ほどあるんだよね
例えば、二分探索や三分探索とか

foreach（a in vec）で順繰りに回せる処理ならいいけど、
そういう処理ではできないこともあるので、
forで回す前提で考えたほうが、あとから修正する余地があるので、どうしてもforでindexで回すことになる
これは、イテレータのほうがループが速いというのと、また別の問題

**デフォルトの名無しさん** · 2021/08/31(火) 21:25:16.59

rustのforは他言語でいうforeach(a in vec)やろ

**デフォルトの名無しさん** · 2021/08/31(火) 21:26:56.02

そもそも二分探索を普通forで実装しないだろ

**デフォルトの名無しさん** · 2021/08/31(火) 21:39:55.47

for each 的なループで書いたものを二分探索に直す時点でプログラムとしては別物になりそうなんだけど
元のコードを iter じゃなく index アクセスするコードにしておくことでこの書き換えがどれほど楽になるのかね

まあここまでくると個人の好みの話なのでお好きにどうぞとしか言えないが

**デフォルトの名無しさん** · 2021/08/31(火) 21:59:30.62

Rustのfor式を理解してなかったんかーいっ！！！

**デフォルトの名無しさん** · 2021/08/31(火) 22:43:09.54

>>250
それは違う

まず1点目
リスト対するfor文をforeachと書かずforと書く言語の方が非常に多く一般的
C++もJavaもJavaScriptもPythonもRubyもAwkもshもリストに対してfor文

次に2点目
Rustのfor文はIterator loopと明確に書かれてるようにリストや配列に対してではなくイテレータ正確にはIntoIteratorを実装するものに対して

**デフォルトの名無しさん** · 2021/08/31(火) 23:30:53.76

もうコイツどうにかしてくれwww

**デフォルトの名無しさん** · 2021/08/31(火) 23:44:40.84

>>254
恥かいたので頑張って調べましたってレスなんだろうけど何一つ理解できてないぞ
もう一回調べ直してこい

**デフォルトの名無しさん** · 2021/08/31(火) 23:52:15.67

調べたのにfor式を理解できんかったんかーいっ！！！

**デフォルトの名無しさん** · 2021/08/31(火) 23:54:52.53

Rustのforで二分探索ってどうやるのか気になる

**デフォルトの名無しさん** · 2021/08/31(火) 23:56:09.61

どうせ自分で二分探索なんか実装しないだろ
気にするな
標準ライブラリ使え

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

>>258
for _ in 0..log2(n) as usize 的に回せばいいんでは?

まずやらないけど

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

>>260 それでどうやるかわかんねーんすけど
少なくとも>>249が言ってるforでindex回すってのとは違うような

**デフォルトの名無しさん** · 2021/09/01(水) 03:29:00.40

>>254
もちろんRustのforはVecや配列に適用じゃなくてイテレータに適用
だからリスト処理しかできない言語のfor/foreachよりはRustのforは適用範囲が広い
しかし

>>258
for以前に確定しているデータしかイテレータ内で使えなくて
これはforの中で算出されたデータを借用規則によりイテレータに反映させられないためで
forの中でif分岐などする形で二分探索は無理と思う
しかし

元々の>>249が言う
「forを利用してindexで回さないとできないことが山ほどある。例えば二分探索とか」も間違い
このforはC言語などのfor (index初期値; index条件判定; index更新)を指しているが
二分探索はindex更新が状況により増減変化するためfor(;;)文を使えない
無理やりにforを使っても更新項がないため最初からwhile文を使うのが正解
つまりCでもRustでも同じでforではなくwhileが使われる

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

こんな感じ？
fn binary_search<T>(array: &[T], target: T) -> Option<usize> where T: std::cmp::PartialOrd {
　let mut left = 0;
　let mut right = array.len() as i32 - 1;
　while left <= right {
　　let mid = (left + right) / 2;
　　if array[mid as usize] == target {
　　　return Some(mid as usize);
　　} else if array[mid as usize] < target {
　　　left = mid + 1;
　　} else {
　　　right = mid - 1;
　　}
　}
　return None;
}
Cで書いてもほぼ同じコードになるね
同じコードで任意の型に楽に対応できるRustの方が有利かな

**デフォルトの名無しさん** · 2021/09/01(水) 08:56:44.94

>>262
常識的なことを盛大に勘違いしてるので
>>254と同一人物なのモロバレだぞ

自分の書いたレスに他人のフリして間違いを指摘しようとするのは控えめに言っても病気

**デフォルトの名無しさん** · 2021/09/01(水) 19:34:58.07

>>249
お、249は俺だ。
言われてみれば確かに二分探索でforはないなｗｗ
while max-min > 0 とかそんな感じだった。飲んで書いてたからすまんすまん

でも、イテレータでなくてindexでやるほうが便利なことのほうが多いのは事実なのよ
動的計画法で現在の参照している配列の前後の内容を参照する時とか

**デフォルトの名無しさん** · 2021/09/01(水) 20:35:07.40

indexが便利なことの "方が" 多いの？
indexが便利なこと "も" 多いならわかる

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

自分は競プロでRustを使ってるけど、その範囲では圧倒的にindex

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

うーん、こういうのはイテレータだけでもいけるね
ttps://atcoder.jp/contests/abc138/tasks/abc138_d

static mut tree_list: Vec<(i64, i64)> = Vec::new();
static mut job_list: Vec<(i64, i64)> = Vec::new();
static mut res_list: Vec<i64> = Vec::new();

fn main() {
　unsafe {
　　input! {
　　　edge: i64, job: i64,
　　　tree_list0: [(i64, i64); edge-1],
　　　job_list0: [(i64, i64); job],
　　}

　　tree_list = tree_list0;
　　job_list = job_list0;
　　res_list = vec![0_i64; edge as usize + 1];

　　unsafe fn calc(index: i64, count: i64) {
　　　res_list[index as usize] += count;
　　　for &(a, b) in &tree_list { if a == index { calc(b, count); } }
　　}

　　for &(a, b) in &job_list { calc(a, b); }

　　for i in 1..res_list.len() { print!("{} ", res_list[i]); }
　　println!();
　}
}

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

ところで非同期ライブラリはどれが標準になるの？

**デフォルトの名無しさん** · 2021/09/02(木) 01:42:02.99

そりゃあれでしょ

**デフォルトの名無しさん** · 2021/09/02(木) 11:37:50.37

名前がダセェあれか

**デフォルトの名無しさん** · 2021/09/02(木) 14:15:51.06

お江戸

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

>>269
futuresで行ける

**デフォルトの名無しさん** · 2021/09/02(木) 15:18:41.35

Rustは、Tiobe index で、少し前に始めて20位に入ったが、今見たら
24位に下がってる。
このランキングの信憑性にも議論の余地はあろうが。
でも、日経の調査ではプロが使っている言語のTOPは、C/C++ということなので、
その調査とも整合はしている。
他の調査でも、CとC++を合算するとTOPか、2位になる。

**デフォルトの名無しさん** · 2021/09/02(木) 15:28:38.88

https://www.rust-lang.org/ja/production/users
には、Rust公式サイト(?)で製品に使っている企業名が書いてあるが、
聞いたことが無い企業が多い。それはそういうものなのかもしれないが。

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

>>254
お前の負けやでｗ

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

>>256
そらそろ宿題できたかい？

**デフォルトの名無しさん** · 2021/09/02(木) 18:51:20.53

>>277
お前の負けやでｗ

**デフォルトの名無しさん** · 2021/09/02(木) 19:10:59.17

また荒らしが来てるな
ところで非同期関数を呼ぶとfuture/promiseを返すだけでそのタイミングては実行開始しない怠惰タイプのプログラミング言語はRust以外に何があります？

**デフォルトの名無しさん** · 2021/09/02(木) 19:14:26.82

>>275
それはそう。
C++ を使ってる企業を並べてもほとんどは知らん企業になるはずだわ。

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

>>279
イテレータも理解してないのに他スレでRustをバカ推しすんなよな

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

イテレータも理解してないアホがいるのか

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

>>282
ほぅ(for)（　＾ω＾）・・・

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

>>269
せめてfutures::io::AsyncRead,AsyncWriteトレイトあたりで中立に互換性問題なんとかしてほしい

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

>>268
これじゃナイーブ過ぎて通らないでしょ

**デフォルトの名無しさん** · 2021/09/03(金) 00:54:23.74

>>283
いちゃラブ ((っ´ω`)♡(´ω`⊂ )) すればすぐわかるのにね

**デフォルトの名無しさん** · 2021/09/03(金) 13:54:25.02

let a = [10, 20, 130, 40];
let v = vec!a;//←これってなんでダメなんですか？

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

>>287
そういう構文規則(syntax)だから。
二行目は、vec! はマクロ名で、直後からはマクロの引数列が続く。
そして、その引数列は決まった形式で書く必要があり、
vec!a という形式はそれに当てはまってない。

**デフォルトの名無しさん** · 2021/09/03(金) 14:20:52.38

>>287
vec![]の[]は配列リテラルではなくて、一般的にマクロ呼び出しは[]か()か{}で引数を渡す
なので実はvec!(1)やvec!{1}も通るのだが、配列リテラルの見た目と合わせるために普通[]が使われる

**デフォルトの名無しさん** · 2021/09/03(金) 14:26:18.39

>>288
>>289
ありがとう
コンパイラの言い分もよくわかんなかったし、助かったぜ

**デフォルトの名無しさん** · 2021/09/03(金) 15:36:22.40

Cのvolatileって低レイヤで多用されるにもかかわらず実装依存なんだな
処理系依存の属性値的なのと同じようなもんか
Rustはcoreの中にvolatileアクセス用のメソッドが用意されている分進んでいる

**デフォルトの名無しさん** · 2021/09/03(金) 15:55:22.52

>>287
これは視点が斬新
いい質問だな

**デフォルトの名無しさん** · 2021/09/03(金) 18:49:30.86

何らか単純なmacroリライトとは異なるproprocessorが必要になりそうね
cとかlisp(cより遥かにまし)みたいなエラー挟み込むだけのマクロよりかは
rustのマクロはマシよね殆ど利便性は特になくcompile前にregex雑魚ver replace導入してるだけだけど
まぁ、素直なアプローチというか何というか(´・ω・｀)

**デフォルトの名無しさん** · 2021/09/03(金) 23:47:36.72

rustの勉強のため自作のbashコマンドを、rustで書き直してるんですが、
コマンド置換（　$(echo )　）はどうやればいいでしょうか？

Command::new('hoge').args......は調べたのですが、コマンド置換の方法が
どうしてもわかりません。

**デフォルトの名無しさん** · 2021/09/04(土) 01:53:11.04

>>294
Command::outputでstdout取得してきてそれをコマンド列に埋め込むとか？

**デフォルトの名無しさん** · 2021/09/04(土) 05:20:01.42

インタプリタを作るのでなければ置換の必要性ある？
例えばこういうことが出来ればいいんだよね？
let s = format!("今日は{}曜日です", String::from_utf8(std::process::Command::new("date").arg("+%a").env("LANG", "ja_JP.utf8").output()?.stdout)?.trim_end());

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

汚いコードだなぁ

**デフォルトの名無しさん** · 2021/09/04(土) 12:45:59.97

>>294
rustで書き直すのにCommandは違くないか？
bashのランタイムでevalしてるだけじゃん

**デフォルトの名無しさん** · 2021/09/04(土) 14:38:37.40

>>298
Command は system 関数相当じゃなくて fork/exec だから shell は関与しないと思ってたんだけど違うの？

**デフォルトの名無しさん** · 2021/09/04(土) 17:05:10.13

>>297
美しいコードをご教示して下さい

**デフォルトの名無しさん** · 2021/09/04(土) 17:33:46.64

>>299
fork/execだからとかそういう問題じゃなくて、
外部コマンド使うんだったら、それは単なるラッパーだろうと

要求する機能を満たすだけなら別にそれでも良いと思うが、
勉強のためにrustで書き直すというなら違和感がある
自作コマンドの内容にもよるけど

**デフォルトの名無しさん** · 2021/09/04(土) 19:48:22.92

>>299
もちろんshellは関与していない。
環境変数PATHに従い直接起動。
>>301
どのプログラミング言語で書いていようが、外部コマンドの呼び出しは普通にある。
それをゼロにするかどうかは様々なコストの問題。
例えば、そこがボトルネックになったら内部化など。

**デフォルトの名無しさん** · 2021/09/04(土) 20:41:42.28

>>301
shell を作ってるんだから外部コマンド呼び出してなんぼだと思うんだが

**デフォルトの名無しさん** · 2021/09/04(土) 21:53:33.09

>>303
>>294 はシェルを自作してるの？

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

>>304
自作のbashコマンドを自作の bash 互換シェルと読んでコマンド置換の仕組みを作ろうとしてるのかと思ったけど
もしかして bash スクリプトで書いたコマンドのことだったりする？
それにしたって外部コマンド含めて自作する必要はないと思うが

**デフォルトの名無しさん** · 2021/09/04(土) 23:54:37.12

なるほど
>>296と書くのではRustで書き直したことになっていないとはそういう意味か
これでいいのかな
use locale::Time;
use chrono::{Local, Datelike};
let s = format!("今日は{}曜日です", Time::load_user_locale().unwrap().short_day_name(Local::now().date().weekday().num_days_from_sunday() as usize));

**デフォルトの名無しさん** · 2021/09/05(日) 01:20:41.47

$ foo=$(bar $(baz))
↓
let foo = bar(baz())

**デフォルトの名無しさん** · 2021/09/05(日) 14:42:42.92

>>294
>rustの勉強のため自作のbashコマンドを、rustで書き直し
https://github.com/uutils/coreutils/blob/master/src/uu/echo/src/echo.rs

> コマンド置換（　$(echo )　）はどうやればいいでしょうか？
https://www.joshmcguigan.com/blog/build-your-own-shell-rust/
https://zenn.dev/garebare/articles/a463257c447fa9

独自shellスクリプトをbashやzshのように実行する際は標準入力を逐次読むインタラクティブシェルの
動作モードの他に第一引数のスクリプトパスを受け取り連続的に動作するようにしなければなりません。
上記のサンプルのように変数やコマンド置換を展開（子プロを作って実行結果を保持する）パーサーが
必要になります。（上の例ではリダイレクトやパイプなどしか処理していませんが）またファイル先頭の
#!/bin/shと同じようにshebangを認識するのはOSが行います。
そのほかにもifに使われるや"["もしくはtestなどは大昔はコマンドでしたが、現在は多くのシェルでは
組み込みのビルトインコマンドになっています。
また現在でもbashなどでクラッシュさせる脆弱性が発見されていますが、GNU bashの場合はパーサーは
手書きではなく、parse.yなどのyaccです

**デフォルトの名無しさん** · 2021/09/05(日) 19:37:48.09

シェル自体をRustで実装する話なん？

**デフォルトの名無しさん** · 2021/09/05(日) 20:23:09.21

想定外。
シェルスクリプトで書かれてる日常ツール類を、高速化＆練習ついでにRust化、ってのはよくある話なので、今回もそういうことかと想定してた。

**デフォルトの名無しさん** · 2021/09/05(日) 20:31:50.21

grepの書き換えとか入門用テキストあるあるだしな俺もそれかと思ってたw

インタープリターみたいの作りたいなら単純に考えて$(.+)みたいの発見し次第rustで書かれたプログラムに書き換え
この際$(.+)の.+の部分にもrust書き換えプログラムを同様に適用のrecursiveな奴考えるな
match等でregex構文が扱いやすい分rust native interpreterみたいの造りやすそう
あとそうゆうのredosだかなんだかのrust os projectみたいのあるから見たら面白いんじゃね(´・ω・｀)

**デフォルトの名無しさん** · 2021/09/07(火) 12:42:27.81

nullの可能性がある複数の参照を作りたい場合って
OptionとかRcを組み合わせるの？
縦によも横にもコードが長くなりそう

**デフォルトの名無しさん** · 2021/09/07(火) 13:22:01.93

Option<&T> や &Option<T>でも良いかも知れないけど状況次第
可変参照にしたいなら Rc<RefCell<Option<T>>> とかになるかも

**デフォルトの名無しさん** · 2021/09/07(火) 14:39:19.62

Rustの文化詳しくないけど、null objectは使わないの？
せっかく静的安全性にこだわっているのに、型無しのnullを使うのはこだわりが足りない気がするなぁ。

**デフォルトの名無しさん** · 2021/09/07(火) 15:00:30.72

OptionがあるのにNullObjectいらなくないです？

**デフォルトの名無しさん** · 2021/09/07(火) 15:16:47.38

>>314
見当違い。 >>312 はどこも指さない参照を便宜的に null と言ってるだけで、
実際には代数的データ型を活用して区別しようとしている。

**デフォルトの名無しさん** · 2021/09/07(火) 15:20:59.00

NullObjectは時代遅れ過ぎる

**312** · 2021/09/07(火) 15:36:48.61

>>316
正解

ただし、Rc<RefCell<Option<T>>>とか見ちゃうと
生ポインタにしたくなってくる……