Rust part18

**デフォルトの名無しさん** · 2022/12/10(土) 18:17:02.61

公式
https://www.rust-lang.org/
https://blog.rust-lang.org/
https://github.com/rust-lang/rust

Web上の実行環境
https://play.rust-lang.org

※Rustを学びたい人はまず最初に公式のThe Bookを読むこと
https://doc.rust-lang.org/book/

※Rustを学ぶ際に犯しがちな12の過ち
https://dystroy.org/blog/how-not-to-learn-rust

※Rustのasyncについて知りたければ「async-book」は必読
https://rust-lang.github.io/async-book/

※次スレは原則>>980が立てること

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

**デフォルトの名無しさん** · 2023/01/06(金) 23:51:15.52

>>762
>>759を動かそうとしてるんなら"calc\0"は第1引数じゃなくて第2引数よ
もうちょっと落ち着いて色々見直しなさいな

**デフォルトの名無しさん** · 2023/01/06(金) 23:53:05.97

>>761
10.1に書いてるコードがすでに参照使って書いてるじゃん
PartialOrd足せばそのまま動くけど？

**デフォルトの名無しさん** · 2023/01/07(土) 00:26:35.07

>>763
MSDNを見る限り単にアプリを起動するだけなら第一引数でも第二引数(読み込み専用不可)でも大差なくない？
動くようになった状態で入れ替えても問題なく動作するし

**デフォルトの名無しさん** · 2023/01/07(土) 01:02:32.01

>>765
こっちじゃ第1引数使うなら"C:\\Windows\\system32\\calc.exe\0"以外は
GetLastError()が2(ERROR_PATH_NOT_FOUND)を返してきて動かんのだけど……
MSDNも第1引数の説明にだけパス検索はしないだの拡張子つけろだの書いてあって、その通りに動作してるだけのように見えるし

https://learn.microsoft.com/en-us/windows/win32/api/processthreadsapi/nf-processthreadsapi-createprocessw

> The function will not use the search path. This parameter must include the file name extension; no default extension is assumed.

**デフォルトの名無しさん** · 2023/01/07(土) 01:04:28.02

>>761
とりあえず修正したコード

fn largest<T: PartialOrd>(list: &[T]) -> &T {
let mut res: &T = &list[0];
for elem in list.iter() {
if *elem > *res {
res = elem;
}
}
res
}

forの変数elemの型が諸々の事情でTになってたから&Tに直した
ついでにTのCopyもいらなくなりそうだから外した

letとかも同じだけど
let &x = ...
みたいに受け取る側に&をつけるとxの型は入れる値の&を外した型になる（とても雑な説明）

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

iter().min::<T>()みたいにかけないっけ
うんこまん

**デフォルトの名無しさん** · 2023/01/07(土) 01:32:02.10

>>767
ありがとうー
そういう仕組みなのね。勉強します

**はちみつ餃子** ◆8X2XSCHEME · 2023/01/07(土) 01:44:37.82

>>769
そのへんはパターンマッチと同じ理屈で解釈されるよ。

**デフォルトの名無しさん** · 2023/01/07(土) 02:06:28.88

・system()っぽい関数(起動したプロセスが終了するまでブロックする)
・CreateProcessW失敗時は起動失敗を呼び出し元に通知したい
・成功時に戻すべき情報はない
・Rust的にはResultを返すのが定石？
こういう時のコーディング例とかググっても全然出てこなくね・・・
重要なのはOk/Errのみで返り値は不要みたいなケース
とりあえずbool返しにしておくか

>>766
あれ？確かに。すまん気のせいだったっぽい

**デフォルトの名無しさん** · 2023/01/07(土) 02:31:58.39

