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

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

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

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

人間の脳もスタック状になってるんでドンドン文が接続されていくと脳内にスタックが作られてスタックがチェーンして肥大化して理解が苦しくなる
これは当たり前

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

文章がダラダラと接続されているものは、まともに推敲されていないので、基本的に読むコストに比べて得られるものが少ない
雰囲気で書かれているので間にも間違いや矛盾が含まれている

読み手に対して読みやすさが考慮されていないのでふつーに読まなくても良い

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

ここでようやくchatGPTに聞いてみた

✅ 読みにくさの主な原因

1.接続詞やつなぎ言葉の多用による文の長文化

「一方で」「だから」「そもそも」「もちろん」「したがって」などの論理接続語が多く使われ、それぞれの文が長くなりがちです。
　
結果として、読者は一文ごとの意味の切れ目を捉えづらくなります。

2.
文構造が複雑で、主語と述語の対応が曖昧

「コピーして渡すのではなく参照を渡すのが正解だ」のように、主語が省略されていて読み手が文脈を補う必要があります。

3.抽象的な話が続き、具体例や対比が乏しい

例えば「ムーブはコピーと違う」と言いつつ、具体的にどう違うのかの明示がないため、読者が前提知識を持っていないと理解しにくいです。

4.
視点の切り替えが頻繁

ムーブとコピー、CopyとClone、参照と値渡しなど、話題が細かく切り替わっているが、その都度明確な導入がないため混乱を招きます。

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

もっと詳しく書け、とAIが言っている
みんなAIに騙されてる

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

さっき書いた部分は連続で接続されている

A 一方で　B　=　C（文意）
C　そもそも　D = E（文意）
E だから　F　= G（文意）
略
Y　したがって　Z

Zを理解するためにAから後を状態や文意を含めて全部覚えておかないといけない

読み手を疲弊させるには接続を多用したらいいとも言える

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

みんな読みやすい文を書いて良い大学、良い企業に入りたいとか
読みやすい文を書いて本を出版して売りたいとか
金の為に文を書いているからな
文なんて記号に過ぎない意味が伝わればいいのよ

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

意味が伝わればいいとか言ってるやつが書いた文章はたいてい伝わってねーから。
プロが推敲したってきちんと伝えるのは難しいのにそれ以下の質ならそれ以下にしか伝わらないよ。

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

国語の天才が推敲すると数学も理科も社会も意味がわかるようになるなら
学校で国語だけ教えてればいいだけだろボケ

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

確率扁微分方程式を国語で説明してくれ

三行でよろぴく

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

教
科
書読め

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

もちろんでNGしとけ

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

AIにコードを生成させるならもうRustはいらない子だよね

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

>>48
こういうのはビッグウェーブに乗る力であって国語力ではないね

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

他人に自分の主張を理解してもらいたいなら、少なくともわかりやすく書く必要がある

いつも例の人の文章を読んでると念仏を聞いてるような気分になる
誰かが眠くなると書いてたけど自分もその印象が強い

言葉を吐くマシーンの様で理解してもらおうなどと思ってないんだろうなと

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

理解されるためならなんでもしますという意志はたいして重要ではない気がする
なんでもするって言わせたい人にとって重要なだけだろう

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

文章の読みやすさを意識しないプログラマのコード品質って大丈夫なのか？

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

理解されないなら主張としては存在しないのと変わらない
公共の場にただのデカいゴミがあってみんな邪魔だなって思うだけ

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

derive_builderのドキュメント見てみた
Rustはこれらのclone呼び出しも最適化して賢いと書かれている

https://docs.rs/derive_builder/latest/derive_builder/#-performance-considerations

Performance Considerations

Luckily Rust is clever enough to optimize these clone-calls away in release builds for your every-day use cases. Thats quite a safe bet - we checked this for you. ;-) Switching to consuming signatures (=self) is unlikely to give you any performance gain, but very likely to restrict your API for non-chained use cases.

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

derive_builderはRustのセマンティクス的には割と非効率な実装を採用していて、
常に一度のbuildだけの使い捨てに特化したバージョンも提供するなど制約を強めることで更にセマンティクス上効率的な実装もありうる
でもそうしないのは実際最適化で変わんなくなるんだろう
コンパイラの解析に委ねる前にセマンティクス上の最適を目指すのがRustの大きなコンセプトだと個人的には思っているが、その観点ではあまり理想的とは言えないやり方だし、
Rustの言語側にも改善の余地があるかもしれない

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

#[builder(pattern = "owned")]だと使い捨てになるんでしょ
こっちをデフォルトにした方がいい気もするけど１回しかbuildしない場合は最適化されて同じになるらしい

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

さらに限定したケースでRustコードの段階で最適化できる可能性もあるかもしれない
この初期化ビルダーがプログラム全体のネックになる時が来たらチャレンジするかな

現実には誤差の範囲内なのでこのderive_builder利用で十分と思う
初期化関数を自分で用意せずとも構造体への属性修飾だけでよい利便性は他のプログラミング言語と比べてもベスト

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

でもビルダーパターンは潜在的にバグ発生の要因をはらんでいる

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

>>58
あらゆるパターンが潜在的にバグ発生の要因をはらんでいるから意味のない発言
具体的にderive_builderでバグ発生の要因があるなら指摘して

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

