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

は？頭悪いの？

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

>>861
> アロケーションがボトルネックならそういう対処もあるだろうけど十中八九違うんじゃね？
そんなのはみんなわかっててあーだこーだ言ってるわけだがw

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

>>863
的外れないことを言ってる自覚があるなら>>860みたいなレスはしないだろ

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

的外れないことって何？w

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

dunce::canonicalizeはダメっぽいのでGetFullPathNameWを使うことにした
ちょうどいいシステムコールが用意されているなら安易に野良クレートを使うより確実な気がしてきた

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

やっぱC言語の方が良くね？

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

というと ?

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

いや、知らんけどｗ

**デフォルトの名無しさん** · 2023/01/13(金) 20:32:09.46

知らないなら言うなよ

**デフォルトの名無しさん** · 2023/01/13(金) 21:11:06.84

>>844
のコード見るだけでも、Rustは書き味の悪い言語だと思う。

**デフォルトの名無しさん** · 2023/01/13(金) 21:13:37.70

>>871
悪い見本だもの

**デフォルトの名無しさん** · 2023/01/13(金) 21:16:19.91

>>872
Rust関連の本を何冊か読んだが良いコードは余り無い。

**デフォルトの名無しさん** · 2023/01/13(金) 21:19:33.92

悪い見本だと判別できない時点でろくな本を読んでないことが分かる

**デフォルトの名無しさん** · 2023/01/13(金) 21:21:43.63

みんなの参考になるように読んだ本を列挙してみてはどうだ？

**デフォルトの名無しさん** · 2023/01/13(金) 21:26:26.06

はっきり言ってやろう。Rustは根本的に書き味が悪いんだよ。

**デフォルトの名無しさん** · 2023/01/13(金) 21:29:15.41

Rustは苦痛を感じるためのドM言語ってこと、忘れてないか？

**デフォルトの名無しさん** · 2023/01/13(金) 21:29:53.28

>>876
じゃ君が思う根本的に書き味が良い言語は何なの？

**デフォルトの名無しさん** · 2023/01/13(金) 21:35:01.32

>>878
c

**デフォルトの名無しさん** · 2023/01/13(金) 21:47:38.65

ワイはJava

**デフォルトの名無しさん** · 2023/01/13(金) 21:48:28.21

Kotlin、C#も好き

**デフォルトの名無しさん** · 2023/01/13(金) 22:05:13.48

ラクダケース派か
PythonとかRustみたいに型と変数でラクダとヘビ使い分けるパターンって名前あるのかな

**デフォルトの名無しさん** · 2023/01/13(金) 22:18:14.76

C#はたしかに何やるのも楽だ

**デフォルトの名無しさん** · 2023/01/13(金) 22:45:44.13

Rustってそもそもコンパイル速度が遅くてダメだわ

**デフォルトの名無しさん** · 2023/01/13(金) 22:48:50.23

Goはコンパイル最速だからデオキシスのスピードフォルムだな
Rustはディフィンス、Java/C#はノーマルフォルムだな
アタックフォルムは知らん

**デフォルトの名無しさん** · 2023/01/13(金) 23:27:46.90

>>878
C, C++, C#, JS, Ruby, Java は、Rustよりは書き味がいい。

**デフォルトの名無しさん** · 2023/01/14(土) 00:10:54.25

自分はスネーク派だからJavaとC#は苦手（根本的に書き味が悪い）
Python使用歴が長かったからだと思う
CとC++は何でもありだからどうでもいいけど
TypeScript（JS）も油断するとスネークで書いてたりする

**デフォルトの名無しさん** · 2023/01/14(土) 00:20:05.26

スネークとは関係なく、Rustは書き味が悪い。
他のどんな言語にも無い書きにくさ。
Kotlinも書き味が悪いから没落中。

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

汚コード量産言語

**デフォルトの名無しさん** · 2023/01/14(土) 06:19:32.45

書き味で言うならNimが一番良い。

特にメソッド呼出し構文はNimが一番洗練されていると思う。UFCSとかもっと色々な言語で採用されてほしい。

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

でもnimって流行ってないじゃん？

**デフォルトの名無しさん** · 2023/01/14(土) 10:29:27.36

nimの構文とか好きな人は好きだろうと思うけど自分は嫌いだし
嫌いな構文をわざわざ使うほどの他の魅力がないんだよなぁ

**デフォルトの名無しさん** · 2023/01/14(土) 11:26:06.77

書き味悪いとか言ってRust使う気全くないのにわざわざRustスレに書き込もうとするのが一番意味不明

**デフォルトの名無しさん** · 2023/01/14(土) 11:58:15.30

>>893
オレもそう思った
意味不明というかアンチスレあるからそっちでやれよ
って感じ

**デフォルトの名無しさん** · 2023/01/14(土) 12:05:24.38

わざわざ文句いいに来るおじさんって大抵構ってちゃん

**デフォルトの名無しさん** · 2023/01/14(土) 13:50:07.41

「書き味」の良さ悪さの原因を自分なりに考察して言語化してれば多少は議論になるんだけどな

慣れと好みの次元でしか語れないならお爺ちゃんの自分語りでしかないから相手しても無駄

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

そもそもRustはいろいろ我慢して使う言語だし
みんな上に言われて仕方なく使ってる

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

>>896
そんなことしたら、ずるがしこい人達にアイデア盗まれるだけじゃ。

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

何が良くて何が悪いかを発見すること能力こそ重要なのだから。

