25/05/03 07:56:18.42 ERFTsxnY.net
>>前969
>このパターンが「便利だから」という理由で他の言語でも流行る
C++のstreamのsetwみたいでださいな
3:デフォルトの名無しさん
25/05/03 09:25:44.77 qBega2UP.net
>>前995
> 構造体のフィールドに値を入れていって構造体を作成しても
> derive_builderを使いメソッドで値を入れていっても同じになった
> メソッド呼び出しが消えた
> ゼロコスト
builderのコストは下記。名前付き引数とデフォルト値を使用した方法であれば全て不要で単なるnewの呼び出しとなるが、これらが全て最適化で消えるのか?
* パラメータ用の構造体(以下P)のアロケーション
* 構造体Pのデフォルト値での初期化
* 構造体Pのフィールドに対する上書き
* 構造体Pから最終的に作成する構造体への各フィールドの逐次的なコピー
* 構造体Pの破棄
4:デフォルトの名無しさん
25/05/03 09:44:09.41 WnzKFtQv.net
全部消える。 構造体初期化の文法で書いた場合と同じ。
最適化しない場合の素朴な処理でもそんなに気にするような深刻な差もない。
5:デフォルトの名無しさん
25/05/03 10:00:48.18 WFDs7LYH.net
>>4
compiler explorerで示して
6:デフォルトの名無しさん
25/05/03 10:10:18.01 h9Jrb8E+.net
は？
7:デフォルトの名無しさん
25/05/03 10:43:01.54 rfaECn6+.net
君は見たか？
複おじがぐうのねも出ずに論破された所を
8:デフォルトの名無しさん
25/05/03 10:49:14.34 NA/ingJD.net
過視化するな
9:デフォルトの名無しさん
25/05/03 10:52:36.35 rfaECn6+.net
大体のケースでビルダーパターンはアンチパターンと主張し続けて20年以上経つ
10:デフォルトの名無しさん
25/05/03 10:54:37.53 0l2J5oT4.net
最適化されることを主張するなら証拠を示すべきなのは当然だが、
コピーの最適化を前提にするのなら例えば安易にCopy実装したりcloneしたりすんな、
みたいな意識高い言説は多くの場合無意味になっちゃうわけだけど、Rustおじはそれでいいのだろうか
11:デフォルトの名無しさん
25/05/03 11:28:41.74 x2OSMXKg.net
この流れは流石に重箱の隅をつつきすぎじゃないの？
Rustのビルダーはオプショナルな動作を指定するパターンでしかないし、これが最適化されないと困る場面もそんなに無い
せいぜい、ヒープを使うデータについてビルダーを消費するか、中身を clone するかを検討するくらいでしょ
コピー動作が問題になるとしたら、例えば数十万とかの要素を持つ配列の for ループ内でビルダーを使う場合が考えられるけど、それならビルダーを1度だけ作ってそれを使いまわせばいいし
「Rustにも他の言語のオプション引数やキーワード引数があると嬉しいよね」という話なら同意だけど、ビルダーのパフォーマンスはそんなに重要な話でないというか
12:デフォルトの名無しさん
25/05/03 11:29:53.96 rfaECn6+.net
ストローマン論法
13:デフォルトの名無しさん
25/05/03 11:53:45.69 NA/ingJD.net
匿名の藁人形は作れない
作れるのは名指しできる個人や団体だけ
だから実名のSNSは嫌なんだよね
14:デフォルトの名無しさん
25/05/03 12:04:07.72 ekVKJoF2.net
>>10
一理ある
15:デフォルトの名無しさん
25/05/03 12:39:00.21 0l2J5oT4.net
RustやC++のゼロオーバーヘッドが意味するところは結局「俺達のコードがどのように処理系によって最適化されるかを俺達は知っている」ということであって、
どのような最適化がなされるかについて一定の透明性があり結果が自明であることが重要
その点で、コピーの最適化を前提にするってのはかなり微妙
16:デフォルトの名無しさん
25/05/03 13:47:12.37 ekVKJoF2.net
「かいたとおりにうごく」が最適化では成り立たないからなぁ
17:デフォルトの名無しさん
25/05/03 13:55:18.67 NA/ingJD.net
昔ある言語でcontinueがないぞと散々言われて、gotoが実装されたことがあった
何もしないのと比較すればcontinueの提案は優れていたかもしれないが
それは比較対象との相性が良かっただけ
18:デフォルトの名無しさん
25/05/03 14:13:59.39 rfaECn6+.net
数年前に読んだ書籍にcontinueは使うべきでないと書かれていて驚いた
19:デフォルトの名無しさん
25/05/03 14:41:11.34 WnzKFtQv.net
>>10
安易に clone すべきでないのは所有権管理の話で、実行コストの話とはレイヤが違う。
20:デフォルトの名無しさん
25/05/03 18:56:47.80 Q4RX0Sa/.net
スマホとPCの作業を効率化したい--「Copilot Vision」の便利な8つの活用例
2025-05-03 07:00
URLﾘﾝｸ(japan.zdnet.com)
1 プログらまーまこれを改造してるので上記以外の状態でも使用できるようにしている
2 すでにプログラムがあるので１～コードを作成する必要が無い
ボイス・トォ・スカルの本態が一般パソコンにまで来たのでつい買い捨てができるようになった
マネーロンダリング 談合 インサイダー などがはかどるといわれる
21:デフォルトの名無しさん
25/05/03 23:51:30.72 OINldK7L.net
>>3
それらは最適化ですべて消えて最終的な初期化構造体のみになった
イテレータメソッドチェーンなどの時と同じ原理
それはもっと極端で各イテレータ毎にいくつ構造体があろうと縮約したりレジスタ化されたりして各構造体は消えていく
22:デフォルトの名無しさん
25/05/04 01:14:00.32 31CqVJjs.net
複オジ脳やべぇな
視野が狭すぎる
23:デフォルトの名無しさん
25/05/04 09:21:09.35 AbCvwvGO.net
>>19
cloneして意図通りに動作しなくなるならそりゃ普通にcloneの実装もしくは利用者側のバグだろ。作法の問題ではない。
そんな中身を理解しないままコピペしてるバカみたいな低次元のことは誰も問題にしていないでしょ。
24:デフォルトの名無しさん
25/05/04 09:55:20.90 768oLjN1.net
>>10
区別できないバカなのか？
ムーブの時などを含めて実態がコピーになるといってもコピー元は二度と使われないのだから最適化できる
一方でclone()などはコピー元をその後も使うためにコピーしている
コピー元を二度と使わないならclone()の必要がない
そしてコピー元をその後も使うから最適化の前提さえ成立しない
25:デフォルトの名無しさん
25/05/04 11:20:50.74 AbCvwvGO.net
それは少なくともbuilderの最適化の文脈においては明確に誤り
実際、derive_builderはcloneが最適化されることに依存している
26:デフォルトの名無しさん
25/05/04 12:05:36.94 RkNPiBO2.net
RustやC++のムーブも同じで一次的にはコピーをして元を使わないため最適化できる場合が多い
一方でプログラマがコピーやクローンを明示的にした場合は元が生きていて全く異なる
そもそも元も後で使いたいからコピーしているわけだ
だからムーブとは異なり最適化でコピーが消えることはない
もちろん後で使いたい場合はコピーして渡すのではなく参照を渡すのが正解だ
したがってプログラマはコピーを可能な限り避けるべきである
暗黙のコピーが行われるプログラミング言語では意識せずコピーしてしまう
プログラムを見ただけですぐにコピーしてあることがわかる方が望ましい
RustではCopyトレイト実装した型のみ暗黙のコピーが起きる
前述のように数値などはその方が有利なので最初からCopy実装されている
ヒープを用いない型ならばプログラマは自由にCopy実装できるがコード上でそれが明示され読む側は気付ける
サイズが大きく参照で扱った方がよい型をCopy実装していればおかしいことがわかる
一方でヒープを用いていればCopy実装はできないがClone実装はできる
これはコード上でfoo.clone()とコピーすることを明示的に記述する必要がある
したがって参照を使えばよいのに無駄なコピーをしていればすぐにわかる
27:デフォルトの名無しさん
25/05/04 13:33:55.47 V3G8dKZI.net
無駄をなくそうとしたらコンパイルが通らなくなった
っていう質問を処理するコストが高いよね
実行時のコストではなく
28:デフォルトの名無しさん
25/05/04 13:35:26.53 YbSG8qnS.net
読む気が失せる分だけど読んだ
ところが間違ってるというか言い過ぎだと思う
29:デフォルトの名無しさん
25/05/04 13:38:00.38 JiKNIZxM.net
クソデカ長文とかどこでも現れる辺りRustとRubyって似てるなーと思った次第である
30:デフォルトの名無しさん
25/05/04 13:41:35.32 w7r9Yiaa.net
この程度で長文扱いって普段どれだけ文章を読まないんだよ。
31:デフォルトの名無しさん
25/05/04 13:43:24.90 YbSG8qnS.net
暗黙のコピーが行われるプログラミング言語は大体値のコピーを行っている
値はこの場合参照なのでコストは限りなく低い
暗黙でポインターをコピーしてそれがコストが掛かると言う人はいないだろ
32:デフォルトの名無しさん
25/05/04 13:44:23.89 YbSG8qnS.net
>>30
読む気が失せるのは文章が下手くそだからであって長いことは関係ない
そしてボロボロと誤りと言うか独断に基づいた誤りがたくさん入っている
33:デフォルトの名無しさん
25/05/04 13:47:16.56 YbSG8qnS.net
複おじはAIに下書きを食わせて推敲してもらうべきだと思う
34:デフォルトの名無しさん
25/05/04 13:53:19.75 RkNPiBO2.net
むしろAIに生成させてるんじゃないかと思われる
同じことを何度も何度もダラダラ箇条書きに
眠くなるわ
35:デフォルトの名無しさん
25/05/04 13:57:45.80 V3G8dKZI.net
見たい所だけ切り取ればいいんだよ
切り取りや編集の責任をトリクルダウンするために、書く側は編集をしないという戦術だろうけど
それはどうでもいい
36:デフォルトの名無しさん
25/05/04 13:59:33.25 YbSG8qnS.net
AIではないよ
小論文など書くときに指摘されるけど、考えをまとめないでずらずらと続く文章は修正しろと言われる
一部の行頭だけ切りだすと以下のように前の文章とつなげて書いてるから読み手にはわかりにくい
↓これが連続して使われているので読み手への負担になっている
一方で
そもそも
だから
もちろん
したがって
37:デフォルトの名無しさん
25/05/04 14:05:10.05 YbSG8qnS.net
人間の脳もスタック状になってるんでドンドン文が接続されていくと脳内にスタックが作られてスタックがチェーンして肥大化して理解が苦しくなる
これは当たり前
38:デフォルトの名無しさん
25/05/04 14:21:14.87 YbSG8qnS.net
文章がダラダラと接続されているものは、まともに推敲されていないので、基本的に読むコストに比べて得られるものが少ない
雰囲気で書かれているので間にも間違いや矛盾が含まれている
読み手に対して読みやすさが考慮されていないのでふつーに読まなくても良い
39:デフォルトの名無しさん
25/05/04 14:36:43.37 YbSG8qnS.net
ここでようやくchatGPTに聞いてみた
✅ 読みにくさの主な原因
1.接続詞やつなぎ言葉の多用による文の長文化
「一方で」「だから」「そもそも」「もちろん」「したがって」などの論理接続語が多く使われ、それぞれの文が長くなりがちです。
結果として、読者は一文ごとの意味の切れ目を捉えづらくなります。
2.
文構造が複雑で、主語と述語の対応が曖昧
「コピーして渡すのではなく参照を渡すのが正解だ」のように、主語が省略されていて読み手が文脈を補う必要があります。
3.抽象的な話が続き、具体例や対比が乏しい
例えば「ムーブはコピーと違う」と言いつつ、具体的にどう違うのかの明示がないため、読者が前提知識を持っていないと理解しにくいです。
4.
視点の切り替えが頻繁
ムーブとコピー、CopyとClone、参照と値渡しなど、話題が細かく切り替わっているが、その都度明確な導入がないため混乱を招きます。
40:デフォルトの名無しさん
25/05/04 14:42:19.99 V3G8dKZI.net
もっと詳しく書け、とAIが言っている
みんなAIに騙されてる
41:デフォルトの名無しさん
25/05/04 14:51:46.05 YbSG8qnS.net
さっき書いた部分は連続で接続されている
A 一方で B = C（文意）
C そもそも D = E（文意）
E だから F = G（文意）
略
Y したがって Z
Zを理解するためにAから後を状態や文意を含めて全部覚えておかないといけない
読み手を疲弊させるには接続を多用したらいいとも言える
42:デフォルトの名無しさん
25/05/04 15:48:20.78 pRD7GF2w.net
みんな読みやすい文を書いて良い大学、良い企業に入りたいとか
読みやすい文を書いて本を出版して売りたいとか
金の為に文を書いているからな
文なんて記号に過ぎない意味が伝わればいいのよ
43:デフォルトの名無しさん
25/05/04 15
44::53:36.21 ID:w7r9Yiaa.net
45:デフォルトの名無しさん
25/05/04 16:11:44.87 pRD7GF2w.net
国語の天才が推敲すると数学も理科も社会も意味がわかるようになるなら
学校で国語だけ教えてればいいだけだろボケ
46:デフォルトの名無しさん
25/05/04 16:24:07.39 rF0671A/.net
確率扁微分方程式を国語で説明してくれ
三行でよろぴく
47:デフォルトの名無しさん
25/05/04 16:27:43.19 pRD7GF2w.net
教
科
書読め
48:デフォルトの名無しさん
25/05/04 16:34:02.19 SPPeLARI.net
もちろんでNGしとけ
49:デフォルトの名無しさん
25/05/04 16:43:31.57 NNcLkyI5.net
AIにコードを生成させるならもうRustはいらない子だよね
50:デフォルトの名無しさん
25/05/04 17:06:18.99 V3G8dKZI.net
>>48
こういうのはビッグウェーブに乗る力であって国語力ではないね
51:デフォルトの名無しさん
25/05/04 17:29:04.69 YbSG8qnS.net
他人に自分の主張を理解してもらいたいなら、少なくともわかりやすく書く必要がある
いつも例の人の文章を読んでると念仏を聞いてるような気分になる
誰かが眠くなると書いてたけど自分もその印象が強い
言葉を吐くマシーンの様で理解してもらおうなどと思ってないんだろうなと
52:デフォルトの名無しさん
25/05/04 18:03:43.43 V3G8dKZI.net
理解されるためならなんでもしますという意志はたいして重要ではない気がする
なんでもするって言わせたい人にとって重要なだけだろう
53:デフォルトの名無しさん
25/05/04 18:15:26.35 MUJ0VZ08.net
文章の読みやすさを意識しないプログラマのコード品質って大丈夫なのか？
54:デフォルトの名無しさん
25/05/04 18:50:12.49 YbSG8qnS.net
理解されないなら主張としては存在しないのと変わらない
公共の場にただのデカいゴミがあってみんな邪魔だなって思うだけ
55:デフォルトの名無しさん
25/05/04 19:37:09.88 hE1W0oD0.net
derive_builderのドキュメント見てみた
Rustはこれらのclone呼び出しも最適化して賢いと書かれている
URLﾘﾝｸ(docs.rs)
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.
56:デフォルトの名無しさん
25/05/04 20:04:32.38 AbCvwvGO.net
derive_builderはRustのセマンティクス的には割と非効率な実装を採用していて、
常に一度のbuildだけの使い捨てに特化したバージョンも提供するなど制約を強めることで更にセマンティクス上効率的な実装もありうる
でもそうしないのは実際最適化で変わんなくなるんだろう
コンパイラの解析に委ねる前にセマンティクス上の最適を目指すのがRustの大きなコンセプトだと個人的には思っているが、その観点ではあまり理想的とは言えないやり方だし、
Rustの言語側にも改善の余地があるかもしれない
57:デフォルトの名無しさん
25/05/04 20:20:39.66 MUJ0VZ08.net
#[builder(pattern = "owned")]だと使い捨てになるんでしょ
こっちをデフォルトにした方がいい気もするけど１回しかbuildしない場合は最適化されて同じになるらしい
58:デフォルトの名無しさん
25/05/04 20:38:30.13 4IVc0xff.net
さらに限定したケースでRustコードの段階で最適化できる可能性もあるかもしれない
この初期化ビルダーがプログラム全体のネックになる時が来たらチャレンジするかな
現実には誤差の範囲内なのでこのderive_builder利用で十分と思う
初期化関数を自分で用意せずとも構造体への属性修飾だけでよい利便性は他のプログラミング言語と比べてもベスト
59:デフォルトの名無しさん
25/05/04 21:23:32.91 YbSG8qnS.net
でもビルダーパターンは潜在的にバグ発生の要因をはらんでいる
60:デフォルトの名無しさん
25/05/04 21:31:29.80 4IVc0xff.net
>>58
あらゆるパターンが潜在的にバグ発生の要因をはらんでいるから意味のない発言
具体的にderive_builderでバグ発生の要因があるなら指摘して
61:デフォルトの名無しさん
25/05/04 21:32:02.50 YbSG8qnS.net
IDEのサポートを受けた元で初期化関数を使うのがベスト
単純にビルダーパターンで起こる記述漏れ、順序の間違い、重複指定バグが減る
62:デフォルトの名無しさん
25/05/04 21:33:14.08 YbSG8qnS.net
>>59
前スレで書いたけど複おじは反論不能だったみたいでスルーしてたな
複おじ論破されて草だった
63:デフォルトの名無しさん
25/05/04 21:36:49.89 hRPtBNkv.net
>>60
手動で初期化関数を作るのは面倒かつバグの入る余地もあり劣ってる
derive_builderは利便性も良いからこれより優れているものを持ってこないと話にならないかと
64:デフォルトの名無しさん
25/05/04 21:39:37.45 4IVc0xff.net
>>61
「おじ」使いのキチガイの人かよ
具体的にderive_builderでバグ発生の要因があるなら指摘しなさい
65:デフォルトの名無しさん
25/05/04 21:39:44.02 YbSG8qnS.net
>>62
そんなもんテストでわかるでしょう
テストしないところでビルダーパターンはバグを起こす可能性が高い
人間がビルダーパターンのメソッドに注視して思考してパラメーターを指定する場合は問題が比較的起こりにくい
それをコピペや思い込みで書くとヒューマンエラーが入り込む余地がある
ビルダーパターンで複数行でメソッドを記述した場合には列レベルで記述が抜けることが考えられる
行で記述しても対応ミスなどが起こる
複おじは問題点をわざと見ないふりをしている
66:デフォルトの名無しさん
25/05/04 21:40:04.11 YbSG8qnS.net
>>63
前スレ見ろ
おじいちゃん
67:デフォルトの名無しさん
25/05/04 21:45:21.35 hRPtBNkv.net
>>64
わざわざ手動で初期化関数を作ってテストするってか
面倒なだけでメリットが全くない
利便性も良いderive_builderより優れているものを持って来なされ
68:デフォルトの名無しさん
25/05/04 21:46:26.28 YbSG8qnS.net
>>66
前スレで問題点を指摘されて論破されて何もできないで誤魔化してるんでしょ
みっともない
69:デフォルトの名無しさん
25/05/04 21:49:41.13 hRPtBNkv.net
>>67
誤魔化してるのは君だ
derive_builderに問題点があるなら指摘しなされ
derive_builderよりも利便性の高い方法があるなら持ってきなされ
70:デフォルトの名無しさん
25/05/04 21:52:48.22 YbSG8qnS.net
>>68
ストローマン論法だな
自分の主な主張はで前スレで書いたようにビルダーパターンは複雑なオブジェクト生成で使われるべきで
普通のオブジェクト生成ではコンストラクタなどの初期化関数を使うべきと言うもの
理由はビルダーパターンはヒューマンエラーが入り込む余地が非常に大きいから
初期化関数はIDEの補助があるのでビルダーパターンで起こる問題が発生しにくいか発生しない
71:デフォルトの名無しさん
25/05/04 21:56:47.92 YbSG8qnS.net
それにしても「～しなされ」って言われたのは人生で初じゃないかな
ガチおじいちゃんじゃん 複おじいちゃん
72:デフォルトの名無しさん
25/05/04 22:01:03.15 hRPtBNkv.net
>>69
詭弁はよろしくない
derive_builderは自分で初期化関数を書く必要がない
他の方法では初期化関数を書く必要がありヒューマンエラーが入り込む余地があるのはその通りだ
利便性も良くてその問題が生じないderive_builderが優れている
73:デフォルトの名無しさん
25/05/04 22:02:35.26 YbSG8qnS.net
>>71
ストローマン論法だな
こちらの主張していない内容を勝手に作り出してそれで話を続けている
74:デフォルトの名無しさん
25/05/04 22:08:16.17 YbSG8qnS.net
初期化関数はビルダーパターンのメソッドの適用ミスで容易に起こりうる 重複、順序ミス、記述漏れに対して有用
初期化関数自体は一回書くだけ
各所で必要になる単純なオブジェク生成の場面ではビルダーパターンはヒューマンエラーが入り込む恐れがある
それを初期化関数で行えばIDEの補助を得られるのでミスが減る
75:デフォルトの名無しさん
25/05/04 22:21:31.66 abvIudxv.net
>>73
先ほどから主張しているderive_builderを使わなければIDEの補助が得られるからミスが減るの意味がわからない
derive_builderを使えば初期化関数の用意はお任せなので提供側のミスはない
利用側はデフォルト値以外の値指定をしたい時にそのメソッド候補がIDEなどで補助があるのでミスが起きようがない
derive_builderを使った方が提供側も利用側もよいのではないか
76:デフォルトの名無しさん
25/05/04 22:24:30.81 V3G8dKZI.net
まだバグを起こす前の時期に、バグを起こしやすい習慣をやめない、まつもとなかいがいたとする
その時点で彼らをどのように処分したいのかね
77:デフォルトの名無しさん
25/05/04 22:33:13.89 YbSG8qnS.net
>>74
ストローマン論法をやめなされ
初期化関数を使うと指定の重複、順序ミス、記述漏れが起こりにくいのは事実だろう
まず単純な初期化関数で指定の重複が起こるのか？
func( a,b,c,d....にたいしてaを重複指定させられるのか？
これすら判らないなら話すだけ無駄
78:デフォルトの名無しさん
25/05/04 22:35:21.33 YbSG8qnS.net
「～しなされ」っていうのって少なくとも80歳以上じゃないかと
79:デフォルトの名無しさん
25/05/04 22:42:41.94 abvIudxv.net
>>76
derive_builderで提供された場合も問題は起きないよね
仮にそのaを重複指定してしまい
.a(123)
.a(123)
と書いてもバグは起きない
可読性もよいからそれ自体を起こさないね
derive_builderは提供側も利用側もデメリットがなく最も良い方法にみえる
もっと良い方がある？
80:デフォルトの名無しさん
25/05/04 22:44:40.17 YbSG8qnS.net
>>78
.a(123)
.a(321)
で始めの123が正しい場合問題になる
81:デフォルトの名無しさん
25/05/04 22:50:43.73 abvIudxv.net
>>79
aを123で初期化したいなら前者しか起きようがない
aを321で初期化したいなら後者しか起きようがない
そんなナンセンスな指摘しかデメリットらしきものを見つけることが出来なかったということは
derive_builderが最も良い方法であることを認めたと理解してよろしいか
82:デフォルトの名無しさん
25/05/04 22:50:51.74 V3G8dKZI.net
the bookによるとnewtypeパターンってのがあって
traitをimplすることが目的みたいだけど
どうにかすれば名前つき引数にも使えそうなんだよね
83:デフォルトの名無しさん
25/05/04 22:51:05.55 YbSG8qnS.net
順序ミスについて
これは前スレでも書いたのを再掲
.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() と言う間違いも入り込みやすい
84:デフォルトの名無しさん
25/05/04 22:53:00.11 YbSG8qnS.net
書いてるそばから間違えている
BGRが正しい
85:デフォルトの名無しさん
25/05/04 22:55:04.07 YbSG8qnS.net
>>80 の疑問については
>>82 で書いたようなミスで重複と記述漏れが発生する
そういうところまで考えたことないだろ？コーディングしてる？
86:デフォルトの名無しさん
25/05/04 22:57:59.52 abvIudxv.net
>>82
その比較はおかしい
デフォルト値以外のみを指定して初期化する話なのだから
それは✕ func(P[0], P[1], P[2],...
これが○ func(R=P[0], G=P[1], B=P[2], ...
87:デフォルトの名無しさん
25/05/04 23:00:32.68 YbSG8qnS.net
記述漏れについては
n個パラメーターを指定しないといけないのにn-1個しか記述していない場合
目で見てn個すべて指定したのかn-1個指定したのかなんて数が多くなると判らない
これは初期化関数では基本的に起こらない
数が多いとやはり大変だけどIDEの補助があったりコンパイル時にエラーがでる
ビルダーパターンでは実行時エラーや思った挙動にならない時点でしかミスに気が付かない
88:デフォルトの名無しさん
25/05/04 23:01:35.79 YbSG8qnS.net
>>85
誰もそんな縛りは指定していない
普通に初期化関数使えばよい
89:デフォルトの名無しさん
25/05/04 23:05:28.74 YbSG8qnS.net
これ以降ストローマン論法禁止
90:デフォルトの名無しさん
25/05/04 23:05:37.33 hRPtBNkv.net
オプション値の初期化の話だもんな
必須値の初期化の話ならRustでも
fn foo(red: Type, green: Type, blue: Type)
とするだけなのでderive_builderは使わない
だから>>82の指摘は間違ってる
91:デフォルトの名無しさん
25/05/04 23:09:07.67 YbSG8qnS.net
>>89
それはお爺さんにもわかりやすいように簡易化して書いているからだろ
ビルダーパターンは上にあげたようなヒューマンエラーを誘発する仕組みなので基本的に使わない方が良い
92:デフォルトの名無しさん
25/05/04 23:11:26.83 YbSG8qnS.net
生成に柔軟性があり複雑な場合にはビルダーパターンを適用するのは良い
一般的なオブジェクト生成に対してはヒューマンエラーに弱くアンチパターン
93:デフォルトの名無しさん
25/05/04 23:13:07.88 abvIudxv.net
>>87
プログラミングの基本的なことを理解していないのかい？
derive_builderを使うようなオプションで必要な項目だけ値を指定して初期化するケースを1つの初期化関数を単体で済ませようとすると
どんなプログラミング言語でもキーワード付きオプション引数を使うことになる
具体的にはf(1, 2, 3, option1=111, option5=222)などの指定方式になる
option5など名前を指定しないとどの項目を指定しているのか区別がつかないためだ
94:デフォルトの名無しさん
25/05/04 23:15:31.49 YbSG8qnS.net
>>92
その指定だとしても重複は大体の言語ではエラーになる
ビルダーパターンは重複を検知しないのでヒューマンエラーが入り込む
95:デフォルトの名無しさん
25/05/04 23:20:45.80 hRPtBNkv.net
>>91
オプション初期化のない一般的なオブジェクト生成でderive_builderを使う人はそりゃいないよ
それは普通にRustでも引数固定の初期化関数でおしまい
前スレを読んだけど最初から特定項目だけオプション初期化する話
だからderive_builderが最も優れているという結論になってる
96:デフォルトの名無しさん
25/05/04 23:21:18.11 YbSG8qnS.net
>>94
重複すら検知できないのに？
97:デフォルトの名無しさん
25/05/04 23:26:47.62 YbSG8qnS.net
重複を検知するには内部にフラグを持たなくてはならない
もちろんこれは実行時エラーになる
98:デフォルトの名無しさん
25/05/04 23:30:18.53 YbSG8qnS.net
実行時エラーを検出するにはテストで網羅しなくてはならない
99:デフォルトの名無しさん
25/05/04 23:40:27.55 YbSG8qnS.net
我々はコンパイル時にエラーが検出されるのを利点としてRustを使っている
それなのに実行時エラーに頼らざるを得ないビルダーパターンは劣っている
100:デフォルトの名無しさん
25/05/04 23:45:58.01 GqHoJEAc.net
結局、話をまとめると
ビルダーパターンで
foo()
.item1(value1)
.item3(value3)
.item7(value7)
と書くか
名前付きオプション引数で
foo(
item1=value1,
item3=value3,
item7=value7,
)
と書くか
これだけの違いだよな
どちらも変わらん慣れだけの問題
どちらも見た通りなので指定ミスや重複ミスなど起きようがない
あとはそれらを提供するライブラリ側だ
いずれも普通は初期化関数を自分で書かなければならない
Rustでderive_builderを使えば構造体に属性を付けるだけで済みシンプルかつミスも起きない
少なくとも現状でderive_builderに欠点は見つかっておらず最善な方法であるといえる
101:デフォルトの名無しさん
25/05/04 23:55:20.08 YbSG8qnS.net
>>99
結局何も見なかった利かなかったふりして自分のいいように矮小化し続けてるな
呆れるよ
80代になると何も感じなくなるのだろうか
102:デフォルトの名無しさん
25/05/04 23:58:47.69 GqHoJEAc.net
的外れな言いがかりでスレを荒らしてる人は
derive_builderより良い方法を具体的にコードで示せ
103:デフォルトの名無しさん
25/05/04 23:59:41.54 YbSG8qnS.net
精神論で間違いは発生しないと言うのは容易
間違えたら間違えた人間が悪いと言う
ビルダーパターンには結局ヒューマンエラーを防ぐように十分な対策がなされていないだろ
わかっていながら無視をする
c++精神だね
104:デフォルトの名無しさん
25/05/05 00:00:40.76 jqQPAhm/.net
>>101
ファクトリーパターンなどを使えばよい
メソッドの種類を充実させるだけだ
105:デフォルトの名無しさん
25/05/05 00:03:11.76 jqQPAhm/.net
ビルダーパターンはヒューマンエラーに弱い
毎回論理的構造を構築しなければならないがそこにバグが紛れ込む可能性がある
それよりも初期化のための関数を作るべき
106:デフォルトの名無しさん
25/05/05 00:03:28.63 +OgYhFfL.net
derive_builderは全自動だからミス起きなくね？
derive_builderより好いのがあるならコードを出して
107:デフォルトの名無しさん
25/05/05 00:05:02.99 jqQPAhm/.net
おじいちゃんは乱心して同じことを何度も書いて来る
普通の人間にはすでに書かれた内容で理解出来るのに知らないふりして実行時エラーやバグを許容している
108:デフォルトの名無しさん
25/05/05 00:06:42.46 jqQPAhm/.net
これも相手の疲労を狙ってくるくだらないやり口なんだろうと思うが
109:デフォルトの名無しさん
25/05/05 00:07:25.49 H9yekDq7.net
>>104
そんな方法は存在しないよ
>>99が挙げてる二つの方法しかない
もしあるなら同様のコード例を示そう
110:デフォルトの名無しさん
25/05/05 00:08:38.62 jqQPAhm/.net
他のスレでもでもおじいちゃん的書き込みを見ることがある
それに対して80代ではと書くと100%反論される
今回は反論されないところを見るとやはり80代以上なんだろうなと
111:デフォルトの名無しさん
25/05/05 00:09:40.80 jqQPAhm/.net
>>108
＞ それよりも初期化のための関数を作るべき
これが全てだろう？
いくら何でも馬鹿すぎるだろう？判らないの？
112:デフォルトの名無しさん
25/05/05 00:10:41.78 Eyx6FHs7.net
Builderはオプションの追加実装が破壊的な変更にならないメリットがあるな
生成関数に全部渡す方式だとパラメータが増えて破壊的になる
新しい生成関数を追加すれば破壊的にはならないけど
オプション追加する度に生成関数増やすのはあほくさい
>>103
もし暇だったら↓のRegexBuilderをFactoryで実装する場合の関数の個数を見積もってくれ
URLﾘﾝｸ(docs.rs)
113:デフォルトの名無しさん
25/05/05 00:12:00.84 H9yekDq7.net
>>110
今回のようなケースで初期化のための関数は>>99が挙げてる二つの方法しかない
もし他に存在するなら同様のコード例を示そう
114:デフォルトの名無しさん
25/05/05 00:15:57.46 jqQPAhm/.net
なんで自分にレスしてんの？
115:デフォルトの名無しさん
25/05/05 00:19:17.48 jqQPAhm/.net
>>111
他の言語でもRegexは普通にメソッドを使って解決してるけど…
長いならregexoption構造体作って指定したらよいだろう？他ではそうしてる物もある
116:デフォルトの名無しさん
25/05/05 00:20:28.67 jqQPAhm/.net
Rustしか使ったことがない前提なのかな
さすがに馬鹿の相手をするのは疲れてきた…
117:デフォルトの名無しさん
25/05/05 00:21:44.77 jqQPAhm/.net
おじいちゃんは他の言語は使えないの？しょうもない雑魚レベルの質問しかしないのはなんで？
118:デフォルトの名無しさん
25/05/05 00:29:27.74 J617bx8A.net
デフォルト値に対して必要分だけオプション指定したい場合
まともな方法はどのプログラミング言語を使って>>99のどちらかの方式になる
まともではない方法としてはオプションの有無ごとの組み合わせ数の分だけ大量の関数を用意する手もあるけど論外だ
119:デフォルトの名無しさん
25/05/05 00:41:54.17 jqQPAhm/.net
何で間違ってることを繰り返すの？
macroで重複チェック可能なbuilderは書けるとか書いてこないのは意外なんだけど
120:デフォルトの名無しさん
25/05/05 00:53:11.08 jqQPAhm/.net
実行時チェックの話もchatGPTの方がまともで面白い回答や提案をしてくれる
121:デフォルトの名無しさん
25/05/05 00:56:27.23 Eyx6FHs7.net
>>118
設定値の重複チェックとか誰も気にしないからでは
重複設定によるバグとか生成関数に渡す引数の順番を間違えるバグと同じくらい起こりにくいし
122:デフォルトの名無しさん
25/05/05 01:00:46.13 EffckoF6.net
一部の必須値の設定を忘れるケースは普通にあるでしょ
123:デフォルトの名無しさん
25/05/05 01:09:30.63 v8V26/QO.net
>>121
必須値は様々な対応が取れるため問題は起きない
・オプションにしない
・全体の整合チェックの一貫として必須値の有無の判断を入れる
・ビルド最終メソッドで指定する (ex. std::fs::OpenOptions::open)
124:デフォルトの名無しさん
25/05/05 01:17:39.76 Eyx6FHs7.net
一番オーソドックスなのが抜けてるな
RegexBuilderの場合はRegexBuilder::new()にパターン文字列を渡してる
125:デフォルトの名無しさん
25/05/05 01:21:35.04 v8V26/QO.net
>>123
先頭の「オプションにしない」が
その最初に必須値を渡す意味
わかりにくてすまん
フォローサンクス
126:デフォルトの名無しさん
25/05/05 08:29:59.12 EffckoF6.net
名前付き引数であれば必須パラメータも名前付きで渡せるため順番の間違いによるミスが発生しづらく可読性も高い
derive_builderを使う以上は必須パラメータもメソッドで渡すしかなく実行時エラーの可能性が排除できないしチェックのために余計なランタイムコストを払う必要がある
文句はderive_builder作者に言ってきた方がいいぞ
127:デフォルトの名無しさん
25/05/05 08:39:51.80 jqQPAhm/.net
狂信者には何を言っても無駄であり論理的な考えを持ち合わせていない
こちらがいくら論拠を提示してもRustが正しいderive_builderが正しいとそんなミスは起こりえないと繰り返すのみ
正しくないのはお前の頭だろう
128:デフォルトの名無しさん
25/05/05 08:41:20.98 PDh+rYm1.net
ビルド方式に問題はない
既出のstd::fs::OpenOptions::open()や
regex::RegexBuilder::new()など
Rustはビルド方式でも対応しており問題になっていない
>>125
名前付き引数であろうとなかろうとバリデーションは必要でそれは実行時エラーとなる
そしてResultを返すから実行時エラーで問題ない
129:デフォルトの名無しさん
25/05/05 08:42:39.33 S3aML2VS.net
>>82
順序ミス対策なら
.rgb(p[0], p[1], .p[2]).build()
でいいんじゃね？
Rustてこういうのできないんだっけ？
130:デフォルトの名無しさん
25/05/05 08:45:40.37 jqQPAhm/.net
>>127
＞ 少なくとも現状でderive_builderに欠点は見つかっておらず最善な方法であるといえる
じゃなかったのか？方針変えたのか？
131:デフォルトの名無しさん
25/05/05 08:49:55.75 3AfvJi9A.net
“イリヤ神”がまたやった 動画生成AI「FramePack」が革命的なワケ
2025年05月05日 07時00分更新
URLﾘﾝｸ(ascii.jp)
4月17日に登場した動画生成AIプログラム「FramePack（フレームパック）」が世界的に衝撃を与えています。PCローカル環境で動画AIを動かすには、少なくともビデオメモリー（V
132:RAM）が12GBあるビデオカードを搭載していないと難しいというのが常識でした。ところが、VRAM 6GBでも安定的に動作させられるため、一気に動画AIの裾野を広げそうです。開発したのは、画像生成AI分野で「ControlNet」や、使いやすいツール「Fooocus」などを開発してきたことで知られる、スタンフォード大学に在籍中のIllyasviel（イリヤスフィール、以下イリヤ）さん。既存の方法論にまったく違ったアプローチでブレイクスルーを引き起こす、“イリヤ神”のアプローチに再び注目が集まっています。 中略 AI動画を作ってみたいけれども、スペックが足りないために諦めていたという人が次々に自前の環境で試すようになってきました。既にワンパッケージでインストールできる環境も整えられているため、スタートも簡単です。様々なファイルをダウンロードしてくるため、初期設定は2時間くらいは見ておく必要があるものの、圧倒的にハードルが下がりました。
133:デフォルトの名無しさん
25/05/05 08:51:02.82 jqQPAhm/.net
>>127
名前付き引数のミスは大体言語でコンパイルエラーになるので的外れ
ビルダーパターンより安全性が高いだろ
134:デフォルトの名無しさん
25/05/05 08:51:16.55 RIr+9vrd.net
>>126
Rustが間違っていると主張したいなら問題点と代替策を述べればよい
本当にそれが示せるならRustはIT大手各社も用いているため世界中にインパクトを与えられるぞ
この我々の5chのやりとりすらRust製のPingoraを経由しているほどネットインフラ各所でもRustは使われている
135:デフォルトの名無しさん
25/05/05 08:52:25.13 jqQPAhm/.net
>>132
何言ってるんだよ
最後の一行が全てだろ
136:デフォルトの名無しさん
25/05/05 08:53:13.86 jqQPAhm/.net
本当に暇さえあれば関係ない話題で誤魔化そうとするよな
脳がストローマン論法で浸食されているんだろ
137:デフォルトの名無しさん
25/05/05 08:53:53.74 S3aML2VS.net
それよりもbuilderパターンは初期化時の情報指定漏れをコンパイルエラーにできないのがRustらしくないと思う。
138:デフォルトの名無しさん
25/05/05 08:54:21.19 RIr+9vrd.net
>>128
個別パラメータとして与える必要がないからその通り
Rustの言語仕様としてはそれで制限ない
そのライブラリの仕様ならタプルにすればよい
139:デフォルトの名無しさん
25/05/05 08:55:05.06 Nqd+X/r+.net
>>127
なるほど、実行時に他のバリデーションするからタイプセーフでなくていいと君は考えるわけね
それはそれで一理あるが、だったら君が使うべき言語は静的型付け言語ではなくRubyなどのゆるふわ言語だな
さようなら
140:デフォルトの名無しさん
25/05/05 08:56:18.75 jqQPAhm/.net
ビルダーパターンで疑似カリー化が行えるのが利点なのにタプル化するって
わざわざ手足を縛ることになるけど
141:デフォルトの名無しさん
25/05/05 08:56:40.00 RIr+9vrd.net
>>135
勘違いしていないか？
必要とはされないオプションが有る時にビルダーパターンが使われる
142:デフォルトの名無しさん
25/05/05 08:58:33.63 RIr+9vrd.net
>>138
それマジで言ってるならRustでプログラミングしたことがないんだな
タプルで扱うのが正解
これがわからないならfor文すら書いたことがないのだろう
143:デフォルトの名無しさん
25/05/05 08:59:24.57 Nqd+X/r+.net
>>139
それは一部必須パラメータが依然として存在することと矛盾しない
144:デフォルトの名無しさん
25/05/05 09:01:01.47 jqQPAhm/.net
>>140
もはや話がかみ合ってないな
疑似カリー化で個々のパラメータを指定してその他のパラメータをここに設定した生成物を作れるのが利点だという意味が判らないのかな
これは重複を許容する使用法
145:デフォルトの名無しさん
25/05/05 09:02:05.60 RIr+9vrd.net
>>141
必須パラメータの事例はさっき出てただろ
>> std::fs::OpenOptions::open()
>> regex::RegexBuilder::new()
これで対応できている
誰もが使っていて問題となったことはない
146:デフォルトの名無しさん
25/05/05 09:04:25.68 RIr+9vrd.net
>>142
カリー化の意味すら理解できてないのか？
Rustでカリー化ならばクロージャを使う
ちなみにビルダーパターンはビルダー構造体のまま変わらずカリー化は行わない
147:デフォルトの名無しさん
25/05/05 09:07:05.32 EffckoF6.net
>>143
だからそれはderive_builderの作者に言ってくれ
それに前から言ってるが必須パラメータの数が増えればミスが増えるし可読性も落ちる
148:デフォルトの名無しさん
25/05/05 09:07:28.43 jqQPAhm/.net
>>144
ストローマン論法
疑似カリー化と書いてるだろ？
derive_builderは正しいと繰り返していたのにすでに複おじになかったことにされている
149:デフォルトの名無しさん
25/05/05 09:10:38.57 jqQPAhm/.net
微妙に論点をずらしたり相手の言ってないことに対して批判したり
本当にずっとストローマン論法続けてるよなあ
複おじいさん
ストローマン論法はやめなされｗ
150:デフォルトの名無しさん
25/05/05 09:11:10.84 RIr+9vrd.net
>>137
Rustは静的型付けだから常にタイプセーフだよ
それらの例は引数の型が合ってなければ当然コンパイルエラーとなる
一方で引数の値が合っているかどうかは構造体の方針だから当然コンパイルエラーにできず実行時エラーとなる
151:デフォルトの名無しさん
25/05/05 09:13:10.00 RIr+9vrd.net
>>145
何を言いたいのかわからない
fsやregexの話を作者に伝える？
そんなの知ってるだろ
152:デフォルトの名無しさん
25/05/05 09:15:12.07 RIr+9vrd.net
>>146
カリー化は定義もメリットもはっきりしていて幅広く使われてきているが
その疑似カリー化とやらも定義もメリットもわからない
無意味なことをしようとしていないか？
153:デフォルトの名無しさん
25/05/05 09:17:40.24 jqQPAhm/.net
>>150
見ればわかるだろうｗ疑似カリー化が何を意味しているのかぐらい
そういう議論のための議論を繰り返してなんになるんだよ
154:デフォルトの名無しさん
25/05/05 09:24:52.62 RIr+9vrd.net
>>151
だから疑似カリー化の定義とメリットを明確にしてくれ
少なくともこの件のrgbバラバラにするのはメリットないどころかデメリットだぞ
>>128
>> 順序ミス対策なら
>> .rgb(p[0], p[1], .p[2]).build()
>> でいいんじゃね？
155:デフォルトの名無しさん
25/05/05 09:29:59.66 jqQPAhm/.net
>>152
こちらのID辿ってみたらいい
156:デフォルトの名無しさん
25/05/05 09:37:07.71 jqQPAhm/.net
>>62
>>68
複おじはderive_builderを全力で支持
初期化関数は全否定していた
ところが…
157:デフォルトの名無しさん
25/05/05 10:05:55.48 n6fK3gUl.net
＞ .R(p[0]).G(p[1]).B(p[2]).build()
これ3つとも指定が必要ならメソッドを分けるべきではないと思う
それ以前にRustのプログラミングしたことないのかメソッド大文字は置いとくにしても
この場合ならp[0]はRust的な使用方法ではないな
(r, g, b)もしくはRGB構造体で持つかその参照で持つのが普通
p[i]はなるべく避けてイテレータ時点でポインタを動かして参照で持つか小さいなら値で持つ
構造があるならその構造で持つ
そのためp[i]の形が出てきたらRustでは少し臭うため怪しみ避けられないか考える
158:デフォルトの名無しさん
25/05/05 10:33:19.28 20YqVkB+.net
>>75
>まつもとなかい
うby界隈のmatzとそのとりまきか？
159:デフォルトの名無しさん
25/05/05 10:58:23.25 EffckoF6.net
>>155
> これ3つとも指定が必要ならメソッドを分けるべきではないと思う
おっ
derive_builderって必須パラメータをランタイムチェックとはいえ個別setterの形で適切に扱えるというのが重要なコンセプトなんだけど、ここにきて全否定か
160:デフォルトの名無しさん
25/05/05 11:07:31.16 20YqVkB+.net
>>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()
みたいな間違いが起こるんだと思うよ
161:デフォルトの名無しさん
25/05/05 11:07:36.46 aemkUy0l.net
ボクシングには蹴り技がない
それは重要なコンセプトだと考えていた時期が俺にもありました
162:デフォルトの名無しさん
25/05/05 11:10:17.68 jqQPAhm/.net
コンパイラでうまくいかないから規約で縛ると言うことだろ？ビルダーパターンを導入する意義とどんどん崩れていく
RGB各値は指定が必須とは限らない
defaltで各値が0指定されていて同じなら書く必要がないだう
初期化関数では場合によっては記述する必要があるけどそれも必須ではない
疑似カリー化で少しずつパラメーターの違う複数のオブジェクト生成を行う場合にも便利
163:デフォルトの名無しさん
25/05/05 11:19:55.94 upfK5ln+.net
f(
red=red,
green=green,
blue=blue,
)
f()
.red(red)
.green(green)
.blue(blue)
どちらの方式でも間違えようがないと思うんだが
ミスが起きると言ってる人はどういうミスを想定してるのだろう
164:デフォルトの名無しさん
25/05/05 11:28:12.80 jqQPAhm/.net
red=p[0]; //p[0]は実際はblue
green=p[1];
blue=p[0]; // コピペの修正漏れ
165:デフォルトの名無しさん
25/05/05 11:28:24.28 EffckoF6.net
>>161
今更そんなところを理解できてなかったのか？
greenの指定を忘れたら前者はコンパイルエラー、後者は実行時エラー
166:デフォルトの名無しさん
25/05/05 11:35:07.99 jqQPAhm/.net
>>162
これの悩ましいところは後ろのコピペ修正漏れでblueに正しいp[0]が指定されているので
原因が判断しにくいところ
167:デフォルトの名無しさん
25/05/05 11:41:36.57 upfK5ln+.net
>>163
前者と後者は同じ
greenの指定をしなくてもコンパイルエラーとならない
greenは指定しなかった場合にデフォルト値となるオプション引数
168:デフォルトの名無しさん
25/05/05 11:44:04.39 EffckoF6.net
>>165
知らんがな
俺は必須パラメータの問題を指摘している
169:デフォルトの名無しさん
25/05/05 11:44:39.10 upfK5ln+.net
>>162
p[0]やp[1]など
可読性の悪いコードを書くやつは失格
p.red p.green p.blueにしろ
170:デフォルトの名無しさん
25/05/05 11:45:55.35 jqQPAhm/.net
>>167
dataと言うバイト列の中の一部だとしたら？
171:デフォルトの名無しさん
25/05/05 11:47:59.01 upfK5ln+.net
>>166
おっちょこちょいだな
直前のこれを見ろ
必須ではなくオプションパラメーターだ
>>160
> RGB各値は指定が必須とは限らない
> defaltで各値が0指定されていて同じなら書く必要がない
172:デフォルトの名無しさん
25/05/05 11:50:23.87 upfK5ln+.net
>>168
バイト列？
各8bitなのか各16bitなのかそれ以上なのかそれでは構造がわからん
ちゃんと構造体の列にするべきだ
173:デフォルトの名無しさん
25/05/05 11:54:15.50 jqQPAhm/.net
>>170
また真面に回答できないから適当に話をごまかして議論のための議論しようとしてる
受信データなどのバイト列から値を取り出すのは一般的だろう
必ずしも構造体の列構造とは限らない
それと数値指定無くすならコーディング規約でこう書かないとアウトですとするのか？
blue=data[ i + blue_index_offset];
red=data[ i + red_index_offset];
green=data[ i + green_index_offset];
174:デフォルトの名無しさん
25/05/05 12:01:19.27 upfK5ln+.net
>>171
あのさ
Rustでプログラミングしたことないの？
Rust以外でもシリアライズとデシリアライズしたことないの？
まともなプログラミングしたことある人ならRustですぐにserdeにたどりつく
175:デフォルトの名無しさん
25/05/05 12:10:05.78 aemkUy0l.net
まともな人が言ったのか人形が言ったのか全然わからない時代だ
人形が言ったにすぎないなら、そんな言葉は存在しないのと同じ
176:デフォルトの名無しさん
25/05/05 12:14:04.97 jqQPAhm/.net
>>172
お前はわざと議論のための議論してるだけだろ
通常のコーティングで出てくるであろう例を誤魔化している
177:デフォルトの名無しさん
25/05/05 12:16:46.89 jqQPAhm/.net
p[ i+0 ],p[ i+1 ],p[i +2 ]を取り出すだけのためにどれだけコーディング量を増やして
ライブラリ依存させていくのか
本当に意味不明
178:デフォルトの名無しさん
25/05/05 12:33:03.95 upfK5ln+.net
>>175
そんな可読性が悪くてミスしやすいプログラミングは避けるべきだ
構造化と抽象化が不得手でプログラマやエンジニアに向いてないな
serdeは構造体に#[derive(Serialize, Deserialize)]など付加するだけでデシリアライズ関数などは自動生成される
179:デフォルトの名無しさん
25/05/05 12:57:25.54 jqQPAhm/.net
>>176
構造体にって自分で書いてるだろ
単なるバイト列からp[ i+0 ],p[ i+1 ],p[i +2 ]を取り出すだけのために構造体などを作らないといけない
180:デフォルトの名無しさん
25/05/05 13:06:55.72 Q0EqhiJQ.net
p[ i+0/*0=赤*/ ],p[ i+1/*1=緑*/ ],p[i +2/*2=青*/ ]
俺ならこうするよ
コメントを見れば0が赤、１が緑、２が青と見たん瞬間わかる
日本語なので英語より間違えにくい
もし間違った数字が間違ってたらコメントと比べればすぐわかる
181:デフォルトの名無しさん
25/05/05 14:25:06.41 aemkUy0l.net
（言語を強化することにより）アプリのコーディング量を減らせという話はなかなか面白い
言語の数がアプリの数より多い気がする原因はこれかもしれない
182:デフォルトの名無しさん
25/05/05 15:35:05.95 4XowqzeV.net
>>174
議論のための議論をしてるのはお前だろ
それともガチで何も意味を読み取れないインデックスアクセスが正義と思ってるわけ？
どんなみじめな経験を積んできたんだよ
害悪プログラマすぎて仕事で関わらないことを願うわ
183:デフォルトの名無しさん
25/05/05 15:41:59.59 AjenNrLi.net
議論とは関係ないけど大体の画像処理ライブラリだとRGBもBGRも扱えるように channel[0], channel[1], channel[2] のようにアクセスさせると思う
内部のデータによって channel 数は1や4 (アルファチャネル付き) もあるし
184:デフォルトの名無しさん
25/05/05 16:02:16.97 Q0EqhiJQ.net
仕事はお金を貰ってやることだから丁寧に書いて上司に褒められる必要があるけれど
趣味とか経営者とかなら何を書いてもじゆうなんだよな
185:デフォルトの名無しさん
25/05/05 16:11:32.03 Q0EqhiJQ.net
簡潔で見にくいコードを書くか
冗長で醜いコードを書くか
２択だな
186:デフォルトの名無しさん
25/05/05 16:35:32.16 0Pl94lQ7.net
>>181
これはそう
画像に限らず構造化されたバイナリデータを扱うときに一般に言えることだけど、
単純にビット列をそのまま構造体として読み替える間違いは、低水準に踏み込める言語に入門して調子乗ってる初心者がやりがち
187:デフォルトの名無しさん
25/05/05 16:47:29.64 aemkUy0l.net
上司はunsafeの箇所をチェックすればいいのに
コンパイラが自動で調べてエラーがなかった箇所を、手動で調べ直して逆張りするのが胡散臭い
188:デフォルトの名無しさん
25/05/05 18:15:43.01 fQ8xBj6s.net
Serdeは暗黙のCopyしがち
189:デフォルトの名無しさん
25/05/05 18:29:47.69 jqQPAhm/.net
>>180
８０代のおじいさんと仕事をする機会はないかな
190:デフォルトの名無しさん
25/05/05 22:23:21.43 I4eA7HrP.net
話を整理すると
>>82
>> .G(p[0]).R(p[1]).B(p[2]).build()
>> のところを容易に
>> .R(p[0]).G(p[1]).B(p[2]).build()と間違え
と彼は言い出すから
それは名前付けせずにp[0]を用いていることが間違える本質的な問題という話だよな
191:デフォルトの名無しさん
25/05/05 22:25:33.48 I4eA7HrP.net
さらに
>>160
> RGB各値は指定が必須とは限らない
> defaltで各値が0指定されていて同じなら書く必要がない
と彼は言ってるので
彼の好み通りにp[0]を用いるとして
名前付きオプション引数方式
foo(
green = p[0],
blue = p[2],
)
ビルダーメソッド方式
foo()
.green(p[0])
.blue(p2])
どちらの方式でも同じだな
仮にミスが起きるとしたらそれは名前を付けずにp[0]を使っていることが本質的な問題であると確定
192:デフォルトの名無しさん
25/05/05 22:47:31.22 fQ8xBj6s.net
構造体は
foo{green:green,blue:blue}
を
foo{green,blue}
と描ける訳で
ビルダーメソッド方式とやらも
foo().green().blue()
的に描ければ無駄が減るから改良してくれんかのぅ
193:デフォルトの名無しさん
25/05/05 23:13:19.16 If8Py5os.net
>>189
その大量連投していた彼はRustをほぼ知らないと判明した上に他の言語の経験値も低そうなので彼自身に問題があることを理解できないと思う
194:デフォルトの名無しさん
25/05/05 23:39:40.43 Cn3HeiMA.net
その連投してスレを荒らしていた人が
「おじ」「複おじ」「おじいさん」「おじいちゃん」使いの人だったとはね
>>61 >>70
195:デフォルトの名無しさん
25/05/05 23:42:50.66 fQ8xBj6s.net
foo().(green).(blue)
でもいいな
196:デフォルトの名無しさん
25/05/05 23:55:27.76 hXT/3Bxe.net
RustはJavaよりも構造体リテラルの表記が強力だから
Builder使うよりOptions構造体１つで渡す方が楽かもしれんね
パターンとしてはB
197:uilderよりマイナーだけど
198:デフォルトの名無しさん
25/05/05 23:58:49.46 +Xl4Ck1b.net
>>190
引数なしで何を指定するのか？
>>193
メソッド名なしはエラー
どんな方式を取ろうとも大元の変数(ex. rgbやp)は指定せざるをえない
foo().green(rgb).blue(rgb)
199:デフォルトの名無しさん
25/05/06 09:36:09.23 sXCqetJD.net
>オプション引数やキーワード引数については他言語が内部的にやってることをRustの場合は開発者が自分でやらなきゃいけないことになっててバカらしい
>しかも関数シグニチャに情報をまとめられないから書く方も読む方も煩雑になるだけで開発者的には何もメリットがない
これに尽きる
言語に機能が不足してるから何でもかんでもビルダーパターンにしなきゃいけなくてサードパーティのマクロに依存することになる
アホらし
200:デフォルトの名無しさん
25/05/06 09:48:17.91 j5CJU7Aq.net
>>196
真逆だろ
キーワード付オプション引数をズラズラ並べた長い長い関数シグニチャはデメリットしかない欠陥品
しかも機能拡張したらさらにキーワード付オプション引数が増えて関数シグニチャが変わるアホらしさ
201:デフォルトの名無しさん
25/05/06 09:51:10.91 HDXWn70Z.net
複数IDと口調を使い分けて自分のレスに賛成するキチガイが複おじ
202:デフォルトの名無しさん
25/05/06 09:51:38.50 K1Pjz07i.net
Rustのダサい処は認めるべき
203:デフォルトの名無しさん
25/05/06 09:56:28.46 HDXWn70Z.net
>>197
ビルダーパターンは30年以上前から知られていたけどあまり有用ではないので使われていない
過去に誰かがざっくりデザインパターンを否定してたけど、その人の言うにはデザインパターンで有用なものは言語自体に取り込まれるはずだと
実際いくつかは新しい言語では取り込まれている
204:デフォルトの名無しさん
25/05/06 09:56:50.79 SvTeM3j9.net
マクロで解決可能なんだろ？ それは「不足している」のか？
まあ標準ライブラリとして入っているべきみたいな論はあるかもしれんけど、マクロでの解決が悪くて言語機能として直接サポートするのが良いとする根拠は出てないな。
言語ユーザがそれぞれのやり方で解決できる自由さと言語の方針を強制する一貫性は両立しないがそれぞれに良さはあるし、 Rust は今のところ自由さをとりつつもデファクトな地位のライブラリはあるという状況だ。
手頃な妥協点と言えるだろ。
205:デフォルトの名無しさん
25/05/06 10:01:33.47 HDXWn70Z.net
些細な内容なら初期化関数を複数作ればよい話で更に多くなればオプション指定する構造体を作ればよい
mutに拘る必要が無ければさらに多くの可能性がある
わざわざ穴の多いビルダーパターンを使う必要はない
206:デフォルトの名無しさん
25/05/06 10:08:26.28 SvTeM3j9.net
>>200
ポールグレアムはイディオム (デザインパターン) は言語機能として持つかライブラリにまとめるべきと述べていて、考えられる様々なパターン (またはこれから登場する未知のパターン) をライブラリにまとめるには「本物のマクロ」が必要と主張してた。
そして本物のマクロを持つ実用的な言語は Common Lisp くらいしかなかったんだが、 Rust のマクロは彼の言う本物のマクロだ。
マクロで抽象化されてるならその実装がビルダーパターンでもそうでなくてもどうでもいいよ。
207:デフォルトの名無しさん
25/05/06 10:10:04.33 j5CJU7Aq.net
>>202
初期化関数を複数作るとオプション分の組み合わせ爆発となる一番アホな方式
それならビルダー方式がよい
208:デフォルトの名無しさん
25/05/06 10:12:49.15 HDXWn70Z.net
>>204
他の言語では大体オーバーロードでオプション指定しているけどそれが馬鹿だとは思わないけどね
209:デフォルトの名無しさん
25/05/06 10:15:57.89 j5CJU7Aq.net
>>205
それはオプションが増えると組み合わせ爆発が起こる馬鹿な方式
210:デフォルトの名無しさん
25/05/06 10:17:10.44 HDXWn70Z.net
>>206
同じ主張と文章を繰り返すやり方が複おじそっくりですね
オーバーロードの初期化関数で馬鹿らしいと思うのは型が同じで対象が違うものがある時
重複を避けるためにシグネチャの設計をしなくては成らないことは馬鹿らしいと思うよ
例えば基本的に2つだけ引数があって後はオプションがずらずら並ぶならやはりオプション内容を含む構造体渡せばいいと思う
そちらも設計が必要だけど
211:デフォルトの名無しさん
25/05/06 10:18:50.49 j5CJU7Aq.net
>>205
それ以前にオーバーロードは欠陥機能
オーバーロードを使うとred,green,blueのオプション実装すらできない
212:デフォルトの名無しさん
25/05/06 10:19:38.79 K1Pjz07i.net
>Rust のマクロは彼の言う本物のマクロ
macro_rules! は偽物のマクロ
proc_macro2 が本物のマクロ
213:デフォルトの名無しさん
25/05/06 10:20:41.45 HDXWn70Z.net
普通は書き込み内容が単調にならないように人は文章に揺らぎをいれてくるんだけど
複おじは基本全部同じ
口調を変えても同じなので同一人物なんじゃないかと思って見ていると後で全く同じ書き込みを始めるので同じ人間なんだなと
214:デフォルトの名無しさん
25/05/06 10:20:45.54 j5CJU7Aq.net
>>209
どちらも本物だ
衛生マクロの概念すら知らないのか？
215:デフォルトの名無しさん
25/05/06 10:20:58.22 AZSw2w0R.net
>>208
何の問題もないと思うが、具体的には？
216:デフォルトの名無しさん
25/05/06 10:22:59.33 HDXWn70Z.net
本物のマクロと言う主張は面白い
でライブラリ作成者ではなく一般的なユーザ側が書いてるマクロはどっちなのかと
217:デフォルトの名無しさん
25/05/06 10:23:21.48 j5CJU7Aq.net
>>212
オーバーロードの制限を知らないのかね？
red,green,blueそれぞれだけを指定したい関数をオーバーロードで書いてごらん
218:デフォルトの名無しさん
25/05/06 10:24:49.05 j5CJU7Aq.net
>>213
衛生的なマクロとは何かを勉強するといいよ
219:デフォルトの名無しさん
25/05/06 10:24:50.06 HDXWn70Z.net
オーバーロード自体は良い仕組みだと思うけど設計が必要だ
最近の言語が取り入れていないのはヒューマンエラー対策という名目
だったらビルダーパターンもヒューマンエラー対策で禁止になるかと言えばそうでもない
220:デフォルトの名無しさん
25/05/06 10:27:37.75 j5CJU7Aq.net
>>216
オーバーロードは最悪な仕組み
欠陥が多すぎる上に
red,green,blue各オプションしてすら実現できない
221:デフォルトの名無しさん
25/05/06 10:28:08.85 HDXWn70Z.net
徐々に文体におじいさんぽさが出てきたね
222:デフォルトの名無しさん
25/05/06 10:47:02.68 46q0jEJS.net
AIを屈服させるレベルの改善ができるなら改善してもいいけどね
どうせAIが勝つという前提なら何も修正しないのが合理的だ
223:デフォルトの名無しさん
25/05/06 10:51:59.27 K1Pjz07i.net
今のAI()の実力ってこんなもんか
>2つのリンゴを3人で分ける場合、1つのリンゴを2つに切り、もう1つのリンゴも2つに切って、3人で分けます。
>そうすると、3人ともリンゴの切れ目と半分になります。
>具体的な分け方
1. 1つのリンゴを半分に切る:1つのリンゴを真ん中から半分に切り、2つの半分のリンゴにします。
2. もう1つのリンゴも半分に切る:もう1つのリンゴも同じように半分に切り、さらに2つの半分のリンゴにします。
3. リンゴを合計4つの半分に分ける:2つのリンゴを合わせて、全部で4つの半分に切ったリンゴが手に入ります。
4. 3人で分配する:3人でリンゴの半分を1つずつ取ると、3人とも1つずつ取ることができます。
5. 残った1つを3人で分ける:1つの半分に切ったリンゴが残りますが、それを3人で分けることができます。
例えば、さらに半分に切って3人で分けたり、3つの小さく切って3人で分けたりできます。
224:デフォルトの名無しさん
25/05/06 10:52:27.53 SvTeM3j9.net
>>209
本物のマクロというのが何であるか明瞭な定義はされてないのだが、文脈的に「構文木の操作が出来る」というのが要件だと一般的に解されている。
トークン単位の置き換えしか出来ない C のマクロのようなものを除外するための言い回しだ。
構文木を操作できるなら操作できる範囲の違いは本物のマクロかどうかには重要ではない。
(もちろん出来ることが多いほうがより良い本物のマクロとは言えるだろうが、出来ることが多いほうが危険な間違いも引き起こしやすいので現実には適度に制限があったほうが良いこともある。)
macro_rules! も普通は本物のマクロと解される。
225:デフォルトの名無しさん
25/05/06 11:06:32.44 46q0jEJS.net
リスパーはmatchを知らない
matchを知らなくても理解できるマクロが本物のマクロ
226:デフォルトの名無しさん
25/05/06 11:11:44.35 HDXWn70Z.net
複数ID使用おじ
別人が複おじと疑われたら自分は複おじじゃねーよと反論する
気持ち悪いから
ところが何故かしない
複おじはそういうのに反論しない仕組みになっている
227:デフォルトの名無しさん
25/05/06 11:19:55.25 AZSw2w0R.net
>>214
ヒント:
struct Red(u8);
228:デフォルトの名無しさん
25/05/06 11:20:28.10 HDXWn70Z.net
マクロ自体がただの似たような機能の概念の総称であってその中で本物だ、元祖だと言っても笑われるだけ
キーボードマクロは真のマクロではないとか衛生的ではないと言われてもそうですかと
229:デフォルトの名無しさん
25/05/06 11:22:58.43 HDXWn70Z.net
ID:j5CJU7Aq の反応待ちのawait状態です
230:デフォルトの名無しさん
25/05/06 11:23:42.97 K1Pjz07i.net
>>223
複OGはどうでも良いけど
5chはもう禿しく過疎ってるのにこのスレだけやけに延びてるのは不自然だと感じる
231:デフォルトの名無しさん
25/05/06 11:31:04.25 SvTeM3j9.net
>>225
「本物のマクロ」というのは正しさとか起源を主張しているわけではなくそういう名前の分類。
少なくとも C のマクロなどでは様々なイディオムを抽象化するには不十分だというごく当然の話をしてる。
232:デフォルトの名無しさん
25/05/06 11:33:12.59 AZSw2w0R.net
なお、名前付き引数での呼び出しを前提とするならばhoge(red) と hoge(green)を名前付き引数の引数名だけで呼び分けるオーバーロードは技術的には実装できない理由は特にない
しかし、多くの言語では名前付き引数の使用はオプションだしこの場合はhoge_red(val)のように機械的に名前変えりゃいいだけだから、実装コストに見合わないという判断をされているのだろう
233:デフォルトの名無しさん
25/05/06 11:39:56.59 ZZS2r6Zz.net
>>224
こうですか？わかりません
impl From<Red> for Color {...}
impl From<Green> for Color {...}
impl From<Blue> for Color {...}
impl From<(Red, Green)> for Color {...}
impl From<(Red, Blue)> for Color {...}
impl From<(Green, Blue)> for Color {...}
impl From<(Red, Green, Blue)> for Color {...}
let red = Color::from(Red(255));
let yellow = Color::from((Red(255), Green(255)));
let white = Color::from((Red(255), Green(255), Blue(255));
234:デフォルトの名無しさん
25/05/06 11:48:34.17 46q0jEJS.net
メリットが不確実なだけでしょ
メリットもコストも確定していてなおかつ見合わないという話ではない
235:デフォルトの名無しさん
25/05/06 12:18:40.67 0KYdit4+.net
このスレでずっと自演してる人って糖質とかなんだろうなあ
236:デフォルトの名無しさん
25/05/06 12:28:45.22 K1Pjz07i.net
traitで騒いでた自演と同じ人だろう
237:デフォルトの名無しさん
25/05/06 12:40:06.43 WV2uqB5+.net
オーバーロードはそもそもCのAPIにありがちな、後で〇〇2だの〇〇exだのが増えて格好悪くなる問題を解消するためのもの
後で引数名だけ異なるオーバーロードが増えたら名前付き引数を使っていない既存の呼び出しがエラーになるのは、互換性維持という本来の目的からすれば論外
238:デフォルトの名無しさん
25/05/06 12:49:02.99 w/CyTLi+.net
話題のderive_builderを使ってみた
構造体に属性を付けるだけで初期化関数を書かなくて済むのは便利だね
ドキュメント見ると今回は使ってないけど色々と機能が充実してるみたい
話題のred/green/blueはこれでいいのかな
use derive_builder::Builder;
#[derive(Default, Builder, Debug)]
struct Color {
#[builder(default = "0")]
red: u8,
#[builder(default = "0")]
green: u8,
#[builder(default = "0")]
blue: u8,
}
fn main() {
let pink = ColorBuilder::default().red(255).blue(200).build().unwrap();
println!("{pink:?}"); // Color { red: 255, green: 0, blue: 200 }
}
239:デフォルトの名無しさん
25/05/06 12:57:12.48 aXFsP9SC.net
>>235
よくない
散々言われている通り、必須属性の設定を忘れると実行時エラーになるという致命的な問題がある
240:デフォルトの名無しさん
25/05/06 13:06:06.15 w/CyTLi+.net
>>236
例えばファイル名を打ち間違えちゃったけど
まずリリースモードの前にデバッグモードの時点で実行時エラーで気付いて
直してしまえばそれ以降は大丈夫と同じじゃないのかな
特に問題ないような
241:デフォルトの名無しさん
25/05/06 13:10:03.39 w/CyTLi+.net
補足するとファイル名は必須項目だけど
コンパイル時にチェックできるのは型だけだから現実的にチェックできることはほとんどないよね
242:デフォルトの名無しさん
25/05/06 13:16:05.70 sXCqetJD.net
お前らめちゃくちゃ暇人だな
レス多すぎ
243:デフォルトの名無しさん
25/05/06 13:18:37.75 sXCqetJD.net
>>201
>マクロで解決可能なんだろ？
ビルダーパターンの手書きコード量を多少なりとも削減したいという問題は解決してるかもね
それが本当に解決したい問題だと思ってるのならそれでいいんじゃない
244:デフォルトの名無しさん
25/05/06 13:24:33.64 w/CyTLi+.net
ビルダー方式でも他の方式でもなんでもいいけど
初期化のための関数を自分で書くよりも>>235のように構造体への属性マクロ指定だけにするのがいいと思う
面倒がなくコードがすっきりとしてプログラミングミスも起きないから
245:デフォルトの名無しさん
25/05/06 13:44:43.14 aXFsP9SC.net
>>238
それはそうなのだけど、だからといってコンパイル時のチェックを安易に諦めたら、極論Cでいいだろって話になっちゃう
Rustの存在意義が問われる危険な思想
246:デフォルトの名無しさん
25/05/06 13:46:48.63 ZZS2r6Zz.net
現時点のderive_builderはFooBuilder::new()に必須項目を渡すパターンには対応してないっぽいな
全部default()でも構わないケースだと使えるけどRegexBuilder::new(pattern)みたいなケースもあるから万能ではない
247:デフォルトの名無しさん
25/05/06 13:53:00.39 K1Pjz07i.net
良い例があるな
ｽﾚﾘﾝｸ(tech板:33番)
貴方が配慮を欠いている
そのx^nつまりxのn乗を求めるにしても
例えば2^100を求めたいならば128bitがないと溢れるのでu128::pow(2, 100)となるが
2^5を求めたいだけで結果も8bitで十分ならばu8::pow(2, 5)となる
このようにメモリサイズも異なってくるので別々の関数が必要
もちろんu128::pow(x, n)があればu8::(x, n)をカバーできるが明らかに無駄である
そこで符号なし整数だけでも
u8::pow(x, n)
u16::pow(x, n)
u32::pow(x, n)
u64::pow(x, n)
u128::pow(x, n)
と5つの関数が必要となる
一方でxの型が確定しているのであればpowで再び型指定は不要なので
x.pow(n)と表記することも可能
以上は整数の場合だがxとpowの結果が小数の場合は2種類の関数が必要となる
f32::powi(x, n) 【nが整数の場合】
f32::powf(x, n) 【nも小数の場合】
もちろんnが小数のpowfだけあればpowiもカバーできるが明らかに無駄なので2種類必要となる
さらに32bit小数だけでなく64bit小数も扱う必要があるため以下も必要
f64::powi(x, n) 【nが整数の場合】
f64::powf(x, n) 【nも小数の場合】
これらもxの型が確定していれば以下のように略して書くことも可能
x.powi(n) 【nが整数の場合】
x.powf(n) 【nも小数の場合】
ちなみに「x^n」を表記するのに不自然な「pow(x, n)」よりも「x.pow(n)」の方がたまたま自然に見えるが誤差だろう
どちらでも好きな表記法を選べばよいだけにすぎない
248:デフォルトの名無しさん
25/05/06 14:21:46.28 97zxA3f+.net
>>244
例えば
このように
もちろん
そこで
一方で
以上は
もちろん
さらに
これらも
ちなみに
そのx から始まって論理的？接続で参照を握ったままで最後まで離さないな
読みにくいのは当然
249:デフォルトの名無しさん
25/05/06 14:26:52.22 97zxA3f+.net
id変わってしまった
250:デフォルトの名無しさん
25/05/06 14:30:10.65 97zxA3f+.net
上の強烈な接続もビルダーパターンの一種かな？
251:と思ってしまう
252:デフォルトの名無しさん
25/05/06 15:04:10.81 46q0jEJS.net
>>242
忠臣蔵みたいに、諦めたふりをするぐらいがちょうどいい
危険思想？
なんのことやら
253:デフォルトの名無しさん
25/05/07 00:06:42.37 oRVzsgHT.net
>>245
複おじ語録よくぞまとめてくれたな
ほめてつかわす
254:デフォルトの名無しさん
25/05/07 10:19:22.81 0n7pwB6u.net
後から〇〇2や〇〇exが増える問題ってRustだとどう対処するのが一般的なんだろう
まあRustの場合ABIを維持する必要のあるケースは比較的限られてるけど、引数増やしたら既存のソースは壊れるよね
最初から構造体にしておけというのは意味のない意見なので無しで
255:デフォルトの名無しさん
25/05/07 10:32:45.05 Gjm+c4fd.net
普通に関数が増える
256:デフォルトの名無しさん
25/05/07 10:59:58.84 jrPMMEx+.net
>>250
ダイナミックリンクで提供する場合はバイナリ互換性が必要な場面も多いのは Rust でも変わらないよ。
言語の文化としてはスタティックリンクを使いがちではあるけど。
ダイナミックリンクは OS の機能なので言語の側からどうにか出来る余地も少ないし、 OS の文化に乗っかるしかない。
257:デフォルトの名無しさん
25/05/07 11:36:16.32 hcgUqjSt.net
○○exがある言語でJVMを実装し、○○exに依存してないと主張する
258:デフォルトの名無しさん
25/05/07 13:51:32.15 nPKhYJKb.net
Ubuntu 25.10から、sudoがsudo-rsに置き換わるそうだ
259:デフォルトの名無しさん
25/05/07 14:09:26.72 jrPMMEx+.net
まあ Rust が良いかどうかはともかくたまには刷新したほうがええやろ。
260:デフォルトの名無しさん
25/05/07 14:24:28.93 4cRsIVof.net
いや、sudoのようなパフォーマンスが重要でないコマンドなら
RustではなくGoで書くべきだった
261:デフォルトの名無しさん
25/05/07 14:25:34.83 iQ9Crc5o.net
どんなものでも機能も速さも同じだとしても
C/C++製よりRust製を選ぶわ
C/C++のせいでのセキュリティホールが後からいくらでも見つかってる現状
262:デフォルトの名無しさん
25/05/07 14:27:05.51 iQ9Crc5o.net
>>256
余分なランタイムが必要なGoはありえない
263:デフォルトの名無しさん
25/05/07 14:50:13.61 sBD46f0F.net
>>250
外部ライブラリならメジャーバージョン増やして普通に破壊する
旧バージョンのAPIをcompatモジュールとかに入れとけば親切
標準ライブラリはエディションで切り替える形になりそう
std::preludeのサブモジュール名は最初v1だったけど今はrust_20XXに方針転換してる
グローバルな名前の追加も一種の破壊だし
264:デフォルトの名無しさん
25/05/07 15:20:58.49 7aByWlek.net
下記は全て2025年５月７日の記事
OpenAI、ChatGPTの6つのモデルの違いと適切なプロンプトを解説
URLﾘﾝｸ(news.mynavi.jp)
Microsoftの新規のソースコードの約3割をAIが生成、Nadella氏が明かす
URLﾘﾝｸ(news.mynavi.jp)
スコットランドの住民を悩ます謎の怪音「ヘブリディアン・ハム」の正体はいまだ不明
URLﾘﾝｸ(karapaia.com)
265:デフォルトの名無しさん
25/05/07 18:35:48.88 hcgUqjSt.net
モダンなライブラリはdeprecateしやすいのか
古いCと最新のRustだけが残されて中途半端な時代は無かったことになりそうだ
266:デフォルトの名無しさん
25/05/07 19:03:14.70 3Nv7PA1l.net
いや、利用者が少ないうちに直しとけ心理で、どんな技術も通る道だよ
sudo-rsがいい例だがこういう長期間にわたって重要な役割を果たす、かつあまり変更が必要とされない用途が増えてくると、だんだんと進化は遅くなるものだ
267:デルフォトの名無しさん
25/05/07 19:08:29.35 Ja3pQWVu.net
>>257
(´・ω・)マジ？
268:デフォルトの名無しさん
25/05/07 22:26:25.21 LUGJMjLo.net
>>254
この国際的なプロジェクトでセキュリティ的に重要なものから順にRust化されていく一環だよ
Memory Safety for the Internet's most critical infrastructure
URLﾘﾝｸ(www.memorysafety.org)
269:デフォルトの名無しさん
25/05/08 09:08:51.16 8ptxnmrn.net
>>244-245
このように.drop();
もちろん.drop();
そこで.drop();
一方で.drop();
以上は.drop();
もちろん.drop();
さらに.drop();
これらも.drop();
ちなみに.drop();
270:デフォルトの名無しさん
25/05/08 09:25:34.07 xZxJToWs.net
ubuntuはsudoだけでなく、cp, ls, find, diff なんかもRust化する予定なんだな
ntpdもRust化が進められてる
271:デフォルトの名無しさん
25/05/08 09:33:12.04 n2pO1y9P.net
>>265
error[E0040]: explicit use of destructor method
help: consider using `drop` function
参考：URLﾘﾝｸ(doc.rust-lang.org)
272:デフォルトの名無しさん
25/05/08 10:28:22.03 1mgB1EfY.net
>>266
Ubuntuに限らず誰もが全てをC/C++製から安全なRust製へ変えたいと思っているが一気には無理なので重要なものや新たなものからRust採用という感じ
273:デフォルトの名無しさん
25/05/08 12:25:36.55 d06WSi70.net
全てを変えたい、とかいうビジョンは無意味
意味のないビジョンだよ
274:デフォルトの名無しさん
25/05/08 12:38:14.55 jIG0GCL4.net
安全でないC/C++を早く全廃したい世界の流れ
275:デフォルトの名無しさん
25/05/08 12:49:37.23 iRreO2Ee.net
Linuxコマンド開発専用言語Rust
276:デフォルトの名無しさん
25/05/08 12:51:53.54 Crcrgp42.net
メンテナ高齢化問題の対策としては良い取り組みなんじゃないかな
作業するのもインターンの学生が中心だろうし
277:デフォルトの名無しさん
25/05/08 12:55:02.85 Ad6EgOfh.net
多くのシステムやインフラがRust化してるね
この5chが使ってるCloudflareもRust製へと移行した
URLﾘﾝｸ(github.com)
278:デフォルトの名無しさん
25/05/08 13:05:00.97 8ptxnmrn.net
コマンドツールがRustになってもAPIがRust用じゃない限り
CのAPIのラッパーでしかないけどそういう造りでもRust化したってカウントして良いのかは疑問
279:デフォルトの名無しさん
25/05/08 13:09:51.90 Ad6EgOfh.net
>>274
コマンドツールが誰に対するAPI？？
プログラムを書いたことないのかな？
280:デフォルトの名無しさん
25/05/08 15:06:07.28 a6DlXdfJ.net
こういうのってFedoraやらArchやらGentooあたりが人柱やってから普及していくものだと思ってたが…
Canonicalのくせに思い切ったことするなあ
281:デフォルトの名無しさん
25/05/08 15:26:10.55 n2pO1y9P.net
Ubuntuはカジュアル路線でしょ
初期状態だとrootも使えなかったと思う
他よりもsudoの負荷が大きい
282:デフォルトの名無しさん
25/05/08 18:54:46.08 gU6gKsMd.net
5chは真の漢が使う言語perlで書かれている
283:デフォルトの名無しさん
25/05/08 21:50:58.54 Ad6EgOfh.net
5chはperlだけでなくサーバも貧弱なのでキャッシュしてくれるCDNに頼らないと成り立たない
5chが利用しているCDNは>>273のCloudflareでRust製だよ
284:デフォルトの名無しさん
25/05/09 00:22:05.59 tlxkaAFs.net
>>279
誰が見てもただの印象操作
子供でも分かる
285:デフォルトの名無しさん
25/05/09 00:29:31.48 2I38bFbw.net
5chどうこうよりも
インターネットを支えるCDN世界トップシェアのCloudflareがRust化したインパクトが大きいよな
286:デフォルトの名無しさん
25/05/09 00:31:49.35 tlxkaAFs.net
そういう幼稚な書き込みはやめとけよｗ
287:デフォルトの名無しさん
25/05/09 07:07:43.56 rj7v79QA.net
もう見抜けない、最先端のAIディープフェイク動画は心臓の鼓動まで再現、判別が困難に
2025-05-08
URLﾘﾝｸ(karapaia.com)
288:デフォルトの名無しさん
25/05/09 08:08:28.79 oZuZXuL3.net
クラウド界トップのAWSもRust製に
289:デフォルトの名無しさん
25/05/09 10:14:04.36 52E7/scg.net
AWSのプラットフォームはほぼJavaでしょ
ハードウェア寄りのローレベルな部分だけシステムプログラミング言語を使っていて、更にその中の一部でRustを使っているものもある、という程度
290:デフォルトの名無しさん
25/05/09 11:14:51.12 OK+uD+G+.net
URLﾘﾝｸ(japan.zdnet.com)
2022-02-22 14:31
Amazon Web Services（AWS）は、同社のエンジニアたちがプログラミング言語「Rust」を使っている大きな理由として、エネルギー効率の高さを挙げる。
Rustはメモリー安全性を高め、セキュリティ関連の不具合を減らす役に立つだけでなく、PythonやJavaよりもはるかに「エネルギー効率に優れている」という。
Amazonは、2025年までにデータセンターの100％を再生エネルギーでまかなうという目標を掲げ、データセンターの環境負荷の軽減に取り組んでいる。
Rustの採用はその一翼を担うという。
Rustで構築されたAWSサービスの例としては、コンテナーアプリ用のサーバーレスプラットフォーム「Lamba」を支える「Firecracker」、「Amazon Simple Storage Service（S3）」「Amazon Elastic Compute Cloud（EC2）」、コンテンツ配信ネットワーク「Amazon CloudFront」、LinuxベースのコンテナーOS「Bottlerocket」がある。
291:デフォルトの名無しさん
25/05/09 11:17:44.85 /9qtDNkV.net
大半は既存のソフトウェアの組み合わせなんで、仮に自社内で書いているプログラムの全てを Rust で書いても割合としては数割ってところだろう。
ただ、これから割合が増えることはあっても減りはしないとは思う。
292:デフォルトの名無しさん
25/05/09 11:50:43.35 OnJLIdRJ.net
Rustがこのままオワコンになったら撤廃もあり得るだろ
293:デフォルトの名無しさん
25/05/09 11:56:12.65 Olh4o+f/.net
AWSもRust製か
Rust製のクラウドとJava製のクラウドが競争したらJava側が100%負けるだろうしな
294:デフォルトの名無しさん
25/05/09 12:53:15.09 84hPiMCY.net
クラウドってなに？
ハイパーバイザがrustで作り直されたの？
295:デフォルトの名無しさん
25/05/09 14:06:44.17 uNK6cNVH.net
>>286
これは誤訳
原文だと、それらのサービスにRustを使っていると書かれているだけ
RedditなんかでAWS社員のコメントとか探してみりゃわかるが、AWSは基本Java
296:デフォルトの名無しさん
25/05/09 15:01:02.33 tXd4RgSB.net
エネルギー効率に劣るJavaなんかで構築していたら笑うわ
>>286でもそう書いてるよな
297:デフォルトの名無しさん
25/05/09 15:25:02.70 61qYlkzR.net
Rustって人気なのね
AIにC#から移植できる？って聞いてみたらいやだって言われちゃったからRustが広まるの、なんか困る
298:デフォルトの名無しさん
25/05/09 15:30:45.33 EODoJGlX.net
JVM前提な特殊環境を除き
Rustの登場でJavaを使う意味は全くなくなった
299:デフォルトの名無しさん
25/05/09 15:41:48.51 xdbk/Yg/.net
何の前提も縛りも無い環境こそが特殊
300:デフォルトの名無しさん
25/05/09 15:59:06.67 U8gSLCWq.net
コンテナ化は Java の有力なメリットだったけど Docker の隆盛で様変わりしちゃったね。
301:デフォルトの名無しさん
25/05/09 18:53:55.90 lGkzhvel.net
>>293
いやだと言うAI、なんかいいな
302:デフォルトの名無しさん
25/05/09 22:11:52.71 dSLYIzJ3.net
>>291
サービス提供には安全性が一番重要なのでC++ではなくJavaを採用していた
Javaより安全で性能の良いRustが出現したため切り替えた
そしてAWSが発起人となってRust Foundationを設立した
303:デフォルトの名無しさん
25/05/10 00:48:13.31 tNjV2wjQ.net
Rustで戦う領域ではない気もするけど、エンタープライズ向けはまだ弱いと思う
ここはまだJavaや.NETの資産が大きい
「ファイルが見つかりません」みたいにユーザーの言語でエラーメッセージが出たり、文字列のソート (例えば「あアいイ」のように、ひらがなカタカナを考慮した自然な順になる) だったり、そういうのが外部ライブラリ無しで揃ってるのが Java や .NET なわけで
規模としては相対的に小さくなってるけど、こういうのが必要な領域は普通にあるし、Javaが消えることは無いと思う