Rust part29

**デフォルトの名無しさん** · 2025/05/03(土) 00:47:30.13

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

公式ドキュメント
https://www.rust-lang.org/learn

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 part28
https://mevius.5ch.net/test/read.cgi/tech/1742805420/

ﾜｯﾁｮｲスレ
プログラミング言語 Rust 4【ﾜｯﾁｮｲ】
https://mevius.5ch.net/test/read.cgi/tech/1514107621/

**デフォルトの名無しさん** · 2025/05/03(土) 07:56:18.42

>>前969
>このパターンが「便利だから」という理由で他の言語でも流行る

C++のstreamのsetwみたいでださいな

**デフォルトの名無しさん** · 2025/05/03(土) 09:25:44.77

>>前995
> 構造体のフィールドに値を入れていって構造体を作成しても
> derive_builderを使いメソッドで値を入れていっても同じになった
> メソッド呼び出しが消えた
> ゼロコスト

builderのコストは下記。名前付き引数とデフォルト値を使用した方法であれば全て不要で単なるnewの呼び出しとなるが、これらが全て最適化で消えるのか?
* パラメータ用の構造体(以下P)のアロケーション
* 構造体Pのデフォルト値での初期化
* 構造体Pのフィールドに対する上書き
* 構造体Pから最終的に作成する構造体への各フィールドの逐次的なコピー
* 構造体Pの破棄

**デフォルトの名無しさん** · 2025/05/03(土) 09:44:09.41

全部消える。構造体初期化の文法で書いた場合と同じ。
最適化しない場合の素朴な処理でもそんなに気にするような深刻な差もない。

**デフォルトの名無しさん** · 2025/05/03(土) 10:00:48.18

>>4
compiler explorerで示して

**デフォルトの名無しさん** · 2025/05/03(土) 10:10:18.01

は？

**デフォルトの名無しさん** · 2025/05/03(土) 10:43:01.54

君は見たか？
複おじがぐうのねも出ずに論破された所を

**デフォルトの名無しさん** · 2025/05/03(土) 10:49:14.34

過視化するな

**デフォルトの名無しさん** · 2025/05/03(土) 10:52:36.35

大体のケースでビルダーパターンはアンチパターンと主張し続けて20年以上経つ

**デフォルトの名無しさん** · 2025/05/03(土) 10:54:37.53

最適化されることを主張するなら証拠を示すべきなのは当然だが、
コピーの最適化を前提にするのなら例えば安易にCopy実装したりcloneしたりすんな、
みたいな意識高い言説は多くの場合無意味になっちゃうわけだけど、Rustおじはそれでいいのだろうか

**デフォルトの名無しさん** · 2025/05/03(土) 11:28:41.74

この流れは流石に重箱の隅をつつきすぎじゃないの？
Rustのビルダーはオプショナルな動作を指定するパターンでしかないし、これが最適化されないと困る場面もそんなに無い
せいぜい、ヒープを使うデータについてビルダーを消費するか、中身を clone するかを検討するくらいでしょ

コピー動作が問題になるとしたら、例えば数十万とかの要素を持つ配列の for ループ内でビルダーを使う場合が考えられるけど、それならビルダーを1度だけ作ってそれを使いまわせばいいし

「Rustにも他の言語のオプション引数やキーワード引数があると嬉しいよね」という話なら同意だけど、ビルダーのパフォーマンスはそんなに重要な話でないというか

**デフォルトの名無しさん** · 2025/05/03(土) 11:29:53.96

ストローマン論法

**デフォルトの名無しさん** · 2025/05/03(土) 11:53:45.69

匿名の藁人形は作れない
作れるのは名指しできる個人や団体だけ
だから実名のSNSは嫌なんだよね

**デフォルトの名無しさん** · 2025/05/03(土) 12:04:07.72

>>10
一理ある

**デフォルトの名無しさん** · 2025/05/03(土) 12:39:00.21

RustやC++のゼロオーバーヘッドが意味するところは結局「俺達のコードがどのように処理系によって最適化されるかを俺達は知っている」ということであって、
どのような最適化がなされるかについて一定の透明性があり結果が自明であることが重要
その点で、コピーの最適化を前提にするってのはかなり微妙

**デフォルトの名無しさん** · 2025/05/03(土) 13:47:12.37

「かいたとおりにうごく」が最適化では成り立たないからなぁ

**デフォルトの名無しさん** · 2025/05/03(土) 13:55:18.67

昔ある言語でcontinueがないぞと散々言われて、gotoが実装されたことがあった
何もしないのと比較すればcontinueの提案は優れていたかもしれないが
それは比較対象との相性が良かっただけ

**デフォルトの名無しさん** · 2025/05/03(土) 14:13:59.39

数年前に読んだ書籍にcontinueは使うべきでないと書かれていて驚いた

**デフォルトの名無しさん** · 2025/05/03(土) 14:41:11.34

>>10
安易に clone すべきでないのは所有権管理の話で、実行コストの話とはレイヤが違う。

**デフォルトの名無しさん** · 2025/05/03(土) 18:56:47.80

スマホとPCの作業を効率化したい--「Copilot Vision」の便利な8つの活用例
2025-05-03 07:00
https://japan.zdnet.com/article/35232549/

1 プログらまーまこれを改造してるので上記以外の状態でも使用できるようにしている

