Rust part12

1 名前：デフォルトの名無しさん mailto:sage [2021/08/24(火) 22:55:27.78 ID:972JwtmU.net] 公式 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/ 231 名前：デフォルトの名無しさん [2021/08/30(月) 13:33:43.06 ID:w/2FJku9.net] ほぼかぶってたごめん 232 名前：デフォルトの名無しさん mailto:sage [2021/08/30(月) 13:38:15.69 ID:iy37Frot.net] >>225-226 インデックス自体のイテレータを作るって発想がありませんでした、ありがとうございます 競プロ用ではないしndarray使うのも考えてみます 233 名前：デフォルトの名無しさん mailto:sage [2021/08/30(月) 14:45:34.31 ID:07yK3Bti.net] 汎用的には縦横入れ替えの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]] } 234 名前：デフォルトの名無しさん mailto:sage [2021/08/30(月) 20:06:03.21 ID:kOjyqHoG.net] transposeみたいな関数用意すべきかは配列の要素数次第かなあ たかだか1度しか読まないデータのためだけに配列全体をコピーするのはもったいないケースはありそう 235 名前：デフォルトの名無しさん mailto:sage [2021/08/30(月) 20:10:57.31 ID:kOjyqHoG.net] 性能気にするなら Vec<Vec<_>> の形で数値格納するのではなく Vec<_> に格納して (i, j) -> j*n+i みたいにインデックスを変換してくれるラッパーを被せた方がよさそう 236 名前：デフォルトの名無しさん mailto:sage [2021/08/30(月) 20:40:55.84 ID:W4wNS06G.net] >>231 それがndarrayなのでは? 237 名前：デフォルトの名無しさん mailto:sage [2021/08/30(月) 20:50:30.90 ID:k7vUdD10.net] これ匙投げたな https://lkml.org/lkml/2021/7/4/171 238 名前：デフォルトの名無しさん mailto:sage [2021/08/30(月) 21:09:01.34 ID:bfTdIfIK.net] C++ドロップアウターの吹き溜まりスレ 239 名前：デフォルトの名無しさん mailto:sage [2021/08/30(月) 21:16:46.70 ID:Xk6FdWtE.net] >>223 競プロではむしろ回答時間や処理速度のほうが重要なので、 あえてこういうのをイテレータで実装しようとしないよ おれなら間違いなくforで回す。わざわざイテレータで回そうと考える時間が無駄 だけど、後から振り返って、これをイテレータで1行で簡単に表示できるんじゃないかな？と思うことはよくあるんよ。 そして、ドキュメントを見返したり、他人のソースを見て、ああこういうやり方もあるんだなと学習する 競プロは実際のコーディングに役立たないという人もいるけど、 普段、自分が利用しないメソッドや方法を発見すること、実務で役立ちそうなアルゴリズムがあることを知る という意味では意味があると思う 240 名前：デフォルトの名無しさん mailto:sage [2021/08/30(月) 21:24:57.91 ID:zvivEi6g.net] >>235 競プロに対する君の考えを急に述べられましても・・・ 誰も興味ないよ 241 名前：デフォルトの名無しさん mailto:sage [2021/08/31(火) 00:14:29.47 ID:NYCNDL8F.net] >>236 逆にいうと、君が競プロはこういうものだろうという勝手な解釈で意見を言うことにも意味がないということよ それこそ誰も興味がない 242 名前：デフォルトの名無しさん mailto:sage [2021/08/31(火) 01:03:24.14 ID:P5Wfb+Ix.net] 今日もまたこのパターンw ヤバいやつっすね 243 名前：デフォルトの名無しさん mailto:sage [2021/08/31(火) 01:24:07.51 ID:uga9Wpe3.net] たまにLKMLのURL貼られるけどURLだけ貼られてもなんもわからん 244 名前：デフォルトの名無しさん [2021/08/31(火) 09:11:07.02 ID:7zPv8PJ6.net] >>235 最適化まで考えるならforなんだろうけど、iterやcollectなんかが最適化が効かないのは今昔で、いずれは 最適化されるんじゃないだろうかと希望的観測を述べてみたり。実際gccなんかだとリンク時の最適化なんて オプションあるし、あんまり凝ったiter/map/collect/foldだと理解に時間が掛かることはいなめない 245 名前：デフォルトの名無しさん mailto:sage [2021/08/31(火) 09:16:05.39 ID:uIcWKBVk.net] ぼくのかんがえた最強のコードが見下されたと思って悔しかったんだろうな 図星だったからこそ競プロでは逆にこんな書き方しないとか競プロは役に立つとか自己正当化に必死になる 追い越されたらバカにされたと思って煽り運転をする人と心理と同じなのでどちらの側も少し気を付けたほうがいい 246 名前：デフォルトの名無しさん mailto:sage [2021/08/31(火) 10:02:54.76 ID:Mir3UPzo.net] forよりイテレータのメソッドチェーンのほうが処理速度速かった気がするんだが 247 名前：デフォルトの名無しさん mailto:sage [2021/08/31(火) 10:51:36.61 ID:ajUm3fTo.net] やっていることが同じなら (最適化などによって) 結果のコードもおおよそ同じところに着地するよ。 248 名前：デフォルトの名無しさん mailto:sage [2021/08/31(火) 12:44:14.75 ID:Iv8lyMCD.net] C/C++でポインタを使うと速い(プラシーボ) 249 名前：デフォルトの名無しさん mailto:sage [2021/08/31(火) 13:28:16.71 ID:ajUm3fTo.net] せやな。 素朴なコンパイラならともかく いまどきの最適化能力を期待できるなら ポインタはエイリアス解析を困難にするから むしろ足を引っ張る要素になる。 250 名前：デフォルトの名無しさん mailto:sage [2021/08/31(火) 14:25:42.76 ID:SlncBcTV.net] >>244 ポインタは適切に使えばデータ構造やアルゴリズム自体が根本的に変えることが できるので使わない時と比べて計算オーダー自体が劇的に変化することがあり、 プラシーボではない。 Rustはその点でC/C++に勝てない事がある。 251 名前：デフォルトの名無しさん mailto:sage [2021/08/31(火) 14:28:10.16 ID:SlncBcTV.net] 例えば、動的配列であるところのVectorはポインタでアクセスしても余り 効率は良くならないが、LinkedListは構造的にポインタで連結されており、 首尾一貫して添え字アクセスを使わずに必ずポインタでノードを識別する ようにすれば、Vectorに比べて劇的に効率アップできることがある。 それはRustではほぼ不可能。ベンチマークはこの点が反映されてない。 252 名前：デフォルトの名無しさん mailto:sage [2021/08/31(火) 15:24:34.70 ID:8qO1h2Cp.net] 続きはこちらで https://mevius.5ch.net/test/read.cgi/tech/1619219089/ 253 名前：デフォルトの名無しさん mailto:sage [2021/08/31(火) 21:08:01.25 ID:NYCNDL8F.net] >>240 最適化ではなくて、forを利用してindexで回さないとできないことが山ほどあるんだよね 例えば、二分探索や三分探索とか foreach（a in vec）で順繰りに回せる処理ならいいけど、 そういう処理ではできないこともあるので、 forで回す前提で考えたほうが、あとから修正する余地があるので、どうしてもforでindexで回すことになる これは、イテレータのほうがループが速いというのと、また別の問題 254 名前：デフォルトの名無しさん mailto:sage [2021/08/31(火) 21:25:16.59 ID:RnSwjxg3.net] rustのforは他言語でいうforeach(a in vec)やろ 255 名前：デフォルトの名無しさん mailto:sage [2021/08/31(火) 21:26:56.02 ID:RnSwjxg3.net] そもそも二分探索を普通forで実装しないだろ 256 名前：デフォルトの名無しさん mailto:sage [2021/08/31(火) 21:39:55.47 ID:KWeLtswn.net] for each 的なループで書いたものを二分探索に直す時点でプログラムとしては別物になりそうなんだけど 元のコードを iter じゃなく index アクセスするコードにしておくことでこの書き換えがどれほど楽になるのかね まあここまでくると個人の好みの話なのでお好きにどうぞとしか言えないが 257 名前：デフォルトの名無しさん mailto:sage [2021/08/31(火) 21:59:30.62 ID:Gkdn/HXs.net] Rustのfor式を理解してなかったんかーいっ！！！ 258 名前：デフォルトの名無しさん mailto:sage [2021/08/31(火) 22:43:09.54 ID:JHqwYLi1.net] >>250 それは違う まず1点目 リスト対するfor文をforeachと書かずforと書く言語の方が非常に多く一般的 C++もJavaもJavaScriptもPythonもRubyもAwkもshもリストに対してfor文 次に2点目 Rustのfor文はIterator loopと明確に書かれてるようにリストや配列に対してではなくイテレータ正確にはIntoIteratorを実装するものに対して 259 名前：デフォルトの名無しさん mailto:sage [2021/08/31(火) 23:30:53.76 ID:lNvHqkvm.net] もうコイツどうにかしてくれwww 260 名前：デフォルトの名無しさん mailto:sage [2021/08/31(火) 23:44:40.84 ID:Gy6+Rq7 ] [ここ壊れてます] 261 名前：L.net mailto: >>254 恥かいたので頑張って調べましたってレスなんだろうけど何一つ理解できてないぞ もう一回調べ直してこい [] [ここ壊れてます] 262 名前：デフォルトの名無しさん mailto:sage [2021/08/31(火) 23:52:15.67 ID:3ENBWRwS.net] 調べたのにfor式を理解できんかったんかーいっ！！！ 263 名前：デフォルトの名無しさん mailto:sage [2021/08/31(火) 23:54:52.53 ID:uga9Wpe3.net] Rustのforで二分探索ってどうやるのか気になる 264 名前：デフォルトの名無しさん mailto:sage [2021/08/31(火) 23:56:09.61 ID:cANa6qyq.net] どうせ自分で二分探索なんか実装しないだろ 気にするな 標準ライブラリ使え 265 名前：デフォルトの名無しさん mailto:sage [2021/09/01(水) 01:38:57.54 ID:iOouKnxp.net] >>258 for _ in 0..log2(n) as usize 的に回せばいいんでは? まずやらないけど 266 名前：デフォルトの名無しさん mailto:sage [2021/09/01(水) 01:59:11.36 ID:p49DyIKy.net] >>260 それでどうやるかわかんねーんすけど 少なくとも>>249が言ってるforでindex回すってのとは違うような 267 名前：デフォルトの名無しさん mailto:sage [2021/09/01(水) 03:29:00.40 ID:MtyAaHfZ.net] >>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が使われる 268 名前：デフォルトの名無しさん mailto:sage [2021/09/01(水) 05:05:49.84 ID:W5DSGMZK.net] こんな感じ？ 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の方が有利かな 269 名前：デフォルトの名無しさん mailto:sage [2021/09/01(水) 08:56:44.94 ID:wrwogreT.net] >>262 常識的なことを盛大に勘違いしてるので >>254と同一人物なのモロバレだぞ 自分の書いたレスに他人のフリして間違いを指摘しようとするのは控えめに言っても病気 270 名前：デフォルトの名無しさん mailto:sage [2021/09/01(水) 19:34:58.07 ID:8EcW0Jj4.net] >>249 お、249は俺だ。 言われてみれば確かに二分探索でforはないなｗｗ while max-min > 0 とかそんな感じだった。飲んで書いてたからすまんすまん でも、イテレータでなくてindexでやるほうが便利なことのほうが多いのは事実なのよ 動的計画法で現在の参照している配列の前後の内容を参照する時とか 271 名前：デフォルトの名無しさん mailto:sage [2021/09/01(水) 20:35:07.40 ID:+RqlKI+M.net] indexが便利なことの "方が" 多いの？ indexが便利なこと "も" 多いならわかる 272 名前：デフォルトの名無しさん mailto:sage [2021/09/01(水) 21:13:02.22 ID:8EcW0Jj4.net] 自分は競プロでRustを使ってるけど、その範囲では圧倒的にindex 273 名前：デフォルトの名無しさん mailto:sage [2021/09/01(水) 21:38:57.15 ID:8EcW0Jj4.net] うーん、こういうのはイテレータだけでもいけるね 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!(); 　} } 274 名前：デフォルトの名無しさん [2021/09/02(木) 00:21:53.48 ID:nqohbFGX.net] ところで非同期ライブラリはどれが標準になるの？ 275 名前：デフォルトの名無しさん mailto:sage [2021/09/02(木) 01:42:02.99 ID:S2XiqXH4.net] そりゃあれでしょ 276 名前：デフォルトの名無しさん mailto:sage [2021/09/02(木) 11:37:50.37 ID:UEpMLVw4.net] 名前がダセェあれか 277 名前：デフォルトの名無しさん mailto:sage [2021/09/02(木) 14:15:51.06 ID:AObLO14s.net] お江戸 278 名前：デフォルトの名無しさん mailto:sage [2021/09/02(木) 14:55:26.38 ID:2FuyxSW6.net] >>269 futuresで行ける 279 名前：デフォルトの名無しさん mailto:sage [2021/09/02(木) 15:18:41.35 ID:l4XbE5cZ.net] Rustは、Tiobe index で、少し前に始めて20位に入ったが、今見たら 24位に下がってる。 このランキングの信憑性にも議論の余地はあろうが。 でも、日経の調査ではプロが使っている言語のTOPは、C/C++ということなので、 その調査とも整合はしている。 他の調査でも、CとC++を合算するとTOPか、2位になる。 280 名前：デフォルトの名無しさん mailto:sage [2021/09/02(木) 15:28:38.88 ID:l4XbE5cZ.net] https://www.rust-lang.org/ja/production/users には、Rust公式サイト(?)で製品に使っている企業名が書いてあるが、 聞いたことが無い企業が多い。それはそういうものなのかもしれないが。 281 名前：デフォルトの名無しさん [2021/09/02(木) 17:24:27.18 ID:oZlwZEWk.net] >>254 お前の負けやでｗ 282 名前：デフォルトの名無しさん mailto:sage [2021/09/02(木) 17:50:16.02 ID:5ahReTWB.net] >>256 そらそろ宿題できたかい？ 283 名前：デフォルトの名無しさん [2021/09/02(木) 18:51:20.53 ID:oZlwZEWk.net] >>277 お前の負けやでｗ 284 名前：デフォルトの名無しさん mailto:sage [2021/09/02(木) 19:10:59.17 ID:2FuyxSW6.net] また荒らしが来てるな ところで非同期関数を呼ぶとfuture/promiseを返すだけでそのタイミングては実行開始しない怠惰タイプのプログラミング言語はRust以外に何があります？ 285 名前：デフォルトの名無しさん mailto:sage [2021/09/02(木) 19:14:26.82 ID:rwq3+G7G.net] >>275 それはそう。 C++ を使ってる企業を並べてもほとんどは知らん企業になるはずだわ。 286 名前：デフォルトの名無しさん mailto:sage [2021/09/02(木) 20:17:55.99 ID:cdb/p6kF.net] >>279 イテレータも理解してないのに他スレでRustをバカ推しすんなよな 287 名前：デフォルトの名無しさん mailto:sage [2021/09/02(木) 21:18:33.70 ID:5ahReTWB.net] イテレータも理解してないアホがいるのか 288 名前：デフォルトの名無しさん [2021/09/02(木) 21:26:15.36 ID:+7Q9WvZy.net] >>282 ほぅ(for)（　＾ω＾）・・・ 289 名前：デフォルトの名無しさん mailto:sage [2021/09/02(木) 22:29:04.14 ID:2FuyxSW6.net] >>269 せめてfutures::io::AsyncRead,AsyncWriteトレイトあたりで中立に互換性問題なんとかしてほしい 290 名前：デフォルトの名無しさん mailto:sage [2021/09/02(木) 23:41:15.18 ID:Ubg4tWaQ.net] >>268 これじゃナイーブ過ぎて通らないでしょ 291 名前：デフォルトの名無しさん mailto:sage [2021/09/03(金) 00:54:23.74 ID:2xSRfF9g.net] >>283 いちゃラブ ((っ´ω`)♡(´ω`⊂ )) すればすぐわかるのにね 292 名前：デフォルトの名無しさん [2021/09/03(金) 13:54:25.02 ID:j8ut1qUg.net] let a = [10, 20, 130, 40]; let v = vec!a;//←これってなんでダメなんですか？ 293 名前：デフォルトの名無しさん mailto:sage [2021/09/03(金) 14:17:04.75 ID:9y+1HwQb.net] >>287 そういう構文規則(syntax)だから。 二行目は、vec! はマクロ名で、直後からはマクロの 294 名前：引数列が続く。 そして、その引数列は決まった形式で書く必要があり、 vec!a という形式はそれに当てはまってない。 [] [ここ壊れてます] 295 名前：デフォルトの名無しさん mailto:sage [2021/09/03(金) 14:20:52.38 ID:12Im1YVo.net] >>287 vec![]の[]は配列リテラルではなくて、一般的にマクロ呼び出しは[]か()か{}で引数を渡す なので実はvec!(1)やvec!{1}も通るのだが、配列リテラルの見た目と合わせるために普通[]が使われる 296 名前：デフォルトの名無しさん [2021/09/03(金) 14:26:18.39 ID:j8ut1qUg.net] >>288 >>289 ありがとう コンパイラの言い分もよくわかんなかったし、助かったぜ 297 名前：デフォルトの名無しさん mailto:sage [2021/09/03(金) 15:36:22.40 ID:eAcQJHwr.net] Cのvolatileって低レイヤで多用されるにもかかわらず実装依存なんだな 処理系依存の属性値的なのと同じようなもんか Rustはcoreの中にvolatileアクセス用のメソッドが用意されている分進んでいる 298 名前：デフォルトの名無しさん mailto:sage [2021/09/03(金) 15:55:22.52 ID:4g+/rgm+.net] >>287 これは視点が斬新 いい質問だな 299 名前：デフォルトの名無しさん [2021/09/03(金) 18:49:30.86 ID:XJw5Azdc.net] 何らか単純なmacroリライトとは異なるproprocessorが必要になりそうね cとかlisp(cより遥かにまし)みたいなエラー挟み込むだけのマクロよりかは rustのマクロはマシよね殆ど利便性は特になくcompile前にregex雑魚ver replace導入してるだけだけど まぁ、素直なアプローチというか何というか(´・ω・｀) 300 名前：デフォルトの名無しさん [2021/09/03(金) 23:47:36.72 ID:g/jq2Cau.net] rustの勉強のため自作のbashコマンドを、rustで書き直してるんですが、 コマンド置換（　$(echo )　）はどうやればいいでしょうか？ Command::new('hoge').args......は調べたのですが、コマンド置換の方法が どうしてもわかりません。 301 名前：デフォルトの名無しさん mailto:sage [2021/09/04(土) 01:53:11.04 ID:HZGHSQTb.net] >>294 Command::outputでstdout取得してきてそれをコマンド列に埋め込むとか？ 302 名前：デフォルトの名無しさん mailto:sage [2021/09/04(土) 05:20:01.42 ID:iqtSb51S.net] インタプリタを作るのでなければ置換の必要性ある？ 例えばこういうことが出来ればいいんだよね？ let s = format!("今日は{}曜日です", String::from_utf8(std::process::Command::new("date").arg("+%a").env("LANG", "ja_JP.utf8").output()?.stdout)?.trim_end()); 303 名前：デフォルトの名無しさん mailto:sage [2021/09/04(土) 09:57:53.03 ID:KxfCnNFO.net] 汚いコードだなぁ 304 名前：デフォルトの名無しさん mailto:sage [2021/09/04(土) 12:45:59.97 ID:mADKIhQi.net] >>294 rustで書き直すのにCommandは違くないか？ bashのランタイムでevalしてるだけじゃん 305 名前：デフォルトの名無しさん mailto:sage [2021/09/04(土) 14:38:37.40 ID:1i5Z4ndW.net] >>298 Command は system 関数相当じゃなくて fork/exec だから shell は関与しないと思ってたんだけど違うの？ 306 名前：デフォルトの名無しさん mailto:sage [2021/09/04(土) 17:05:10.13 ID:iqtSb51S.net] >>297 美しいコードをご教示して下さい 307 名前：デフォルトの名無しさん mailto:sage [2021/09/04(土) 17:33:46.64 ID:mADKIhQi.net] >>299 fork/execだからとかそういう問題じゃなくて、 外部コマンド使うんだったら、それは単なるラッパーだろうと 要求する機能を満たすだけなら別にそれでも良いと思うが、 勉強のためにrustで書き直すというなら違和感がある 自作コマンドの内容にもよるけど 308 名前：デフォルトの名無しさん mailto:sage [2021/09/04(土) 19:48:22.92 ID:FwiYtexa.net] >>299 もちろんshellは関与していない。 環境変数PATHに従い直接起動。 >>301 どのプログラミング言語で書いていようが、外部コマンドの呼び出しは普通にある。 それをゼロにするかどうかは様々なコストの問題。 例えば、そこがボトルネックになったら内部化など。 309 名前：デフォルトの名無しさん mailto:sage [2021/09/04(土) 20:41:42.28 ID:HZGHSQTb.net] >>301 shell を作ってるんだから外部コマンド呼び出してなんぼだと思うんだが 310 名前：デフォルトの名無しさん [2021/09/04(土) 21:53:33.09 ID:CUdge0sZ.net] >>303 >>294 はシェルを自作してるの？ 311 名前：デフォルトの名無しさん mailto:sage [2021/09/04(土) 22:09:11.34 ID:HZGHSQTb.net] >>304 自作のbashコマンドを自作の bash 互換シェルと読んでコマンド置換の仕組みを作ろうとしてるのかと思ったけど もしかして bash スクリプトで書いたコマンドのことだったりする？ それにしたって外部コマンド含めて自作する必要はないと思うが 312 名前：デフォルトの名無しさん mailto:sage [2021/09/04(土) 23:54:37.12 ID:iqtSb51S.net] なるほど >>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)); 313 名前：デフォルトの名無しさん mailto:sage [2021/09/05(日) 01:20:41.47 ID:lJqHVJAL.net] $ foo=$(bar $(baz)) ↓ let foo = bar(baz()) 314 名前：デフォルトの名無しさん [2021/09/05(日) 14:42:42.92 ID:5vCe2TIK.net] >>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です 315 名前：デフォルトの名無しさん mailto:sage [2021/09/05(日) 19:37:48.09 ID:vqQF7q4/.net] シェル自体をRustで実装する話なん？ 316 名前：デフォルトの名無しさん mailto:sage [2021/09/05(日) 20:23:09.21 ID:qXYO1Gcj.net] 想定外。 シェルスクリプトで書かれてる日常ツール類を、高速化＆練習ついでにRust化、ってのはよくある話なので、今回もそういうことかと想定してた。 317 名前：デフォルトの名無しさん [2021/09/05(日) 20:31:50.21 ID:Mq9n6pyZ.net] grepの書き換えとか入門用テキストあるあるだしな俺もそれかと思ってたw インタープリターみたいの作りたいなら単純に考えて$(.+)みたいの発見し次第rustで書かれたプログラムに書き換え この際$(.+)の.+の部分にもrust書き換えプログラムを同様に適用のrecursiveな奴考えるな match等でregex構文が扱いやすい分rust native interpreterみたいの造りやすそう あとそうゆうのredos 318 名前：だかなんだかのrust os projectみたいのあるから見たら面白いんじゃね(´・ω・｀) [] [ここ壊れてます] 319 名前：デフォルトの名無しさん mailto:sage [2021/09/07(火) 12:42:27.81 ID:O1QkM6d3.net] nullの可能性がある複数の参照を作りたい場合って OptionとかRcを組み合わせるの？ 縦によも横にもコードが長くなりそう 320 名前：デフォルトの名無しさん mailto:sage [2021/09/07(火) 13:22:01.93 ID:J2y4//gF.net] Option<&T> や &Option<T>でも良いかも知れないけど状況次第 可変参照にしたいなら Rc<RefCell<Option<T>>> とかになるかも 321 名前：デフォルトの名無しさん mailto:sage [2021/09/07(火) 14:39:19.62 ID:vfOWvkqv.net] Rustの文化詳しくないけど、null objectは使わないの？ せっかく静的安全性にこだわっているのに、型無しのnullを使うのはこだわりが足りない気がするなぁ。 322 名前：デフォルトの名無しさん mailto:sage [2021/09/07(火) 15:00:30.72 ID:gb4OeP+0.net] OptionがあるのにNullObjectいらなくないです？ 323 名前：デフォルトの名無しさん mailto:sage [2021/09/07(火) 15:16:47.38 ID:yn0D/zff.net] >>314 見当違い。 >>312 はどこも指さない参照を便宜的に null と言ってるだけで、 実際には代数的データ型を活用して区別しようとしている。 324 名前：デフォルトの名無しさん mailto:sage [2021/09/07(火) 15:20:59.00 ID:oZHnA/lF.net] NullObjectは時代遅れ過ぎる 325 名前：312 mailto:sage [2021/09/07(火) 15:36:48.61 ID:O1QkM6d3.net] >>316 正解 ただし、Rc<RefCell<Option<T>>>とか見ちゃうと 生ポインタにしたくなってくる…… 326 名前：デフォルトの名無しさん mailto:sage [2021/09/07(火) 15:42:12.42 ID:gb4OeP+0.net] 参照をRcするような場面てあんまりないような気がする ところでRc<RefCell<Option<T>>>は、 参照じゃなくてヒープにある（かもしれない）Tの共有になりませんか 327 名前：デフォルトの名無しさん mailto:sage [2021/09/07(火) 15:58:38.34 ID:X4ha4H+D.net] >>319 実体は必ずヒープ上 実体の構造は(強,弱,(借,(Some,T)) そしてそのヒープ上にある実体を指してるポインタはどこにあっても複数あってもよい 328 名前：デフォルトの名無しさん mailto:sage [2021/09/07(火) 18:22:59.95 ID:J2y4//gF.net] >>319 ヒープ上にある RefCell<Option<T>> を共有することになるね 参照 (&T) ではないというのはそう 329 名前：デフォルトの名無しさん mailto:sage [2021/09/07(火) 19:09:15.95 ID:/9ekKyA5.net] >>316 >>318 サンクス。JavaのOptionalみたいなものね。 >>317 nullobjectと比較したときのメリットは？ 条件分岐を強制させることができることくらいかしらん？ 330 名前：デフォルトの名無しさん mailto:sage [2021/09/07(火) 20:06:06.42 ID:Z/GuZfd2.net] >>322 impl<T> SomeTrait for Option<T> where T: SomeTrait { ... } ってやれば条件分岐すら自分で書かなくていいよ 331 名前：デフォルトの名無しさん mailto:sage [2021/09/07(火) 21:28:45.74 ID:GNL8Ud6q.net] >>323 それはTraitのメソッドで分岐相当のコードを書くか chainさせるだけで分岐処理を遅延するかのどちらかなので 分岐すら自分で書かなくていいというのはちょっと違う気がする

---

---

[ 続きを読む ] / [ 携帯版 ]

read.cgi ver5.27 [feat.BBS2 +1.6] / e.0.2 (02/09/03) / eucaly.net products.
担当:undef