**デフォルトの名無しさん** · 2023/01/14(土) 14:33:09.89

>>898
糖質おつ

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

コンパイラ安全最強はrust
コンパイラ速度最強はgolang
オブジェクト指向設計最強はjava/c#
汎用最強はc/c++

**デフォルトの名無しさん** · 2023/01/14(土) 14:56:30.09

殆どの言語は高速化に向けて頑張ってるからGo言語の地位は危ういけど、既存の言語をメモリ安全にするのは大変だからRustは安泰
強みがあるって大事

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

もう次世代言語スレ立ててこいよ

**デフォルトの名無しさん** · 2023/01/14(土) 15:40:05.51

また次世代言語スレ(旧世代おじいちゃん隔離スレ)が消えたから溜まり場になってるのか
迷惑な話だな

**デフォルトの名無しさん** · 2023/01/14(土) 15:51:18.61

rustが次世代言語、、？まじぃ？

**デフォルトの名無しさん** · 2023/01/14(土) 15:55:26.44

次世代の言語
https://mevius.5ch.net/test/read.cgi/tech/1571717826/

**デフォルトの名無しさん** · 2023/01/14(土) 17:40:41.95

>>898
アホだろw

「トマトは不味い、俺はりんごが好き」と同程度の話なのにお前がりんごが美味いと感じる理由を説明したらそのアイデアwとやらがが盗まれると思ってんのかww

**デフォルトの名無しさん** · 2023/01/14(土) 17:48:38.74

>>907
まともにrust使ったことないのがまたバレるから誤魔化してるだけでしょ

**デフォルトの名無しさん** · 2023/01/14(土) 18:06:11.45

アイデアってことは書き味のいい最強のプログラミング言語の開発でもしてるんだろうな

**デフォルトの名無しさん** · 2023/01/14(土) 18:36:28.57

仮に、あくまでも仮にプログラミング言語を確実に素晴らしくする案があったとして
その案が盗まれて (他の言語に取り入れられて) なんか損なことがあるのか？
世の中に良いものがひとつ増えればありがたい話。

**デフォルトの名無しさん** · 2023/01/14(土) 19:24:05.22

車関連のソフトウェア携わってるやつおる？
今年から急にrustの案件増えてきてね？
しかもすごい金かけてる案件が目白押し
うちは4次請け5次受けくらいの立場だからわからないけどこれってＴＯＹＯＴＡとかホンダとかが大元なのか？

**デフォルトの名無しさん** · 2023/01/14(土) 19:34:43.90

勘弁してくれよ、、
Google Chrome、プログラミング言語「Rust」の採用を発表
https://news.mynavi.jp/techplus/article/20230113-2561774/

**デフォルトの名無しさん** · 2023/01/14(土) 20:10:33.53

>>911
>>589

世間知らずもほどがある

**デフォルトの名無しさん** · 2023/01/14(土) 20:48:41.86

車載での普及はかなり先では
少なくとも今のE/EではCのままでしょ

**デフォルトの名無しさん** · 2023/01/14(土) 20:53:17.78

>>912
この流れだとedgeやsafariが追随するのは必至か

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

車つってもエンジン制御とUIじゃ全然違くないか

**デフォルトの名無しさん** · 2023/01/14(土) 22:11:15.42

>>915
EdgeはChromiumベースじゃん

**デフォルトの名無しさん** · 2023/01/14(土) 22:11:45.32

>>915
edgeはchromiumだから追随も何も自動的にRust採用
chromeの脆弱性の大半はメモリ関連バグが原因なので自然な流れ

**デフォルトの名無しさん** · 2023/01/14(土) 22:12:14.30

ァー！

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

>>886
Ruby入れんなバカ

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

>>911
俺もそんぐらいの商流だけど、話は増えてる。

>>914,916
今の車はエンジンやナビ以外も色々電子制御してるんだわ。
んでもって今まさに売るもんじゃなくて、ン年先に出るかもしれないモデルの話。
C/C++のテスト工数がばかんなんないんだわ。

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

Rustは自動車などの人命に関わる部分では人気が高まっていると。
人命に関わるからめんどくさくても仕方が無いと。

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

その話が事実ならルネサスからRustの開発環境が提供されるのも
時間の問題ってこと？(もしくは一部にはすでに提供されている？)
現状組み込み用だとCortex-MやRISC-V用の野良コンパイラと
vscodeあたりを組み合わせるしかないわけだし

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

ソニー・ホンダのAFEELAとかどうなんだろ？
Rustとか使ってるのかね。

ソニー･ホンダも志向､自動車の｢走るスマホ化｣
https://toyokeizai.net/articles/-/644484?page=2
ソニー・ホンダモビリティの河野拓・デザイン＆ブランド戦略部ゼネラルマネジャーは、AFEELAを「iPhoneにタイヤがついたようなもの」と例える。

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

>>921
>>922
914です。ADやゾーンE/Eに向けて採用されていくのは同意。演算能力はマイコンというよりPC

エンジン、ブレーキ、ステアECU等々のマイコン使った従来E/EのECUは人命に関わっていたとしてもCのままだと思うよ
モデルベースでRustのコード生成なんて聞いたことないし

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

書き味ってのはオブジェクト指向し易いかどうかってこと？

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

>>924
> ソニー・ホンダモビリティの河野拓・デザイン＆ブランド戦略部ゼネラルマネジャーは、AFEELAを「iPhoneにタイヤがついたようなもの」と例える。
そう言うのはECUとか知らない一般向けの宣伝文句だよ