>>767
> if *elem > *res {
if elem > res でいいよね

**デフォルトの名無しさん** · 2023/01/07(土) 02:40:46.97

古い劣化日本語訳を読んじゃってるみたいね
最低限本物のThe Bookを参照してから質問しよう
https://doc.rust-lang.org/book/ch10-01-syntax.html

**デフォルトの名無しさん** · 2023/01/07(土) 11:49:37.35

>>747
変数間でのオブジェクトの共有が気になるシチュエーションはjavaなんかは結構あると思う。

**デフォルトの名無しさん** · 2023/01/07(土) 16:25:18.46

rust-analyzerにもVSみたいにドロップダウンでplatform切り替える機能ほしいのう
cfgで複数のplatformに対応しているタイプのライブラリで便利そう

**デフォルトの名無しさん** · 2023/01/07(土) 16:40:32.23

継続不可能な状態→エラーダイアログを表示
ここまではいいけどこの後の後始末ってどう書くのがいいんだろうな
後始末のために共有データ(起動時に設定ファイルから読み込む)にアクセスしたいが
Dropトレイトにしろパニックハンドラにしろmainとは別スコープなのでアクセスできない
後始末のスコープ中で共有データを読み直すという手もあるけど、本当に意図しない状態で
強制終了する場合にファイルのロード＆パースをするのが望ましいとは思えない
Dropトレイトの初期化時に共有データの参照を渡しておくとか？

**デフォルトの名無しさん** · 2023/01/07(土) 17:10:37.53

>>776
mainの中で初期化してResultを返す本処理を呼ぶ形は無理？

fn main() {
// 初期化（設定読み込み）
let info = ...;

// 本処理
let result = main_body(&info);
match result {
OK(_) => {}
Err(e) => {
// エラー処理（info使える）
}
}
}

**デフォルトの名無しさん** · 2023/01/07(土) 18:02:32.48

>>777
それコードの位置が逆なだけじゃ。というかResult返しの実装方法を理解できていない
とりあえず共有データを保持している構造体にdropを実装してみた
自身へのアクセスは可能だしmainの終了時に実行される・・・はず

**デフォルトの名無しさん** · 2023/01/07(土) 18:21:41.85

>>777
よくこの文章を解釈できたな
素直にすごいわ

**デフォルトの名無しさん** · 2023/01/08(日) 00:10:22.65

Rustってゲームに向いてそうなイメージあるけどどうなんだろ
メモリリークは相当起きにくいよな？

**デフォルトの名無しさん** · 2023/01/08(日) 00:39:44.59

ゲーム開発はトリッキーな手品も使うだろうから向いてないんじゃないか

**デフォルトの名無しさん** · 2023/01/08(日) 00:51:12.10

今のご時世に非標準的な実装をするゲームとかOSのバージョンアップで爆死する未来が見える

**デフォルトの名無しさん** · 2023/01/08(日) 01:11:48.94

>>782
OSに関係無いところでのトリッキーなテクニックは有りえる。
例えば、複数のポインタ用のバッファをまとめてnewで確保してから、
直後に値を代入するようなことはC/C++では簡単に行なえる。
ところが安全性重視の言語だと、非初期化状態のポインタは許されないから、
少なくともnew演算子が自力でNULL初期化しなくてはならないので、
無駄になる。
他にも、配列の範囲チェックが無駄になる。

**デフォルトの名無しさん** · 2023/01/08(日) 01:15:49.98

>>783
ちなみに、
「非初期化状態の変数」は不安定になり易いので減らした方が良いとされているが、
BYTE *dst = new BYTE[1024];　// dst[k] はこの時点では未初期化状態
memcpy( dst, src, size );
のような時にはC++では効率を考えると仕方が無いものと考えられている。
0初期化すると無駄になるから。

**デフォルトの名無しさん** · 2023/01/08(日) 01:45:10.78

ヒープでいいならVec::with_capacityしてデータ入れた後にBoxed sliceにすればいい話だね
スタックでゼロ初期化した方が性能はいいと思うけど

**デフォルトの名無しさん** · 2023/01/08(日) 02:04:33.63

Box<dyn T>はBox<dyn T + 'static>のライフタイム省略版って聞いてたのに片方だけエラーになる
なんじゃこりゃ

https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=21ad8deab1cb8fb311aeed2ee668bf71

**デフォルトの名無しさん** · 2023/01/08(日) 02:36:10.85

Rustのメモリ安全性にはメモリリークしないことは含まれていないんだよね。
Rc<T>で循環参照するデータを作ってもコンパイルエラーにはならずメモリが解放されないままだったはず。
まぁメモリリークしててもメモリがある限り正しい結果を返すわけだし、メモリがなくなったらクラッシュするので間違いが起きたまま動作しつづけることはないけど。

**デフォルトの名無しさん** · 2023/01/08(日) 02:55:51.04

Rustは例えばGodotではGDScriptが実質Rustだし相当ゲーム制作に向いてる
https://gitlab.com/the-SSD/gdscript-compiler

**デフォルトの名無しさん** · 2023/01/08(日) 04:35:49.54

>>786
なんじゃそりゃ
どこでそんなデタラメ仕入れてきたの？

**デフォルトの名無しさん** · 2023/01/08(日) 06:55:53.23

技術評論社の書籍だろ。

**デフォルトの名無しさん** · 2023/01/08(日) 11:05:23.60

>>789
The Rust Referenceだった
この本デタラメなん？
https://doc.rust-lang.org/reference/lifetime-elision.html#default-trait-object-lifetimes

**デフォルトの名無しさん** · 2023/01/08(日) 11:05:27.68

>>781
そういう部分だけunsafe使えばいい。
unsafeダメ原理主義者になるな。

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

>>791
そこにはライフタイム省略版とは書いてないよ
expressionなどからライフタイムを推論できない場合はstaticになると書いてある
（例えばコード例のようなタイプエイリアスの場合など）
playgroundのコードではu2のライフタイムから推論されるからstaticにはならない

**デフォルトの名無しさん** · 2023/01/08(日) 11:35:19.20

>>791
これでしょ？

If the trait object is used as a type argument of a generic type then the containing type is first used to try to infer a bound.

If there is a unique bound from the containing type then that is the default

**デフォルトの名無しさん** · 2023/01/08(日) 11:50:51.08

>>793
は～んなるほどな
関数引数とか構造体メンバとかの'staticに推論される場所で使うことが多かったから勘違いしてたっぽい
ありがとう

**デフォルトの名無しさん** · 2023/01/08(日) 12:37:06.99

みんな大好きUnityなどと比べたらRust由来の効率低下なんて微々たるもの

**デフォルトの名無しさん** · 2023/01/08(日) 13:59:02.14

https://cdn.discordapp.com/attachments/953965039105232906/1061347007664500737/knhtsxphnnaa1.jpg

**デフォルトの名無しさん** · 2023/01/08(日) 14:01:25.73

https://lr.mint.lgbt/img/knhtsxphnnaa1.jpg

**デフォルトの名無しさん** · 2023/01/08(日) 14:08:03.69

>>796
それは言語としての魅力があればの話。

**デフォルトの名無しさん** · 2023/01/08(日) 15:57:06.75

>>797
安心安全だなあ

**デフォルトの名無しさん** · 2023/01/08(日) 16:08:08.46

>>797
unsafeの絵面ヤバくて草

**デフォルトの名無しさん** · 2023/01/08(日) 16:09:10.68

unsafeで書いたほうがコンパイル速度速くて好き

**デフォルトの名無しさん** · 2023/01/08(日) 16:30:50.12

せめてunsafeの間くらいは起こしてやれよ

**デフォルトの名無しさん** · 2023/01/08(日) 19:26:34.22

Rustで多量のファイルを高速に読み込みたい場合ってどうすればいいの？
std::fs::readはVec<u8>を返す＝メモリアロケータが動く＝遅い
十分なサイズのVecを事前に確保してreadなりReadFileなりを叩けば
任意のアドレスに読み込んでくれるけどほかに方法はないのかな

**デフォルトの名無しさん** · 2023/01/08(日) 20:32:01.24

Rustに限らずreadで遅いと感じるレベルならOS依存のmmap(memmap)くらいしか思いつかない
速さ目的で使ったことないから本当に速くなるか分からないけど

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

The Book を進めていくと Box<trait> でエラーになって Box<dyn trait> に変えろって言われるんだけど、dyn ってなんですか？

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

動的　ダイナミック
実行時に決まる的な

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

>>807
なるほど
trait は動的なのでより明確になるように dyn キーワードが追加された... という理解でいいでしょうか？

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

>>805
1MB/1000個くらいのファイルをstd::fs::readで読みながらVec[u8]に
extend_from_sliceで追加していくコードを書いてみたら数秒かかった
さすがに遅すぎ
せめてVec<u8>→Vec<u8>(の任意のインデックス)みたいなmemcpy的な
コピー手段はないのなか。どのくらい早くなるかわからんが

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

>>809
>1MB/1000個くらいのファイル
これはどういう意味？
/ は、割る、または、OR(または) の意味で用いる。
もしかして、
一個当り 1MB のファイルが 1000 個、合計サイズ 1GB の
ファイルのことを言っている？

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

>>810
ちなみに、そのくらい巨大になると、Rustの「安全機構」は体感速度に
まで影響する。

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

>>810
わかりにくくてすまん。ファイル総数1000程度、合計サイズ1MB程度

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

>>809
リリースビルドでその速度？

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

>>808
間違えてるかもしれんが俺の理解だと
>>traitは動的
traitは静的だけど、trait実装してる型が静的/動的に決まるかで
動的→dyn Trait　静的→ジェネリクスやimpl Trait　を使い分ける
よくある例では
Vec<T>はT１つ確定して他の型は一切受け付けないけど
Vec<Box<dyn Trait>>はTraitを実装してる型なら何でも入る

**デフォルトの名無しさん** · 2023/01/08(日) 22:01:47.30

>>814
分かりやすい説明でなんとなく理解できた気がする
ありがとう

**デフォルトの名無しさん** · 2023/01/08(日) 22:13:49.41

>>806
いい加減に本物のThe Book読めよ
ちゃんと説明されてるだろ？
https://doc.rust-lang.org/book/ch17-02-trait-objects.html

**デフォルトの名無しさん** · 2023/01/08(日) 22:45:09.72

>>809
extend_from_sliceだと遅そうだね
io::copyにしてみれば？

ちなみにその1000個をcpしたらどの程度で終わる環境？

**デフォルトの名無しさん** · 2023/01/08(日) 22:48:55.19

>>809
memcpyと同じことしたいならstd::ptrにcopyとかcopy_nonoverlappingが用意されてる
ただ引数はポインタだからunsafe

copy_nonoverlappingのExamplesがやりたいことに近いと思う
この例はコピー元のVecを空にしてるけどu8みたいなCopy型に限定すればコピー元のVecをそのままにしても一応安全

**デフォルトの名無しさん** · 2023/01/08(日) 22:52:59.71

818追記
コピー元が空になっても構わないならVec::appendで同じことができる

**デフォルトの名無しさん** · 2023/01/08(日) 23:03:17.84

>>817-819
ありがと。試してみます

エクスプローラーから同ドライブへのコピーで数秒ってところでしょうか

**デフォルトの名無しさん** · 2023/01/09(月) 00:21:25.60

>>812
1000個のファイルで1秒だと、もともとOSの速度がその程度の場合も有り得そう。
1ファイル当り1(ms)ということになるから。
もともとファイルはそこまで一度に沢山の個数をopen, closeすることは
想定されて無いので。
それもRustの安全機構が遅さに影響を与えているかも。

**デフォルトの名無しさん** · 2023/01/09(月) 00:26:23.50

>>821
ファイルって、例えばファイラーでコピーする場合でも、合計が同じ容量でも、
細かいファイルが多数有る場合の方がずっと遅くなる。
一個の1MBのファイルをコピーすると一瞬なのに、1KBの1000個のファイルをコピー
すると1秒くらい掛かるかも。

**デフォルトの名無しさん** · 2023/01/09(月) 01:18:38.59

profilingしてsyscallがボトルネックになってれば非同期や並列化で高速化するしかない

**デフォルトの名無しさん** · 2023/01/09(月) 10:40:30.18

たとえどんなにメモリ確保が遅くともディスクIOよりも遅いってことはないだろう
体感の遅さが何秒とかじゃなくてドライブのベンチマークと比べて判断しよう

**デフォルトの名無しさん** · 2023/01/09(月) 10:58:52.04

>>820
エクスプローラーってことはWindows?
そもそもWindowsはファイルシステムのsyscallが結構重いから
メモリコピーとか関係なくそんなものの可能性はあるかと
思い込みで試行錯誤してないでちゃんとプロファイル取ったほうがいいよ

**デフォルトの名無しさん** · 2023/01/09(月) 15:14:46.56

cargo testでドキュメントテストが実行されないんだけどお前らも同じ？
ドキュメントに書いてある通りに実行してるけど実行されない

**デフォルトの名無しさん** · 2023/01/09(月) 15:29:11.68

>>826
普通に実行されるから doctest の書き方間違えてるんじゃないのかなぁ
`(バッククォート) じゃなくて '(シングルクォート) になってるとか

**デフォルトの名無しさん** · 2023/01/09(月) 15:35:17.32

>>827
ああ、すみません。解決しました。
どうもバイナリだと実行されないみたいです。

cargo new myprog

で作成したバイナリだと駄目で

cargo new doclib --lib

で作成したライブラリではちゃんと実行されました。

**デフォルトの名無しさん** · 2023/01/09(月) 15:52:28.38

>>828
おお、本当ですね... なんでこういう動きなんだろう、分かる人いないかな？

**デフォルトの名無しさん** · 2023/01/09(月) 17:51:48.91

Rust固有の話でもないんだけどUnicode対応のアーカイブフォーマットってどんなのがあるんだろ
比較的新しい7zipはUnicodeファイル名をサポートしているけどライブラリやクレートが豊富とはいいがたい
かといってレガシーなzipやtarだとファイル名のコーディングは実装依存にみえる
実装依存の場合Unicodeファイル名をサポートしているライブラリやクレートがあるのかという問題も出てくるし

**デフォルトの名無しさん** · 2023/01/09(月) 19:37:23.02

tarで実験していたら詰んだｗ
let mut v:Vec<u8> = Vec::new();
let mut c = std::io::Cursor::new(v);
let mut t = tar::Builder::new(c);
t.append_path("foo.txt");
std::fs::write("foo.tar", &v); // borrow of moved value: `v`
どうしろと・・・

**はちみつ餃子** ◆8X2XSCHEME · 2023/01/09(月) 19:48:59.36

>>830
zip も特定のビットを立てていればファイル名が UTF-8 ということになる。
https://pkware.cachefly.net/webdocs/APPNOTE/APPNOTE-6.3.10.TXT
項目 4.4.4 で説明されている Bit 11 を見て。

**デフォルトの名無しさん** · 2023/01/09(月) 19:50:26.02

>>831
なにがしたいんこれ

**デフォルトの名無しさん** · 2023/01/09(月) 20:12:49.13

mut大好きそう

**デフォルトの名無しさん** · 2023/01/09(月) 20:21:20.61

>>833
オンメモリでtarを作って出来上がったものをファイルに保存したい

**デフォルトの名無しさん** · 2023/01/09(月) 20:46:41.39

tar使ったことないけどt.get_ref().get_ref()で&Vec<u8>取り出せるのかな
先にt.finish()呼ぶべきかもしれないしget_refよりinto_innerの方がいいかもしれない

get_refは詰み回避の頻出手筋

**デフォルトの名無しさん** · 2023/01/09(月) 21:28:27.40

>>836
let a = t.get_ref().get_ref();
std::fs::write("foo.tar", a);
これは一応それっぽいファイルが作られた

let mut a = t.into_inner().unwrap();
let mut f = std::fs::File::create("foo.tar").unwrap();
std::io::copy(&mut a, &mut f);
こっちは空っぽだった

ttps://crates.io/crates/tar
こんなサンプルしかないしCursorを使用する例なんて見当たらないし
どうやるのが妥当なのか全くわからん

**デフォルトの名無しさん** · 2023/01/09(月) 22:00:04.05

ttps://docs.rs/tar/latest/tar/struct.Builder.html#method.append_path
>pub fn append_path<P: AsRef<Path>>(&mut self, path: P) -> Result<()>
>～
>Also note that after all files have been written to an archive the finish function needs to be called to finish writing the archive.
らしいが
>pub fn finish(&mut self) -> Result<()>
>～
>In most situations the into_inner method should be preferred.
どっちなんだよｗ
ここに載っているサンプルだってinto_innerもfinishも呼んでいないのがあるし

**デフォルトの名無しさん** · 2023/01/09(月) 23:33:14.26

>>835
もう解決してそうだけど
let mut c = ...からt.append_path(...)までを別スコープにすれば通らない？

**デフォルトの名無しさん** · 2023/01/10(火) 00:39:55.01

>>837
空っぽになるのはtarのinto_innerでfinish経由でwrite_allが呼ばれて
cursorのpositionが末尾になっててio::copy時には書き出すものがないから

**デフォルトの名無しさん** · 2023/01/10(火) 00:49:25.83

t.append_pathしたタイミングでcursor.position進んでたわ
そりゃそうか

**デフォルトの名無しさん** · 2023/01/10(火) 01:07:25.76

let mut v = Vec::new();
let c = std::io::Cursor::new(&mut v);
let mut t = tar::Builder::new(c);
t.append_path("foo.txt");
t.finish();
drop(t);
std::fs::write("foo.tar", &v);

**デフォルトの名無しさん** · 2023/01/10(火) 01:15:57.75

get_mutでCursorにすればReaderとして使える

**デフォルトの名無しさん** · 2023/01/10(火) 02:21:46.49

そのコードでCursor使う意味が分からん
let mut tar = tar::Builder::new(Vec::new());
tar.append_path("foo.txt").unwrap();
let body = tar.into_inner().unwrap();
std::fs::write("foo.tar", body).unwrap();

**デフォルトの名無しさん** · 2023/01/10(火) 03:54:21.65

昨日のファイル1000個の続きなんじゃね
メモリに全部読読み込んでから処理しようとする理由は謎

**デフォルトの名無しさん** · 2023/01/10(火) 11:07:15.73

The Bookをやり終えたあとってどうするのがいい？
次に読むべきおすすめの書籍があるか知りたいです！

**デフォルトの名無しさん** · 2023/01/10(火) 13:00:32.37

>>846
次の書籍を読む前にThe Bookの復習がてら簡単なCLIツールを3～5個くらい書いて自分の理解を確かめたほうがいいよ

**デフォルトの名無しさん** · 2023/01/10(火) 16:48:39.24

>>847
アドバイスありがとうございます！
とりあえず何かしら作ってみようと思います

**デフォルトの名無しさん** · 2023/01/10(火) 17:29:32.58

コマンドラインに渡した(1000個の)ファイルを
指定した名前のtarファイルに書き出すツールとか

**デフォルトの名無しさん** · 2023/01/10(火) 18:47:02.53

>>845
メモリを事前に一括で確保してVecの逐次伸長をなくせば早くなるんじゃね？
と思ったけど実験してみたら全くそんなことはなかった。Rustのメモリアロケータって優秀なんだな・・・

**デフォルトの名無しさん** · 2023/01/10(火) 19:01:05.30

何使ってんのかな
mallocかな

**デフォルトの名無しさん** · 2023/01/10(火) 21:06:19.40

10回程度の小さい容量のアロケートなんてI/Oに比べれば微々たるものでしょ

**デフォルトの名無しさん** · 2023/01/11(水) 14:35:14.84

Vecのcapacityって再確保のたびに倍々に増えていくんじゃなかったっけ
ならpushの回数を増やしても再確保回数は大した数字にならないだろう

**デフォルトの名無しさん** · 2023/01/11(水) 19:26:52.32

ドライブレターを割り当ててあるネットワークドライブのパスを
dunce::canonicalizeに食わせるとUNCパスが返ってくる
そりゃねーぜ・・・

**デフォルトの名無しさん** · 2023/01/11(水) 21:38:38.39

こういう瑣末な問題を自分で解決する力のない人はまだRustを使うべき時期じゃないよね

**デフォルトの名無しさん** · 2023/01/11(水) 23:08:05.53

というかLinuxのProtonだとネットワークドライブへのアクセスでも
ドライブレタースタートのパスが返ってくるのな
結果、Windowsだと動かないけどLinuxなら動くという珍事になってるｗ

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

ファイル属性の取得はファイル読み込みよりは圧倒的に速いので
・ファイル名とファイルサイズの取得
・合計サイズのチェックと領域の確保
の順でやればマシかもね
ファイル読み込みに比べたら微々たる違いだとは思うが

**デフォルトの名無しさん** · 2023/01/12(木) 10:55:41.76

ファイルの数だけ二重にsyscallを呼び出すことになるからサイズのデカい数ファイルを処理するときならともかく1000ファイルで合計1MBという今回のケースだと悪化するんじゃね？

**デフォルトの名無しさん** · 2023/01/12(木) 11:13:05.66

ripgrepの実装でも見た方が早そう

**デフォルトの名無しさん** · 2023/01/12(木) 11:37:44.42

>>858
そもそもトータル１MB程度って分かってるなら余裕みて２MB程度確保しとけば良いような気がするが...

**デフォルトの名無しさん** · 2023/01/12(木) 12:26:48.24

>>859
ripgrepは今回のようにすべてのコンテンツを全て一括でメモリに保持するわけじゃないから
streamingで処理するのでいいなら固定長のバッファ確保してそこを使いながらパイプライン通して結果をI/O出力すればいい

>>860
アロケーションがボトルネックならそういう対処もあるだろうけど十中八九違うんじゃね？

**デフォルトの名無しさん** · 2023/01/12(木) 13:42:55.06

は？頭悪いの？