2 すでにプログラムがあるので１～コードを作成する必要が無い

ボイス・トォ・スカルの本態が一般パソコンにまで来たのでつい買い捨てができるようになった
マネーロンダリング談合インサイダーなどがはかどるといわれる

**デフォルトの名無しさん** · 2025/05/03(土) 23:51:30.72

>>3
それらは最適化ですべて消えて最終的な初期化構造体のみになった
イテレータメソッドチェーンなどの時と同じ原理
それはもっと極端で各イテレータ毎にいくつ構造体があろうと縮約したりレジスタ化されたりして各構造体は消えていく

**デフォルトの名無しさん** · 2025/05/04(日) 01:14:00.32

複オジ脳やべぇな
視野が狭すぎる

**デフォルトの名無しさん** · 2025/05/04(日) 09:21:09.35

>>19
cloneして意図通りに動作しなくなるならそりゃ普通にcloneの実装もしくは利用者側のバグだろ。作法の問題ではない。
そんな中身を理解しないままコピペしてるバカみたいな低次元のことは誰も問題にしていないでしょ。

**デフォルトの名無しさん** · 2025/05/04(日) 09:55:20.90

>>10
区別できないバカなのか？
ムーブの時などを含めて実態がコピーになるといってもコピー元は二度と使われないのだから最適化できる

一方でclone()などはコピー元をその後も使うためにコピーしている
コピー元を二度と使わないならclone()の必要がない
そしてコピー元をその後も使うから最適化の前提さえ成立しない

**デフォルトの名無しさん** · 2025/05/04(日) 11:20:50.74

それは少なくともbuilderの最適化の文脈においては明確に誤り
実際、derive_builderはcloneが最適化されることに依存している

**デフォルトの名無しさん** · 2025/05/04(日) 12:05:36.94

RustやC++のムーブも同じで一次的にはコピーをして元を使わないため最適化できる場合が多い
一方でプログラマがコピーやクローンを明示的にした場合は元が生きていて全く異なる
そもそも元も後で使いたいからコピーしているわけだ
だからムーブとは異なり最適化でコピーが消えることはない
もちろん後で使いたい場合はコピーして渡すのではなく参照を渡すのが正解だ
したがってプログラマはコピーを可能な限り避けるべきである
暗黙のコピーが行われるプログラミング言語では意識せずコピーしてしまう
プログラムを見ただけですぐにコピーしてあることがわかる方が望ましい
RustではCopyトレイト実装した型のみ暗黙のコピーが起きる
前述のように数値などはその方が有利なので最初からCopy実装されている
ヒープを用いない型ならばプログラマは自由にCopy実装できるがコード上でそれが明示され読む側は気付ける
サイズが大きく参照で扱った方がよい型をCopy実装していればおかしいことがわかる
一方でヒープを用いていればCopy実装はできないがClone実装はできる
これはコード上でfoo.clone()とコピーすることを明示的に記述する必要がある
したがって参照を使えばよいのに無駄なコピーをしていればすぐにわかる

**デフォルトの名無しさん** · 2025/05/04(日) 13:33:55.47

無駄をなくそうとしたらコンパイルが通らなくなった
っていう質問を処理するコストが高いよね
実行時のコストではなく

**デフォルトの名無しさん** · 2025/05/04(日) 13:35:26.53

読む気が失せる分だけど読んだ
ところが間違ってるというか言い過ぎだと思う

**デフォルトの名無しさん** · 2025/05/04(日) 13:38:00.38

クソデカ長文とかどこでも現れる辺りRustとRubyって似てるなーと思った次第である

**デフォルトの名無しさん** · 2025/05/04(日) 13:41:35.32

この程度で長文扱いって普段どれだけ文章を読まないんだよ。

**デフォルトの名無しさん** · 2025/05/04(日) 13:43:24.90

暗黙のコピーが行われるプログラミング言語は大体値のコピーを行っている
値はこの場合参照なのでコストは限りなく低い

暗黙でポインターをコピーしてそれがコストが掛かると言う人はいないだろ

**デフォルトの名無しさん** · 2025/05/04(日) 13:44:23.89

>>30
読む気が失せるのは文章が下手くそだからであって長いことは関係ない
そしてボロボロと誤りと言うか独断に基づいた誤りがたくさん入っている

**デフォルトの名無しさん** · 2025/05/04(日) 13:47:16.56

複おじはAIに下書きを食わせて推敲してもらうべきだと思う

**デフォルトの名無しさん** · 2025/05/04(日) 13:53:19.75

むしろAIに生成させてるんじゃないかと思われる
同じことを何度も何度もダラダラ箇条書きに
眠くなるわ

**デフォルトの名無しさん** · 2025/05/04(日) 13:57:45.80

見たい所だけ切り取ればいいんだよ
切り取りや編集の責任をトリクルダウンするために、書く側は編集をしないという戦術だろうけど
それはどうでもいい

**デフォルトの名無しさん** · 2025/05/04(日) 13:59:33.25

AIではないよ
小論文など書くときに指摘されるけど、考えをまとめないでずらずらと続く文章は修正しろと言われる

一部の行頭だけ切りだすと以下のように前の文章とつなげて書いてるから読み手にはわかりにくい
↓これが連続して使われているので読み手への負担になっている

一方で
そもそも
だから
もちろん
したがって