IDEのサポートを受けた元で初期化関数を使うのがベスト
単純にビルダーパターンで起こる記述漏れ、順序の間違い、重複指定バグが減る

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

>>59
前スレで書いたけど複おじは反論不能だったみたいでスルーしてたな
複おじ論破されて草だった

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

>>60
手動で初期化関数を作るのは面倒かつバグの入る余地もあり劣ってる
derive_builderは利便性も良いからこれより優れているものを持ってこないと話にならないかと

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

>>61
「おじ」使いのキチガイの人かよ
具体的にderive_builderでバグ発生の要因があるなら指摘しなさい

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

>>62
そんなもんテストでわかるでしょう

テストしないところでビルダーパターンはバグを起こす可能性が高い
人間がビルダーパターンのメソッドに注視して思考してパラメーターを指定する場合は問題が比較的起こりにくい
それをコピペや思い込みで書くとヒューマンエラーが入り込む余地がある

ビルダーパターンで複数行でメソッドを記述した場合には列レベルで記述が抜けることが考えられる
行で記述しても対応ミスなどが起こる

複おじは問題点をわざと見ないふりをしている

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

>>63
前スレ見ろ
おじいちゃん

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

>>64
わざわざ手動で初期化関数を作ってテストするってか
面倒なだけでメリットが全くない
利便性も良いderive_builderより優れているものを持って来なされ

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

>>66
前スレで問題点を指摘されて論破されて何もできないで誤魔化してるんでしょ
みっともない

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

>>67
誤魔化してるのは君だ
derive_builderに問題点があるなら指摘しなされ
derive_builderよりも利便性の高い方法があるなら持ってきなされ

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

>>68
ストローマン論法だな

自分の主な主張はで前スレで書いたようにビルダーパターンは複雑なオブジェクト生成で使われるべきで
普通のオブジェクト生成ではコンストラクタなどの初期化関数を使うべきと言うもの

理由はビルダーパターンはヒューマンエラーが入り込む余地が非常に大きいから
初期化関数はIDEの補助があるのでビルダーパターンで起こる問題が発生しにくいか発生しない

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

それにしても「～しなされ」って言われたのは人生で初じゃないかな

ガチおじいちゃんじゃん　複おじいちゃん

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

>>69
詭弁はよろしくない
derive_builderは自分で初期化関数を書く必要がない
他の方法では初期化関数を書く必要がありヒューマンエラーが入り込む余地があるのはその通りだ
利便性も良くてその問題が生じないderive_builderが優れている

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

>>71
ストローマン論法だな

こちらの主張していない内容を勝手に作り出してそれで話を続けている

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

初期化関数はビルダーパターンのメソッドの適用ミスで容易に起こりうる　重複、順序ミス、記述漏れに対して有用
初期化関数自体は一回書くだけ

各所で必要になる単純なオブジェク生成の場面ではビルダーパターンはヒューマンエラーが入り込む恐れがある
それを初期化関数で行えばIDEの補助を得られるのでミスが減る

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

>>73
先ほどから主張しているderive_builderを使わなければIDEの補助が得られるからミスが減るの意味がわからない
derive_builderを使えば初期化関数の用意はお任せなので提供側のミスはない
利用側はデフォルト値以外の値指定をしたい時にそのメソッド候補がIDEなどで補助があるのでミスが起きようがない
derive_builderを使った方が提供側も利用側もよいのではないか

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

まだバグを起こす前の時期に、バグを起こしやすい習慣をやめない、まつもとなかいがいたとする
その時点で彼らをどのように処分したいのかね

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

>>74
ストローマン論法をやめなされ

初期化関数を使うと指定の重複、順序ミス、記述漏れが起こりにくいのは事実だろう
まず単純な初期化関数で指定の重複が起こるのか？
func( a,b,c,d....にたいしてaを重複指定させられるのか？
これすら判らないなら話すだけ無駄

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

「～しなされ」っていうのって少なくとも80歳以上じゃないかと

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

>>76
derive_builderで提供された場合も問題は起きないよね
仮にそのaを重複指定してしまい
.a(123)
.a(123)
と書いてもバグは起きない
可読性もよいからそれ自体を起こさないね

derive_builderは提供側も利用側もデメリットがなく最も良い方法にみえる
もっと良い方がある？

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

>>78
.a(123)
.a(321)

で始めの123が正しい場合問題になる

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

>>79
aを123で初期化したいなら前者しか起きようがない
aを321で初期化したいなら後者しか起きようがない
そんなナンセンスな指摘しかデメリットらしきものを見つけることが出来なかったということは
derive_builderが最も良い方法であることを認めたと理解してよろしいか

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

the bookによるとnewtypeパターンってのがあって
traitをimplすることが目的みたいだけど
どうにかすれば名前つき引数にも使えそうなんだよね

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

順序ミスについて
これは前スレでも書いたのを再掲

.G(p[0]).R(p[1]).B(p[2]).build()
のところを容易に
.R(p[0]).G(p[1]).B(p[2]).build()と間違えて
さらに
.R(p[0]).R(p[1]).B(p[2]).build()と間違える

色指定でよく目にするのはRGB方式だけどコンピュータービジョンなどではBRGがよく使われる
最初にGRBとして覚えていても実際各段階になるとRGBと混同することがある

初期化関数では
func(P[0],P[1],P[2],...
等で考えなくても書き間違える可能性が低い　それにIDEの補助でパラメーターについてポップアップが出るのでそれでも間違いは減る
バグに気が付いて書き直す際に2か所の書き換えをしないで
.R(p[0]).R(p[1]).B(p[2]).build()　と言う間違いも入り込みやすい

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

書いてるそばから間違えている
BGRが正しい

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

>>80　の疑問については
>>82　で書いたようなミスで重複と記述漏れが発生する

そういうところまで考えたことないだろ？コーディングしてる？

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

>>82
その比較はおかしい
デフォルト値以外のみを指定して初期化する話なのだから
それは✕　func(P[0], P[1], P[2],...
これが○　func(R=P[0], G=P[1], B=P[2], ...

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

記述漏れについては
n個パラメーターを指定しないといけないのにn-1個しか記述していない場合
目で見てn個すべて指定したのかn-1個指定したのかなんて数が多くなると判らない

これは初期化関数では基本的に起こらない
数が多いとやはり大変だけどIDEの補助があったりコンパイル時にエラーがでる

ビルダーパターンでは実行時エラーや思った挙動にならない時点でしかミスに気が付かない

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

>>85
誰もそんな縛りは指定していない
普通に初期化関数使えばよい

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

これ以降ストローマン論法禁止

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

オプション値の初期化の話だもんな
必須値の初期化の話ならRustでも
fn foo(red: Type, green: Type, blue: Type)
とするだけなのでderive_builderは使わない
だから>>82の指摘は間違ってる

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

>>89
それはお爺さんにもわかりやすいように簡易化して書いているからだろ

ビルダーパターンは上にあげたようなヒューマンエラーを誘発する仕組みなので基本的に使わない方が良い

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

生成に柔軟性があり複雑な場合にはビルダーパターンを適用するのは良い
一般的なオブジェクト生成に対してはヒューマンエラーに弱くアンチパターン

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

>>87
プログラミングの基本的なことを理解していないのかい？
derive_builderを使うようなオプションで必要な項目だけ値を指定して初期化するケースを1つの初期化関数を単体で済ませようとすると
どんなプログラミング言語でもキーワード付きオプション引数を使うことになる
具体的にはf(1, 2, 3, option1=111, option5=222)などの指定方式になる
option5など名前を指定しないとどの項目を指定しているのか区別がつかないためだ

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

>>92
その指定だとしても重複は大体の言語ではエラーになる
ビルダーパターンは重複を検知しないのでヒューマンエラーが入り込む

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

>>91
オプション初期化のない一般的なオブジェクト生成でderive_builderを使う人はそりゃいないよ
それは普通にRustでも引数固定の初期化関数でおしまい

前スレを読んだけど最初から特定項目だけオプション初期化する話
だからderive_builderが最も優れているという結論になってる

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

>>94
重複すら検知できないのに？

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

重複を検知するには内部にフラグを持たなくてはならない
もちろんこれは実行時エラーになる

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

実行時エラーを検出するにはテストで網羅しなくてはならない

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

我々はコンパイル時にエラーが検出されるのを利点としてRustを使っている
それなのに実行時エラーに頼らざるを得ないビルダーパターンは劣っている

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

結局、話をまとめると
ビルダーパターンで
foo()
　.item1(value1)
　.item3(value3)
　.item7(value7)
と書くか

名前付きオプション引数で
foo(
　item1=value1,
　item3=value3,
　item7=value7,
)
と書くか

これだけの違いだよな
どちらも変わらん慣れだけの問題
どちらも見た通りなので指定ミスや重複ミスなど起きようがない

あとはそれらを提供するライブラリ側だ
いずれも普通は初期化関数を自分で書かなければならない
Rustでderive_builderを使えば構造体に属性を付けるだけで済みシンプルかつミスも起きない
少なくとも現状でderive_builderに欠点は見つかっておらず最善な方法であるといえる

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

>>99
結局何も見なかった利かなかったふりして自分のいいように矮小化し続けてるな
呆れるよ
80代になると何も感じなくなるのだろうか

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

的外れな言いがかりでスレを荒らしてる人は
derive_builderより良い方法を具体的にコードで示せ

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

精神論で間違いは発生しないと言うのは容易
間違えたら間違えた人間が悪いと言う

ビルダーパターンには結局ヒューマンエラーを防ぐように十分な対策がなされていないだろ
わかっていながら無視をする
c++精神だね

**デフォルトの名無しさん** · 2025/05/05(月) 00:00:40.76

>>101
ファクトリーパターンなどを使えばよい
メソッドの種類を充実させるだけだ

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

ビルダーパターンはヒューマンエラーに弱い
毎回論理的構造を構築しなければならないがそこにバグが紛れ込む可能性がある

それよりも初期化のための関数を作るべき

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

derive_builderは全自動だからミス起きなくね？
derive_builderより好いのがあるならコードを出して

**デフォルトの名無しさん** · 2025/05/05(月) 00:05:02.99

おじいちゃんは乱心して同じことを何度も書いて来る
普通の人間にはすでに書かれた内容で理解出来るのに知らないふりして実行時エラーやバグを許容している

**デフォルトの名無しさん** · 2025/05/05(月) 00:06:42.46

これも相手の疲労を狙ってくるくだらないやり口なんだろうと思うが

**デフォルトの名無しさん** · 2025/05/05(月) 00:07:25.49

>>104
そんな方法は存在しないよ
>>99が挙げてる二つの方法しかない
もしあるなら同様のコード例を示そう

**デフォルトの名無しさん** · 2025/05/05(月) 00:08:38.62

他のスレでもでもおじいちゃん的書き込みを見ることがある
それに対して80代ではと書くと100%反論される

今回は反論されないところを見るとやはり80代以上なんだろうなと

**デフォルトの名無しさん** · 2025/05/05(月) 00:09:40.80

>>108
＞　それよりも初期化のための関数を作るべき
これが全てだろう？
いくら何でも馬鹿すぎるだろう？判らないの？

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

Builderはオプションの追加実装が破壊的な変更にならないメリットがあるな
生成関数に全部渡す方式だとパラメータが増えて破壊的になる
新しい生成関数を追加すれば破壊的にはならないけど
オプション追加する度に生成関数増やすのはあほくさい

>>103
もし暇だったら↓のRegexBuilderをFactoryで実装する場合の関数の個数を見積もってくれ
https://docs.rs/regex/latest/regex/struct.RegexBuilder.html

**デフォルトの名無しさん** · 2025/05/05(月) 00:12:00.84

>>110
今回のようなケースで初期化のための関数は>>99が挙げてる二つの方法しかない
もし他に存在するなら同様のコード例を示そう

**デフォルトの名無しさん** · 2025/05/05(月) 00:15:57.46

なんで自分にレスしてんの？

**デフォルトの名無しさん** · 2025/05/05(月) 00:19:17.48

>>111
他の言語でもRegexは普通にメソッドを使って解決してるけど…
長いならregexoption構造体作って指定したらよいだろう？他ではそうしてる物もある

**デフォルトの名無しさん** · 2025/05/05(月) 00:20:28.67

Rustしか使ったことがない前提なのかな

さすがに馬鹿の相手をするのは疲れてきた…

**デフォルトの名無しさん** · 2025/05/05(月) 00:21:44.77

おじいちゃんは他の言語は使えないの？しょうもない雑魚レベルの質問しかしないのはなんで？

**デフォルトの名無しさん** · 2025/05/05(月) 00:29:27.74

デフォルト値に対して必要分だけオプション指定したい場合
まともな方法はどのプログラミング言語を使って>>99のどちらかの方式になる
まともではない方法としてはオプションの有無ごとの組み合わせ数の分だけ大量の関数を用意する手もあるけど論外だ

**デフォルトの名無しさん** · 2025/05/05(月) 00:41:54.17

何で間違ってることを繰り返すの？

macroで重複チェック可能なbuilderは書けるとか書いてこないのは意外なんだけど

**デフォルトの名無しさん** · 2025/05/05(月) 00:53:11.08

実行時チェックの話もchatGPTの方がまともで面白い回答や提案をしてくれる

**デフォルトの名無しさん** · 2025/05/05(月) 00:56:27.23

>>118
設定値の重複チェックとか誰も気にしないからでは
重複設定によるバグとか生成関数に渡す引数の順番を間違えるバグと同じくらい起こりにくいし

**デフォルトの名無しさん** · 2025/05/05(月) 01:00:46.13

一部の必須値の設定を忘れるケースは普通にあるでしょ

**デフォルトの名無しさん** · 2025/05/05(月) 01:09:30.63

>>121
必須値は様々な対応が取れるため問題は起きない
・オプションにしない
・全体の整合チェックの一貫として必須値の有無の判断を入れる
・ビルド最終メソッドで指定する　(ex. std::fs::OpenOptions::open)

**デフォルトの名無しさん** · 2025/05/05(月) 01:17:39.76

一番オーソドックスなのが抜けてるな
RegexBuilderの場合はRegexBuilder::new()にパターン文字列を渡してる

**デフォルトの名無しさん** · 2025/05/05(月) 01:21:35.04

>>123
先頭の「オプションにしない」が
その最初に必須値を渡す意味
わかりにくてすまん
フォローサンクス

**デフォルトの名無しさん** · 2025/05/05(月) 08:29:59.12

名前付き引数であれば必須パラメータも名前付きで渡せるため順番の間違いによるミスが発生しづらく可読性も高い
derive_builderを使う以上は必須パラメータもメソッドで渡すしかなく実行時エラーの可能性が排除できないしチェックのために余計なランタイムコストを払う必要がある
文句はderive_builder作者に言ってきた方がいいぞ

**デフォルトの名無しさん** · 2025/05/05(月) 08:39:51.80

狂信者には何を言っても無駄であり論理的な考えを持ち合わせていない
こちらがいくら論拠を提示してもRustが正しいderive_builderが正しいとそんなミスは起こりえないと繰り返すのみ

正しくないのはお前の頭だろう

**デフォルトの名無しさん** · 2025/05/05(月) 08:41:20.98

ビルド方式に問題はない
既出のstd::fs::OpenOptions::open()や
regex::RegexBuilder::new()など
Rustはビルド方式でも対応しており問題になっていない

>>125
名前付き引数であろうとなかろうとバリデーションは必要でそれは実行時エラーとなる
そしてResultを返すから実行時エラーで問題ない

**デフォルトの名無しさん** · 2025/05/05(月) 08:42:39.33

>>82
順序ミス対策なら
.rgb(p[0], p[1], .p[2]).build()
でいいんじゃね？
Rustてこういうのできないんだっけ？

**デフォルトの名無しさん** · 2025/05/05(月) 08:45:40.37

>>127
＞　少なくとも現状でderive_builderに欠点は見つかっておらず最善な方法であるといえる

じゃなかったのか？方針変えたのか？

**デフォルトの名無しさん** · 2025/05/05(月) 08:49:55.75

“イリヤ神”がまたやった　動画生成AI「FramePack」が革命的なワケ
2025年05月05日 07時00分更新
https://ascii.jp/elem/000/004/267/4267160/
　4月17日に登場した動画生成AIプログラム「FramePack（フレームパック）」が世界的に衝撃を与えています。PCローカル環境で動画AIを動かすには、少なくともビデオメモリー（VRAM）が12GBあるビデオカードを搭載していないと難しいというのが常識でした。ところが、VRAM 6GBでも安定的に動作させられるため、一気に動画AIの裾野を広げそうです。開発したのは、画像生成AI分野で「ControlNet」や、使いやすいツール「Fooocus」などを開発してきたことで知られる、スタンフォード大学に在籍中のIllyasviel（イリヤスフィール、以下イリヤ）さん。既存の方法論にまったく違ったアプローチでブレイクスルーを引き起こす、“イリヤ神”のアプローチに再び注目が集まっています。
中略
　AI動画を作ってみたいけれども、スペックが足りないために諦めていたという人が次々に自前の環境で試すようになってきました。既にワンパッケージでインストールできる環境も整えられているため、スタートも簡単です。様々なファイルをダウンロードしてくるため、初期設定は2時間くらいは見ておく必要があるものの、圧倒的にハードルが下がりました。

**デフォルトの名無しさん** · 2025/05/05(月) 08:51:02.82

>>127
名前付き引数のミスは大体言語でコンパイルエラーになるので的外れ
ビルダーパターンより安全性が高いだろ

**デフォルトの名無しさん** · 2025/05/05(月) 08:51:16.55

>>126
Rustが間違っていると主張したいなら問題点と代替策を述べればよい
本当にそれが示せるならRustはIT大手各社も用いているため世界中にインパクトを与えられるぞ
この我々の5chのやりとりすらRust製のPingoraを経由しているほどネットインフラ各所でもRustは使われている

**デフォルトの名無しさん** · 2025/05/05(月) 08:52:25.13

>>132
何言ってるんだよ
最後の一行が全てだろ

**デフォルトの名無しさん** · 2025/05/05(月) 08:53:13.86

本当に暇さえあれば関係ない話題で誤魔化そうとするよな
脳がストローマン論法で浸食されているんだろ

**デフォルトの名無しさん** · 2025/05/05(月) 08:53:53.74

それよりもbuilderパターンは初期化時の情報指定漏れをコンパイルエラーにできないのがRustらしくないと思う。

**デフォルトの名無しさん** · 2025/05/05(月) 08:54:21.19

>>128
個別パラメータとして与える必要がないからその通り
Rustの言語仕様としてはそれで制限ない
そのライブラリの仕様ならタプルにすればよい

**デフォルトの名無しさん** · 2025/05/05(月) 08:55:05.06

>>127
なるほど、実行時に他のバリデーションするからタイプセーフでなくていいと君は考えるわけね
それはそれで一理あるが、だったら君が使うべき言語は静的型付け言語ではなくRubyなどのゆるふわ言語だな
さようなら

**デフォルトの名無しさん** · 2025/05/05(月) 08:56:18.75

ビルダーパターンで疑似カリー化が行えるのが利点なのにタプル化するって
わざわざ手足を縛ることになるけど

**デフォルトの名無しさん** · 2025/05/05(月) 08:56:40.00

>>135
勘違いしていないか？
必要とはされないオプションが有る時にビルダーパターンが使われる

**デフォルトの名無しさん** · 2025/05/05(月) 08:58:33.63

>>138
それマジで言ってるならRustでプログラミングしたことがないんだな
タプルで扱うのが正解
これがわからないならfor文すら書いたことがないのだろう

**デフォルトの名無しさん** · 2025/05/05(月) 08:59:24.57

>>139
それは一部必須パラメータが依然として存在することと矛盾しない

**デフォルトの名無しさん** · 2025/05/05(月) 09:01:01.47

>>140
もはや話がかみ合ってないな
疑似カリー化で個々のパラメータを指定してその他のパラメータをここに設定した生成物を作れるのが利点だという意味が判らないのかな
これは重複を許容する使用法

**デフォルトの名無しさん** · 2025/05/05(月) 09:02:05.60

>>141
必須パラメータの事例はさっき出てただろ

>> std::fs::OpenOptions::open()
>> regex::RegexBuilder::new()

これで対応できている
誰もが使っていて問題となったことはない

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

>>142
カリー化の意味すら理解できてないのか？
Rustでカリー化ならばクロージャを使う
ちなみにビルダーパターンはビルダー構造体のまま変わらずカリー化は行わない

**デフォルトの名無しさん** · 2025/05/05(月) 09:07:05.32

>>143
だからそれはderive_builderの作者に言ってくれ
それに前から言ってるが必須パラメータの数が増えればミスが増えるし可読性も落ちる

**デフォルトの名無しさん** · 2025/05/05(月) 09:07:28.43

>>144
ストローマン論法
疑似カリー化と書いてるだろ？

derive_builderは正しいと繰り返していたのにすでに複おじになかったことにされている

**デフォルトの名無しさん** · 2025/05/05(月) 09:10:38.57

微妙に論点をずらしたり相手の言ってないことに対して批判したり
本当にずっとストローマン論法続けてるよなあ
複おじいさん

ストローマン論法はやめなされｗ

**デフォルトの名無しさん** · 2025/05/05(月) 09:11:10.84

>>137
Rustは静的型付けだから常にタイプセーフだよ
それらの例は引数の型が合ってなければ当然コンパイルエラーとなる
一方で引数の値が合っているかどうかは構造体の方針だから当然コンパイルエラーにできず実行時エラーとなる

**デフォルトの名無しさん** · 2025/05/05(月) 09:13:10.00

>>145
何を言いたいのかわからない
fsやregexの話を作者に伝える？
そんなの知ってるだろ

**デフォルトの名無しさん** · 2025/05/05(月) 09:15:12.07

>>146
カリー化は定義もメリットもはっきりしていて幅広く使われてきているが
その疑似カリー化とやらも定義もメリットもわからない
無意味なことをしようとしていないか？

**デフォルトの名無しさん** · 2025/05/05(月) 09:17:40.24

>>150
見ればわかるだろうｗ疑似カリー化が何を意味しているのかぐらい

そういう議論のための議論を繰り返してなんになるんだよ

**デフォルトの名無しさん** · 2025/05/05(月) 09:24:52.62

>>151
だから疑似カリー化の定義とメリットを明確にしてくれ
少なくともこの件のrgbバラバラにするのはメリットないどころかデメリットだぞ

>>128
>> 順序ミス対策なら
>> .rgb(p[0], p[1], .p[2]).build()
>> でいいんじゃね？

**デフォルトの名無しさん** · 2025/05/05(月) 09:29:59.66

>>152
こちらのID辿ってみたらいい

**デフォルトの名無しさん** · 2025/05/05(月) 09:37:07.71

>>62
>>68

複おじはderive_builderを全力で支持
初期化関数は全否定していた

ところが…

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

＞ .R(p[0]).G(p[1]).B(p[2]).build()

これ3つとも指定が必要ならメソッドを分けるべきではないと思う
それ以前にRustのプログラミングしたことないのかメソッド大文字は置いとくにしても
この場合ならp[0]はRust的な使用方法ではないな
(r, g, b)もしくはRGB構造体で持つかその参照で持つのが普通
p[i]はなるべく避けてイテレータ時点でポインタを動かして参照で持つか小さいなら値で持つ
構造があるならその構造で持つ
そのためp[i]の形が出てきたらRustでは少し臭うため怪しみ避けられないか考える

**デフォルトの名無しさん** · 2025/05/05(月) 10:33:19.28

>>75
>まつもとなかい

うby界隈のmatzとそのとりまきか？

**デフォルトの名無しさん** · 2025/05/05(月) 10:58:23.25

>>155
> これ3つとも指定が必要ならメソッドを分けるべきではないと思う
おっ
derive_builderって必須パラメータをランタイムチェックとはいえ個別setterの形で適切に扱えるというのが重要なコンセプトなんだけど、ここにきて全否定か

**デフォルトの名無しさん** · 2025/05/05(月) 11:07:31.16

>>128
>.rgb(p[0], p[1], .p[2]).build()

重複を主張する人の場合
.rgb(p[0], p[1], .p[2]).b(3).g(4).r(5).g(6).b(7).build()
みたいな間違いが起こるんだと思うよ

**デフォルトの名無しさん** · 2025/05/05(月) 11:07:36.46

ボクシングには蹴り技がない
それは重要なコンセプトだと考えていた時期が俺にもありました

**デフォルトの名無しさん** · 2025/05/05(月) 11:10:17.68

コンパイラでうまくいかないから規約で縛ると言うことだろ？ビルダーパターンを導入する意義とどんどん崩れていく

RGB各値は指定が必須とは限らない
defaltで各値が0指定されていて同じなら書く必要がないだう
初期化関数では場合によっては記述する必要があるけどそれも必須ではない

疑似カリー化で少しずつパラメーターの違う複数のオブジェクト生成を行う場合にも便利

**デフォルトの名無しさん** · 2025/05/05(月) 11:19:55.94

f(
　red=red,
　green=green,
　blue=blue,
)

f()
　.red(red)
　.green(green)
　.blue(blue)

どちらの方式でも間違えようがないと思うんだが
ミスが起きると言ってる人はどういうミスを想定してるのだろう

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

red=p[0];　//p[0]は実際はblue
green=p[1];
blue=p[0]; // コピペの修正漏れ

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

>>161
今更そんなところを理解できてなかったのか？
greenの指定を忘れたら前者はコンパイルエラー、後者は実行時エラー

**デフォルトの名無しさん** · 2025/05/05(月) 11:35:07.99

>>162
これの悩ましいところは後ろのコピペ修正漏れでblueに正しいp[0]が指定されているので
原因が判断しにくいところ

**デフォルトの名無しさん** · 2025/05/05(月) 11:41:36.57

>>163
前者と後者は同じ
greenの指定をしなくてもコンパイルエラーとならない
greenは指定しなかった場合にデフォルト値となるオプション引数

**デフォルトの名無しさん** · 2025/05/05(月) 11:44:04.39

>>165
知らんがな
俺は必須パラメータの問題を指摘している

**デフォルトの名無しさん** · 2025/05/05(月) 11:44:39.10

>>162
p[0]やp[1]など
可読性の悪いコードを書くやつは失格
p.red p.green p.blueにしろ

**デフォルトの名無しさん** · 2025/05/05(月) 11:45:55.35

>>167
dataと言うバイト列の中の一部だとしたら？

**デフォルトの名無しさん** · 2025/05/05(月) 11:47:59.01

>>166
おっちょこちょいだな
直前のこれを見ろ
必須ではなくオプションパラメーターだ

>>160
> RGB各値は指定が必須とは限らない
> defaltで各値が0指定されていて同じなら書く必要がない

**デフォルトの名無しさん** · 2025/05/05(月) 11:50:23.87

>>168
バイト列？
各8bitなのか各16bitなのかそれ以上なのかそれでは構造がわからん
ちゃんと構造体の列にするべきだ

**デフォルトの名無しさん** · 2025/05/05(月) 11:54:15.50

>>170
また真面に回答できないから適当に話をごまかして議論のための議論しようとしてる
受信データなどのバイト列から値を取り出すのは一般的だろう
必ずしも構造体の列構造とは限らない

それと数値指定無くすならコーディング規約でこう書かないとアウトですとするのか？
blue=data[ i + blue_index_offset];
red=data[ i + red_index_offset];
green=data[ i + green_index_offset];

**デフォルトの名無しさん** · 2025/05/05(月) 12:01:19.27

>>171
あのさ
Rustでプログラミングしたことないの？
Rust以外でもシリアライズとデシリアライズしたことないの？
まともなプログラミングしたことある人ならRustですぐにserdeにたどりつく

**デフォルトの名無しさん** · 2025/05/05(月) 12:10:05.78

まともな人が言ったのか人形が言ったのか全然わからない時代だ
人形が言ったにすぎないなら、そんな言葉は存在しないのと同じ

**デフォルトの名無しさん** · 2025/05/05(月) 12:14:04.97

>>172
お前はわざと議論のための議論してるだけだろ
通常のコーティングで出てくるであろう例を誤魔化している

**デフォルトの名無しさん** · 2025/05/05(月) 12:16:46.89

p[ i+0 ],p[ i+1 ],p[i +2 ]を取り出すだけのためにどれだけコーディング量を増やして
ライブラリ依存させていくのか
本当に意味不明

**デフォルトの名無しさん** · 2025/05/05(月) 12:33:03.95

>>175
そんな可読性が悪くてミスしやすいプログラミングは避けるべきだ
構造化と抽象化が不得手でプログラマやエンジニアに向いてないな
serdeは構造体に#[derive(Serialize, Deserialize)]など付加するだけでデシリアライズ関数などは自動生成される

**デフォルトの名無しさん** · 2025/05/05(月) 12:57:25.54

>>176
構造体にって自分で書いてるだろ
単なるバイト列からp[ i+0 ],p[ i+1 ],p[i +2 ]を取り出すだけのために構造体などを作らないといけない

**デフォルトの名無しさん** · 2025/05/05(月) 13:06:55.72

p[ i+0/*0=赤*/ ],p[ i+1/*1=緑*/ ],p[i +2/*2=青*/ ]
俺ならこうするよ
コメントを見れば0が赤、１が緑、２が青と見たん瞬間わかる
日本語なので英語より間違えにくい
もし間違った数字が間違ってたらコメントと比べればすぐわかる

**デフォルトの名無しさん** · 2025/05/05(月) 14:25:06.41

（言語を強化することにより）アプリのコーディング量を減らせという話はなかなか面白い
言語の数がアプリの数より多い気がする原因はこれかもしれない

**デフォルトの名無しさん** · 2025/05/05(月) 15:35:05.95

>>174
議論のための議論をしてるのはお前だろ
それともガチで何も意味を読み取れないインデックスアクセスが正義と思ってるわけ？
どんなみじめな経験を積んできたんだよ
害悪プログラマすぎて仕事で関わらないことを願うわ

**デフォルトの名無しさん** · 2025/05/05(月) 15:41:59.59

議論とは関係ないけど大体の画像処理ライブラリだとRGBもBGRも扱えるように channel[0], channel[1], channel[2] のようにアクセスさせると思う
内部のデータによって channel 数は1や4 (アルファチャネル付き) もあるし

**デフォルトの名無しさん** · 2025/05/05(月) 16:02:16.97

仕事はお金を貰ってやることだから丁寧に書いて上司に褒められる必要があるけれど
趣味とか経営者とかなら何を書いてもじゆうなんだよな

**デフォルトの名無しさん** · 2025/05/05(月) 16:11:32.03

簡潔で見にくいコードを書くか
冗長で醜いコードを書くか
２択だな

**デフォルトの名無しさん** · 2025/05/05(月) 16:35:32.16

>>181
これはそう
画像に限らず構造化されたバイナリデータを扱うときに一般に言えることだけど、
単純にビット列をそのまま構造体として読み替える間違いは、低水準に踏み込める言語に入門して調子乗ってる初心者がやりがち

**デフォルトの名無しさん** · 2025/05/05(月) 16:47:29.64

上司はunsafeの箇所をチェックすればいいのに
コンパイラが自動で調べてエラーがなかった箇所を、手動で調べ直して逆張りするのが胡散臭い

**デフォルトの名無しさん** · 2025/05/05(月) 18:15:43.01

Serdeは暗黙のCopyしがち

**デフォルトの名無しさん** · 2025/05/05(月) 18:29:47.69

>>180
８０代のおじいさんと仕事をする機会はないかな

**デフォルトの名無しさん** · 2025/05/05(月) 22:23:21.43

話を整理すると

>>82
>> .G(p[0]).R(p[1]).B(p[2]).build()
>> のところを容易に
>> .R(p[0]).G(p[1]).B(p[2]).build()と間違え

と彼は言い出すから
それは名前付けせずにp[0]を用いていることが間違える本質的な問題という話だよな

**デフォルトの名無しさん** · 2025/05/05(月) 22:25:33.48

さらに

>>160
> RGB各値は指定が必須とは限らない
> defaltで各値が0指定されていて同じなら書く必要がない

と彼は言ってるので
彼の好み通りにp[0]を用いるとして

名前付きオプション引数方式
foo(
　green = p[0],
　blue = p[2],
)

ビルダーメソッド方式
foo()
　.green(p[0])
　.blue(p2])

どちらの方式でも同じだな
仮にミスが起きるとしたらそれは名前を付けずにp[0]を使っていることが本質的な問題であると確定

**デフォルトの名無しさん** · 2025/05/05(月) 22:47:31.22

構造体は
foo{green:green,blue:blue}
を
foo{green,blue}
と描ける訳で
ビルダーメソッド方式とやらも
foo().green().blue()
的に描ければ無駄が減るから改良してくれんかのぅ

**デフォルトの名無しさん** · 2025/05/05(月) 23:13:19.16

>>189
その大量連投していた彼はRustをほぼ知らないと判明した上に他の言語の経験値も低そうなので彼自身に問題があることを理解できないと思う

**デフォルトの名無しさん** · 2025/05/05(月) 23:39:40.43

その連投してスレを荒らしていた人が
「おじ」「複おじ」「おじいさん」「おじいちゃん」使いの人だったとはね
>>61 >>70

**デフォルトの名無しさん** · 2025/05/05(月) 23:42:50.66

foo().(green).(blue)
でもいいな

**デフォルトの名無しさん** · 2025/05/05(月) 23:55:27.76

RustはJavaよりも構造体リテラルの表記が強力だから
Builder使うよりOptions構造体１つで渡す方が楽かもしれんね
パターンとしてはBuilderよりマイナーだけど

**デフォルトの名無しさん** · 2025/05/05(月) 23:58:49.46

>>190
引数なしで何を指定するのか？

>>193
メソッド名なしはエラー

どんな方式を取ろうとも大元の変数(ex. rgbやp)は指定せざるをえない
foo().green(rgb).blue(rgb)

**デフォルトの名無しさん** · 2025/05/06(火) 09:36:09.23

>オプション引数やキーワード引数については他言語が内部的にやってることをRustの場合は開発者が自分でやらなきゃいけないことになっててバカらしい

>しかも関数シグニチャに情報をまとめられないから書く方も読む方も煩雑になるだけで開発者的には何もメリットがない

これに尽きる
言語に機能が不足してるから何でもかんでもビルダーパターンにしなきゃいけなくてサードパーティのマクロに依存することになる
アホらし

**デフォルトの名無しさん** · 2025/05/06(火) 09:48:17.91

>>196
真逆だろ
キーワード付オプション引数をズラズラ並べた長い長い関数シグニチャはデメリットしかない欠陥品
しかも機能拡張したらさらにキーワード付オプション引数が増えて関数シグニチャが変わるアホらしさ

**デフォルトの名無しさん** · 2025/05/06(火) 09:51:10.91

複数IDと口調を使い分けて自分のレスに賛成するキチガイが複おじ

**デフォルトの名無しさん** · 2025/05/06(火) 09:51:38.50

Rustのダサい処は認めるべき

**デフォルトの名無しさん** · 2025/05/06(火) 09:56:28.46

>>197
ビルダーパターンは30年以上前から知られていたけどあまり有用ではないので使われていない
過去に誰かがざっくりデザインパターンを否定してたけど、その人の言うにはデザインパターンで有用なものは言語自体に取り込まれるはずだと

実際いくつかは新しい言語では取り込まれている