Rust part24

1 名前：デフォルトの名無しさん mailto:sage [2024/05/27(月) 06:41:26.82 ID:T4AFD1f4.net] 公式 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 part23 https://mevius.5ch.net/test/read.cgi/tech/1708677472/ 348 名前：デフォルトの名無しさん mailto:sage [2024/06/24(月) 18:44:46.10 ID:jX1oxSab.net] 一般的には、次のように書けると思うわ: a=2*(x-2)(x-3)+1*(x-1)(x-3)+3*(x-1)(x-2); b=(x-2)(x-3)+(x-1)(x-3)+(x-1)(x-2); y=a/b; 349 名前：デフォルトの名無しさん mailto:sage [2024/06/24(月) 19:35:34.10 ID:maSlaTHT.net] >>340 合っているかどうか以前に プログラムコードで回答しないとスレ違い 具体的な数値例が式やコードに含まれるのは望ましくない 出来上がった関数の動作検算の時に具体的な数値例を用いる 350 名前：デフォルトの名無しさん mailto:sage [2024/06/24(月) 23:33:41.46 ID:FIb4AZ4T.net] >>328-329 なんかダサい https://paiza.io/projects/uc8gH6yNWCWKdQSYtqNREg pub fn f(x: i32) -> i32 351 名前：{ ( -2413f64*(x.pow(6) as f64)/120960f64 +739f64*(x.pow(5) as f64)/1260f64 -157991f64*(x.pow(4) as f64)/24192f64 +69551f64*(x.pow(3) as f64)/2016f64 -2691673f64*(x.pow(2) as f64)/30240f64 +88679f64*(x as f64)/840f64 -905f64/21f64 +0.5) as i32 } pub fn g(y: i32) -> i32 { ( 13f64*(y.pow(6) as f64)/120960f64 -(y.pow(5) as f64)/315f64 +1415f64*(y.pow(4) as f64)/24192f64 -1511f64*(y.pow(3) as f64)/2016f64 +144793f64*(y.pow(2) as f64)/30240f64 -3053f64*(y as f64)/280f64 +185f64/21f64 +0.5) as i32 } pub fn main() { let a = vec![(1, 2), (2, 1), (3, 3), (4, 10), (6, 4), (8, 8), (10, 6)]; for (x, _y) in &a { println!("{}, {}", x, f(*x)); } for (_x, y) in &a { println!("{}, {}", y, g(*y)); } } [] [ここ壊れてます] 352 名前：デフォルトの名無しさん [2024/06/24(月) 23:39:26.44 ID:FIb4AZ4T.net] 係数はこっちで求めたでござる https://paiza.io/projects/YvPFB5g4cCOtCXz1wpA86g import sys, os from functools import reduce import sympy as sy def lc(a): x, y = sy.symbols('x y') p = 0 for i, (c, d) in enumerate(a): g = reduce(lambda s, t: (t[0], (s[1][0] * (1 if t[0] == i else (x - t[1][0])), 0)), enumerate(a), (-1, (1, 0))) f = g[1][0] p += d * f / f.subs(x, c) print(p) print(p.expand()) for c, d in a: print(p.subs(x, c), p.subs(x, c) == d) if __name__ == '__main__': lc([(1, 2), (2, 1), (3, 3), (4, 10), (6, 4), (8, 8), (10, 6)]) lc([(2, 1), (1, 2), (3, 3), (10, 4), (4, 6), (8, 8), (6, 10)]) 353 名前：デフォルトの名無しさん mailto:sage [2024/06/25(火) 01:47:22.24 ID:SRTwQJBb.net] 1〜10は4bitに収まるから64bitのシフト演算と論理積（&）がOKなら簡単なんだけどな やることはテーブル参照と変わらんけど 354 名前：デフォルトの名無しさん mailto:sage [2024/06/25(火) 02:44:46.88 ID:MBITUZQb.net] >>332 Rustを習得する上でC++の知識は不要 Cでの基礎知識(ポインタ、スタック、ヒープ)しか必要としない >>343 ここはRustのスレだ 355 名前：デフォルトの名無しさん mailto:sage [2024/06/25(火) 05:16:25.10 ID:6VG6SXsU.net] >>342 6次式を使う場合それを展開することに意味があると思えないから展開前の>>336でいいんじゃない？ 356 名前：デフォルトの名無しさん mailto:sage [2024/06/25(火) 07:25:12.24 ID:H43UHQbv.net] >>346 ほぼ定数になる部分まで 実行時に二重ループで毎回計算してるのは効率悪いと思う 357 名前：デフォルトの名無しさん mailto:sage [2024/06/25(火) 07:47:56.32 ID:hXiD4muz.net] >>345 っ move semantics っ RAII っ SmartPointer(Rc) 358 名前：デフォルトの名無しさん mailto:sage [2024/06/25(火) 08:03:22.73 ID:ZJws2e45.net] >>348 そりゃすでにC++を知っているならそのへんの知識が流用できて楽だけど 新たに学ぶならわざわざC++を経由する必要なくね？ 特にmoveとか明らかにC++のほうが複雑だし 359 名前：デフォルトの名無しさん mailto:sage [2024/06/25(火) 08:54:41.29 ID:Lgitw8zf.net] お題スレが機能しなくなってゴミがあふれてきてんのかこれ？ 360 名前：デフォルトの名無しさん [2024/06/25(火) 09:00:44.98 ID:ZTu14b8J.net] >>349 c++通らなきゃなんでこんなめんどいことするか理解できんだろ 361 名前：デフォルトの名無しさん mailto:sage [2024/06/25(火) 09:03:31.00 ID:9+k+boDP.net] 「アセンブラ知らずにCって理解できるものなのか？」 ↓ 「C++の方が普通。Cは専門家向け」 ↓ 「いきなりRust」 362 名前：デフォルトの名無しさん mailto:sage [2024/06/25(火) 09:25:46.54 ID:eEyTJz94.net] オレはPHPからRustに移行したよ actix web使ってる 速さには感激してる 戸惑うのは謎のワーニングが出る時かな mut付けてないのにmut付けるなってワーニング出たりする cargo cleanとかすれば消えるんだけど 363 名前：デフォルトの名無しさん mailto:sage [2024/06/25(火) 09:32:01.85 ID:GyGy4ZSw.net] >>351 Cでmalloc/free手書きしたりSEGV起こすだけで十分理解できると思うけどなぁ C++じゃないとダメなのってどのへん？ 364 名前：デフォルトの名無しさん mailto:sage [2024/06/25(火) 10:36:22.38 ID:398g93Vj.net] >>348 その3つはどの言語から来ても簡単にすんなり理解できるでしょ >>353 PHPから来た人はジェネリクスはすんなり理解できるものなの？ 365 名前：デフォルトの名無しさん mailto:sage [2024/06/25(火) 11:03:26.31 ID:eEyTJz94.net] >>355 ジェネリクスが特段わかりずらいとは思わなかった それより型があいまいなPHPから移行すると型定義したくてうずうずする ちゃんと型定義したかったんだわ 366 名前：デフォルトの名無しさん mailto:sage [2024/06/25(火) 11:48:25.07 ID:EN7MeMPi.net] C++ を知っていると Rust がわかりやすいというよりも有難みを感じやすいとは思う。 なんだかんだで Rust は面倒くさいしそれなりに学習曲線の急上昇もあるのは本当だけど、 それでもなお Rust が良いと思えるのは C++ の駄目な部分についての反省が入ってるから。 C++ 的なものが必要な場面で C++ より上手くやるものという感覚で捉えてる。 367 名前：デフォルトの名無しさん mailto:sage [2024/06/25(火) 12:43:05.46 ID:qH1sgo3/.net] 「Rustを学ぶためにC++を学ぶ必要があるか(学ぶといいか)」も定期的に沸くな 何度も見てて思うのが 「あなたはRustを学ぶ前にC++を学んでいたか」とYes/Noが一致して、平行線にしかならない議論なのでは 368 名前：デフォルトの名無しさん mailto:sage [2024/06/25(火) 13:05:45.82 ID:ZtCD4zFU.net] フランス語を学ぶときに英語を知ってる必要があるか(學ぶといいか)を考えれば良い 日本語←→フランス語だけ教わりたいのに英語學ぶ必要は無い 369 名前：デフォルトの名無しさん mailto:sage [2024/06/25(火) 15:05:50.09 ID:UfTXO4rA.net] Rustを学ぶ前に他言語を学ぶ必要は無い。 しかしプログラム自体の経験が浅いのなら、絶壁の学習曲線に挫折する可能性が高い。 そういう初学者はRusuではなく、とりあえずは動くところまで持っていきやすい言語を使って勉強したほうがいい。 370 名前：デフォルトの名無しさん mailto:sage [2024/06/25(火) 15:23:35.53 ID:bjcoCLHQ.net] C++を経由しないでRustを使えてる人たちがたくさんいることから C++が不要言語であることは間違いない 371 名前：デフォルトの名無しさん mailto:sage [2024/06/25(火) 15:29:24.75 ID:ZtCD4zFU.net] >とりあえずは動くところまで持っていきやすい言語 Rustも変な事しなければとりあえずは動く C/C++みたいに一見動いてるフリしてメモリ壊してたりに気付かない方が有害 372 名前：デフォルトの名無しさん mailto:sage [2024/06/25(火) 16:22:38.23 ID:EN7MeMPi.net] それはプログラミングに慣れてるから言えることで、 エラーになってくれることが心底から有難いことだと思えるのは エラーにならずにぶっ壊れる体験を通してじゃないと無理だよ。 結果的にわかりやすいかどうかの話じゃなくて 学習する当人がちゃんと納得して学習し続けられるかというモチベーションの話としてね。 373 名前：デフォルトの名無しさん mailto:sage [2024/06/25(火) 16:57:26.38 ID:bjcoCLHQ.net] Cでmalloc/free面倒とか忘れたとか解放したのにポインタ残っていて使っちゃったとか体験しておいたほうがよいかもしれないが C++は不要 374 名前：デフォルトの名無しさん [2024/06/25(火) 17:23:57.01 ID:jUYULW90.net] >>363 つまり最初はPerlが良いってことか 375 名前：デフォルトの名無しさん mailto:sage [2024/06/25(火) 17:55:00.58 ID:EN7MeMPi.net] 初心者レベルだと C/C++ もRust も向いてないって話 376 名前：デフォルトの名無しさん [2024/06/25(火) 19:32:04.37 ID:l0yCAl6v.net] そう言えばHaskell難しい言うやつも似たようなこと言ってたな。 そんなに難しいと感じてなかったから不思議だったんだが、 自分でバグ作っておいて言語が難しいとか言うなよ…。 377 名前：デフォルトの名無しさん mailto:sage [2024/06/25(火) 20:03:41.12 ID:qH1sgo3/.net] ID:ZtCD4zFU ID:bjcoCLHQ 378 名前：デフォルトの名無しさん mailto:sage [2024/06/25(火) 20:13:30.50 ID:urOX5j9P.net] 関数型言語を使ってるとRustの理解が少し早くなるよ 特にHaskellを知っていればtraitの理解も早いね しかしRustを学ぶために関数型言語を知っている必要はないんだよな 同様にC++も知っている必要はない 379 名前：デフォルトの名無しさん [2024/06/25(火) 22:48:01.04 ID:3rDdWdgz.net] Erlang使ってて良かったと思った 380 名前：デフォルトの名無しさん mailto:sage [2024/06/25(火) 23:04:44.45 ID:8sxbkiyD.net] バレおじw 381 名前：デフォルトの名無しさん mailto:sage [2024/06/25(火) 23:30:51.26 ID:oKw2Pfcc.net] >>347 展開しないほうがよい 展開する時も二重ループは発生するだけでなく単なる計算より重い さらに本来は回避できる浮動小数点を使わざるを得なくなる そして>>342のコードをその例のような静的ではなく問題入力値に応じて動的に作り出さなければならない 一方で展開しないならばRustコード数行だけで済み任意の問題に対応できる 割り算部分も0/N=0かN/N=1だけなので整数で済む 382 名前：デフォルトの名無しさん mailto:sage [2024/06/25(火) 23:49:25.06 ID:ThxORcgc.net] >>369 >特にHaskellを知っていればtraitの理解も早いね これには全く同意できない type classというかHaskellとはやり方もできることも違いすぎるから そもそも何の事前知識なくてもtraitは容易に理解できるでしょ 383 名前：デフォルトの名無しさん [2024/06/26(水) 08:25:01.52 ID:egC8x8gn.net] 神 精霊 絶大なエネルギーを使用可能 幽霊 人間を疲れさせるや一時操作可能 �@エネルギーの貯蔵の仕方は➁そのエネルギーの発生方法は�Bそのエネルギーを貯蔵する方法は�Cそれだけのエネルギーの物体を科学で観測不能はなぜ 6G通信に使われるテラヘルツ帯の電波、脳細胞の成長を促進 2022/08/16 タンパク質の操作／マイクロ波等の照射が記憶に影響 2008/11/01 男性の精子の減少、携帯電話の使用と関係か 最新研究 2023/11/02 統合失調症.発達障害.各身体症状 など国力低下 人為的で身体攻撃 威力を測定すれば判明するのにテロリストを野放し 全ての精神病 �@　英キングス・カレッジ・ロンドンをはじめとするグループは、人間の脳内で発現している古代ウイルス由来のDNA配列を調べ、それがうつ病・統合失調症・双極性障害といった主要な精神疾患のなりやすさと関係していることを明らかにした。 ➁九大、後の出来事が直前の出来事に錯覚を起こさせる脳の仕組みの一端を解明 2024/06/05 �C幼児期の脳活動から18歳時点でのIQを予測できるという研究結果 2023/09/09 �D3歳までに脳は形成される �E統合失調症などの患者に幻覚や妄想を引き起こす脳のネットワークがAIを使った研究で明らか 1立方ミリメートルの脳の断片をハーバード大学とGoogleの研究者がナノメートル単位で3Dマッピングすることに成功 2024年05月10日 ※MRIで物理的に神経の接続問題観測可能 嘘つきの知的障碍者と精神障碍者や認知症の者発見 ◇電磁波攻撃はあるとないどの思考【組織】の者が話しているのかな マイクロ波聴覚効果やボイス・トォ・スカル発見可能 電磁波している者守りたいもの守りたくないものの判別 384 名前：方法は各対象者の将来で名よある地位やよい未来の映像と悪い未来の映像を見てもらえば副交感神経と交感神経の差と脳波パターンをみたら判明する [] [ここ壊れてます] 385 名前：デフォルトの名無しさん mailto:sage [2024/06/26(水) 12:30:12.07 ID:j6fp+f8B.net] >>372 >割り算部分も0/N=0かN/N=1だけなので整数で済む そうだね この問題の本質はそこだと思うけどそれ言い出すとif使わない理由が無いな 386 名前：デフォルトの名無しさん mailto:sage [2024/06/26(水) 12:31:27.14 ID:j6fp+f8B.net] >>373 事前にやるならNimの方が良いよ 387 名前：デフォルトの名無しさん mailto:sage [2024/06/26(水) 13:01:41.83 ID:eR4cI6Xf.net] Rustを学ぶ前に他の言語を学ぶ必要はないけど 全くプログラミング言語を知らないならシンプルで学習例も多いC言語一択だね ポインタとヒープの扱いまで学べたらたらC言語を忘れてRustへ 388 名前：デフォルトの名無しさん [2024/06/26(水) 14:31:44.00 ID:uKek7pO0.net] デストラクタの動きを知らないで本当にrustできんの？って思うけど 389 名前：デフォルトの名無しさん mailto:sage [2024/06/26(水) 14:43:55.70 ID:eR4cI6Xf.net] スコープを抜けた時にデストラクタが自動的に呼ばれる それだけ 予備知識を必要としない 390 名前：デフォルトの名無しさん mailto:sage [2024/06/26(水) 14:54:42.66 ID:j6fp+f8B.net] Rustのデストラクタの描き方ってなんであんなんなん 391 名前：デフォルトの名無しさん mailto:sage [2024/06/26(水) 15:00:49.20 ID:KtPyzxFO.net] C書くしかない時代だったからC勉強できたけど Rustがある時代に純粋な教養としてC勉強なんて苦行できないだろ 修行僧かよ 392 名前：デフォルトの名無しさん mailto:sage [2024/06/26(水) 15:13:01.92 ID:UcL9V/nx.net] 最近気付いたんだけどもしかしてRustの所有権って2通りの意味がある？ 393 名前：デフォルトの名無しさん mailto:sage [2024/06/26(水) 17:42:24.19 ID:AVbFTHWJ.net] >>382 そのココロは？ 394 名前：デフォルトの名無しさん mailto:sage [2024/06/26(水) 18:05:02.22 ID:tR/OTOKs.net] >>378 それってc＋＋学ぶときも一緒じゃない？ 395 名前：デフォルトの名無しさん mailto:sage [2024/06/26(水) 20:50:33.32 ID:mzS1vumz.net] >>382 Rustを学ぶ上で所有権は忘れた方がいい 実はRustは非常にシンプルで 値をmoveして用いるか参照して用いるかしかない (ただしCopy実装型はmoveの代わりにcopy) 値はmoveされないままスコープが尽きると消える 消える直前にデストラクタが呼ばれる 以上たったこれだけだ 396 名前：デフォルトの名無しさん [2024/06/26(水) 23:00:32.38 ID:GOea043w.net] >>381 苦行はごちゃごちゃして煩わしい記述を強要されるRustだろ。fnだのmutだの略語が多く 殺伐としているし、記号の使い方なども含めて如何にもギークが作ったというような 美的感覚が欠如した野暮ったいコードを書き連ねるのはおぞましい。 Cと違って新しいSwiftはRustに機能的に近いが、Rustよりずっと洗練されている。 397 名前：デフォルトの名無しさん mailto:sage [2024/06/26(水) 23:26:44.75 ID:skjSHmL1.net] Rust言語を知らないから見た目のキーワード批判しかできないのだ 398 名前：デフォルトの名無しさん mailto:sage [2024/06/27(木) 04:20:04.01 ID:nawTLqWn.net] スタックは早くてヒープは遅い、みたいな話よく聞くんだけど、 具体的に何が早い/遅いの？ 399 名前：デフォルトの名無しさん mailto:sage [2024/06/27(木) 04:33:33.49 ID:TDzAch9x.net] >>388 自分でヒープメモリ管理部分を書いてみるとよくわかる ヒープでメモリ確保したり解放したりするのは色んな処理が入って非常に遅い スタック上ならそのコストはない 関数に入る＆抜けるときにスタックフレームを指してるレジスタの値を変えるだけ というのに加えて CPUの多段メモリキャッシュ機構での速さが桁が変わってくる スタックフレーム上なら常にアクセスしていてキャッシュに載るから超速い 400 名前：デフォルトの名無しさん [2024/06/27(木) 07:18:32.22 ID:CXekxx/V.net] >>386 mutが煩わしい言うてる時点で関数型プログラミングをまともに出来てないな。 今までの副作用だらけの言語だとマルチスレッドプログラミングが上手く出来ないから関数型プログラミングを取り込んだというのに。 Rustでごちゃごちゃしてると感じるならHaskellにおいで。 forやifと書くことすら煩わしく感じるくらいシンプルだよ。 401 名前：デフォルトの名無しさん [2024/06/27(木) 08:56:33.16 ID:ozUuBzDI.net] Swift、よく知らないんだよなあ Appleの囲い込み言語という時点でもう勉強する気になれない 402 名前：デフォルトの名無しさん mailto:sage [2024/06/27(木) 09:08:39.14 ID:AKJ8/1zo.net] C++ でも変更なしのときに const を付けるんじゃなくて変更ありのときに指定するほうがよかったという声は結構あるよな。 まあいまさら変更できんが。 403 名前：デフォルトの名無しさん mailto:sage [2024/06/27(木) 09:50:18.20 ID:OTNDZ+yC.net] >>372 PyO3おすすめ 404 名前：デフォルトの名無しさん [2024/06/27(木) 10:07:28.99 ID:OTNDZ+yC.net] >美的感覚が欠如した野暮ったいコード 禿しく同意 405 名前：デフォルトの名無しさん mailto:sage [2024/06/27(木) 10:21:46.91 ID:nawTLqWn.net] >>389 キャッシュに乗るという前提なら、 確保・解放が遅いだけでアクセス速度とかは変わらないってことでOK？ キャッシュに乗る確率とかもスタックとヒープでやっぱちがうんかな 406 名前：デフォルトの名無しさん mailto:sage [2024/06/27(木) 10:30:52.47 ID:OTNDZ+yC.net] キャッシュに載ったらアクセス速度変わるやろ 407 名前：デフォルトの名無しさん mailto:sage [2024/06/27(木) 10:33:46.61 ID:xhKCtT/7.net] そりゃ、キャッシュ・イズ・キングと言うぐらいだからな 408 名前：デフォルトの名無しさん mailto:sage [2024/06/27(木) 11:05:58.76 ID:AKJ8/1zo.net] >>395 キャッシュに乗りやすいというのはアクセスに局所性があるということ。 関数自体が小さくてすぐ終わるなら普通はスタックのほうが以前と近い場所にアクセスすることになる。 409 名前：デフォルトの名無しさん mailto:sage [2024/06/27(木) 11:20:07.91 ID:veLj9zg3.net] よくわかんないんだけどスタック上に確保したメモリの所有権を外に移して関数は終了してスタックが縮んじゃうとかさ 「そんなわけないだろ」って思うんだけど 410 名前：デフォルトの名無しさん mailto:sage [2024/06/27(木) 11:56:53.85 ID:TDzAch9x.net] >>395 スタックフレーム同士も連続しているし レジスタ退避でアクセスしているし 他のローカル変数もスタック上にありアクセスしているから スタック上に確保すればキャッシュ上にある 411 名前：デフォルトの名無しさん mailto:sage [2024/06/27(木) 12:00:05.74 ID:TDzAch9x.net] >>399 関数が値を返す場合にサイズが小さければレジスタで返す サイズが大きい場合は呼び出し元のスタックフレームに領域を確保してそこへ直接書き込んでいる つまり暗に可変参照を渡す最適化が行われている それはサイズの大きい値を返す関数呼び出しが多段でも同じなので一番最初の関数のスタックフレームに直接書き込まれる 412 名前：デフォルトの名無しさん mailto:sage [2024/06/27(木) 12:27:57.71 ID:OTNDZ+yC.net] >>399 >「そんなわけないだろ」 その感覚は正しい Rustを広めたいために勢い余ってデマを流してる香具師が一定数いる >>401 が正しい 413 名前：デフォルトの名無しさん mailto:sage [2024/06/27(木) 12:45:47.11 ID:VTKaeii9.net] >>399 >よくわかんないんだけどスタック上に確保したメモリの所有権を外に移して関数は終了してスタックが縮んじゃうとかさ これ自体なにを言いたいのかよくわからんけど その前にそんなこと言ってるやつおる？ >>400 >スタック上に確保すればキャッシュ上にある キャッシュから追い出される状況もあるよね 414 名前：デフォルトの名無しさん mailto:sage [2024/06/27(木) 12:53:21.92 ID:TDzAch9x.net] >>402 いや>>399の話も正しいんだよ 重要なのはRust上の概念とその実現方法(実装)とその最適化の3つは当然異なるということ 所有権を移すとはmoveという概念であって moveの実装はコピー(してコピー元を使わない) ただし無駄なコピーは最適化で消える 例えば大きなサイズの構造体を関数が返す場合は呼び出し元の関数のスタックフレーム上に直接書き込まれることで無駄なコピーが発生しない 415 名前：デフォルトの名無しさん mailto:sage [2024/06/27(木) 13:06:53.73 ID:VTKaeii9.net] それをスタックが縮むと表現してるのか 意味は分かった 416 名前：デフォルトの名無しさん mailto:sage [2024/06/27(木) 13:24:58.99 ID:veLj9zg3.net] スタックてのは関数が何段か終了して縮んだあと、また伸び直して前の伸びを上書きしちゃうでしょって話 とにかく「移動」というのが新しくて、代入の移動はわかったけど 関数呼び出しの引数も移動です、返り値も移動ですってのがどういう実装に落とされるのかまだわかってない 417 名前：デフォルトの名無しさん mailto:sage [2024/06/27(木) 13:49:01.55 ID:AKJ8/1zo.net] 低レイヤで起こってることは C と変わらん。 寿命の矛盾がないか静的な検査がクソ強いってだけだ。 418 名前：デフォルトの名無しさん mailto:sage [2024/06/27(木) 15:56:45.17 ID:AKJ8/1zo.net] スタックを伸ばすだの縮めるだのいうのはメモリのとある番地に実際のメモリを割り当てたり切り離したりすること。 スタックが足りなくなってきたら連続するアドレスのところに実メモリを割り当てるのがスタックを伸ばすってこと。 普通の使い方をしていたらスタック領域を縮めることはあんまりない。 スタックがあるところまで伸びたということはもう一度そこまで伸びる可能性が高いので回収してまた割り当ててをするよりは割り当てっぱなしにしたほうが良いという設計思想になってるので全体のメモリが足りている限りスタックが浅いところまで戻ってきても実メモリを回収しないという のが現代的な OS。 逆に言えば全体のメモリが足りなくなってきたら回収することもあるんだけど。 素人感覚だとメモリをなるべく空くようにするのが「メモリの無駄を防ぐ」という意識の人がいるんだけど、存在するメモリが使われないままになってるほうがもったいないんだ。 それとたとえば Linux だとスタックの大きさは 8MB が上限というのがデフォ。 これは OS 側の設定なのでアプリケーション側では (OS の設定をいじる権限がない限りは) どうにもできない。 8MB ってめちゃくちゃ少ないように感じるかもしれないけどだいたいこんなもんで足りちゃうんだよ。 419 名前：デフォルトの名無しさん mailto:sage [2024/06/27(木) 16:39:29.50 ID:EaS5WQGi.net] >>406の書いてる「縮む」はVecで言うところのcapacityじゃなくてlenっぽくない？ ムーブとの関連がよくわからんけど 420 名前：デフォルトの名無しさん [2024/06/27(木) 17:46:10.67 ID:6+Lg0PcZ.net] >>407 ですな 421 名前：デフォルトの名無しさん mailto:sage [2024/06/27(木) 17:59:42.80 ID:AKJ8/1zo.net] 低レイヤのメモリの取り扱いモデルが確立している高級言語が C/C++ くらいしかなくて、 LLVM も汎用的なフレームワークのふりして思ったほど自由ではないので Rust の言語仕様が LLVM の都合に、 C/C++ の都合に引っ張られているところはまあまあある。 422 名前：デフォルトの名無しさん mailto:sage [2024/06/27(木) 18:20:02.76 ID:veLj9zg3.net] つまりC++同様、ポインタの糖衣構文としての参照？ 423 名前：デフォルトの名無しさん mailto:sage [2024/06/27(木) 18:50:13.20 ID:veLj9zg3.net] あ、なるほど &mutみたいに*mutって書けば実体を扱えるわけか 424 名前：デフォルトの名無しさん mailto:sage [2024/06/27(木) 18:56:27.59 ID:RLHdjniL.net] いつものことながら妙なこと書く人はだいたいThe Book(本物)を読んでないよな 425 名前：デフォルトの名無しさん [2024/06/27(木) 19:07:01.79 ID:inDwmtnT.net] そんなの読むような真面目な人間は5chに来ない 426 名前：デフォルトの名無しさん mailto:sage [2024/06/27(木) 20:08:52.27 ID:AKJ8/1zo.net] >>412 まあ機械語レベルの低レイヤまでいけば参照もポインタも同じっちゃおなじだけど、構文糖だという認識は明確に誤りだ。 参照がポインタの構文糖なんて書いてあるデタラメ本で C++ を学んだのなら C++ の理解も全然できてないと思う。 または書いてないことを脳内で作り出すタイプのやつは誤った方向に邁進してどうにもならなくなったところで質問したりするから言ってることが意味不明になりやすい。 仮に(あくまでも仮にだが！)言ってる理屈自体が正しかったとしてもちゃんとした用語でいってくれないと伝わらないし、ちゃんとした用語は(一次資料に基づいた)ちゃんとした資料で学ばないと身に付かん。 427 名前：デフォルトの名無しさん mailto:sage [2024/06/27(木) 22:40:30.91 ID:TDzAch9x.net] >>406 そのmoveについてもmoveというRust上の概念の理解のみがRustを学習＆利用していく上で必要となるよ moveによる生成コードがどのようになるかは最適化の方法の変更や進化で変わり得る話だから確定することはできず、学ぶこともできない こんな場合に現在はたまたまこんな生成コードになっていることだけは実験などでわかるけど今後の保証はない、としか言えない だからmoveはmoveとして理解することが唯一の正解でしょう 428 名前：デフォルトの名無しさん [2024/06/27(木) 22:43:00.49 ID:QXPbo1LF.net] どうせChatGPTの回答を使い回してるだけだろ 429 名前：デフォルトの名無しさん [2024/06/27(木) 22:45:03.57 ID:QXPbo1LF.net] >>416 C/C++でポインタのポインタと言わずに ダブルポインタって言ってる香具師のことか 430 名前：デフォルトの名無しさん mailto:sage [2024/06/27(木) 23:03:07.98 ID:TDzAch9x.net] Rustの各概念を無理矢理なC/C++と結びつけようとしたり生成コードと対応させようとしてる人々がRustを難しいと言ってるようにみえる そんなことをせずに各概念の理解だけに集中すればRustはシンプルに出来ていてわかりやすい言語だと理解できるよ 431 名前：デフォルトの名無しさん mailto:sage [2024/06/27(木) 23:34:16.52 ID:AKJ8/1zo.net] C/C++ だと抽象機械という概念を挟む形で仕様化されてる。 言語の挙動を抽象的な (架空の) 機械の動作として記述していて、それを実際の機械とどう対応させるかは知らんけど見かけ上の動作が仕様通りなら良しとする規定。 だから最適化を豪快にやっても結果が同じなら言語仕様に反しない。 で、抽象機械っていうのはある程度は現実のコンピュータを想定はしているけど細かいところは意図的にうやむやにして選択の余地を残してる。 C/C++ には言語仕様としてはスタックもヒープも存在せず書いてあるのは寿命についてのルールだけで、それをどういう形で実現するかは自由…… なんだけど現実にはスタックとヒープを使い分けるとちょうどいいような仕組みになってる。 C/C++ の言語仕様に低レイヤのメモリアクセスのことも確かに書いてあるんだ。 でもそれは抽象的な機械のことであって本物の機械のことじゃない。 でもある程度は対応しているという絶妙なバランスで成り立ってる。 Rust では言語の高レイヤの話と低レイヤの話の間を取り持つ理屈がまだ十分に整理されてないと思う。 言語の性質上、やっぱり低レイヤを全く意識しないで上手く使えるようなものでもないし、低レイヤのことを考えるのもそれなりには必要だと思う。 必要なんだけど意識的にレイヤを分けて考えられないなら混乱するのも確かなので、 (少なくとも最初は) 低レイヤのことは忘れろというのは理に適った助言だと思う。 432 名前：デフォルトの名無しさん mailto:sage [2024/06/27(木) 23:40:56.83 ID:ZCM59EGi.net] C/C++の方こそ誤魔化しているぜ そのため未定義動作だらけだ Rustはわかりやすく抽象的に明確だ そして未定義動作もない 433 名前：デフォルトの名無しさん [2024/06/27(木) 23:46:01.41 ID:AKJ8/1zo.net] 未定義動作の話をしてはいないよ。 低レイヤとの間をどう取り持つかの話をしてる。 434 名前：デフォルトの名無しさん mailto:sage [2024/06/27(木) 23:53:14.85 ID:iyfRmZdF.net] Rustは低レイヤにも対応している 高い抽象度によるプログラミングもできる 高い抽象度のプログラミングにおいて低レイヤとの対応付けは不要であってやるべきではない 435 名前：デフォルトの名無しさん mailto:sage [2024/06/27(木) 23:56:31.92 ID:lXX+GpEL.net] オジーw 436 名前：デフォルトの名無しさん mailto:sage [2024/06/28(金) 00:09:40.45 ID:uAgz1Jdl.net] >>424 その論を許すなら Rust は OS やデバイスドライバを書くのには使えない言語であってよいという立場になるが、そうじゃないよね？ 437 名前：デフォルトの名無しさん mailto:sage [2024/06/28(金) 00:16:19.92 ID:hS2q8k+h.net] >>426 なぜなの？ Rustが抽象的にプログラミングできるのも事実であるし OSやデバイスドライバを記述できるのも事実だよ 438 名前：デフォルトの名無しさん mailto:sage [2024/06/28(金) 00:20:27.61 ID:uAgz1Jdl.net] >>427 低レイヤを書くための仕様が確立していなくて今はなんとなく書けているという状態を「できる」と称していいならそうだね。 439 名前：デフォルトの名無しさん mailto:sage [2024/06/28(金) 00:28:00.38 ID:UvqDoogo.net] >>428 うーん Rustに何か欠けているわけではなく 実用的に問題なく機能している状況で 言い掛 440 名前：かりをつけてるだけにみえるけどどうよ [] [ここ壊れてます] 441 名前：デフォルトの名無しさん mailto:sage [2024/06/28(金) 00:48:52.30 ID:uAgz1Jdl.net] >>429 実用的に問題があって、機能できていない。 Rust の仕様に明るくて低レイヤのメカニズムに明るくても Rust で OS は書けないから。 現状では Rust の実装に明るいという要素が求められていて、ある程度はそういうものかもしれないけど仕様 (というか文書化というべきかな) の明確化が十分とは言えない。 442 名前：デフォルトの名無しさん mailto:sage [2024/06/28(金) 00:57:19.20 ID:UvqDoogo.net] >>430 本気で言ってるのかなあ デバイスドライバはRust製に置き換えられたよ OSもRustで新たに作られて機能することも判明してるけど 既存のOSは書き換えコストの問題だから別問題だね 443 名前：デフォルトの名無しさん mailto:sage [2024/06/28(金) 01:04:07.98 ID:0ko0Zb9B.net] そういえばRedoxの開発は今どうなってるんだろ 444 名前：デフォルトの名無しさん mailto:sage [2024/06/28(金) 01:21:44.32 ID:uAgz1Jdl.net] >>431 これからやる人に対して説明できる形になってないという話をしてる。 出来てるから出来るんだというのは何の根拠にもならんよ。 出来るようになるための道筋が確立しているかどうかの話なんだ。 445 名前：デフォルトの名無しさん mailto:sage [2024/06/28(金) 01:57:43.66 ID:/H5n5ha9.net] 流れを切って申し訳ないんだけど Rustってディープラーニングのプログラムを作るのに実用的な段階に来てる? まだ一部の物好きが書いてるだけ? 446 名前：デフォルトの名無しさん mailto:sage [2024/06/28(金) 02:39:42.33 ID:OzTZZFgl.net] 自分 Rustってディープラーニングのプログラムを作るのに実用的な段階に来てる? まだ一部の物好きが書いてるだけ? Copilot Rustでディープラーニングのプログラムを作ることは可能ですが、まだ一部のエンジニアが実験的に取り組んでいる段階と言えます。具体的には、『ゼロから作るDeep Learning』の内容をRustで実装する試みや、Deep LearningのフレームワークDeZeroをRustで実装する試みなどがあります。 これらの試みは、Pythonで書かれたディープラーニングのコードをRustに翻訳し、Rustの学習やディープラーニングの理解を深めるためのものです。しかし、これらの実装はあくまで個々のエンジニアの学習目的で行われており、一般的なディープラーニングの実装にRustが広く使われているわけではありません。 Rustはパフォーマンスが高く、メモリ安全な言語であるため、ディープラーニングの実装にも適していると言えます。しかし、Pythonのように豊富なディープラーニングライブラリが存在しないため、現状ではディープラーニングの実装にはPythonが主に使われています。 Rustでのディープラーニングの実装が一般的になるかどうかは、今後のRustコミュニティの活動やディープラーニングの研究動向によるところが大きいでしょう。 447 名前：デフォルトの名無しさん mailto:sage [2024/06/28(金) 02:47:01.21 ID:/H5n5ha9.net] >>435 さっそくの返信ありがとうございます > 今後のRustコミュニティの活動やディープラーニングの研究動向 がどうなってるかを聞きたかったんですがどんな感じですか? libtorchバインディングのtorch-rsや ほぼ純Rust製のcandleが出てきたのはわかったんですが まだ周辺ライブラリが足りない感じです? 448 名前：デフォルトの名無しさん mailto:sage [2024/06/28(金) 03:31:36.21 ID:OzTZZFgl.net] 少なくとも俺よりはAIの方が物知りだから自分でAIに聞いた方がいいと思う 449 名前： 警備員[Lv.22] mailto:sage釣 [2024/06/28(金) 03:44:03.44 ID:J0YB6tE5.net] 論文の検証を論文と異なる言語ではしないでしょぅ NCNNやDarkNetを超えるエンジンがあるわけではなし 450 名前：デフォルトの名無しさん mailto:sage [2024/06/28(金) 05:55:26.25 ID:OzTZZFgl.net] >>417 関数の引数にオブジェクト（Copy型でない型）を渡す際は参照渡しが基本で、 うっかり所有物を引数として渡すと所有権ごと関数の向こうへ移動してしまって二度と戻って来ない これは逆に、関数が何らかの実体を返り値として返す際には便利 とまあネチネチ考えてればわかってくるもんだよ 451 名前：デフォルトの名無しさん mailto:sage [2024/06/28(金) 07:54:27.71 ID:diDidYCE.net] >>422 unsafeを無視しちゃいかんよ。 452 名前：デフォルトの名無しさん [2024/06/28(金) 09:41:44.10 ID:RD8xbJnt.net] 型がガチガチの言語でdeepnetの実装するのは面倒な割に生産性薄いわ 453 名前：デフォルトの名無しさん mailto:sage [2024/06/28(金) 09:45:48.57 ID:uAgz1Jdl.net] 仕組みがまだ確立してなくて試行錯誤があるなら型で制約しまくるのは面倒なだけだけどもうそういう段階じゃないのなら型で固めたほうが (使い方の間違いが検出されやすいので) 生産性高いよ。 454 名前：デフォルトの名無しさん [2024/06/28(金) 12:27:02.70 ID:4Cbqp0xY.net] >>441 C++/C#/Javaとの比較はともかく、LLとの比較は目指すところが違うでしょ。 Rustは組み込みやOSまでカバーする言語。 医療用機器とか、自動車とか、命に関わるような分野でバグを入れないための言語なんだから。 金融も同じようなものだけど、そっちはOCamlの実績（みずほ）があるのでRustである必要は必ずしもは無い。 455 名前：デフォルトの名無しさん mailto:sage [2024/06/28(金) 13:07:10.53 ID:gx/r5usH.net] LLとかいう死語を使ってるのは複オジだけだぞ 456 名前：デフォルトの名無しさん mailto:sage [2024/06/28(金) 13:32:56.61 ID:3PtwFBGo.net] >>441 ささっと数行書くスクリプトでなければ静的型付け言語が生産性高いよ 457 名前：デフォルトの名無しさん [2024/06/28(金) 17:07:56.21 ID:v8X9ZSBd.net] うい。４０のおっさんよん(^_-) まあ、プロトタイプは動的型言語で作って、本番のコードは静的型言語で作るなんて常識なんだから、若い人じゃなければ > 型がガチガチの言語でdeepnetの実装するのは面倒な割に生産性薄いわ 何てこと書かないわな…。 458 名前：デフォルトの名無しさん [2024/06/28(金) 18:51:50.94 ID:y+eGYcxn.net] 今のご時世にプロトタイプは動的言語とか言ってるのは頭の硬いジジイか、ジジイの本でしか勉強出来ない馬鹿がほとんどなんだよなあ 459 名前：デフォルトの名無しさん [2024/06/28(金) 19:09:29.56 ID:v8X9ZSBd.net] 出来る人ならそれで良いし、それで>>441の言うように生産性が低いと感じないなら全然かまわない。 馬鹿馬鹿言うけど、そういう馬鹿にも作らせないといけないし、それでも作れない救えない奴はリストラするしか道が無い。 460 名前：デフォルトの名無しさん mailto:sage [2024/06/28(金) 19:58:03.61 ID:pImSoiYg.net] 動的型でプロトは結局本番で書き直す時間など取れないから机上の空論ってのが最近の認識では 最初から静的型にするか、どうしようもなくなるまで動的型で耐えるかの2択じゃないかな まぁたいていのスタートアップは耐えられなくなる前に潰れるからそれを見越して動的型というのはありだと思うが 461 名前：デフォルトの名無しさん mailto:sage [2024/06/28(金) 20:05:28.17 ID:3PtwFBGo.net] スタートアップ企業であろうと 動的型付け言語を使うのは開発効率が悪い 462 名前：デフォルトの名無しさん [2024/06/28(金) 20:36:15.04 ID:v8X9ZSBd.net] んー…。 おっさん的には関数単位でテスト出来るかどうかが問題であって、プロトタイプは動的か静的かの問題じゃない気がするな。 最近は静的型言語でもインタラクティブシェル（略語忘れた)のインタプリタで関数単位でプロトタイプ作ってテストして、上手くいけばビルドって流れだし。 そういうのが無い言語は今でもプロトタイプは動的言語で作って…ないわｗ 場合によるな。 すでに作り方を知ってたらいきなり静的型言語で書くし、何か思いついたけど確信が持てない。みたいな時(試行錯誤が予想される)は動的型言語でプロトタイプ書いてるかな。 (静的型言語にインタラクティブシェルが無い時) 463 名前：デフォルトの名無しさん mailto:sage [2024/06/29(土) 03:44:24.89 ID:pz5Aaald.net] Rustのメモリモデル https://doc.rust-lang.org/reference/memory-model.html 464 名前：デフォルトの名無しさん mailto:sage [2024/06/29(土) 09:52:45.11 ID:H9n2Ca7a.net] 少人数で超大規模なシステムを作るのには Common Lisp が向いてるみたいな話もある (実際に使われてる) けど、それはプログラマが超人なだけじゃないのみたいな話もあってあまり一般化した話には出来んな。 465 名前：デフォルトの名無しさん mailto:sage [2024/06/29(土) 10:24:54.66 ID:PsPEDCdZ.net] 権利あるいは義務が移動することを物理メモリで説明するのは難しいが 実行時型情報みたいにいちいちメモリを消費して情報を管理すれば 物理で説明できないこともない そのためには動的言語の知識も役に立つ 466 名前：デフォルトの名無しさん [2024/06/29(土) 11:40:57.14 ID:VzEkAlY7.net] 実際機械学習でc++でもjavaでもほとんど使われてないってのに、やっぱ静的解析バカが多いんだなここ 467 名前：デフォルトの名無しさん mailto:sage [2024/06/29(土) 12:11:39.54 ID:hrAqOO+e.net] Pythonでも”静的解析”は普通に使ってるだろw 自分が書いてる用語くらいは学んどけよww 468 名前：デフォルトの名無しさん mailto:sage [2024/06/29(土) 12:15:59.49 ID:bAOaGwrv.net] ダックタイプあれば動的でも静的でもあんまり変わらん。ビルド時間の違いくらいか。 実装初期は設計の柔軟性を確保できればいい。まぁ、アダプタでなんとかするのが妥当なところかもしれんが。 469 名前：デフォルトの名無しさん mailto:sage [2024/06/29(土) 12:40:22.21 ID:tytG9AfV.net] オーナーシップとライフタイムの関係でGC言語なら簡単なリファクタリングがRustでは大手術が必要になることがよくある 大手術すぎて根本的なリファクタリングに着手できてない例もよく見かける ここでいってるプロトタイプとは少し意味が違うがPython等でプロトタイプ作ってRust化する人がある一定程度いるのはプロトタイピング時にボローチェッカーで時間を浪費するよりも言語変えた方が効率がいいと考えられてるから この辺はRustのメリットとデメリットを考えた使い分け 470 名前：デフォルトの名無しさん [2024/06/29(土) 12:42:41.17 ID:OVmXtfXA.net] ダックタイピングがあれば良いが、Pythonのダックタイピングはライブラリの型が壊れているからダメ あと、ダックタイピングの不満を消していくとTraitになるから出来ればTraitの方が良い 471 名前：デフォルトの名無しさん mailto:sage [2024/06/29(土) 13:28:37.21 ID:7275QU0+.net] >>458 そういうRustでのリファクタリングならば大手術にならない メモリ保有を適切な位置に移したり分解したりするなどの単純なリファクタリングで済んでいる それにより保守性もデバッグ効率も上がるためリファクタリングコストは誤差に等しい 仮にGC言語で書いている時でも同様でその状態は各データが複雑に絡み合っている状態なのでリファクタリングしたほうが望ましい 472 名前：デフォルトの名無しさん mailto:sage [2024/06/29(土) 13:38:30.46 ID:xx5BdVU7.net] ダックタイピングがあるってどういう状態のことだろう 473 名前：デフォルトの名無しさん mailto:sage [2024/06/29(土) 14:06:46.53 ID:H9n2Ca7a.net] リファクタリングの原則のひとつとして外側から見たときに変わらないというのがある。 内と外を分ける境界線がどこなのかというのは場合によるので UI レベルで同じなら良しとすることもあるけど、普通は適当なモジュール単位でやるだろう。 「変わらない」ことの保証のひとつとして型やライフタイムアノテーションは頼りになるよ。 型システムがあてにならないほどの大改革ならどうせ全部書き直しなので足を引っ張られることもない。 474 名前：デフォルトの名無しさん [2024/06/29(土) 14:24:33.15 ID:lbQtaoAJ.net] Rustはリファクタリングには全く向いていない 475 名前：デフォルトの名無しさん mailto:sage [2024/06/29(土) 14:31:05.74 ID:dyJ1RvLM.net] いつも汚いコードを貼り付けてた複オジがリファクタリングは簡単などと言い張ったところで全く説得力がない 476 名前：デフォルトの名無しさん mailto:sage [2024/06/29(土) 14:38:55.22 ID:pz5Aaald.net] 数のイテレータで遊んで満足してる人に機械学習の文脈が理解できるわけないやん？ 477 名前：デフォルトの名無しさん mailto:sage [2024/06/29(土) 14:41:30.81 ID:Kxp5xIIU.net] 掲示板に貼れる程度の内容なら リファクタリングしても知れてるでしょ 478 名前：デフォルトの名無しさん mailto:sage [2024/06/29(土) 15:08:40.24 ID:BT1eNZRh.net] >>463 Rustはリファクタリングに向いている言語だよ リファクタリングで最も重要なことはその前後で同じ機能動作が保証されることだけど そこで静的型付け言語が有利なことは当たり前としてRustのアクセス競合排他原則がさらに大きく効いてるよ データ書き換え中の読み取りによるバクがリファクタリングによって入り込むことも防いでくれているね 479 名前：デフォルトの名無しさん mailto:sage [2024/06/29(土) 15:23:13.20 ID:PsPEDCdZ.net] デジタル小作人やめるレベルの大手術ではなく 地主との関係が変わらないことを保証したいんだな 480 名前：デフォルトの名無しさん mailto:sage [2024/06/29(土) 15:34:20.66 ID:KH8yb7Br.net] それまで参照を持たなかった構造体にメンバとして参照を持たせると、型にジェネリックライフタイムが付いて、その型の使用箇所全部でライフタイムを書く必要がある さらに悪いことに、実際のところこれは必要ではなく、ライフタイムを書かなくても省略されていると見なされてコンパイルが通ることもある しかしこれでは意図通りのライフタイムになっていないことが多く、その型の使用箇所を増やしたときに初めてそのことに気づくことになる Rust特有のリファクタリングしづらさは、あるよ 481 名前：デフォルトの名無しさん mailto:sage [2024/06/29(土) 15:52:41.67 ID:jlQztVvs.net] ライフタイム関連に限らずRustのリファクタリングは 他言語に比べて波及する範囲が大きくなりやすいんだよね それで作業量が多いからしんどい しんどさと難しさは必ずしもイコールではないんだけど サクサク変更できる言語を経験してると Rustのリファクタリング時には精神的なエネルギーが相当必要 482 名前：デフォルトの名無しさん mailto:sage [2024/06/29(土) 16:01:57.62 ID:obFhbebh.net] >>469 リファクタリングの作業の大きさに対して、必要なライフタイム注釈を付けるだけの些細なことが障害になったことはないな。 ライフタイム注釈が'aになるか'_になるか省略できるかは、その必要性と省略ルールに基づくだけなので、そこで問題が発生することはないだろう。 483 名前：デフォルトの名無しさん mailto:sage [2024/06/29(土) 16:03:28.89 ID:obFhbebh.net] >>470 Rustでは様々なことをコンパイラチェックに任せられるため、リファクタリングで最も崩れにくく、人間の負担は他より小さい。 484 名前：デフォルトの名無しさん mailto:sage [2024/06/29(土) 16:10:10.85 ID:FxtNCeeF.net] 糠に釘 暖簾に腕押し 複オジにRust 485 名前：デフォルトの名無しさん mailto:sage [2024/06/29(土) 16:52:22.95 ID:KH8yb7Br.net] >>471 「ライフタイム注釈が'aになるか'_になるか省略できるか」は、すべての使用箇所ごとに以下を検討したうえで決まる * 追加するライフタイムは既存のライフタイムと同じであるべきか * 既存と同じであるべきでないなら、そのライフタイムはどこで宣言すべきか（impl? fn? トレイトや構造体?） それで1つの型がリファクタリングできたところで、 * トレイトや構造体にジェネリックライフタイムパラメータを追加した場合、そいつにも同じ作業がいる。最初から繰り返し ここまでのすべての作業に尋常でない集中力が必要になる 繰り返しの中でライフタイムの宣言箇所の選択が誤っていたことに後で気づいたりすると悲惨だ 「エラーのあるコードをgit commitしない方が良い」という思い込みを捨て、選択を必要とするタイミングでgitに記録するようにして、 作業効率は安定はするようになったが、それでも作業を捨てるというのは気が滅入る 「あ、この関数の引数にライフタイム追加することになるけど、後で戻り値にもライフタイム追加することになるな」なんて思っても一挙に作業してはいけない 少なくとも自分の頭では作業の段取りを崩すだけだった そしてここまでを全集中して完了してコンパイルを通すところまで持って行けても、クレート外の使用箇所でおかしなことにならないことは保証できない ボローチェッカーは書かれている使用法が妥当であるかどうかしか検証しないからだ こっちは体験談として言っているんだから、机上の空論を弄するのはもうやめなさい 486 名前：デフォルトの名無しさん mailto:sage [2024/06/29(土) 16:58:20.78 ID:KH8yb7Br.net] Rustはライフタイムさえ正しく書けていれば本当に有用な助けを与えてくれる しかしライフタイムを正しく書くための助けはほとんど与えてくれないので、自分で書く必要があるときには上と同じような期待をしてはいけない 487 名前：デフォルトの名無しさん [2024/06/29(土) 16:59:51.95 ID:TiydCxUm.net] 知ったかぶりして間違ったこと書く やんわり間違いを指摘される 反省せずに開き直る！ またこの流れ ググればすぐわかるような間違いなのになんなんだろうな 488 名前：デフォルトの名無しさん mailto:sage [2024/06/29(土) 17:06:14.07 ID:HTwQ17U9.net] >>474 >>475 それは大きな誤解をしているなあ ライフタイムアノテーションを間違って書いて矛盾が起きていればコンパイルエラーとなるよ コンパイルが通れば正しく書けているからプログラマーがそこで困ることはないよ 489 名前：デフォルトの名無しさん mailto:sage [2024/06/29(土) 17:17:23.37 ID:KH8yb7Br.net] >>477 いいからこれでも読んでろ https://github.com/pretzelhammer/rust-blog/blob/master/posts/translations/jp/common-rust-lifetime-misconceptions.md > Rustのトレイトオブジェクトへのライフタイム省略ルールはどんな状況でも正しいというわけではない > Rustはプログラムの意味についてプログラマよりも知っているわけではない > Rustのコンパイラが吐くエラーメッセージでおすすめされる修正はコンパイルが通るようにするが、コンパイルが通り、 かつ プログラムへの要求をちゃんと満たしたものするわけではない 490 名前：デフォルトの名無しさん mailto:sage [2024/06/29(土) 17:26:08.00 ID:3fxfEuZj.net] それは省略ルールの結果が望むものと一致するかどうかは限らないという意味だぜ 間違っていると部分的にはコンパイルが通ったとしてもプログラム全体ではコンパイルエラーとなる そのミスをコンパイラが見逃すことはない 491 名前：デフォルトの名無しさん mailto:sage [2024/06/29(土) 18:07:09.50 ID:PsPEDCdZ.net] 言語を比較しなくても &Tに比べてRc<T>はリファクタリングしやすいとかいう認識でいいよな ただ進化論じゃないんだから&Tが淘汰されてRc<T>が生き残るということはない 言語を比較すれば淘汰される言語もありうる 492 名前：デフォルトの名無しさん mailto:sage [2024/06/29(土) 18:13:00.59 ID:E9RFAyQx.net] >>469 その逆のリファクタリングを影響範囲が大き過ぎて無理って話をcargoのissueで見たことある cargoはそれ以外でも技術的負債が溜まってるけど影響範囲が大きくなるから簡単に手を入れられないってことを中の人がよくボヤいてるね 493 名前：デフォルトの名無しさん [2024/06/29(土) 18:24:11.81 ID:bsok8bJg.net] C/C++をメモリ安全にするプロジェクト https://www.itmedia.co.jp/enterprise/articles/2406/28/news084.html Rustイラネになりそう 494 名前：デフォルトの名無しさん mailto:sage [2024/06/29(土) 18:44:47.93 ID:4ikwzvl0.net] >>482 それは自動で見つけられる脆弱性の範囲を広げる話 その種の脆弱性をゼロにするRustへと移行する流れはそのまま変わらず 495 名前：デフォルトの名無しさん mailto:sage [2024/06/29(土) 20:21:20.41 ID:U1RWDnMp.net] >>480 Rc<T>の比較対象はTやBox<T> ・Tの参照は&T ・Box<T>の参照は&T ・Rc<T>の参照は&T どれも同じになり&Tは不要とならない 違いはスコープから外れたとき 裸のTはTがスタック上ですぐ消える Box<T>はTがヒープ上ですぐ消える Rc<T>はTがヒープ上でカウンタが最後のときだけ消える 496 名前：デフォルトの名無しさん mailto:sage [2024/06/29(土) 20:23:11.41 ID:KH8yb7Br.net] >>469 これか…… https://github.com/rust-lang/cargo/issues/7342 > I think the answer here is "Alex thought it was fun to avoid RefCell and Mutex", there's no real technical motivation. 「cloneを避ける/ロックを避ける/参照カウンタのコストを避ける」みたいなゼロコスト主義も節度を持ってやれってことね とり� 497 名前：�えず「型のジェネリックライフタイム引数を変更するのは多大なコストがかかる」という理解は合っていると思っておくことにするか [] [ここ壊れてます] 498 名前：デフォルトの名無しさん mailto:sage [2024/06/29(土) 20:23:40.20 ID:KH8yb7Br.net] >>481だった 499 名前：デフォルトの名無しさん mailto:sage [2024/06/29(土) 21:57:07.55 ID:PsPEDCdZ.net] 問題は節度というより抽象化軽視 ゼロコストという損得勘定に強く依存するよりは高コスト抽象化の方がマシ と判断できなくなる 500 名前：デフォルトの名無しさん mailto:sage [2024/06/29(土) 22:55:28.22 ID:xDrSJDK+.net] >>469 それは単にライフタイムに不慣れなだけじゃないかなと思った 構造体に参照を含むのはよくあることでライフタイムパラメタを付けるだけ あとは関数で参照を含むデータを返す時にどの引数に由来するかを指定することなどしかすべきことはない 慣れてしまうと大したことはしていないよね そこでもし間違えて指定してしまっても違反があればコンパイラが必ずエラーとするので安心して大丈夫 では何故コンパイラが自動で指定(解釈)してくれないのか？というと、複数の参照に対して別扱いするかどうかや複数の関係指定など各自に方針の余地があるため 501 名前：デフォルトの名無しさん [2024/06/29(土) 23:12:35.54 ID:/LX7F2Md.net] C/C++だとそのへんを脳内の方針で逸脱しないように人間が監視しないといけない Rustは楽 502 名前：デフォルトの名無しさん mailto:sage [2024/06/29(土) 23:26:59.72 ID:PsPEDCdZ.net] 固定長配列をスライスに、BoxをRcに変換すると抽象度は上がる 失敗するかもしれないパターンマッチは抽象度を下げる コンパイル時または実行時エラーかもしれないborrowも抽象度を下げる 503 名前：デフォルトの名無しさん mailto:sage [2024/06/30(日) 02:58:29.53 ID:CdZYHoVj.net] >>467 詭弁 >>469 ++ >>474 ++おまえもかが口癖になる 504 名前：デフォルトの名無しさん mailto:sage [2024/06/30(日) 03:44:32.65 ID:K2J9qaLk.net] >>474 ライフタイム初心者なだけだな そんなことでは悩まなくなる 505 名前：デフォルトの名無しさん [2024/06/30(日) 05:54:25.07 ID:WATrci3L.net] >>309 横からすみません。 C＃を関数型っぽく書いたら、ここまではなったのでRustだったらどうなるのか聞いても良いでしょうか？ public static void Main(string[] args) { args.ToList().ForEach(f); } static void f(string fileName) { Console.WriteLine(fileName); File.ReadAllLines(fileName).Select(g).ToList().ForEach(Console.WriteLine); } static Func<string,int,string> g = (line,i) => $"{i + 1,2}:{line}"; 506 名前：デフォルトの名無しさん mailto:sage [2024/06/30(日) 09:33:23.06 ID:L3wyoKVN.net] どうもならんよ 507 名前：デフォルトの名無しさん mailto:sage [2024/06/30(日) 10:12:23.11 ID:BLjMhwlM.net] リファクタリングのすごさは、外側から見たら何も変化しないことだからね 508 名前：デフォルトの名無しさん mailto:sage [2024/06/30(日) 10:30:41.18 ID:8eFU1ITU.net] >>493 何回ToListすんねんw ReadAllLines含めて3回とも必要ないやろ 509 名前：デフォルトの名無しさん mailto:sage [2024/06/30(日) 10:53:06.05 ID:DQMdIUg4.net] あえて >>493 で頑張ると https://paiza.io/projects/sk40IXUgPm0k_VgI1wsHBg fn main() { let cwln = |s| { println!("{}", s) }; let g = |(i, line): (usize, &str)| { format!("{:>2}:{}", i + 1, line) }; let f = |file_name: String| { cwln(file_name.clone()); std::fs::read_to_string(file_name).map(|u8b| { u8b.lines().enumerate().map(g).for_each(cwln) }).unwrap() }; std::env::args().skip(1).for_each(f) } 510 名前：デフォルトの名無しさん mailto:sage [2024/06/30(日) 10:54:12.53 ID:BLjMhwlM.net] do記法のたぐいはラムダで実装しても命令型で実装してもどっちでもいい 外側から見れば同じだからだ 511 名前：デフォルトの名無しさん [2024/06/30(日) 11:17:03.52 ID:msuugTQH.net] >>496 .net標準にはList型にしかForEachが導入されてないからやな。 C#ではチェインメソッドにしないほうがいいとされてる。 https://learn.microsoft.com/en-us/archive/blogs/ericlippert/foreach-vs-foreach 512 名前：デフォルトの名無しさん mailto:sage [2024/06/30(日) 12:31:43.09 ID:NR+aRvdr.net] >>499 「.ForEachしたいけど標準にないからToListする」という考え方が間違い enumerable.ToList().ForEach()のパターンは最悪 それとそのEric Rippertの意見がMSやC#コミュニティのコンセンサスというわけではないよ IEnumerable以外ではForEach等の副作用適用メソッドが標準で用意されてるものが多々あるしIEnumerableに拡張メソッド追加して使ってるところもごまんとある 513 名前：デフォルトの名無しさん mailto:sage [2024/06/30(日) 13:08:54.78 ID:7wkc/L2e.net] >>497 キツイ 514 名前：デフォルトの名無しさん mailto:sage [2024/06/30(日) 13:13:35.11 ID:6LaDfHu1.net] >>500 foreachとForEachくらいは好きなほうでやればいいわな ものによっては最適化度合いが変わるからそこだけ気にしとけばいい 515 名前：デフォルトの名無しさん [2024/06/30(日) 13:41:54.85 ID:L3wyoKVN.net] unwarpほんま糞ダサい 516 名前：デフォルトの名無しさん mailto:sage [2024/06/30(日) 14:01:03.54 ID:BLjMhwlM.net] 「すべてはオブジェクトである」が糞ダサいのだ いい感じの構文糖はたいていオブジェクトではない 517 名前：デフォルトの名無しさん mailto:sage [2024/06/30(日) 15:34:51.28 ID:iQS10/oI.net] >>497 エラー返しができていない ファイル一括読み込みでなくバッファリングすべき 本当の関数型だとセミコロンを使うのは邪道 518 名前：デフォルトの名無しさん [2024/06/30(日) 16:34:51.56 ID:WATrci3L.net] >>497 ありがとうございます。 u8b受け取ってるラムダ式を関数化したらスッキリしそうですね。 >>496 Selectもindexを受け取れるんですが値を返さないとダメで、 あえてvoidなメソッドの後にreturn 0を、入れてエラーが出なくなったと思ったら、 遅延評価なのかfor/foreach/ForEachじゃないと中身を実行してくれないんですよ…orz （結論、Selectはデータ加工専用で入出力には使えない） 519 名前：デフォルトの名無しさん mailto:sage [2024/06/30(日) 16:49:10.64 ID:MSv8cbxu.net] Rustで関数型のように書くなら use std::env; use std::fs::File; use std::io::{self, BufRead, BufReader}; fn main() -> io::Result<()> { 　env::args() 　　.skip(1) 　　.inspect(|file_name| println!("{file_name}")) 　　.map(|file_name| { 　　　File::open(file_name).and_then(|file| { 　　　　BufReader::new(file) 　　　　　.lines() 　　　　　.enumerate() 　　　　　.map(|(i, line)| line.map(|line| println!("{}: {line}", i + 1))) 　　　　　.collect() 　　　}) 　　}) 　　.collect() } 520 名前：デフォルトの名無しさん [2024/06/30(日) 16:59:35.48 ID:WATrci3L.net] 質問です。 .map(|(i, line)| line.map(|line| println!("{}: {line}", i + 1))) ↑ line.mapは文字列へのmapで１文字１文字に番号振ってる様に見えますが、違うのでしょうか？ 素直に .map(|(i, line)| println!("{}: {line}", i + 1)) とは出来ないのでしょうか？ 521 名前：デフォルトの名無しさん mailto:sage [2024/06/30(日) 17:13:06.42 ID:MSv8cbxu.net] >>508 そこは手続き型で書くと let line = line?; のところ 最初のlineはio::Result<String>型 それをmapして次のlineがString型 522 名前：デフォルトの名無しさん mailto:sage [2024/06/30(日) 17:55:47.01 ID:2aLeyJWV.net] こうやって関数型を勘違いしたやつが量産されてるんだな 523 名前：デフォルトの名無しさん [2024/06/30(日) 18:10:42.55 ID:WATrci3L.net] >>509 なるほど、最初のmapと内側のmapで型が違うのですね。 ありがとうございました。 524 名前：デフォルトの名無しさん mailto:sage [2024/06/30(日) 18:12:41.76 ID:aILYkgH6.net] さすが二つ名持ちの汚コーダー ひと味もふた味も違う 525 名前：デフォルトの名無しさん mailto:sage [2024/06/30(日) 18:28:40.79 ID:MSv8cbxu.net] 関数型のように書きたいならば基本はfor_eachを使わない 行き詰まりのfor_eachを使うと値もエラーも返せなくなる 526 名前：デフォルトの名無しさん mailto:sage [2024/06/30(日) 18:46:14.08 ID:DeiuUcf0.net] >>506 イテレータがどういうものか全然理解してないのな 試行錯誤もいいが最低限の座学知識は必要やぞ 527 名前：デフォルトの名無しさん [2024/06/30(日) 20:38:10.26 ID:oQ6wZd+v.net] let a: [u32; 4] = [1, 2, 3, 4]; let s: &[u32] = &a[1..3]; a[5]; と書くとコンパイルエラーが発生しますが、 s[5]; と書くとコンパイルは通り実行時にエラーが発生します。 なぜ、 s[5]; が範囲外の領域へのアクセスであることをコンパイル時に見抜けないのでしょうか？ 本を見ても、理由が書いてないです。 ただ、そうなるとしか書いてありません。 528 名前：デフォルトの名無しさん mailto:sage [2024/06/30(日) 21:21:34.70 ID:aS5UFAEb.net] 見抜けるようになっていないから a は array である一方で s は slice array は型として長さの情報を持つ一方 slice は持たない slice の長さはコンパイル時にわからないしわかろうともしないしチェックもない 529 名前：デフォルトの名無しさん mailto:sage [2024/06/30(日) 21:23:59.76 ID:MSv8cbxu.net] >>515 静的にサイズが定数だと静的に比較できるから事前にコンパイルエラーとなる 配列は静的にサイズが定数 スライスもこのように静的にサイズを定数にしてやれば事前にコンパイルエラーとなる const X: &[u32] = &[1, 2, 3, 4]; let x = X[5]; 530 名前：デフォルトの名無しさん mailto:sage [2024/06/30(日) 21:57:28.27 ID:6Q+TlIxj.net] 🦀🦀🦀 531 名前：デフォルトの名無しさん mailto:sage [2024/06/30(日) 22:10:02.00 ID:BLjMhwlM.net] 本といえども一方通行のメディアではなくなってるんじゃないか 読者の側がそれをどうしても知りたい気持ちを表明しなければならないのが双方向でしょ 532 名前：デフォルトの名無しさん mailto:sage [2024/06/30(日) 22:48:34.24 ID:NrRL076G.net] >>513 一体全体何を言ってるんだ？ 533 名前：デフォルトの名無しさん mailto:sage [2024/06/30(日) 23:09:55.43 ID:MSv8cbxu.net] >>520 for_eachは値を返せない 関数は基本的に値やエラーを返す イテレータ利用で値やエラーを返すためにはfor_eachではなくcollectやfoldなどを用いる >>507のように表示するだけで値を返さない場合であっても 関数はエラーを返さなければならない 534 名前：デフォルトの名無しさん mailto:sage [2024/07/01(月) 00:45:59.76 ID:d9FHgeU6.net] >>521 >for_eachは値を返せない for_eachはunitを返してるよ >関数は基本的に値やエラーを返す voidやunitやnilを返すものも関数だよ >イテレータ利用で値やエラーを返すためにはfor_eachではなくcollectやfoldなどを用いる try_for_each使ってね file openやprintのような副作用をイテレータのmapで行うのは関数型の考え方からは程遠いよ 535 名前：デフォルトの名無しさん mailto:sage [2024/07/01(月) 01:02:37.18 ID:3Woy0c9R.net] 値を()しか返せないのでは意味がない 536 名前：デフォルトの名無しさん mailto:sage [2024/07/01(月) 01:19:54.94 ID:CgZJmBCn.net] お前の人生よりは意味あるよ 537 名前：デフォルトの名無しさん [2024/07/01(月) 04:16:03.32 ID:VTE9nWpJ.net] unwrapをmapで代用とかセンス無さ過ぎ 538 名前：デフォルトの名無しさん mailto:sage [2024/07/01(月) 05:26:16.34 ID:WAZyoaEd.net] 見抜いたことを全て警告するコンパイラがあったらこんな感じになるのか 539 名前：デフォルトの名無しさん mailto:sage [2024/07/01(月) 05:49:45.95 ID:ppYg1fh2.net] Rustは清書用(キリっ 540 名前：デフォルトの名無しさん [2024/07/01(月) 05:51:10.72 ID:D/wxxrcg.net] 犯人不明ボイス・トォ・スカル被害者にしている者皆判明 AIで被害者が苦しんでいる映像を作成してそれで喜んでいる脳細胞を読み取れば使用しているかの判定 AIで自分が高みの見物ができるかどうかも判定 あとは下記を参考にして行えばよい いじめで殺害したかも判明するので迷宮入り事件犯人を絞り込める 隠しカメラの場所も判明 忘れた記憶を再び思い出せるようにする脳細胞を発見！ 2024.06.28 「あなたの一番古い記憶は？」人は覚えていても2歳以前の記憶にアクセスできなくなっている 2023.11.30 なぜ私たちは起こってもいない間違った記憶をしてしまうのか？ 2023.11.27 自分でも気づいていない「記憶の間違い」を脳波で判断できると判明 2023.10.19 富山大、睡眠中の脳で行われている推論の演算を神経細胞レベルで解明 2024/06/26 サイコパスはためらわない？−−嘘つきの脳のメカニズム 2019/09/26 脳を刺激して特定の記憶を呼び戻す技術「記憶プロテーゼ」を開発 2024/02/21 「0」を”思う”ときの脳活動は「1」に近い！捕食者への恐怖がゼロの根幹だった？ 2024.03.07 >>MEGを使うと、脳内でわずかに発生する磁場変化をとらえて、脳活動を記録することが可能です。 >>（※脳波計が脳の電気活動を読み取るのに対して、脳磁計は脳の磁気活動を読み取ります） 東工大、磁束集中器を用いない高感度「ダイヤモンド量子センサ」を開発 2024/06/07 >>日常的な検診や脳機能のより詳しい研究や、ブレイン・マシン・インタフェースの研究などへ大きく貢献できると期待されている。 541 名前：デフォルトの名無しさん mailto:sage [2024/07/01(月) 06:29:11.19 ID:XAeGvvJG.net] >>525 unwrapは使わずにmapでNone/Errを透過的に渡すのはRustの基本 542 名前：デフォルトの名無しさん mailto:sage [2024/07/01(月) 07:19:14.88 ID:WAZyoaEd.net] これmapメソッドでもmap関数でもない中立な勢力が勝つパターンだ 543 名前：デフォルトの名無しさん mailto:sage [2024/07/01(月) 11:47:54.40 ID:LZ9kVfeK.net] Functorのmapなんだよね でもFunctorは定義されてなくて統一的に扱えないんだから Result/Optionはfmapとか違う名前にしておいたほうがよかったと思う どっちにしろmap/fmapで副作用はアンチパターン 544 名前：デフォルトの名無しさん mailto:sage [2024/07/01(月) 11:55:40.56 ID:14Z1Ksgh.net] fmapなんかflatMapと勘違いされるだろ 545 名前：デフォルトの名無しさん mailto:sage [2024/07/01(月) 12:47:47.85 ID:Z0Kzqg/U.net] そんな勘違いをする人にRustは無理 546 名前：デフォルトの名無しさん mailto:sage [2024/07/01(月) 12:59:53.25 ID:irzLgX5l.net] >>525 こう書くとresultがErrの時に返せずここでpanicになってしまう 　let val = result.unwrap(); 　f(val) そのためpanicしてもいいとか絶対にErrとならない特殊な場合を除けば unwrapを用いてはダメでmapを使ってこのように書くんだよ 　result.map(|val| f(val)) ここで本当に関数fを呼ぶだけならresult.map(f)と簡略化できるけど f(val)の部分は式やブロックの可能性もあるので簡略化せずに進めるね これは以下と同等でErr(err)の時に保持してくれている 　match result { 　　Ok(val) => Ok(f(val)), 　　Err(err) => Err(err), 　} ちなみにf(val)もResultを返すときは mapの代わりにand_thenがある 　result.and_then(|val| f(val)) つまり以下の二つは同等 　result.map(|val| f(val)) 　result.and_then(|val| Ok(f(val))) この場合はもちろん簡素なmapを用いるべき 547 名前：デフォルトの名無しさん [2024/07/01(月) 13:41:34.54 ID:JlB5uk0q.net] Rustを10年以上使ってるひとに質問です Rust本体をバージョンアップしたときに 動かなくなった旧バージョン用のcratesや自分のプロジェクト(main.rsなど)は どれくらいありましたか？ またdeprecatedやobsoletedにされた機能は 使えなくなるまでに実際何年くらい使い続けられましたか？ 548 名前：デフォルトの名無しさん mailto:sage [2024/07/01(月) 14:05:59.07 ID:/HpLpXor.net] Rust 1.0からまだ10年経っていない Rustは3年毎のedition制度があって後方互換性がない変化はeditionが変わるため安心 今も最初のRust 2015 editionがサポートされてる さらにedition移行支援ツールもある Rustは他言語と比べてかなり恵まれてる良い環境 549 名前：デフォルトの名無しさん mailto:sage [2024/07/01(月) 14:11:38.44 ID:JlB5uk0q.net] >>534 >ちなみにf(val)もResultを返すときは の条件なら >つまり以下の二つは同等 >　result.map(|val| f(val)) // Resultを還さないf >　result.and_then(|val| f(val)) // Resultを還すf じゃないんですかね(Ok(f(val))は蛇足) 550 名前：デフォルトの名無しさん mailto:sage [2024/07/01(月) 14:22:14.04 ID:seu0xN2c.net] Resultを返すか返さないか関係なくこれは常に成り立つね >>534 ＞ 以下の二つは同等 ＞ result.map(|val| f(val)) ＞ result.and_then(|val| Ok(f(val))) 例えばf(val)がOptionを返したとしても成立するよ 551 名前：デフォルトの名無しさん mailto:sage [2024/07/01(月) 14:22:38.11 ID:14Z1Ksgh.net] flat_map の関数名を and_then にしたのはどこの言語の文化？ 552 名前：デフォルトの名無しさん mailto:sage [2024/07/01(月) 14:43:32.98 ID:WAZyoaEd.net] iostreamの記号をまるでセガサターンのように見下して英単語を推した文化 553 名前：デフォルトの名無しさん mailto:sage [2024/07/01(月) 14:48:54.46 ID:JlB5uk0q.net] and_thenはor_elseに対してのantitheseだと思った 554 名前：デフォルトの名無しさん mailto:sage [2024/07/01(月) 14:51:31.68 ID:seu0xN2c.net] result1.and(result2) がまずあって result1.and_then(|ok1| return_result2(ok1)) が関数版だね OptionでもResultでも同じ命名 555 名前：デフォルトの名無しさん mailto:sage [2024/07/01(月) 14:59:21.90 ID:3i64JhgU.net] iostreamの << をRustに導入しなかったのはなぜ？ 556 名前：デフォルトの名無しさん mailto:sage [2024/07/01(月) 15:05:11.12 ID:kC5U6Id4.net] std::fmtで十分だから 557 名前：デフォルトの名無しさん mailto:sage [2024/07/01(月) 15:05:34.52 ID:YDWAPNrm.net] うるせぇやりたきゃShl実装しろ 558 名前：デフォルトの名無しさん mailto:sage [2024/07/01(月) 15:30:41.32 ID:wNG1bhSA.net] >>543 単純な二項演算子でやると書式指定の範囲を制御できないんだよ。 C++ ではストリームに対する書式指定は永続的な効果を持っていて、その効果を上書きするまで続く。 普通の方法で指定したらグローバルな影響を持ってしまうのは明らかにまずい。 iostream が出来たときは可変長引数の関数を型安全に扱う方法 (variadic template) が無かったし、 書式指定文字列をコンパイル時に解釈して安全に扱う方法 (constexpr) も無かったから その範囲内で当時の知見で比較的マシな形にしたらああなったという程度のもんで、 今の考え方からすると iostream は真似したいようなもんじゃない。 むしろ C++ のほうが新しい仕様では Rust 風のやり方に寄せて来てる。 559 名前：デフォルトの名無しさん mailto:sage [2024/07/01(月) 15:53:07.19 ID:2HyCglUW.net] >>543 ダサすぎるから 560 名前：デフォルトの名無しさん mailto:sage [2024/07/01(月) 15:56:35.04 ID:iVgAAf6K.net] rustもprint時のstring interpolationはもう少しどうにかならんものかね 561 名前：デフォルトの名無しさん [2024/07/01(月) 18:51:52.61 ID:r9fpSp0F.net] macroなんで自分で描き替えればええんやで 562 名前：デフォルトの名無しさん mailto:sage [2024/07/01(月) 20:45:22.07 ID:WAZyoaEd.net] 自作した後の自己肯定を10年続けるまでがプログラム技術 563 名前：デフォルトの名無しさん mailto:sage [2024/07/01(月) 23:04:21.05 ID:3i64JhgU.net] 昔、C++でprintf使ったら怖い人に怒られたのに 今じゃあれはクソ設計だったって評価に固まってるんだね、英語圏でも 564 名前：デフォルトの名無しさん [2024/07/01(月) 23:12:10.92 ID:wNG1bhSA.net] >>551 C/C++ の printf は iostream 以上にカス。 型のチェックがガバガバだし、ちゃんと理解してないやつのほうが多いので常に問題を引き起こしていた。 ただ、記法としてはこれで良かった。 565 名前：デフォルトの名無しさん [2024/07/02(火) 02:06:02.53 ID:bkJ9zxrb.net] 今の C/C++ の printf はコンパイル時に型チェックして警告してくれる 566 名前：デフォルトの名無しさん mailto:sage [2024/07/02(火) 05:00:17.05 ID:VNjymWLQ.net] >>553 型チェックできて型がわかっているのに なぜ%dや%fや%sなど指定しなきゃいけないのか理解できない 型がゆるゆるだった大昔の遺物にみえる 567 名前：デフォルトの名無しさん mailto:sage [2024/07/02(火) 06:06:14.65 ID:wHmBy3hI.net] >>554 みえる、じゃなくて完全に遺物だろ 568 名前：デフォルトの名無しさん mailto:sage [2024/07/02(火) 06:44:02.90 ID:VNjymWLQ.net] 表示はRustのDisplayトレイト実装方式が洗練されていて使いやすくていいね 569 名前：デフォルトの名無しさん mailto:sage [2024/07/02(火) 08:28:24.43 ID:UD4Nu927.net] 仕様書が聖書のようなものだから遺物だろうが仕様書に逆らうわけにはいかないじゃん 570 名前：デフォルトの名無しさん mailto:sage [2024/07/02(火) 08:41:47.20 ID:hGRi0mb2.net] >>544 C の関数は基本的にはちゃんと型はついてるが可変長引数は静的な型情報を捨てること実現してる。 もちろんそれを引き継いだ C++ も。 C++ は後に variadic template による安全な可変長引数を導入したが古いスタイルの可変長引数も廃止はしてない。 言語仕様を素朴に実装したら型はわからないんだよ。 printf などの一部の関数に限っては「関数の型情報によらずに」コンパイラが特別扱いでチェックしてる。 関数の型を元に検査してるんじゃなくて printf の仕様をビルトインして特別扱いしてるの。 571 名前：デフォルトの名無しさん mailto:sage [2024/07/02(火) 10:27:11.96 ID:LnXo4/R2.net] >>538 result.and_then(|val| Ok(f(val)?)) とか result.and_then(|val| Ok(f(val).unwrap())) じゃなくて result.and_then(|val| Ok(f(val))) で良いのはなぜ？ 572 名前：デフォルトの名無しさん mailto:sage [2024/07/02(火) 10:37:23.15 ID:tsLlTVbC.net] Rust初めて使ったときは「println! みたいな基本的なものがマクロで？大丈夫かこの言語」みたいに思ったもんだが、 よくよく考えるとマクロにせずに、柔軟なシグニチャでなんとかしようとする他の言語のほうがよっぽど醜いもんな。 573 名前：デフォルトの名無しさん mailto:sage [2024/07/02(火) 10:55:15.33 ID:/ZI4FWA6.net] >>559 上2つはResult<T> 最後のはResult<Result<T>>かResult<Option<T>> ネストが一つ深くなる 574 名前：デフォルトの名無しさん mailto:sage [2024/07/02(火) 11:50:20.39 ID:hGRi0mb2.net] >>560 C++ のライトユーザは関数テンプレートのことを誤ってテンプレート関数と呼ぶことが頻繁にある。 関数テンプレートが関数であるという誤解が言葉になって表れてるんだと思う。 単に使うだけなら関数みたいに見えてしまうからかもしれない。 関数テンプレートは関数を生成する元になるテンプレートだから関数テンプレートなので「生成する」というところに着目したらマクロで生成するのでも理屈はあまり変わらないかもしれない。 ただ、 LISP 系言語の経験から言うと構文レベルで制御されるマクロはエディタのサポートが受けづらいし、ドキュメントを型で表現できないのはやりづらい。 マクロ展開の失敗がどういう失敗なのかをきちんとエラーメッセージにするのも難しい。 デメリットもあるけど、どうせどこかに問題があるならこのくらいで良いという潔さは感じる。 575 名前：デフォルトの名無しさん mailto:sage [2024/07/02(火) 12:37:13.61 ID:UD4Nu927.net] 仕様書がなくなっても 統合環境の支援の成功体験から逆算された縛りがあるんだな 576 名前：デフォルトの名無しさん [2024/07/02(火) 16:01:50.82 ID:LnXo4/R2.net] and_thenってネストが深くても自動で中いじってくれるのか 577 名前：デフォルトの名無しさん [2024/07/02(火) 17:51:34.66 ID:XMmeU2jA.net] Slint ってなんなん？ javascript ? conrod とどう違うん？ 578 名前：デフォルトの名無しさん [2024/07/02(火) 18:31:45.59 ID:W5A1QJhP.net] conrodならもう死んだよ 579 名前：デフォルトの名無しさん mailto:sage [2024/07/02(火) 18:32:06.29 ID:0AnHLV8o.net] >>559 Rustでそれらは全てmatchになるので置き換えて比較すれば理解は簡単 ちなみにmatchにすると記述が長くなるが同レベルで「?」オペレータ適用できるメリットがある result.and_then(|val| f(val)) これはこう置き換えられる match result { 　Ok(val) => f(val), 　Err(err) => Err(err), } result.map(|val| f(val)) これはこう置き換えられる match result { 　Ok(val) => Ok(f(val)), 　Err(err) => Err(err), } つまり常にこれが成り立つ >>534 ＞ 以下の二つは同等 ＞ result.map(|val| f(val)) ＞ result.and_then(|val| Ok(f(val))) 580 名前：デフォルトの名無しさん mailto:sage [2024/07/02(火) 18:34:46.10 ID:0AnHLV8o.net] >>565 SlintはGUI部分だけ専用スクリプトで宣言して プログラムはRustでもC++でもJavaScriptでも記述できる 581 名前：デフォルトの名無しさん mailto:sage [2024/07/02(火) 22:09:25.08 ID:PHqzDXJL.net] RustのGUIまわりは安定しない印象 conrodやdruidやorbtkのようにここ数年内に消えたものもあるし、いま人気のものも今後消えないとは言い切れない感じがする 582 名前：デフォルトの名無しさん mailto:sage [2024/07/02(火) 23:44:50.93 ID:sYgKhdog.net] RustでGUIならこの5つ https://iced.rs/ https://slint.dev/ https://tauri.app/ https://www.egui.rs/ https://dioxuslabs.com/ 方向性がそれぞれ異なるので目的に合わせて選ぶ 583 名前：デフォルトの名無しさん [2024/07/03(水) 03:55:17.90 ID:aYT0CHki.net] tauri遅いな eguiはサクサク 584 名前：デフォルトの名無しさん mailto:sage [2024/07/03(水) 06:25:46.46 ID:uJMJjlOC.net] >>570 tauriはその中に入れるべきじゃないだろ あれはReact/JSだぞ 585 名前：デフォルトの名無しさん mailto:sage [2024/07/03(水) 07:06:30.59 ID:OX+N1U2y.net] >>572 無知すぎ Reactは全く関係ない 併用可能な一つに過ぎない TauriではJavaScriptを一切書かなくても利用可能 Rustによるプログラミングのみでも使うことができる 586 名前：デフォルトの名無しさん [2024/07/03(水) 09:04:55.71 ID:TWMTGehv.net] rstkはどうなの？ 587 名前：デフォルトの名無しさん mailto:sage [2024/07/03(水) 20:03:02.84 ID:zo80GwO2.net] しかしほんとにデスクトップアプリのライブラリってすぐ出ては消えていくな 自分で作ったほうが安定するんじゃないか 588 名前：デフォルトの名無しさん mailto:sage [2024/07/03(水) 22:16:18.13 ID:opT6Sw/L.net] クロスプラットフォームでいくならwinitとwgpuぐらいは頼らないと無理じゃないかな。 しかしその2つもまだまだブレイキングチェンジ激しい発展途上だけどね。 589 名前：デフォルトの名無しさん mailto:sage [2024/07/03(水) 22:53:26.72 ID:cnEeYmV/.net] >>574 */Tkは30年以上の歴史と実績があるGUIライブラリ rstkはそのRust版 590 名前：デフォルトの名無しさん mailto:sage [2024/07/03(水) 23:54:41.68 ID:nLMSU1jW.net] >>573 Yewのこと？ならそう書けよYewなんてくっそマイナーでReact使うのが普通なのに 591 名前：デフォルトの名無しさん mailto:sage [2024/07/03(水) 23:56:15.32 ID:nLMSU1jW.net] Yew使ったことあるけどゴミだぞまじで 592 名前：デフォルトの名無しさん mailto:sage [2024/07/04(木) 00:31:14.93 ID:gMzXB5nS.net] 30年くらい前にTcl/Tkを使ったわ。 593 名前：デフォルトの名無しさん mailto:sage [2024/07/04(木) 00:37:01.85 ID:0fbU9cKr.net] >>575 利用者が集まらなきゃ結局のところ本番環境で使われないもんね MAUIもだけど本番環境で使われなきゃ不具合修正すらされずにフェードアウトしていく 594 名前：デフォルトの名無しさん mailto:sage [2024/07/04(木) 04:07:16.49 ID:H+976rVP.net] >>570 eguiの公式サイト、オサレね 595 名前：デフォルトの名無しさん mailto:sage [2024/07/04(木) 07:04:39.24 ID:pjeQ5Ua2.net] サイト自体が見本なのな 596 名前：デフォルトの名無しさん [2024/07/04(木) 10:17:42.23 ID:HAZY/W56.net] reactもこの10年でだいぶ変わったわな。 プレゼンテーション層はそういうもんかもなと思ってる。 597 名前：デフォルトの名無しさん [2024/07/05(金) 08:36:28.68 ID:GQkuHNKI.net] 銀河英雄伝説で考えるセキュリティ--将来の「帝国の双璧」が陥った罠とセキュリティ業界 https://japan.zdnet.com/article/35220819/ 598 名前：デフォルトの名無しさん mailto:sage [2024/07/05(金) 10:29:56.20 ID:G0wJmtVU.net] >>574 >>577 rstk より tk ( https://crates.io/crates/tk ) の方が良いよ 599 名前：デフォルトの名無しさん mailto:sage [2024/07/05(金) 18:22:04.62 ID:cNWaNn+n.net] どちらも利用者少なくて数の差ではわからんな 600 名前：デフォルトの名無しさん mailto:sage [2024/07/06(土) 04:04:15.80 ID:MPM8/XaB.net] Tkは何十年も前のGUIで古いからね 601 名前：デフォルトの名無しさん [2024/07/06(土) 04:24:49.23 ID:mF2Bv0pD.net] やりたいことを出来る範囲で最小限の道具を選ぶのが望ましい。 Tk で足りるときは Tk を使えばよい。 602 名前：デフォルトの名無しさん mailto:sage [2024/07/06(土) 09:36:32.81 ID:5g1fLWJR.net] UNIX系でGUIをどうしても使わないといけない場合にTk使ってたけど 今はhtmlでいいかなって 603 名前：デフォルトの名無しさん mailto:sage [2024/07/06(土) 09:36:55.52 ID:tDR9EaCv.net] wgpu最強だが変化速過ぎ 604 名前：デフォルトの名無しさん mailto:sage [2024/07/06(土) 10:12:50.18 ID:fehAbjyn.net] 正直GUIをRustで書くメリットが思いつかない ただの2DグラフィックでRustの実行速度を求めるってのはおかしな話だと思うもん ロジックをRustで書いてGUIは安定してるReactでいいよ 605 名前：デフォルトの名無しさん mailto:sage [2024/07/06(土) 10:14:23.55 ID:5g1fLWJR.net] wgpuは三角を書きたい人向けでGUIとは関係ない 606 名前：デフォルトの名無しさん mailto:sage [2024/07/06(土) 11:05:29.63 ID:l5YBQ3zH.net] >>592 お前がそう思うならそうなんだろう お前ん中ではな 607 名前：デフォルトの名無しさん mailto:sage [2024/07/06(土) 12:27:12.12 ID:KR8eM4HE.net] >>592 reactはデータリフトアップして上にまとめるのめんどい。状態管理だけにライブラリ導入とか無理あるんじゃねーの 608 名前：デフォルトの名無しさん mailto:sage [2024/07/06(土) 12:35:51.52 ID:5g1fLWJR.net] streamlitなどのHTML書かないでも作れるようなのがメジャーになればいいんだけど 609 名前：デフォルトの名無しさん mailto:sage [2024/07/06(土) 12:47:45.00 ID:5g1fLWJR.net] reactがパックされてて高度なページはjinjaみたいので中のデータだけいじれればなんでもいい気がする 通常のページの記述はhtmlではなく素のrustで簡単に書ける必要がある 610 名前：デフォルトの名無しさん mailto:sage [2024/07/06(土) 13:00:47.32 ID:mF2Bv0pD.net] ウェブ技術系は普段使いするにはリッチすぎるんだよな。 屋上屋を重ねまくった一番上でしょうもないことをするのは気が引ける。 611 名前：デフォルトの名無しさん mailto:sage [2024/07/06(土) 13:56:26.87 ID:5g1fLWJR.net] streamlitレベルでいいんだけどな 612 名前：デフォルトの名無しさん [2024/07/06(土) 14:33:03.19 ID:+47S9kNa.net] rust版のstreamlit作れよ 613 名前：デフォルトの名無しさん [2024/07/06(土) 14:56:55.97 ID:X3tW4qHs.net] タウリンなんていらん eguiで充分 614 名前：デフォルトの名無しさん [2024/07/06(土) 22:06:51.02 ID:PIuhFLFS.net] Rustってオブジェクト指向言語ではないということですが、それでも困ることはないんです 615 名前：か？ これが最後の言語だ！とRustって名付けたんですか？ [] [ここ壊れてます] 616 名前：デフォルトの名無しさん [2024/07/06(土) 22:35:00.58 ID:KApGuCzH.net] Rust触ってないから分らんけど、QtのRustラッパーライブラリは無いのん？ 一応Android/iOS含めたソースコードレベルでのマルチプラットフォームライブラリに進化しているらしいが、Haskellにすらラッパーライブラリあるんなら、Rustにも探せばあるんじゃ？ 617 名前：デフォルトの名無しさん [2024/07/07(日) 00:52:56.61 ID:goRFIXq7.net] >>602 ネタにマジレスかもしれないけどRustはオブジェクト指向的なものも使えるよ 構造体にメソッドを持たせたり、インターフェースのようなものも扱える 継承はないけど、これはむしろ「その方が良い」というもので、同じくモダンな言語であるGOでも継承は無くしてる 618 名前：デフォルトの名無しさん mailto:sage [2024/07/07(日) 01:50:01.52 ID:NnH56+1c.net] オブジェクト指向プログラミングには クラス継承という悪いやり方を用いるダメな方法と クラス継承を用いない正しい方法があって RustやGoなどのモダンな言語は後者の方法をサポートしている 619 名前：デフォルトの名無しさん [2024/07/07(日) 08:48:31.04 ID:5sr/rOi5.net] >>603 ないわけじゃないけどまともに使えるレベルではないらしい。使ってないから知らんけど。 Qt自体QMLとか迷走してる感じあるし結局JSでやるならもうReact使えばいいんじゃね？感ある 620 名前：デフォルトの名無しさん [2024/07/07(日) 09:17:14.13 ID:7aG8TPof.net] >>604-605 ありがとうございました。 「継承」って良いからオブジェクト指向言語の機能になっていたのではないんですか？ なんか時代とともに、昔は良いとされていたものが今ではダメになったりするんですか？ なぜそんなに揺らぐのでしょうか？ 言語の設計の学者はぼんくらばかりなんですか？ 621 名前：デフォルトの名無しさん mailto:sage [2024/07/07(日) 09:17:45.74 ID:LJE8DJUz.net] 継承がないほうが「正しい」というのは行きすぎた思想だよ。 正しく使えないカスばっかりだという現実に敗北しただけ。 622 名前：デフォルトの名無しさん mailto:sage [2024/07/07(日) 09:49:42.70 ID:Qx35uTG5.net] 何がダメかというと「ある型(クラス)が別の型(クラス)の実装を継承してしまうこと」でこれが依存関係となり負の連鎖をもたらす クラスの継承はこれに該当するから使ってはいけない Rustにも継承とみなせる機能はあるけれど上記に該当しないため大丈夫 そこが決定的な違い 623 名前：デフォルトの名無しさん mailto:sage [2024/07/07(日) 10:06:45.11 ID:rz+I+TB4.net] >実装を継承してしまうこと」でこれが依存関係となり負の連鎖をもたらす 実装継承を使えないレベルの人はだいたいこういうふわっとした認識だよね 624 名前：デフォルトの名無しさん mailto:sage [2024/07/07(日) 10:11:15.42 ID:Eha1J0DV.net] 暗殺術を正しく使える賢者がいる国なんてあったら嫌だなあ 正しく使える者など絶対存在しないという思想は行き過ぎではなくむしろ穏健派 625 名前：デフォルトの名無しさん mailto:sage [2024/07/07(日) 10:27:32.62 ID:nRN7u0+P.net] 全部が悪いと言う話じゃないけど 既存部分をただ継承させるだけならいいけど一部を上書きしたりして それが全ての箇所で矛盾のない正しい挙動になるか判定が難しいか不可能な場合がある 結果実装コスト以上に考えざるを得ない…残念なことに本当に楽をしたのかどうか不明な場合がある 継承がないとそれは避けられるから使うな！と言う人が出てくる 626 名前：デフォルトの名無しさん mailto:sage [2024/07/07(日) 10:29:57.11 ID:nRN7u0+P.net] 変数などに細かいアクセス制限のない言語は特に陥りやすい 制限があったところで制作者がそれを適切に選ばなければならない どうしても経験や思考時間を必要とする ガチ勢にはそれが無駄に思えるんだろう 627 名前：デフォルトの名無しさん mailto:sage [2024/07/07(日) 10:32:06.74 ID:syATK/7U.net] 実装継承は問題を引き起こすだけでなく 代わりの継承機能を提供することで 実装継承は全く不要になったことが大きい そのためRust、Zig、Nim、Goなどモダンな言語はいずれも言語仕様からクラスを追放している 628 名前：デフォルトの名無しさん mailto:sage [2024/07/07(日) 10:33:57.16 ID:nRN7u0+P.net] それをやっても実質オーバーライド問題は解決されていないけどな 629 名前：デフォルトの名無しさん mailto:sage [2024/07/07(日) 10:45:17.84 ID:4XBGKwNL.net] >>607 実装継承はすごく便利だからオブジェクト指向言語では誰でも使いやすい機能としてサポートされてた でも便利すぎて乱用されたからその経験と反省から不便でも乱用されにくいようにした方が得策という考えに至った言語開発者が増えたというのが2010年代 だから今は実装継承は上級者向けの機能という扱い GoでもRustでも一般的なオブジェクト指向言語よりもわざと使いにくくすることで利便性と問題点を理解して実装方法を選択できる上級者向けの技術になっている 630 名前：デフォルトの名無しさん mailto:sage [2024/07/07(日) 10:46:54.77 ID:RLTFRTn6.net] >>615 それは(実装継承となる)クラスでのみ問題となるよな 631 名前：デフォルトの名無しさん mailto:sage [2024/07/07(日) 10:53:40.16 ID:suA6qkkI.net] >>616 デタラメを書くなよ 問題となる機能の代わりに便利で問題を起こさない機能を導入したのがRustだ 頭の固いクラス原理主義の人だけが使いにくいと主張してるが クラスの洗脳から解き放たれた普通の人たちはRustが便利で使いやすいとの理解に至っている 632 名前：デフォルトの名無しさん mailto:sage [2024/07/07(日) 11:05:57.49 ID:nRN7u0+P.net] >>618 それは違うかなｗ Rustで具体的に他と何が違ってて便利になってるか明言できるか？ Rustでも本質は変わってないのでなんも考えないでコピペ（継承）は避けましょうね ぐらいのレベルでしかない 633 名前：デフォルトの名無しさん [2024/07/07(日) 11:21:22.62 ID:goRFIXq7.net] >>607 当時は良いと考えられてたものが後から振り返って「あれは良くなかった」と分かる例はプログラミングに限らず多くあるだろ Cの時代にRustを設計しろというのは無理で、その間にC++やJavaを経験し、そこで生まれた課題意識がないとGoやRustは生まれなかった ニュートンの時代に古典力学を超えた量子力学を発見しろみたいなもの 634 名前：デフォルトの名無しさん mailto:sage [2024/07/07(日) 11:23:38.24 ID:E46Yge5y.net] >>619 コピペを避けるためにあるのが継承 ただし継承には2種類あって >>609に説明がある実装継承とそうならない継承がある 実装継承の典型例がクラス継承 実装継承は他の型(またはクラス)に実装を完全に依存してしまっているために硬直化や崩壊などを招いてしまう 解決方法は単純で実装継承とならない継承機能をRustのようにサポートすればよい 635 名前：デフォルトの名無しさん mailto:sage [2024/07/07(日) 11:31:52.81 ID:Eha1J0DV.net] 当初から、算数の四則演算の型を継承で説明できないことを 知りながら無理を通したぼんくらが流行らせたのだ 難しい算数よりも布教しやすい教義を優先するほうが儲かるという判断 その判断が合理的と思うかどうかは人それぞれ 636 名前：デフォルトの名無しさん mailto:sage [2024/07/07(日) 11:55:49.26 ID:nRN7u0+P.net] 根本的に継承だけの問題じゃない 結局可視であろうがなかろうが関数自体の挙動が理解しないといけない addがあってもリストの一番前に追加するか後ろに追加するかと言う機能の違いが合って コーディングする側がそれを統一的に扱って思った場所に追加されずにバグになる そういう話だからトレイトだからとか継承亡くしたからとかどうとか関係ない 637 名前：デフォルトの名無しさん mailto:sage [2024/07/07(日) 11:59:33.31 ID:kX4AKaVh.net] 継承はなくても良いがあると便利 vs 継承はあってはならない C++は知らなくてもいいが先に知っておくと理解が速い vs C++の理解はいらない こういう境界線のビミョーな議論だと「まだ結論は出てない」と嘯きやすく続けやすいんだろうか 638 名前：デフォルトの名無しさん mailto:sage [2024/07/07(日) 13:43:23.71 ID:7CPxEWjC.net] interfaceはおっけー、abstractは隠蔽されるからだめってことだよ 継承全てが悪というわけではない 639 名前：デフォルトの名無しさん mailto:sage [2024/07/07(日) 13:46:30.77 ID:7CPxEWjC.net] kotlinでもabstractクラスはコード自動生成するときしか書かないもん rustはtraitで十分だし 640 名前：デフォルトの名無しさん mailto:sage [2024/07/07(日) 14:05:34.19 ID:nRN7u0+P.net] rustにも派生はあるじゃん 641 名前：デフォルトの名無しさん [2024/07/07(日) 16:52:52.64 ID:7aG8TPof.net] 大きなプログラムを実際に書かずに、本を読むだけで、この言語のこの仕様は悪いとか良いとか判断できるようになりますか？ 642 名前：デフォルトの名無しさん mailto:sage [2024/07/07(日) 17:13:03.91 ID:KUDE2scl.net] 継承はいらん。 理想(のひとつ)はダックタイプで、継承は実装上の都合でそうなっている妥協の産物でしかない。 643 名前：デフォルトの名無しさん mailto:sage [2024/07/07(日) 17:36:36.74 ID:h+XkpNj2.net] 今まで築いてきた価値観を繰り返し短い言葉で否定して徹底的に壊すというのが洗脳の基本 「継承は悪」「モダンな言語に継承はない」「Rustでは継承による問題は発生しない」(※全部嘘ですよ) 最初に洗脳をはじめた人と違って 洗脳者に洗脳された人は本質を理解していない そればかりか真実かどうかなんてもはやどうでもよく 自分が信じてることだけが真実だと思っている だから議論しようという気もなく一方的に同じことを繰り返し書くだけ 掲示板界隈では身近によくあることなので気をつけようね 644 名前：デフォルトの名無しさん mailto:sage [2024/07/07(日) 18:10:28.88 ID:rdCPsToy.net] 継承はプログラミングで絶対に必要な重要な機能で重複コードを避けることができる ただし継承といっても複数の方法があって実装継承だけは害を招いてしまう 実装継承とは別の型の具体的な実装をそのまま継承してしまうことを指す つまり実装継承をすると二つの型の間に不必要に強力な依存関係が生じてしまう クラス継承でプログラムを書くと自然にこの害悪な実装継承となってしまう そのため様々な異なる方針のモダンな言語が同じ結論に達してクラスを言語仕様から無くした Rustではトレイトを使うことで健全な継承機能のみを使うことができる 特にトレイトのデフォルト実装はどの型にも依存しないため実装継承にならずに健全な継承のメリットを最大限に享受することができる 645 名前：デフォルトの名無しさん mailto:sage [2024/07/07(日) 18:53:59.08 ID:0Udg54Yk.net] >>628 たくさん本を読み自分の頭で考える努力をすればある程度まではなれる ただし実地の経験がなければ最終的には他人の受け売りを判断基準にするしかなく 経験のある人間に比べると妥当な判断ができない状況が多くなる 言語の仕様は一面的に良いとか悪いとかという判断を下せるものはほとんどない 長所短所を把握した上でどういう状況であれば他の仕様に比べて優れていて 逆にどういう状況であれば他の仕様に比べて劣るのかという 状況に合わせた判断が必要 つまり妥当な判断を下せる確率を上げるためには 言語の仕様を把握する力よりもそれが使われる状況を幅広く奥深く想定する力を身につけることが重要 これを本を読むだけで身につけようとしてもすぐに頭打ちになる 646 名前：デフォルトの名無しさん mailto:sage [2024/07/07(日) 19:04:36.65 ID:tn8SIXEe.net] >>622 >算数の四則演算の型を継承で説明できない 詳しく。 647 名前：デフォルトの名無しさん [2024/07/07(日) 19:34:52.42 ID:goRFIXq7.net] >>628 他の言語での開発経験がある人が仕様を見て「この言語のこの仕様は好き/嫌い」と言うことはあると思う どの言語も初心者という人だと無理 それに言語の良し悪しなんて点数で評価できるようなものでないし、好みの問題だったり、ライブラリなどの周辺環境だったり、作りたいもの次第だったりする 648 名前：デフォルトの名無しさん mailto:sage [2024/07/07(日) 21:58:17.95 ID:rdCPsToy.net] 好き嫌いと良い悪いはしっかり区別つけなければならない 他の型との間で不必要に強力な依存関係が生じてしまう実装継承は悪い この実装継承となってしまうクラス継承は悪い Rustに実装継承はなくトレイトを用いることで健全な継承を活用してプログラミングできる 649 名前：デフォルトの名無しさん mailto:sage [2024/07/07(日) 22:26:34.08 ID:rVoIwJvq.net] 受け売り知識しか持たないとこういう感じで論拠薄弱で空疎な意見しか書けなくなる いい反面教師だね 650 名前：デフォルトの名無しさん [2024/07/07(日) 22:51:49.25 ID:goRFIXq7.net] Rustが継承の問題を防げるのってトレイトだけじゃなくてenumの存在も大きいよね 静的ポリモーフィズムを自然に実装できるから、多態のために無理やりインタフェースに当て嵌めようとしたり、ダウンキャストが必要になったりといったものを防げる 本質的に違うものを抽象化しようとして失敗してる例を見たことのある人はそれなりにいるはず 651 名前：デフォルトの名無しさん mailto:sage [2024/07/07(日) 23:03:31.83 ID:Eha1J0DV.net] >>633 整数クラスは分数クラスを継承したいが、分母を表す変数は継承したくない それと文字列 + 文字列が定義されている言語では 分数 + 整数の定義に必要な関数も継承したくない その関数は文字列と無関係だから 652 名前：デフォルトの名無しさん [2024/07/07(日) 23:46:19.40 ID:QlaAOMK5.net] >>638 >整数クラスは分数クラスを継承したいが、分母を表す変数は継承したくない 普通、C++だと、整数クラスを作っておき、 分数クラスはそれを継承せずに、 整数クラスを2つメンバに持つクラス として定義しますよね。 その場合、整数クラスと分数クラスは継承関係を持ってない。 653 名前：デフォルトの名無しさん mailto:sage [2024/07/07(日) 23:51:53.41 ID:gwkq/Sum.net] >>635 クラス継承の問題はある程度の規模でプログラミングしてきた人の多くが体験してきて、 その根本的原因は実装継承にあることが多くのサイトで解説されている通りだけど、 従来の言語ではクラス継承に代わる手段が弱かったり不便であるため、 仕方なく欠陥のあるクラス継承を使い続けてきた不幸� 654 名前：ﾈ歴史があるんだよ。 クラス継承を使わずにすむRustは恵まれてる。 [] [ここ壊れてます] 655 名前：デフォルトの名無しさん mailto:sage [2024/07/08(月) 00:13:34.95 ID:dSFAEVvP.net] >>638 分数クラスを継承して整数クラスを作りたいという要求と 分母を表す変数は継承したくないという要求が矛盾してる 分数クラスを継承して整数クラスを作りたいということは 分数を特化したものが整数であるというモデルを 分数クラスと整数クラスの実装でも作りたいということ そのためには整数クラスにも分母を表す変数が当然必要 矛盾した要求が実現できないのは実装技術の問題ではなく要求の不備 656 名前：デフォルトの名無しさん [2024/07/08(月) 00:24:32.58 ID:aZihrzFg.net] >>607 コード メトリック - 継承の深さ (DIT) https://learn.microsoft.com/ja-jp/visualstudio/code-quality/code-metrics-depth-of-inheritance?view=vs-2022 継承もやりすぎると毒になるってだけで、全くダメってわけじゃない。 657 名前：デフォルトの名無しさん mailto:sage [2024/07/08(月) 00:26:00.53 ID:wE6spjgC.net] >>638 不適切な継承の典型例だな 658 名前：デフォルトの名無しさん [2024/07/08(月) 00:36:15.98 ID:aZihrzFg.net] >>638 数学では整数の組から分数作るけど、整数クラスが親クラスじゃないのは変じゃない？ （そもそも、継承より整数クラスのインスタンスを分子用と分母用の2個使う委譲スタイルの方が適切だと思うけど） (n,m)とn/mは同型 659 名前：デフォルトの名無しさん mailto:sage [2024/07/08(月) 01:24:33.08 ID:QXtalhpf.net] どういう用途のためにクラスを作ろうとしているのか不明瞭な段階で 特定の実装方法が適切だと思い込むのは感心しない 660 名前：デフォルトの名無しさん mailto:sage [2024/07/08(月) 05:17:42.23 ID:9vKk3LiW.net] >>630 継承自体は悪くない 重複コードを回避できて保守性も向上する つまり継承自体は良いもの ただし実装継承だけは悪 異なる型同士に過度な依存をもたらし保守性を悪くする クラス継承は実装継承となるため悪 モダンな各言語がクラスを排除した理由はそのため Rustに実装継承はなく継承でそのような問題を起こさない 661 名前：デフォルトの名無しさん mailto:sage [2024/07/08(月) 09:13:52.72 ID:1Z2Y8mSg.net] 継承で重複コードを回避できるのは実装も共有する継承だけ つまり実装継承だけ Rustスレでこんな初歩的なことを説明しなきゃいけないのはすごく悲しい 662 名前：デフォルトの名無しさん mailto:sage [2024/07/08(月) 09:32:49.17 ID:QAb8fFud.net] 今回はいつまでやるの？ 663 名前：デフォルトの名無しさん mailto:sage [2024/07/08(月) 09:42:44.60 ID:jJBNmhlI.net] >>647 実装継承の意味を理解したほうがいいんじゃね？ ある型Aの実装を別の型Bが継承することが実装継承と呼ばれているんだよ これは不必要に依存関係が強すぎて片方を機能拡張しようとしたときなど破綻を招きがち だから実装継承となるのは避けるべきと言われているね 664 名前：デフォルトの名無しさん mailto:sage [2024/07/08(月) 10:06:04.28 ID:eiH/KN8v.net] ワイの思う継承はenum_dispatch crate でやれるから困ったことないなぁ お前らの心の中の継承は知らんがw 665 名前：デフォルトの名無しさん mailto:sage [2024/07/08(月) 10:42:22.99 ID:UCsocQnW.net] 分数はバカっぽい 有理数と言え 666 名前：デフォルトの名無しさん mailto:sage [2024/07/08(月) 10:42:53.94 ID:29FzOd3r.net] >>647 Rustに実装継承はないけど 継承があり重複コードを回避できている 667 名前：デフォルトの名無しさん mailto:sage [2024/07/08(月) 10:43:30.84 ID:29FzOd3r.net] 例えばどんな型でどんな内部構造でも その型にトレイトのnext関数を実装するだけでイテーレータとして機能するが その時に他のメソッド(nthとかmapとかfoldなど)のコードを自分で書かなくても自動的に継承されて機能する 668 名前：デフォルトの名無しさん mailto:sage [2024/07/08(月) 10:44:27.48 ID:29FzOd3r.net] これをデフォルト実装と言い特定の型の構造に全く依存しないコードのみを書くことができる つまり問題を起こす実装継承とならず Rustでは健全な継承が実現されている 669 名前：デフォルトの名無しさん mailto:sage [2024/07/08(月) 10:55:22.37 ID:6tgHXwg2.net] 複オジの耳に念仏 まさに>>630 670 名前：デフォルトの名無しさん mailto:sage [2024/07/08(月) 11:03:01.23 ID:aq0ZJn08.net] デフォルト実装の制限のかけ方が成功の肝かな トレイトなので各型のメンバーフィールドには一切アクセスできないため実装継承が上手く回避されてる 671 名前：デフォルトの名無しさん mailto:sage [2024/07/08(月) 11:27:47.73 ID:Qb4+6aEo.net] 「実装は継承しているけど実装継承ではない」ｗ 672 名前：デフォルトの名無しさん mailto:sage [2024/07/08(月) 11:38:02.68 ID:0gbetOzk.net] 複オジ論法は無敵だな 673 名前：デフォルトの名無しさん mailto:sage [2024/07/08(月) 11:49:10.64 ID:aq0ZJn08.net] >>657 他の型の実装に実装が依存することが実装継承と呼ばれてる 674 名前：デフォルトの名無しさん mailto:sage [2024/07/08(月) 13:25:29.85 ID:QAb8fFud.net] 継承の本当の問題は、LSPを満たさない部分型関係を作ってしまいがちということ 他の型の実装に依存するのが良くないというのはDIの話で、直接は関係ない 675 名前：デフォルトの名無しさん mailto:sage [2024/07/08(月) 13:56:53.31 ID:0on8bWSc.net] うそん crate製作者サイドでCargo.toml内の 他のcrateへの依存関係の描き方がいい加減だと 割りと頻繁に詰む 人間が追跡して治して行けば使えなくもないが cratesは破綻する可能性がある 676 名前：デフォルトの名無しさん mailto:sage [2024/07/08(月) 15:03:24.53 ID:HJF+848e.net] クレートdownloadでか過ぎ どうみてもどんぐりです ばいばいおさるさん ころころす 677 名前：デフォルトの名無しさん mailto:sage [2024/07/08(月) 17:42:30.38 ID:NWN6grys.net] >>660 クラスを用いる言語では必ず満たすべきLSP(リスコフの置換原則)が頻繁に守られていない現実から GoやRustなどモダンな言語はクラスそのものを廃止して改善したわけだ 他の型の実装に依存するのが良くないのも当たり前の話でそこは各型へ移譲しなければならない 678 名前：デフォルトの名無しさん mailto:sage [2024/07/08(月) 18:36:24.36 ID:jkhWqaDw.net] >>663 LSP全然理解してないんやな クラスの有無とか全く関係ないぞ 679 名前：デフォルトの名無しさん mailto:sage [2024/07/08(月) 18:41:05.12 ID:BP+Tby1x.net] >>657 ジワジワくる 680 名前：デフォルトの名無しさん mailto:sage [2024/07/08(月) 19:00:42.33 ID:lBXxnkJT.net] >>657が実装継承とは何かすら理解できていなくて草 681 名前：デフォルトの名無しさん mailto:sage [2024/07/08(月) 23:32:15.60 ID:HOKpNi7I.net] 所有権といい継承といいLSPといい 某オジは抽象概念を捻じ曲げるスキルが高すぎだろ 682 名前：デフォルトの名無しさん mailto:sage [2024/07/09(火) 00:42:48.79 ID:m6Akkl5N.net] >>660 LSPは派生型がその基底型を継承する時その振る舞いは同じで代替できるという当たり前な話なんだが クラスはこの件でも欠陥があるため意識してプログラムを書かないとLSPに反してしまう Rustはクラスがなくトレイトは枠組みだけで基底型ではないためLSPは全く関係ないぞ 683 名前：デフォルトの名無しさん mailto:sage [2024/07/09(火) 02:24:36.95 ID:ZNKPIxXk.net] >LSPは派生型がその基底型を継承する時その振る舞いは同じで代替できるという当たり前な話なんだが 0点 684 名前：デフォルトの名無しさん mailto:sage [2024/07/09(火) 11:02:57.90 ID:Gz8hLZg7.net] 書けば書くほど無知をさらしてしまう複製オジさん草る 685 名前：デフォルトの名無しさん mailto:sage [2024/07/09(火) 12:31:29.17 ID:B8U2Xwe0.net] >>664 対象となるものはクラスしかないよね 686 名前：デフォルトの名無しさん mailto:sage [2024/07/09(火) 12:39:43.65 ID:YflJELWV.net] >>668 φ(x) を型 T のオブジェクト x に関して証明可能な性質とする。このとき、φ(y) は型 T のサブタイプ S のオブジェクト y について真でなければならない。 φは主に事前条件・事後条件・不変条件で、言語によっては例外条件も入ってくる。 この観点からはRustのTraitは力不足。なんでLSPを引き合いに出せるのかわからん。 687 名前：デフォルトの名無しさん mailto:sage [2024/07/09(火) 12:57:46.02 ID:aoAam1/W.net] >>672 自分でそれを書いておいて理解できていないのかよ そこに明記されてるようにTもSもオブジェクトを持つ具体型についての話だ Rustのtraitは具体型ではないため関係ないぞ そしてtraitを実装する各型の間にはサブタイプの関係はないためそこも対象とならない そこを理解できずに「RustのTraitは力不足」とデタラメを吹聴するのは恥ずかしい 688 名前：デフォルトの名無しさん mailto:sage [2024/07/09(火) 13:01:26.64 ID:YflJELWV.net] >>673 事前条件とかはどこ行ったの？ 689 名前：デフォルトの名無しさん mailto:sage [2024/07/09(火) 13:20:56.23 ID:aoAam1/W.net] >>674 φ(x) のxはオブジェクトと明記されてるのが見えないのかね さらにSはTのサブタイプと明記されている Rustのtrait自体はオブジェクトを持たない さらにtraitを実装する二つの型同士にサブタイプの関係は生じない つまり対象外でφが存在しないため事前条件も何もない 690 名前：デフォルトの名無しさん mailto:sage [2024/07/09(火) 13:35:41.29 ID:YflJELWV.net] >>675 ＞明記されてるのが見えないのかね ＞Rustのtrait自体はオブジェクトを持たない それは「RustのTraitはLSPと関係ない」と言いたいの？ ＞φが存在しないため事前条件も何もない 事前条件も何も表明できないのは「力不足」そのものですな。 691 名前：デフォルトの名無しさん mailto:sage [2024/07/09(火) 14:43:14.46 ID:Tc+iYmTn.net] リファクタリングするとき プログラム(CPU)の動作の副作用は起きないけど コーディングの変更に対して副作用が大き過ぎるというか広過ぎる 692 名前：デフォルトの名無しさん mailto:sage [2024/07/09(火) 15:17:32.29 ID:l7dFkPpL.net] >>673 マジでLSP全然理解してないんやな LSPは具体型かどうかなんて全く関係ないぞ 693 名前：デフォルトの名無しさん mailto:sage [2024/07/09(火) 15:20:15.91 ID:aoAam1/W.net] >>676 LSPに明記されている前提すら満たさない異なるものであるため 「RustのTraitはLSPと関係ない」で合っている LSPが対象としている遺物における諸問題に悩まされずに済むように 新たな視点で整理されたより良いものとしてRustのTraitが提供されている 694 名前：デフォルトの名無しさん mailto:sage [2024/07/09(火) 15:28:08.29 ID:aoAam1/W.net] >>678 LSPは具体型のみが対象 抽象型を対象にしようとしても適用するにはそのいずれかの具体型となる 695 名前：デフォルトの名無しさん mailto:sage [2024/07/09(火) 17:53:13.80 ID:uNqr/AfO.net] https://x.com/shuzaibusoku7/status/1809567812555542920 リアル複おじ 696 名前：デフォルトの名無しさん mailto:sage [2024/07/09(火) 20:23:57.43 ID:YflJELWV.net] >>679 RustとLSPが関係ないのなら、LSPを引き合いに出すのは大嘘か。 知ってて言っているなら詐欺師だな。 そもそもTraitでpanic禁止にできない時点で「LSPが対象としている遺物における諸問題に悩まされずに済む」というのも大嘘だしな。 697 名前：デフォルトの名無しさん mailto:sage [2024/07/09(火) 20:49:10.75 ID:sTXYSGuF.net] 簡単な話だよな オブジェクト指向プログラミングで 例えばクラスを使うと LSPに違反する二つの型のコード例を容易に作れてしまう つまりクラスは本質的に欠陥品なんだよ Rustのトレイトを使うと LSPに違反する二つの型のコード例を作ることができない つまりRustのトレイトは優れた方式なんだよ 698 名前：デフォルトの名無しさん mailto:sage [2024/07/09(火) 21:07:20.42 ID:YflJELWV.net] >>683 あるトレイトでpanic2を禁止しようとしました。事前条件(あるいは例外条件)でnopanicとしたかったけど、そんなのは無いのでとりあえずデフォルト実装でpanic禁止にしました。 しかしトレイトユーザーはそんなのお構い無しにunsafe rustでpanicを使います。ついにpanicが発生してシステムダウンしました。 LSPでケアしている問題はRustのTraitを使っている限り発生しないんじゃないんだっけ？ 699 名前：デフォルトの名無しさん mailto:sage [2024/07/09(火) 21:56:05.19 ID:sTXYSGuF.net] Rustのトレイトは優れているため LSPに違反するコード例を作ることができないんだよ もしRustに文句をつけたかったら LSPに違反する二つの型のコード例を作って示してごらん Rustで違反例を作るのは不可能だよ 700 名前：デフォルトの名無しさん mailto:sage [2024/07/09(火) 22:08:43.14 ID:ZNKPIxXk.net] >>685 Rustに文句をつけたいとかではなく >>660でLSPに言及された途端に実装継承とか言わなくなって「最初から自分はLSPを理由に継承のダメさを語ってましたけど」って態度でイキリ倒してるの(+結局理解してなさそうなの)がバカにされとるんやで 701 名前：デフォルトの名無しさん mailto:sage [2024/07/09(火) 22:36:56.01 ID:YflJELWV.net] >>685 >>684みたいに、 トレイトがpanicを禁止したいのに、ユーザーのトレイト実装がpanicを返す というのはLSP違反だろ。 702 名前：デフォルトの名無しさん mailto:sage [2024/07/09(火) 22:44:26.63 ID:loMF79su.net] LSPはそんなことを要求していないよ LSPをちゃんと読んで理解しようね 703 名前：デフォルトの名無しさん mailto:sage [2024/07/09(火) 22:50:55.17 ID:aoAam1/W.net] >>686 クラスは様々な問題点を抱えている クラスでは実装継承となるため異なる型同士に不必要に過度な依存関係をもたらす硬直性も問題点の一つ クラスはLSP(リスコフの置換原則)を満たさないプログラムが量産されてしまう問題点も別の一つ どちらの問題点もRustならtraitを使うため問題が起きない 704 名前：デフォルトの名無しさん mailto:sage [2024/07/09(火) 22:52:12.26 ID:j8eVmrRh.net] 猿ども落ち着いてください！ ここで論破合戦したところでなんの得にもなりません 705 名前：デフォルトの名無しさん [2024/07/09(火) 22:57:23.83 ID:/lHavWP5.net] >>685 リスコフの置換原則は設計的な原則だから言語仕様で違反を防ぐことはできないぞ 悪名高い長方形・正方形の問題はトレイトがあっても起こり得る trait Rectangle { 　fn set_width(&mut self, width: i32); 　fn set_height(&mut self, height: i32); 　fn width(&self) -> i32; 　fn height(&self) -> i32; 　fn area(&self) -> i32 { self.width() * self.height() } } struct Square { len: i32 } impl Rectangle for Square { 　fn set_width(&mut self, width: i32) { self.len = width; } 　fn set_height(&mut self, height: i32) { self.len = width; } 　fn width(&self) -> i32 { self.len } 　fn height(&self) -> i32 { self.len } } fn func(x: &mut impl Rectangle) { 　x.set_width(3); 　x.set_height(4); 　// xが長方形であれば以下が成り立つはずだが、Square型を渡された場合に失敗する 　assert!(x.area() == 12); } 706 名前：デフォルトの名無しさん mailto:sage [2024/07/09(火) 23:17:09.97 ID:dptasXVA.net] >>691 長方形がトレイトで正方形が構造体とか意味不明なんだが他の形はどっちにするんだ？ おかしいだろ 707 名前：デフォルトの名無しさん mailto:sage [2024/07/09(火) 23:22:06.46 ID:J+Fyw0mO.net] >>691 トレイトは機能を表します 2つの異なる長さを持つ(受け取る)機能を定義しているのならば 正方形はその実装型にはなりえません 708 名前：デフォルトの名無しさん [2024/07/09(火) 23:24:11.46 ID:KAvgjhF7.net] >>692 IRectanble トレイトとかに読み替えてくれ これは設計的に問題のある例を恣意的に示しているので不自然な点はあるけど、意図は伝わると思う 分かる人は分かると思うけど、問題は「そもそも正方形はwidthとheightという2つの値を扱うインタエースを持つべきでない」というところなので、Rectangleトレイトを作った時点で破綻している けどそれは設計の問題なので、トレイトという仕組みによってコンパイラが防げるものではないということ 709 名前：デフォルトの名無しさん [2024/07/09(火) 23:30:16.52 ID:KAvgjhF7.net] >2つの異なる長さを持つ(受け取る)機能を定義しているのならば >正方形はその実装型にはなりえません 論理的にはそう でも実際にそういうコードを書けばビルドは通る >>685 で >LSPに違反する二つの型のコード例を作って示してごらん >Rustで違反例を作るのは不可能だよ とあったので、これはその反例として示した このような問題は設計の問題であり、まずい設計をする人が使えばRustでも問題は起こり得るということを言いたい 710 名前：デフォルトの名無しさん mailto:sage [2024/07/09(火) 23:35:35.51 ID:h2DmPYHm.net] >>691 君はLSPを理解できていない LSPはis-aの関係を持つ二つの型に対して遵守すべきルールだ Rustのtraitとその実装型はis-aの関係ではなくhas-aの関係を持つ したがってtraitとその実装型は明らかにLSPの対象外となる 711 名前：デフォルトの名無しさん mailto:sage [2024/07/09(火) 23:40:48.87 ID:h2DmPYHm.net] >>695 LSPに違反する二つの型はis-aの関係を持つsupertypeとsubtypeでなければならない >>691はhas-aの関係なのでLSPに違反する二つの型のコード例とはなっていない 712 名前：デフォルトの名無しさん mailto:sage [2024/07/09(火) 23:56:35.46 ID:ZNKPIxXk.net] >Rustのtraitとその実装型はis-aの関係ではなくhas-aの関係を持つ すげーのが出てきたなこりゃｗ 713 名前：デフォルトの名無しさん mailto:sage [2024/07/09(火) 23:59:12.82 ID:loMF79su.net] LSPはis-a関係に対して守るべき原則 has-a関係に対してLSPの適用は論外 コード>>691はLSPの違反例となっていない 714 名前：デフォルトの名無しさん mailto:sage [2024/07/10(水) 00:09:07.13 ID:H4rrLaXL.net] メンバ関数名をそのままtraitの名前にしちまえば そのメンバを持つ者とtraitの関係はhas-a 715 名前：デフォルトの名無しさん [2024/07/10(水) 00:10:24.05 ID:HryWiaEt.net] 過去に見た (rust以外の) プロジェクトの失敗例だと ・もともとFooというクラスがあった ・新しく作るBooクラスについて、Fooクラスと同じように扱えれば既存コードをあまり変更しなくても済むぞ！と誰かが気づいた ・その人物は Foo クラスのメソッドを元に IFoo インタフェースを定義し、それを Foo と Boo に実装させた ことから混沌としたコードが生まれた例がある この失敗をやらかした人は、Rustでも同じように「既存の Rectangle クラスを元に IRectangle トレイトを作り、それを Rectangle と Square に実装させる」ことをやりかねない Rustではそれが不自然なパターンになりやすいし、起こりにくくはあるけど、本質的には設計の問題 716 名前：デフォルトの名無しさん [2024/07/10(水) 00:29:11.77 ID:HryWiaEt.net] 「Rustを書く人はみんな賢いからそのような問題は起こさないはずだ」というなら話は別たけど 実装者の設計能力は言語仕様によって担保できるものではない 717 名前：デフォルトの名無しさん mailto:sage [2024/07/10(水) 00:33:23.92 ID:L/ekmjSC.net] >>701 それらインタフェースやトレイトを用いている時点でLSPの対象外となっている LSPを満たす必要がないどころかそんな制限があったら支障が出る >>691のコードをLSP違反例として出してきたのは明確に間違い おバカな設計例としてならば理解する 718 名前：デフォルトの名無しさん mailto:sage [2024/07/10(水) 00:35:49.38 ID:L/ekmjSC.net] >>702 おバカな設計を言語仕様で防げるなんて主張は誰もしていない あなたが勘違い思い込みで暴走している 719 名前：デフォルトの名無しさん mailto:sage [2024/07/10(水) 00:36:32.00 ID:NGyo+F/O.net] LSPを全く理解してないばかりか サブタイピングも理解しとらんのやな よう継承継承言うたなぁｗ 720 名前：デフォルトの名無しさん mailto:sage [2024/07/10(水) 00:53:28.80 ID:ur6BKR72.net] クラスが問題だらけの欠陥品なことが災いを招いてるよね モダンなプログラミング言語の多くがクラスを捨て去ってくれて感謝 721 名前：デフォルトの名無しさん mailto:sage [2024/07/10(水) 01:13:16.99 ID:1XduDtMr.net] >>688 >>679の言う「LSPが対象としている遺物における諸問題に悩まされずに済むように」するためには必要なんだよ。 LISKOVのA behavioral notion of subtyping でも「include exception」と言っているだろ。 まぁ、panicが例外にもなれないそびえ立つクソだからRustから排除すべき、と言うなら同意するが。 722 名前：デフォルトの名無しさん mailto:sage [2024/07/10(水) 01:26:45.94 ID:UJdk5M3g.net] >>707 LSPはsuperclassとsubclassといったような関係を持つ型同士について満たすべき話が書かれてるんよ その前提を無視してpanicがどうこう言い出してるからズレとるんよ 723 名前：デフォルトの名無しさん mailto:sage [2024/07/10(水) 01:45:22.45 ID:1XduDtMr.net] >>708 それを言うなら>>682で言っている通り、RustのTraitでLSPに言及するのが大嘘なんだよ。 RustのTraitは同じTraitでも簡単に異なる振る舞いを実装できる(panicみたいな致命的な振る舞い含め)のに、「LSPが対象としている遺物における諸問題に悩まされずに済む」とかの大嘘が出てくるのは何ともアホらしい話。 724 名前：デフォルトの名無しさん mailto:sage [2024/07/10(水) 02:13:28.47 ID:1XduDtMr.net] >>698 RustのTraitとImplの関係はまさしくsubtypeだしis-aの関係なのにな。「継承しなければsubtypeじゃないしis-aにもならない」と間違って覚えているんかね。 725 名前：デフォルトの名無しさん mailto:sage [2024/07/10(水) 02:30:31.13 ID:GS4KrVsy.net] どこかで聞きかじっただけの「継承は悪」に辻褄を合わせようとしてどんどん変な理屈を積み重ねているだけでしょ 726 名前：デフォルトの名無しさん mailto:sage [2024/07/10(水) 02:33:48.76 ID:H5PXuDT2.net] >>707 LSPでは例外を返すなら基底型で返す例外とそのサブタイプのみに限られるとしか言及していない 例外で値をキャッチできなくなることや値を返す抜け道になることを防ぐためだ ちなみにRustのpanic!では値を返すことはできなくてpanicメッセージのみ そして普通のプログラムでpanicをキャッチすることはない点など前提が全く異なる Rustで従来の例外を扱うケースはpanic!を使わずにResultの返り値で返す したがってpanic!はLSPで出てくる例外の話に該当しないだろう 727 名前：デフォルトの名無しさん mailto:sage [2024/07/10(水) 03:06:35.71 ID:mzDH1NTP.net] >それらインタフェースやトレイトを用いている時点でLSPの対象外となっている 間違ってるよ インターフェースだろうがトレイトだろうがサブタイピングは成立するよ サブタイピングが成立すれば当然LSPの対象範囲だよ >>691の例もLSPの違反例としては合ってるよ 間違った継承の使い方の例としてよく使われてるよね 728 名前：デフォルトの名無しさん mailto:sage [2024/07/10(水) 04:10:08.62 ID:xXJVwGE7.net] >>684 >panic禁止にしました。 たとえno_std環境であろうとpanicは禁止にできない >unsafe rustでpanicを使います。 panicを引き起こすのも扱うのもunsafeを必要としない >panicが発生してシステムダウンしました。 panic発生がそのままシステムダウンではない 何ら特別な設定をしない標準状態でもスレッド内で起きたpanicはエラーとして返るだけで他のスレッドは動き続ける 729 名前：デフォルトの名無しさん mailto:sage [2024/07/10(水) 07:01:39.33 ID:H4rrLaXL.net] >>710 型クラスのinstanceであると宣言すればsubtypeじゃないのは自明だぜ じゃあtraitをimplすると宣言したら 自明だった問題が突如として最先端の未解決問題に変化するのか？ しないでしょ 同じでしょ 730 名前：デフォルトの名無しさん [2024/07/10(水) 07:02:08.59 ID:HryWiaEt.net] >>704 ずっと「オブジェクト指向言語のクラスが抱えている問題はRustでは起こらない」と主張してる人がいるでしょ それに対して、そんなことはないよと言ってるだけ 731 名前：デフォルトの名無しさん mailto:sage [2024/07/10(水) 07:35:50.92 ID:1hn7S5X0.net] >>716 あらゆる問題が解決されたという話は出てないでしょ クラスが抱えてる問題でRustによって解決されてる様々な例が出ているだけで 732 名前：デフォルトの名無しさん mailto:sage [2024/07/10(水) 08:46:54.18 ID:1XduDtMr.net] >>714 だからLSPが対象としている諸問題はRustじゃ解決しないと主張しているんだよ。 >>715 implの実装次第なのに、 「LSPが対象としている遺物における諸問題に悩まされずに済む」と言っているアホが居るのよ。 そんな機能はRustのTrailには無いわな。 >>717 「遺物における諸問題に悩まされずに済む」と言っているアホが居るのよ。しまいにはRustとLSPは関係無いとか言うし。 そんなわけ無いだろと主張している。 733 名前：デフォルトの名無しさん mailto:sage [2024/07/10(水) 12:00:16.62 ID:GhKm8r1f.net] >>718 そのアンカ先は全部複オジだろ LSPも知らない、サブタイピングも知らない、継承で起こりうる簡単な問題も知らない にもかかわらず知ったかぶりして嘘を並び立てる こんなやつがそうそういるわけがない 734 名前：デフォルトの名無しさん [2024/07/10(水) 12:37:44.86 ID:1YSFCzN+.net] キチガイは1人見かけたら10人はいると思え 735 名前：デフォルトの名無しさん [2024/07/10(水) 13:29:52.02 ID:kPG9kWdt.net] >>701 そのやり方がなぜ悪いのか理解できませんので、教えてください。 例えば、C++だと、以下の様にするのも別に悪いやり方ではないような 気がするのですが。 class Number {・・・}; Number add(Number &a, Number &b); Number mul(Number &a, Number &b); class Integer : public Number {・・・}; class Rational : public Number {・・・}; 736 名前：デフォルトの名無しさん mailto:sage [2024/07/10(水) 13:32:41.05 ID:2GPD5dJ4.net] ChatGPTってモノシリなんですね？ 737 名前：デフォルトの名無しさん [2024/07/10(水) 13:34:42.29 ID:kPG9kWdt.net] >>721 改めて見てみると、add()やmul()の戻り値にNumberの実態を返しているのがおかしい気もしますが。 IntegerやRationalにadd()やmul()を仮想関数として定義するのが良いのかもしれません。 そのような点で改良の余地が沢山ありそうです。 738 名前：デフォルトの名無しさん mailto:sage [2024/07/10(水) 13:47:33.33 ID:2GPD5dJ4.net] >>720 色んな板の色んなスレをみて来ているが どこにでもいるのは事実 739 名前：デフォルトの名無しさん mailto:sage [2024/07/10(水) 14:42:18.00 ID:H4rrLaXL.net] 10人いると思ってる人自身が11人目になりやすいから気をつけなよ 数値の計測が抱えている問題は、そもそも計測していない人には起こらない 740 名前：デフォルトの名無しさん mailto:sage [2024/07/10(水) 15:49:38.80 ID:WriLZMcZ.net] >>721 add(integer, rational)できる？ 741 名前：デフォルトの名無しさん mailto:sage [2024/07/10(水) 16:24:23.57 ID:2GPD5dJ4.net] ミイラとりがミイラになるのは昔から 742 名前：デフォルトの名無しさん mailto:sage [2024/07/10(水) 16:42:16.40 ID:aw6hROvm.net] >>712 >例外で値をキャッチできなくなることや値を返す抜け道になることを防ぐためだ 違うよ 勝手な想像でLSPを誤解釈しないで substituteされる型Tに対して定義された仕様上(契約上)の振る舞いを substituteする型Sが満たしてなければLSP違反 つまり仕様上panicを禁止したトレイトの関数を panicする関数でimplしたらLSP違反 743 名前： LSPではあくまで”仕様上定義された振る舞い”が問題 [] [ここ壊れてます] 744 名前：デフォルトの名無しさん mailto:sage [2024/07/10(水) 18:28:13.04 ID:/bwWoePd.net] >>728 panicを禁止という概念も方法もなく不可能だよ 何をしたいの？ 745 名前：デフォルトの名無しさん mailto:sage [2024/07/10(水) 21:04:08.95 ID:H4rrLaXL.net] catchするという対案がない 対案との比較が抱えている問題はそもそも対案がない言語では起こらない 746 名前：デフォルトの名無しさん mailto:sage [2024/07/10(水) 21:42:13.36 ID:DHf/HCo5.net] >>729 そいつはRust叩きで連投していた>>684 panicを禁止できると思い込み unsafeを使うとpanicできると思い込んでいる 747 名前：デフォルトの名無しさん [2024/07/10(水) 22:01:49.20 ID:HryWiaEt.net] >>721 「インタフェースを定義し、それに基づいて実装する」という設計なら問題ないのだけど、 これは「あるクラスに依存していたコード群が新しいクラスでも動くようにするため」という発想になっており、大規模な開発だとこのやり方はだいたい失敗するよという話 例を書きづらいけど、例えば「A社製の装置を制御するアプリ」があったとして、 新しく「B社製の装置も制御できるようにする」という追加の開発案件があったとする。 この時点ではまだADeviceControllerは抽象化されておらず、A社装置の仕様に強く依存したクラスであるとする。 これを「ADeviceController が持つメソッドを IDeviceController として取り出し、それを BDeviceControllerにも実装させる」とすると確実に事故る。 「B社装置にだけある機能Xを呼びたい」「A社装置にあった機能YがB社装置にはない」といった違いを吸収しきえれず、インタフェースがぐちゃぐちゃになったり、「呼んでも何もしない」とかの形で誤魔化したり、呼び出し元でサブクラスの判定が必要になったりする こうならないようにするには a. 具体的な機器に依存しない、機器の振る舞いを適切に抽象化したインタフェースを定義する b. 代数的データ型を使う という方法があり、 Rust では b. の方法も使いやすいので、個人的にはそこが良いなと思う 748 名前：デフォルトの名無しさん [2024/07/10(水) 22:15:46.44 ID:b9m+kH0p.net] 設計が悪いといえばその通りなんだけど、そのせいでインタフェースが崩壊しているプロジェクトは実際にあるし、RustやGoが継承を廃止した理由の一つでもあると思う クラス継承だとこの問題はもっと簡単に起こりやすい 前述の例は (あくまでも見かけ上は) インタフェースを定義しており、クラスを継承してるわけではないので、Rustのトレイトでもやろうと思えば起こるけどね 749 名前：デフォルトの名無しさん mailto:sage [2024/07/10(水) 22:19:25.73 ID:FlmWdBd4.net] 言語を選ぶにあたって継承の有無は選択肢に入らんし正直言ってどうでもいいわ 代替手段があるのにいつまで言ってんだ 750 名前：デフォルトの名無しさん mailto:sage [2024/07/10(水) 22:32:22.87 ID:dGMDZq55.net] >>729 仕様を定義するという簡単なお話がほんとにわからないのかな？ panicを例にすると頭がパニクるみたいなので リスコフの論文にあるFIFO/LIFOの例で言い換えると 仕様としてLIFOの振る舞いを要求するトレイトの関数を FIFOの振る舞いで実装したらLSP違反ってこと 簡単なお話でしょ？ 751 名前：デフォルトの名無しさん mailto:sage [2024/07/10(水) 22:40:16.17 ID:H4rrLaXL.net] 既に言語を選んだのにまだ、is-aとhas-aどっちにするか選べとか catchするかしないか選べとか 言語の内部でいつまでも選択が繰り返されるシステムが謎なんよ いつまで言われるかといえば謎が解けるまでだよ 752 名前：デフォルトの名無しさん mailto:sage [2024/07/10(水) 23:21:18.85 ID:visgGGe9.net] >>732 それは共通インターフェースと特定装置にしかないインターフェースをそれぞれ別で用意すべきだと思う 拡張メソッドや拡張トレイトも活用する ただA社装置もB社装置も1つの共通したコードで扱うなら サブクラス判定ではないにしても呼び出し元での分岐は何かしら必要 753 名前：デフォルトの名無しさん mailto:sage [2024/07/10(水) 23:44:27.81 ID:6pwTfhEs.net] >>733 RustやGoは違う方法で継承を行っているというだけで継承を廃止したというのは誤解 わざと誤解 754 名前：させてるという面もあるにはある [] [ここ壊れてます] 755 名前：デフォルトの名無しさん mailto:sage [2024/07/11(木) 00:29:09.09 ID:dTTJ6k+i.net] クイズ JavaScriptのプロトタイプチェーンはis-a？ それともhas-a？ 756 名前：デフォルトの名無しさん mailto:sage [2024/07/11(木) 00:30:41.75 ID:sJ7PGs8/.net] >>732 一般的に何らかの上位層と下位層があるときに Rustではその界面にtraitを置いて 上位層はそのtraitを利用する側 下位層はそのtraitを実装する側 とSILIDのDIP (Dependency Inversion Principle)にするのがそのa.だね もしクラスでやるときは抽象化を徹底した上で色んな注意が必要になるところ Rustは自然にコーディングできてありがたいね 757 名前：デフォルトの名無しさん mailto:sage [2024/07/11(木) 01:01:01.84 ID:sJ7PGs8/.net] スマソ SILIDはSOLIDのタイポ 758 名前：デフォルトの名無しさん mailto:sage [2024/07/11(木) 01:26:06.15 ID:sLOW5r2m.net] >>740 インターフェース知らないの？ 759 名前：デフォルトの名無しさん mailto:sage [2024/07/11(木) 01:37:36.53 ID:sJ7PGs8/.net] >>742 インタフェースは各言語で付加仕様がバラバラ多種多様だから慎重に言うと それ自体はフィールド変数など持たず完全に抽象化できつつ 実装必須メソッドとデフォルト実装提供メソッドがサポートされて その中で利用可能な他のインタフェース(またはtrait)群による制約ができて となるとどの言語が残るかな 760 名前：デフォルトの名無しさん mailto:sage [2024/07/11(木) 03:34:06.04 ID:huEwUyFV.net] それはたぶんDじゃなくてIかな…… 761 名前：デフォルトの名無しさん [2024/07/11(木) 09:53:46.09 ID:TzM2Jqw+.net] https://doc.rust-jp.rs/ 終了の件 762 名前：デフォルトの名無しさん mailto:sage [2024/07/11(木) 11:33:08.04 ID:gcQpVY2c.net] >>744 DもIも両方関係あるよ 763 名前：デフォルトの名無しさん mailto:sage [2024/07/11(木) 11:36:08.08 ID:gcQpVY2c.net] >>743 インターフェースが使えるメジャーな言語は全部残る C#, Java, Kotlin, Swift, TypeScript, Dart 764 名前：デフォルトの名無しさん mailto:sage [2024/07/11(木) 11:46:30.35 ID:ITTQebkb.net] ʕ◔ϖ◔ʔ 765 名前：デフォルトの名無しさん mailto:sage [2024/07/11(木) 12:31:18.41 ID:QtPgEU0q.net] >>747 ウソはあかん 766 名前：デフォルトの名無しさん mailto:sage [2024/07/11(木) 13:53:08.83 ID:gabJiib7.net] >>747 サーバー用途で強いJavaは残るね Kotlin/Swiftもモバイルアプリのネイティブ言語として残る TSはJSで十分っていう風潮が漂いつつあるけどまあ残るだろう 死ぬのはC#とDartかな 767 名前：デフォルトの名無しさん mailto:sage [2024/07/11(木) 14:12:48.49 ID:0oGtZVd6.net] LSPで嘘ばっかりついてたのがバレたから またしょうもない話をはじめてごまかそうとしてるのか いい加減にしろよ 768 名前：デフォルトの名無しさん mailto:sage [2024/07/11(木) 16:22:35.45 ID:o6wwWo1Z.net] LSPに書かれていることすら読まずに RustのトレイトがLSPの対象だと言い張ってたもんな 769 名前：デフォルトの名無しさん mailto:sage [2024/07/11(木) 16:57:46.28 ID:acwFdQNv.net] PartialOrdとPartialEqの一貫性とかLSPっぽいけど Substitution（置換）とはちょっと違うんだよな 無理矢理Sに当てるならSurrogation（代用）あたりか これをLSPに含めるかは定義重視vs意味重視で意見が分かれそう 770 名前：デフォルトの名無しさん mailto:sage [2024/07/11(木) 17:15:40.81 ID:HnhcW2rv.net] LSPはsupertypeのインスタンス(オブジェクト)とsubtypeのインスタンスの振る舞いを比較してそこで満たすべき原則を挙げていますから Rustのtraitをsupertypeとしてみてもそのインスタンスが存在しないため振る舞いの比較ができないですね traitはLSPとは関係ない立ち位置にいます 771 名前：デフォルトの名無しさん [2024/07/11(木) 20:33:40.77 ID:eOImp5ti.net] ごちゃごちゃ難しいこと考えてるうちにエンバグしたりなんかして。 772 名前：デフォルトの名無しさん mailto:sage [2024/07/11(木) 21:02:05.21 ID:qBSAH7HU.net] >>750 サーバー用途こそJavaはRustとGoに蹴散らされて終わるだろ 773 名前：デフォルトの名無しさん mailto:sage [2024/07/11(木) 21:30:58.09 ID:wPVHCKh0.net] 実際のところRustはサーバーサイドで使われてるの？ 774 名前：デフォルトの名無しさん mailto:sage [2024/07/11(木) 22:25:27.54 ID:A0mL7vqg.net] 実際は派生クラスの方が支持されていたとしても基底クラスを蹴散らしてはならない とLSPは言っている 775 名前：デフォルトの名無しさん mailto:sage [2024/07/11(木) 22:35:40.65 ID:Z3SFRt47.net] >>757 使われてないよ 776 名前：デフォルトの名無しさん mailto:sage [2024/07/11(木) 22:47:57.53 ID:Wdw77EAw.net] >>757 Rust利用のトップがウェブのサーバー側 この件は過去スレでも何度も出ているので興味あるなら見るといいよ その理由も明白でリソースコスト削減が最も効くため 777 名前：デフォルトの名無しさん mailto:sage [2024/07/11(木) 22:50:39.98 ID:wG+w8SXo.net] サーバーは常時稼働させるものだからねえ 778 名前：デフォルトの名無しさん mailto:sage [2024/07/11(木) 23:16:00.08 ID:liPsU6bJ.net] >>757 GAFAMとかCloudflareとかトラフィックの多いとこに入ってるから誰もが必ずお世話になってる程度には使われてる 日本でサーバーサイドの仕事が沢山あるか、という意味ならそんなことはない 779 名前：デフォルトの名無しさん mailto:sage [2024/07/11(木) 23:24:11.59 ID:b01V4j67.net] 世界中で着実にRustへ置き換わっていってるね 特にクラウドを利用しているとランニングコストに直結するので 780 名前：デフォルトの名無しさん mailto:sage [2024/07/12(金) 00:13:00.93 ID:0qGKBZrU.net] >>753, 754 トレイトの場合はLSPで言うsupertypeやsubtypeになるのは トレイトを利用して作られるimpl Traitやtrait objectの型だよ PartialOrd/PartialEqやFn/FnMut/FnOnceのように supertrait/subtraitの関係にあるやつも便宜的にトレイトで互換性が語られるけど 実際はそれらを利用して作られる型についての話なのと同じなんだよ 781 名前：デフォルトの名無しさん mailto:sage [2024/07/12(金) 00:16:45.77 ID:U8/iJiIO.net] >>764 真面目に相手してあげるの偉いな 782 名前：デフォルトの名無しさん mailto:sage [2024/07/12(金) 00:19:01.43 ID:iZsWh24v.net] >>764 いいえ traitが実装される具体的な型は全てsubtypeに相当する兄弟同士であるため 親となるsupertypeの具体的な型はありませんはありません 783 名前：デフォルトの名無しさん mailto:sage [2024/07/12(金) 00:19:49.06 ID:iZsWh24v.net] >>764 いいえ traitが実装される具体的な型は全てsubtypeに相当する兄弟同士であるため 親となるsupertypeに相当する具体的な型はありません 784 名前：デフォルトの名無しさん mailto:sage [2024/07/12(金) 00:47:16.73 ID:KyXC0KGT.net] トレイトにはフィールド変数が一つもなくてメソッドも各個別型で実装されるものだから事前条件・事後条件など比較もできなくてLSP適用は無理でしょ >>764 supertrait/subtraitの場合に例えばある構造体についてそのインスタンスはどちらも同一になるからLSPの前提である二つのインスタンス間での差は論じられないでしょ 785 名前：デフォルトの名無しさん mailto:sage [2024/07/12(金) 09:52:35.34 ID:bw8b12Bg.net] >>757 Rustは殆どどこにも使われてないよ 786 名前：デフォルトの名無しさん [2024/07/12(金) 10:23:09.62 ID:LuKbokrL.net] 「C言語は分かる。機械語も分かる、回路もわかる。30万払うからRustのメモリ安全のからくりをサクッとレクチャーしてくれ」 みたいなニーズがあっさり無料で満たされているべきだと思うんだ 787 名前：デフォルトの名無しさん mailto:sage [2024/07/12(金) 10:57:31.20 ID:KyXC0KGT.net] 誤解は色々あるけど「努力すれば必ずゼロコストになるカラクリ」が あると思ってるならそれが誤解だね クイックソートやハッシュテーブルと同じく、最悪の場合のコストは低くない 788 名前：デフォルトの名無しさん mailto:sage [2024/07/12(金) 11:16:56.09 ID:LuKbokrL.net] 間違ってたら指摘してくれ メモリは唯一の所有者を持つ 所有者たる変数がスコープを抜けた時、もしくは所有者たる変数に他の値が代入された時、メモリは自動的に解放される Rustの、メモリに関する様々な文法はひとえにレキシカルライフタイムのためである レキシカルライフタイムすなわち字句的寿命は、プログラムを走らせなくともコンパイル時に変数の寿命が把握できる仕掛けである メモリの使途に矛盾が発生しているとき、Rustコンパイラはエラーを吐く 789 名前：デフォルトの名無しさん mailto:sage [2024/07/12(金) 11:28:19.38 ID:LuKbokrL.net] そもそも動的メモリ確保一般を知っていますかって話で、 この質問にイエスと答えられる人は横着ができるべき 790 名前：デフォルトの名無しさん mailto:sage [2024/07/12(金) 13:01:13.97 ID:KyXC0KGT.net] >>771 Rustのゼロコスト抽象化はそういう意味ではなくてRustの様々な抽象化仕様を実行時の追加コストゼロで実現していることでしょ >>772 値がムーブされないままスコープが尽きたらデストラクタが自動で呼ばれるだけでしょ だからRcのように参照カウンタを用いて共有ownershipを提供する仕組みもあるよ 791 名前：デフォルトの名無しさん mailto:sage [2024/07/12(金) 13:21:18.68 ID:KyXC0KGT.net] 唯一の所有者が存在することと所有者の情報を誰でも取得できることを 区別するのは少し難しい 大谷の家が実在することと住所を公表できることを区別できない人もいるかもしれない 792 名前：デフォルトの名無しさん [2024/07/12(金) 14:02:34.71 ID:HU5SDXKx.net] 「A が Bの継承クラスであること。即ち、C++で class A : public B {・・・}; と書くのは『A is B』である時が良い事が多いですよ」 という説が有りますけれど、 「多い」というだけだと理解してたんですが、このスレの人には、このルール を徹底徹尾適用できる言語を夢見ておられるようですね。 793 名前：デフォルトの名無しさん mailto:sage [2024/07/12(金) 14:20:30.92 ID:KyXC0KGT.net] ここでID何度か被ってきたけどポエムの人とID被ったのは初めて >>776 クラス継承はメリットが少なくデメリットが多いと長年の共通体験で判明してそれが共通認識となっているから 様々な異なる方針のモダンな言語たちがクラス廃止の点では共通方針となっただけでしょ 794 名前：デフォルトの名無しさん mailto:sage [2024/07/12(金) 15:35:12.29 ID:4qvv2DeJ.net] 何気なく cargo update すると後悔する orz 795 名前：デフォルトの名無しさん mailto:sage [2024/07/12(金) 15:44:29.48 ID:4qvv2DeJ.net] GAFAM は存在しない 今は GAMAM 796 名前：デフォルトの名無しさん mailto:sage [2024/07/12(金) 15:46:16.40 ID:4qvv2DeJ.net] >>772 drop(hoge) 797 名前：デフォルトの名無しさん mailto:sage [2024/07/12(金) 15:49:17.77 ID:4qvv2DeJ.net] >>773 Box Rc Arc Cell RefCell OnceCell Pin 798 名前：デフォルトの名無しさん mailto:sage [2024/07/12(金) 17:11:30.65 ID:LuKbokrL.net] >>780 サンキュー >>781 そのあたり全然勉強してない 「相互に参照し合うあうメモリは持てません。それを制限してあまりあるメリットを提供します。どうしてもやりたい人のために別口を用意しました」 という事実が重要 799 名前：デフォルトの名無しさん [2024/07/12(金) 20:20:08.14 ID:0tYdINiS.net] Rust製コードエディター「Zed」がLinuxにようやく対応 Windowsサポートにも期待 ttps://forest.watch.impress.co.jp/docs/news/1607906.html 800 名前：デフォルトの名無しさん [2024/07/12(金) 20:23:46.34 ID:0tYdINiS.net] 個人利用は無償 ～JetBrainsがRust向けIDE「RustRover」を一般公開 メモリ安全性を保障したプログラミング言語「Rust」の開発に特化した統合開発環境 ttps://forest.watch.impress.co.jp/docs/news/1607747.html 801 名前：デフォルトの名無しさん mailto:sage [2024/07/12(金) 20:46:42.78 ID:KyXC0KGT.net] 別口を用意するとは？ RustらしくないRustを用意することかな もし日本語らしくない日本語が何か成果を出したら 日本語らしさを学習したAIに都合が悪い 802 名前：デフォルトの名無しさん mailto:sage [2024/07/12(金) 21:35:52.40 ID:VV8L6PZC.net] >>784 慣れの問題なんだろうけど vscodeがいい… 803 名前：デフォルトの名無しさん mailto:sage [2024/07/12(金) 22:05:28.85 ID:LuKbokrL.net] >>785 参照カウンタ等がその別口 逆に聞くけど全てを参照カウンタで書かないのはなぜ？ 804 名前：デフォルトの名無しさん [2024/07/12(金) 22:12:50.70 ID:VeLgD+zy.net] >>781 RcやBoxは分かりやすいけどStringやVecも動的確保だよね、ということに気付いてない人もいるかも？ Rustが良いのはムーブが基本なおかげで意図 805 名前：せぬメモリコピーが起きないこと 所有権を他に渡す (ある構造体から別の構造体にか、あるコンテナから別のコンテナにとか移動する) 際にコストが発生しない C++は逆で明示的に move しないと意図せぬコピーが起こる [] [ここ壊れてます] 806 名前：デフォルトの名無しさん mailto:sage [2024/07/12(金) 22:30:09.43 ID:KyXC0KGT.net] >>787 強制されてないから 嫌なら使わなければいい 807 名前：デフォルトの名無しさん mailto:sage [2024/07/12(金) 22:37:23.69 ID:LuKbokrL.net] 電気電子板の人が、Rustの特集やってるインターフェース誌を買って読んだけどわからんかったって言ってたよ 808 名前：デフォルトの名無しさん mailto:sage [2024/07/12(金) 22:52:07.26 ID:LuKbokrL.net] >>789 俺はそんなことしないよ 全てを参照カウンタなんて使わずに書かない理由を探る 809 名前：デフォルトの名無しさん mailto:sage [2024/07/12(金) 23:03:04.47 ID:IhFaP3QA.net] >>787 C++で常にshared_ptrを使うと遅い 参照カウンタを利用しがちなSwiftやNimは遅い 810 名前：デフォルトの名無しさん mailto:sage [2024/07/12(金) 23:08:24.73 ID:LuKbokrL.net] 参照カウンタ自体は全然新しくない Rustがそれを無くせない理由が知りたい 811 名前：デフォルトの名無しさん mailto:sage [2024/07/12(金) 23:24:14.35 ID:LuKbokrL.net] 複数の所有者がいる場合に参照カウンタが有効なのは分かる 難しいのは循環参照 参照カウンタで何が書け、何しか書くべきでないか 812 名前：デフォルトの名無しさん [2024/07/12(金) 23:48:00.71 ID:VeLgD+zy.net] >>793 メモリ安全性を提供するため オブジェクトを共有するのに「所有権は1人だけが持ち、他はそれを参照する」仕組みだと、すでに実体が消えてるオブジェクトを参照する問題が起こり得る Rustでは、そのようなオブジェクトは参照カウンター付き (RcやArc) にするか、ライフタイムにより「寿命の短いものが寿命の長いものを参照している」ことを示さない限りコンパイルが通らないようにすることで安全性を保証している 逆にC++は参照カウンターなしでも共有できるけど正しく実装しないとメモリ関連のバグを引き起こす この手のバグはセキュリティの問題になり得る問題を特定しにくい等の厄介さがあるから、Rustはそれをコンパイル時にできる限り防ぐという考え 813 名前：デフォルトの名無しさん mailto:sage [2024/07/12(金) 23:56:48.21 ID:n+FrpY/U.net] 同一スレッド内の別タスクと共有する時にRcを使う 別スレッドや別スレッドになりうる別タスクと共有する時にArcを使う 814 名前：デフォルトの名無しさん [2024/07/13(土) 00:02:12.31 ID:mV5TIlCk.net] 親子関係のようなオブジェクト間で相互参照するならWeakを使う これはRcやArcから作るもので、「メインの所有者とそれを弱参照する共有相手」の関係になる Weak側は相手がまだ存在することを確認できないと参照できないというもの 815 名前：デフォルトの名無しさん mailto:sage [2024/07/13(土) 00:46:50.81 ID:UG7jOJ2R.net] Rust の所有権システムは機械的に静的検証が可能なように設計されている。 しかし Rust のルールでの機械的静的検証で安全だと確信できないが実際には安全というケースは ごく普通にあり、その内の典型的なものは実行時のチェックで補えるようにライブラリが整備されている。 816 名前：デフォルトの名無しさん mailto:sage [2024/07/13(土) 02:23:43.98 ID:k/Plwdnm.net] >>787 全てをRcで扱って渡すときはRcをclone()して渡せばライフタイムを気にしなくて済むが 参照カウンタとその増減のオーバーヘッドだけでなく 書き換えたいなら内部可変性を持ちそのオーバーヘッドも加わるとともに スタック上で済むときも必ずヒープ利用となるオーバーヘッドもある 817 名前：デフォルトの名無しさん mailto:sage [2024/07/13(土) 08:49:12.36 ID:zzh5ASvo.net] zennとかqiitaとかのrust記事みてると 活発に描いてた人は2019-2022くらいで その後更新されてないのが多い みんな試しただけで使ってないのか 818 名前：デフォルトの名無しさん mailto:sage [2024/07/13(土) 08:51:48.91 ID:zzh5ASvo.net] >>784 いくつものバージョンのrustやそのバージョン用のcratesを それぞれ独立に管理して切り替えて使える統合環境なら嬉しいな venvみたいな 819 名前：デフォルトの名無しさん mailto:sage [2024/07/13(土) 08:54:10.60 ID:zzh5ASvo.net] >>788 >Rustが良いのはムーブが基本なおかげで意図せぬメモリコピーが起きない doubt 820 名前：デフォルトの名無しさん mailto:sage [2024/07/13(土) 08:56:33.88 ID:zzh5ASvo.net] >>790 特集のRustは知らんけど 特集じゃなかったときのインターフェースで紹介されたRustは (インターフェース誌の読者に多いであろう)C言語利用者に判り易く説明されていた そういうスタンスだからC知らん人にはきついのかも 821 名前：デフォルトの名無しさん mailto:sage [2024/07/13(土) 08:58:41.51 ID:zzh5ASvo.net] >>793 無くせない訳じゃなくて 参照カウンタを使わない描き方は今でも充分過ぎるほど可能 特に純粋な関数型言語を使ったことのある人は後者の方が得意だろう 822 名前：デフォルトの名無しさん mailto:sage [2024/07/13(土) 09:03:05.94 ID:UG7jOJ2R.net] ムーブは管理上の概念で、低レイヤではコピーしてる。 Rust のムーブはカスタマイズの余地なくコピーする (最適化で消えることはある) が C++ のムーブはカスタマイズの余地 (ムーブコンストラクタの定義) があるので効率の面から考えると Rust のほうがよいとは言えない。 823 名前：デフォルトの名無しさん mailto:sage [2024/07/13(土) 09:29:23.45 ID:+smP1Ssu.net] >>801 venvはないわー cargoやrustupだけでずっと簡単に管理できる IDEをそれらをGUIから活用するだけ 824 名前：デフォルトの名無しさん mailto:sage [2024/07/13(土) 09:38:04.64 ID:4hBdJvP4.net] コマンドプロンプトを無くせない理由を考え続けているそこのあなた まあいいじゃんそういうの 825 名前：デフォルトの名無しさん mailto:sage [2024/07/13(土) 09:38:06.14 ID:OKewYK0N.net] >>800 当時記事書いてた一人だけど、日本語書籍も増えたしいまさら書くことないんだよね アドベントカレンダーがあるならネタ考えるか、くらい 自分はまだRust使ってるし、当時記事書いてた人たちもRust使ってるベンチャーとかに転職してて、だいたいみんな書いてるんじゃないかな 826 名前：デフォルトの名無しさん mailto:sage [2024/07/13(土) 10:09:47.61 ID:aKeOI53x.net] Rustはカンファレンスとか見てても最近は成熟したからなのか特に目新しいものはない気がする 827 名前：デフォルトの名無しさん mailto:sage [2024/07/13(土) 10:11:38.51 ID:CU8fyG8D.net] vscodeにできてjetbrains製ideにできないことってある？ 正直jetbrainsのヤツのほうがvscodeより使いやすい 828 名前：デフォルトの名無しさん mailto:sage [2024/07/13(土) 10:27:13.13 ID:E2vTTaV1.net] JetBrains製品は金払ってまで使うほどVSCodeより優れてるわけでないだけで良いIDEではある VSCodeを何故使うかは商用利用無料だからに尽きるんだわ 829 名前：デフォルトの名無しさん mailto:sage [2024/07/13(土) 10:59:18.93 ID:SqKWY/h6.net] >>767 >>768 >traitが実装される具体的な型は全てsubtypeに相当する兄弟同士であるため >supertrait/subtraitの場合に例えばある構造体についてそのインスタンスはどちらも同一になるから どちらも同じ勘違いをしてるよ よく読もうね What is wanted here is something like the following substitution property: If for each object o1 of type S there is an object o2 of type T such that for all programs P defined in terms of T, the behavior of P is unchanged when o1 is substituted for o2 then S is a subtype of T 830 名前：デフォルトの名無しさん mailto:sage [2024/07/13(土) 11:00:31.54 ID:l6/BNZgQ.net] 仮にfleetが商用無料になるなら喜んでvscodeを捨てるけど金にがめついjetbrainsが商用無料で配るなんてありえない話 javaやkotlinならともかくrustなら商用無料のvscodeで十分 831 名前：デフォルトの名無しさん mailto:sage [2024/07/13(土) 11:14:27.08 ID:3n/3tOrD.net] >>812 そこでRustの場合はTがトレイトでSが構造体などの各型で 「impl T for S 」とS型にトレイトTを実装して 「let o1: S = ...」がS型の値(＝オブジェクト)になる 『object o1 of type S』　←存在する 『object o2 of type T』　←存在しない したがってRustのトレイトはLSPとなんら関係がない 832 名前：デフォルトの名無しさん [2024/07/13(土) 11:36:15.00 ID:mV5TIlCk.net] よく分からんけど fn do_somethg(x: impl T) にS型のオブジェクトoを渡すなら、do_somethingにとって o is T が成り立つんじゃない？ この関数は渡された o が S1 なのか S2 なのかは認識しないのだし 833 名前：デフォルトの名無しさん mailto:sage [2024/07/13(土) 11:44:56.49 ID:4Ly9sDTU.net] >>815 fn foo(x: impl T)は単相化されて fn foo(x: S1)と fn foo(x: S2)の二つの関数になるんだよ いずれにしてもxはS1の値かS2の値であって Tの値は存在しないね 834 名前：デフォルトの名無しさん mailto:sage [2024/07/13(土) 11:50:56.55 ID:6r0IzkzM.net] >>813 さすがフリーライダー。 相手に対する敬意が毛ほども無い。 835 名前：デフォルトの名無しさん [2024/07/13(土) 11:54:54.91 ID:mV5TIlCk.net] それはコンパイルのされ方の話であって意味の上での問題ではない気がする Box<dyn T> なら動的ディスパッチされるわけだし let x: T = ... のような変数を作れないという意味ならその通りだけど、それはオブジェクト指向言語におけるインターフェースでも同じでは (それともインターフェースに対してLSPは成り立たない？) 836 名前：デフォルトの名無しさん mailto:sage [2024/07/13(土) 12:02:36.42 ID:7b/8td6H.net] >>812,814,816 なんで毎回飛んでレスするの？ 837 名前：デフォルトの名無しさん mailto:sage [2024/07/13(土) 12:09:19.16 ID:Zf2Y/4l2.net] 前も貼ったけどRustはこういうニーズを背負ってる オブジェクト指向を学ばなかった話 https://qiita.com/adaiimps/items/e04ae03371435aeffe87 C++、ObjectiveC、JavaだったのがRust、LLVM、ELFになって、あーやっぱこっちの方が面白いねと、 好きも嫌いもなく色んな言語を学びまくってる人はLLVMは学ばないのかなと 838 名前：デフォルトの名無しさん mailto:sage [2024/07/13(土) 12:15:08.95 ID:SXOx4oHh.net] >>818 LSPでは「o1 of type S」と「o2 of type T」の二つのobjectの挙動を比較してるのよ 「o2」が存在しないと挙動の差を論じられないですよ 839 名前：デフォルトの名無しさん mailto:sage [2024/07/13(土) 12:31:19.55 ID:IqeBToeS.net] rust始めたけどtokioまわりの非同期処理が難しい… 840 名前：デフォルトの名無しさん mailto:sage [2024/07/13(土) 12:34:40.11 ID:UG7jOJ2R.net] 置換原則に沿うかどうかは具体的な実装を検証しないとわからないし、大抵の場合に機械的に検証することは出来ない。 型をサブタイプの関係にするのは原則に沿う「ことにする」という表明になることはあるが、原則に沿うことの保証にはならんのだ。 841 名前：デフォルトの名無しさん [2024/07/13(土) 12:40:54.94 ID:mV5TIlCk.net] >>821 >>812 を字義通りに解釈するならそうだけど、その文章はC#やJavaが登場する前の1988年のもので、現在のオブジェクト指向にそのまま適用して良いのか？と思う インターフェースでない、実体のあるクラスの継承関係についてしか言えなくなるし 現在だとリスコフの置換原則は抽象インターフェースも含んで説明される方が多いように思う 「クラスを継承する際のみに適用できるルール」のように説明されてるのは、少なくとも自分は見たことがない 842 名前：デフォルトの名無しさん mailto:sage [2024/07/13(土) 12:44:05.69 ID:Bid5yHc7.net] お前らずっと同じ話をループさせてんな😅 843 名前：デフォルトの名無しさん mailto:sage [2024/07/13(土) 12:51:22.30 ID:kEBSnfkM.net] >>824 親(基底)と子(派生)の挙動の差で満たすべき条件をLSPは挙げてるよね 少なくとも親にも挙動(実装)が存在しないとLSPを満たしているかどうか言及できないと思う 844 名前：デフォルトの名無しさん mailto:sage [2024/07/13(土) 13:43:19.43 ID:4hBdJvP4.net] >>825 好き嫌いの感覚に素直に従えば面白味のないループはすぐ止まりそうなのに 845 名前：デフォルトの名無しさん mailto:sage [2024/07/13(土) 13:52:54.97 ID:E+PNnzD+.net] PartialOrd: PartialEqは PartialEq（等価判定）を持つ型にPartialOrd（半順序判定）を追加するときに a.partial_cmp(b) == Some(Ordering::Equal) と a.eq(b) （⇔ a == b） が同じになることを期待してる この場合の置換の対象は型のインスタンスではなく使われる型の関数だから LSPをインスタンスの置換に限定するか処理の置換にまで拡張するかで結論が変わる PartialOrdの追加はPartialEqを使ってる既存のコードに影響しないから 技術的にはLSPと無関係ともいえるし PartialOrdとPartialEqの等価判定の互換性は概念的にLSPの対象とも考えられる 846 名前：デフォルトの名無しさん mailto:sage [2024/07/13(土) 14:35:50.27 ID:MYuplL5h.net] つまりRustのトレイトは LSPの原義に従うと対象外となり 拡張して考えるとLSPを常に満たす ことになるわけか 847 名前：デフォルトの名無しさん [2024/07/13(土) 15:25:32.20 ID:mV5TIlCk.net] >>829 意味の上で考えるとしても「常に」は満たさないかと struct MyString(String); impl Clone for MyString { 　fn clone(&self) -> Self { 　　Self("元の文字列と関係ない文字列".to_string()) 　} } のようにすれば、そのトレイトが期待する動作に反した型は作れるわけで 引数や戻り値のシグニチャの同一性だけに注目するならtraitに違反することはできないけど、それなら継承やインタフェースでも同じで、「LSPに違反してはならない」という原則はそもそも意味がない (常に違反できないから) ってことになるし 848 名前：デフォルトの名無しさん mailto:sage [2024/07/13(土) 15:38:58.70 ID:MYuplL5h.net] >>830 それLSPのどの項目に違反してる？ LSPは振る舞いに関する形式的なものなのでそのような意味論にまでは踏み込んでいないよ 849 名前：デフォルトの名無しさん [2024/07/13(土) 15:50:29.46 ID:mV5TIlCk.net] >>831 例えば fn test_clone(x: impl Clone + PartialEq) { 　assert!(x.clone(), x); } はClone および PartialEq トレイトの振る舞いに依存したコードだけど、この振る舞いに反した型は作れるよね トレイトは事後要件 (x.clone() == x) を定義できないし、そもそも Clone はそれを担保していないと主張することはできるけど、それならLPSって何のためにあるんだ？ってなるし 850 名前：デフォルトの名無しさん mailto:sage [2024/07/13(土) 15:54:23.34 ID:4hBdJvP4.net] 「内在論理」に踏み込めば争いを解決できる説のようなものか 逆効果なのでは？ 851 名前：デフォルトの名無しさん [2024/07/13(土) 15:55:51.56 ID:mV5TIlCk.net] 訂正 >>832 のアサート行は assert!(x.clone(), x) でなく assert!(x.clone() == x) 852 名前：デフォルトの名無しさん mailto:sage [2024/07/13(土) 15:57:24.24 ID:UG7jOJ2R.net] >>831 不変条件を弱められないルールだろう。 不変条件はシグネチャや定義域で表現できないものも含めた振る舞いの仕様全てのことで、挙動が (仕様に照らして) 望ましくなければ原則を満たさないと言える。 853 名前：デフォルトの名無しさん mailto:sage [2024/07/13(土) 16:03:55.44 ID:E+PNnzD+.net] 829でPartialEq/PartialOrdを例に出したのは この２つのtraitがsuper/subの関係にあるからで Cloneとその実装型の関係とは別だよ PartialEqとPartialOrdの等価判定についてのLSPを考えてる PartialOrd: PartialEqとする以上 PartialOrdの比較はPartialEqの等価条件を保存すべき←LSP? みたいな 854 名前：デフォルトの名無しさん mailto:sage [2024/07/13(土) 16:10:18.20 ID:MYuplL5h.net] >>836 確かにそちらの例は二つのトレイトがsuperとsubの関係だからLSPを満たしてるけど >>830の例はLSPとは関係ないな 855 名前：デフォルトの名無しさん [2024/07/13(土) 17:43:27.19 ID:mV5TIlCk.net] >>831 意味でなく形式に拘るなら「事後要件を弱めてはいけない」などのルールは、要件がプログラム等の形式で表現されない限りLSPの評価の土台にすら上がらないってことにならない？ Cloneトレイトは公式のドキュメントに // Required method fn clone(&self) -> Self; Returns a copy of the value. とあって、exampleでは実際に assert_eq を使って説明しているので、この説明を元にCloneトレイトを実装する型の妥当性を判断して良いように思う これでもまだ「それは意味論上のものでしかない」というなら、逆にそれをクリアしてクラス間の振る舞いを示している現実的な例を教えてくれ 856 名前：デフォルトの名無しさん mailto:sage [2024/07/13(土) 22:57:22.69 ID:ZTGyFNne.net] >>838 それは単純な例だから上手くいってるように思い込めるんじゃないかな 例えばclassの場合はもっと複雑な例になってもsuperclassのコードと挙動が実際にあり それとsubclassの挙動や(必要なら)コードと照らし合わせて判定できるよ しかしtraitにはそれがないからドキュメントや付加assertなど一段上のメタ情報を用いなければ何も進めることができない したがってLSPの枠組みと似てる面はあっても別物 857 名前：デフォルトの名無しさん mailto:sage [2024/07/14(日) 04:00:15.58 ID:xmUtANA3.net] 知らんけど JavaとかC#の世界でも、interfaceが実装者に要求する条件を実装者が実際には満たさない、って場合にLSP違反って言われるの？ ならRustのtraitでも同じこと言ってよさそうだけど、多分言わんよな 858 名前：デフォルトの名無しさん mailto:sage [2024/07/14(日) 05:23:41.72 ID:QaC7oPd0.net] 継承なしのカプセル化だけなら普通のC言語でもできるし、再コンパイルの問題（変更を加えたファイルだけを再コンパイルすればいいという原則の破れ）も発生しない それがそのままライブラリやオブジェクトの単位になったんじゃないの 859 名前：デフォルトの名無しさん mailto:sage [2024/07/14(日) 06:49:30.82 ID:ma8dE8UE.net] 文系：xとは未知のもの 厨房：いや未知のものはyやろ 理系：未知のものはfですdf/dx=g(f)を解きます 860 名前：デフォルトの名無しさん mailto:sage [2024/07/14(日) 07:37:29.94 ID:iqWqiKXK.net] >>841 Rustのtraitにはクラスのような継承はないけど、抽象的なコードを継承できるよ 861 名前：デフォルトの名無しさん mailto:sage [2024/07/14(日) 07:37:59.13 ID:iqWqiKXK.net] 例えばIteratorのtraitにはこのようにfoldメソッドのコードがあって fn fold<B, F>(mut self, init: B, mut f: F) -> B where 　Self: Sized, 　F: FnMut(B, Self::Item) -> B, { 　let mut accum = init; 　while let Some(x) = self.next() { 　　accum = f(accum, x); 　} 　accum } 862 名前：デフォルトの名無しさん mailto:sage [2024/07/14(日) 07:39:51.02 ID:iqWqiKXK.net] 未知のIteratorであっても重複コードを書くことなく自動的にこのfoldメソッドが使える 863 名前：デフォルトの名無しさん mailto:sage [2024/07/14(日) 07:40:10.97 ID:iqWqiKXK.net] クラスのメソッド継承との決定的な違いは、このコードにメンバー変数は一切登場せず、つまりいかなる構成の型からも独立した抽象的なコードであること 864 名前：デフォルトの名無しさん [2024/07/14(日) 09:23:36.10 ID:JssLuzWj.net] fold って next とどうちがうん 865 名前：デフォルトの名無しさん [2024/07/14(日) 10:13:20.02 ID:aq5pPuoi.net] >>847 nextはイテレーターを一つ進めるもの、foldやreduceはイテレーターに対して畳み込みを行うもの 例えば「配列内の全ての数値を足し合わせる」とか「全ての数値を掛け算する」「配列内の文字列を全て連結する」いった操作を行うものだよ この類のものは他の言語でも使われるし、簡潔なコードを書けるようになるから知っておくと良いよ 配列等のコンテナに対して一般に map, filter, reduce と呼ばれる操作があって、そのうちreduceは「要素を畳み込んで1つの値にする」もの 畳み込む方法を関数で渡すもので、概念的には [1, 2, 3].reduce(add) や [1, 2, 3].reduce(multiply) のような形になる 渡す関数は関数のほかクロージャ (言語によってはラムダ式とも) も使える こんな感じに抽象化するとfor文を使わなくて済むし、何をやってるかが明確になる 866 名前：デフォルトの名無しさん mailto:sage [2024/07/14(日) 10:32:15.39 ID:iqWqiKXK.net] 言語によって呼び名や使い分けが微妙に異なるけど Rustでは2種類をこう呼び分けています foldは初期値を別途指定する万能型の畳み込み reduceは初期値が最初の要素となる畳み込み 867 名前：デフォルトの名無しさん mailto:sage [2024/07/14(日) 10:33:24.33 ID:iqWqiKXK.net] そして万能型のfoldを呼び出す形で このような特定の型の構造に依存しない抽象的なコードが trait Iteratorに用意されているため使えます fn reduce<F>(mut self, f: F) -> Option<Self::Item> where 　Self: Sized, 　F: FnMut(Self::Item, Self::Item) -> Self::Item, { 　let first = self.next()?; 　Some(self.fold(first, f)) } 868 名前：デフォルトの名無しさん mailto:sage [2024/07/14(日) 11:05:51.89 ID:iqWqiKXK.net] なぜ二種類あるのか？と 869 名前：いうと 長さ0だと最初の要素すらないため reduceはOption型が返る特徴があります 例えば和を求める場合でも 長さ0だったらNoneになってほしいならば reduce(|sum, n: i32| sum + n) 長さ0なら和が0となってほしいならば fold(0, |sum, n: i32| sum + n) と使い分けることができます ちなみに後者はsum()メソッドが用意されています [] [ここ壊れてます] 870 名前：デフォルトの名無しさん mailto:sage [2024/07/14(日) 11:33:51.37 ID:iqWqiKXK.net] ごめんなさい >>851で型指定「: i32」の部分は不要です Iteratorの要素の型に必ず定まります 空配列[]から始めると型指定がどこにもないため横着してそこで指定しちゃったという顛末でした 871 名前：デフォルトの名無しさん mailto:sage [2024/07/14(日) 12:47:51.97 ID:JssLuzWj.net] >>822 tokio 自体は難しくないけど cargo test と組み合わせると難しくなる罠 872 名前：デフォルトの名無しさん [2024/07/14(日) 12:50:40.22 ID:JssLuzWj.net] >>848 map も reduce も filter も知ってるけど(pythonとかから) fold は知らんかった?楠 873 名前：デフォルトの名無しさん mailto:sage [2024/07/14(日) 12:54:55.73 ID:JssLuzWj.net] >>850 python の reduce は初期値を [0] にするのも任意に設定するのも 同じ reduce という名前でいけるのが Rust だと reduce と fold で使い分ける必要があるということね Rust が面倒だと言うことは理解した 874 名前：デフォルトの名無しさん mailto:sage [2024/07/14(日) 13:21:58.79 ID:iqWqiKXK.net] >>855 そういうことではないよ RustではOption型やResult型でエラーや異常値を含めて正しい状況を値として得られるんだよ 例えば長さ0で初期値なしの時に Pythonだとエラーだよね Rustは常に値として返してくれて今回はOption<Self::Item>型 875 名前：デフォルトの名無しさん mailto:sage [2024/07/14(日) 14:06:11.77 ID:CpW1/GRz.net] >>854 ML 系とか LISP 系の言語ではだいたい reduce や fold は用意されてるね。 ものによっては右側 (シーケンスの終端) から畳み込むとかのバリエーションもある。 876 名前：デフォルトの名無しさん mailto:sage [2024/07/14(日) 14:15:44.82 ID:iqWqiKXK.net] Rustならrev().fold(...)だね 877 名前：デフォルトの名無しさん mailto:sage [2024/07/14(日) 15:28:53.80 ID:QaC7oPd0.net] テンプレートが出てきたあたりからC++の勉強をやめたのだけど これは「型を引数に取ってインスタンス化する」ということでおｋ？ それがトレイトをまたいだ場合、いつどこで誰が何してるか分からなくなる ファイルをまたぐインライン関数みたいにソースレベルでなされること？ 878 名前：デフォルトの名無しさん mailto:sage [2024/07/14(日) 16:59:00.63 ID:Q38o8Kq2.net] >>840 JavaとかC#の世界でも、interfaceが実装者に要求する条件を実装者が実際には満たさない、って場合にLSP違反って言われるの？ 言われるよ リスコフ本人が書いたJavaの本にも書いてある 879 名前：デフォルトの名無しさん mailto:sage [2024/07/14(日) 17:32:49.60 ID:Q38o8Kq2.net] >>839 >ドキュメントや付加assertなど一段上のメタ情報を用いなければ何も進めることができない 一段上のメタ情報であるspecificaitonを使いなさいというのがリスコフの教え それがBehavioral SubtypingってものでLSPが伝えようとしてる原則だよ 880 名前：デフォルトの名無しさん mailto:sage [2024/07/14(日) 20:15:07.35 ID:QaC7oPd0.net] ああ、なんだ クレート＝ELFファイルだと思ってたけど違うのね 881 名前：デフォルトの名無しさん mailto:sage [2024/07/14(日) 23:33:04.31 ID:jL63bGYb.net] もちろんクレートはコンパイルしてELFに出来得る 882 名前： 警備員[Lv.12] mailto:sage釣 [2024/07/15(月) 00:49:06.25 ID:iuOQZB5q.net] そうかCOFFあかんか。 AIXとかはどうするんだろう？ 883 名前：デフォルトの名無しさん mailto:sage [2024/07/15(月) 01:06:24.34 ID:qZQFNGwo.net] LLVMのバックエンドにCOFFもあるよ 884 名前：デフォルトの名無しさん mailto:sage [2024/07/15(月) 01:09:28.33 ID:RXziJOxB.net] LLVMの役割 ELFもCOFFもXCOFFもいける 885 名前：デフォルトの名無しさん mailto:sage [2024/07/15(月) 01:55:53.37 ID:S6UfnUI4.net] >>860-861 なるほどね、本当に特定の言語処理系の型システムの実装が云々というところからは離れたところにある概念なんだ あえて関連付けるなら、型システムの部分型付け関係がbehavioral subtypingにもなるように定義すべきであると 上位型が具体型であるために暗黙の条件が多数想定される状況では特にLSPを意識すべきだが、それに限定される概念ではないと 886 名前：デフォルトの名無しさん mailto:sage [2024/07/15(月) 02:35:13.63 ID:fmM+TfOR.net] supertypeの実装がない場合は LSPの不変条件・事前条件・事後条件などsubtypeの実装と比較しようがなく LSPの対象になりようがないよね 887 名前：デフォルトの名無しさん [2024/07/15(月) 03:42:20.85 ID:csp8v2ux.net] docs.rs の左上のRマーク 今話題のRen4のマークに似てるね 888 名前：デフォルトの名無しさん [2024/07/15(月) 09:46:03.12 ID:kpV4D65H.net] コレクションしないんだから狭義には参照カウンタはGCとは言えない。 広義には含めてやってもいいが。 889 名前：デフォルトの名無しさん mailto:sage [2024/07/15(月) 11:20:28.28 ID:qZQFNGwo.net] ライブラリは.rlibまたは.rmetaで、これもELFやCOFFとは別物 ふむ 890 名前： 警備員[Lv.1][新芽] [2024/07/15(月) 11:29:04.89 ID:omk2e105.net] たしかにRマークってRustから周りのやつ外したような感じじゃん 891 名前：デフォルトの名無しさん mailto:sage [2024/07/15(月) 11:58:24.83 ID:K85WsTqt.net] Ren4のRマークはsans-serifのゴシック体だからRustのロゴとは全然違うだろ 本人のやる気、こだわりのなさをフォントで表現してるんだから RustのRと一緒にしたら双方に失礼 892 名前：デフォルトの名無しさん mailto:sage [2024/07/15(月) 13:14:40.10 ID:ZO/EZAih.net] 単に好みの問題だけど ウィルスっぽくて気持ち悪い 好きじゃない 893 名前：デフォルトの名無しさん [2024/07/15(月) 14:14:44.43 ID:ko+PCaVU.net] >>874 元々サビ菌がモチーフやからしゃーない 894 名前：デフォルトの名無しさん mailto:sage [2024/07/15(月) 18:49:44.14 ID:GgRIn2WF.net] 独裁者にも見た目がダサい奴がよくいるけど言っても無駄だ デザインの力とは全然違う別の力でねじ伏せてくる 895 名前：デフォルトの名無しさん [2024/07/15(月) 19:16:07.61 ID:Vjas5sQD.net] ダサいという指摘に理由を説明しても、ダサいことは変わらないんだよな 言語がダサければ信者もダサい うだうだ言いながらダサい服着てそう 896 名前：デフォルトの名無しさん mailto:sage [2024/07/15(月) 22:03:42.65 ID:e+J3OGv0.net] イテレータ要素をヒープに格納するにはこれでいいんか .fold(Vec::new(), |mut v, t| { v.push(t); v }) 897 名前：デフォルトの名無しさん mailto:sage [2024/07/15(月) 22:12:32.29 ID:S6UfnUI4.net] またイテレータの話してる 898 名前：デフォルトの名無しさん mailto:sage [2024/07/15(月) 22:50:12.36 ID:9YaXaz6n.net] >>878 collectしろや 899 名前：デフォルトの名無しさん [2024/07/15(月) 23:25:29.58 ID:wT4qVw/w.net] >>878 分かって書いてるかもだけど一応 let v = (0..10).collect::<Vec<i32>>(); コンテナにまとめるならこんな感じに collect を使う 例えば文字を走査するイテレーターをStringにcollectするようなことも可 型パラメーターは推論が効くのでそれに任せても良い 左辺に情報があるならcollectの型パラメーターはいらない let v: Vec<i32> = (0..10).collect(); 要素の型が分かるなら、右辺のコンテナの中身は_で推論させても良い let v = (0i32..10).collect::<Vec<_>>(); 900 名前：デフォルトの名無しさん mailto:sage [2024/07/15(月) 23:35:20.09 ID:nug4GWMJ.net] クロージャにキャプチャさせれば既存ベクタへ格納も追加もできる let mut v = Vec::new(); iter.fold((), |_, t| v.push(t)); しかしこれではfold使ってる意味がなくこれと一緒　 iter.for_each(|t| v.push(t)); もちろん正解は既存Vecへ追加なら v.extend(iter); 新規にVecへ収集なら let v = iter.collect::<Vec<_>>(); 901 名前：デフォルトの名無しさん mailto:sage [2024/07/16(火) 23:25:36.51 ID:ab19AXDr.net] Foo::from_iter(iter)でもいいね 例えばVec::from_iter(iter) 特にIntoIteratorな時にinto_iter()を省けて見やすいよ 902 名前：デフォルトの名無しさん mailto:sage [2024/07/17(水) 18:51:22.39 ID:Hw1cPZyQ.net] イテレータをcollectしたい場合と イテレータではないIntoIteratorを別の構造体に変換したい場合とは文脈が違うでしょ from_iterを直接呼ぶのは基本的に後者 前者の場合にターボフィッシュ書かなくてもいいという理由で from_iterを直接呼ぶのはidiomaticではない 903 名前：デフォルトの名無しさん mailto:sage [2024/07/17(水) 21:48:43.22 ID:3eay5eeN.net] 前者のケースでfrom_iterを直接呼んでても分かるから別にいいよ 自分で書くときはcollect使うけど 904 名前：デフォルトの名無しさん mailto:sage [2024/07/17(水) 23:54:54.61 ID:zgRAxdKk.net] これは短い方がいい let x = HashMap::<_, _>::from_iter(vec); let x = vec.into_iter().collect::<HashMap::<_, _>>(); 905 名前：デフォルトの名無しさん mailto:sage [2024/07/17(水) 23:55:29.92 ID:zgRAxdKk.net] これはほぼ長さ変わらないからどちらがわかりやすいか let x = HashMap::<_, _>::from_iter(iter); let x = iter.collect::<HashMap::<_, _>>(); 906 名前：デフォルトの名無しさん mailto:sage [2024/07/18(木) 01:10:31.87 ID:CNIyJc+8.net] どちらも一度変数で受ける形になるので型アノテーションが必要なら let x: HashMap<_, _> のように基本的には左辺に書く HashMapなら型パラメータ部分も推論に頼らず 明示的に書くことのほうが多いかもしれない イテレータをcollectしたい場合というのは イテレータのメソッドチェーンで各種処理をしてから 最終的にcollectする形になることが多いから from_iterの直呼びじゃなくcollectが好まれる 907 名前：デフォルトの名無しさん mailto:sage [2024/07/18(木) 02:40:28.19 ID:0QBRSK+b.net] ところでchronoって、しょっちゅうAPIが変わるし やたら冗長な書き方になるし結構クソじゃない？ 908 名前：デフォルトの名無しさん mailto:sage [2024/07/18(木) 12:05:40.95 ID:WL/aeG4d.net] 書き方が気に入らないならtime-rsを試してみたら？ 909 名前：デフォルトの名無しさん mailto:sage [2024/07/18(木) 21:07:48.37 ID:2m7Ost/Q.net] なるほど trait Iterator { 　type Item; 　 　fn collect<B: FromIterator<Self::Item>>(self) -> B 　where 　　Self: Sized, 　{ 　　FromIterator::from_iter(self) 　} } 910 名前：デフォルトの名無しさん mailto:sage [2024/07/18(木) 23:31:33.62 ID:GQ1B8wHA.net] 代数的データ型ってなんかすごいけど知名度がモナドより低いな 911 名前：デフォルトの名無しさん mailto:sage [2024/07/19(金) 02:03:52.09 ID:MUvBupZH.net] >>890 使ってみたけど、time-rsいいね いつのまにかダウンロード数でchronoを上回る競合があったとは知らんかった タイムゾーンの扱いがやや簡略化されてるけど、夏時間のない日本人的には問題ない 月を直接intで指定できないのが英語仕様やな……ってちょっと気になる 912 名前：デフォルトの名無しさん mailto:sage [2024/07/19(金) 03:51:08.70 ID:riLGg6QV.net] >>891 この各収納先への移譲と両側のトレイト境界が汎用化の肝 trait FromIterator<A>: Sized { 　fn from_iter<T: IntoIterator<Item = A>>(iter: T) -> Self; } 913 名前：デフォルトの名無しさん mailto:sage [2024/07/19(金) 06:06:24.35 ID:LryDU6eW.net] Rustはジェネリックとトレイト境界と抽象的なデフォルト実装のおかげで 安全で利便性の高いコードの汎用共通化に成功していますね 914 名前：デフォルトの名無しさん [2024/07/19(金) 23:21:36.34 ID:rC6z5NUh.net] cloud strike のはテロルやね 915 名前：デフォルトの名無しさん [2024/07/19(金) 23:30:11.35 ID:rC6z5NUh.net] >>886 let x; HashMap::<_, _> = vec.try_into()?; >>889 ＋１ 916 名前：デフォルトの名無しさん mailto:sage [2024/07/19(金) 23:52:20.75 ID:8WlCJE3Q.net] >>897 エラーとなりますた 917 名前：デフォルトの名無しさん mailto:sage [2024/07/20(土) 00:12:48.41 ID:bNknJoN/.net] >>896 ウィルスバスター以来の快挙やね 918 名前：デフォルトの名無しさん mailto:sage [2024/07/20(土) 14:16:49.05 ID:F167yFzL.net] >>898 ; が : の間違いかな >>899 暴落予想 note.com/asset_n_ichi/n/nceaa6f318b1e 919 名前：デフォルトの名無しさん mailto:sage [2024/07/20(土) 23:38:20.92 ID:6EAP68vq.net] >>897 HashMapとVecにTryFromが実装されていないから無理 FromIteratorが実装されているのでそれを使う 920 名前：デフォルトの名無しさん mailto:sage [2024/07/21(日) 01:48:23.56 ID:eUhj6//q.net] ★┷┓ ┃D┃ ┃D┃ ┃K┃ ┃で┃ ┃も┃ ┃r┃ ┃u┃ ┃s┃ ┃t┃ ┃が┃ ┃使┃ ┃え┃ ┃ま┃ ┃す┃ ┃よ┃ ┃う┃ ┃に┃ ┗━★ 921 名前：デフォルトの名無しさん mailto:sage [2024/07/21(日) 09:43:03.00 ID:QhoywuRk.net] >>901 こういうのが「Rustは学習コストが高い」って言われる原因なんだろうな 答えを知ってる人は判ってても答えを知らない人は判らない 答えを調べるのにコストがかかりすぎる 922 名前：デフォルトの名無しさん mailto:sage [2024/07/21(日) 10:14:17.60 ID:TGGT0XLq.net] とあるライブラリに変な癖があるという話は どの言語でもあるからそういう話ではないだろ 923 名前：デフォルトの名無しさん mailto:sage [2024/07/21(日) 10:29:10.85 ID:U3c7smqS.net] イテレータ使ったことない 924 名前：デフォルトの名無しさん mailto:sage [2024/07/21(日) 10:35:28.58 ID:W0nR4Dwz.net] >>903 Rustはその点シンプルでクセもなく覚えやすい 基本的に複数の要素ならFromIterator VecでもHashMapでも何でもいける 複数のcharやstrなどからString作成もいける 複数のstrやStringやPathなどからPathBuf作成もいける Fromは基本的に単独要素や配列(＝静的固定長)から他へ変換 925 名前：デフォルトの名無しさん mailto:sage [2024/07/21(日) 11:03:59.33 ID:BMrg5vDt.net] >>903 >>897のはコンパイルエラーの内容が読めればすぐわかる エラーの内容が読める程度の基礎力は最初に勉強して身につける必要がある そもそもtry_intoでどういうケースならエラーにして欲しいのか考えればおかしいことに気付く サードパーティライブラリの学習コストは他の言語に比べると顕著に高いが 基本的な言語機能や標準ライブラリは言うほど高くない JavaやC#あたりと比べるとむしろ学習コスト低いんじゃないかと思う 926 名前：デフォルトの名無しさん [2024/07/21(日) 11:04:04.35 ID:xuKRyHnL.net] >>903 それくらいchatGPTで教えてもらえるだろ 927 名前：デフォルトの名無しさん mailto:sage [2024/07/21(日) 11:14:46.17 ID:BMrg5vDt.net] >>908 俺もそう思って試してみたけど駄目だね エラーの簡単な原因とcollect使えみたいな代替案は出してくるけど 根本的な理解につながる答えを返せないだけでなくいろいろと間違った情報を返してくる 928 名前：デフォルトの名無しさん mailto:sage [2024/07/21(日) 11:48:09.12 ID:W0nR4Dwz.net] from_iter(array)で済むのに なぜ配列からHashMapへのFromがあるのか理由はおそらく 配列からmoveするinto_iter()が数年前までなかったためだと思う 今は配列を含めて要素が複数なら→イテレータ利用→FromIteratorと覚えればよいかと 929 名前：デフォルトの名無しさん [2024/07/21(日) 11:54:05.33 ID:9I2odrUJ.net] そもそもイテレーターとコンテナの概念を勘違いしてる可能性ありそう 別種のコンテナ同士の変換は (特別な対応がない限り) 直接的には無理で、イテレーターを介して中身の要素を走査すれば渡せるということ みかん箱を冷蔵庫に変換することはできないけど、箱の中のみかんを1つずつ取り出して、それを冷蔵庫型に纏める (collect) ことはできるような感じ 930 名前：デフォルトの名無しさん mailto:sage [2024/07/21(日) 12:08:53.38 ID:QhoywuRk.net] 今回は >>910 さんをベストアンサーとさせて頂きます みなさんご協力ありがとうございました 931 名前：デフォルトの名無しさん mailto:sage [2024/07/21(日) 12:17:32.86 ID:rbHgMj6q.net] >>911 それは単に抽象度の違いであって勘違いでも何でもない 932 名前：デフォルトの名無しさん mailto:sage [2024/07/21(日) 12:17:32.92 ID:QhoywuRk.net] >>911 勘違いはしてない use std::collections::HashMap; use std::iter::FromIterator; fn main() { let u = vec![("hoge", 1), ("fuga", 2)]; let x: HashMap::<_, _> = u.into_iter().collect(); println!("{:?}", x); let v = vec![("hoge", 1), ("fuga", 2)]; let y = HashMap::<_, _>::from_iter(v); // use std::iter::FromIterator println!("{:?}", y); let w = [("hoge", 1), ("fuga", 2)]; // array let z = HashMap::<_, _>::from(w); println!("{:?}", z); } 933 名前：デフォルトの名無しさん mailto:sage [2024/07/21(日) 12:21:47.94 ID:QhoywuRk.net] なぜ Vec から HashMap は from が使えないのか？ の問いに GPT は答えてくれない 934 名前：デフォルトの名無しさん mailto:sage [2024/07/21(日) 12:29:53.31 ID:+gih9iRs.net] >>910 順番が逆 arrayにIntoIteratorが実装された方が先で From array for HashMapのほうが後 935 名前：デフォルトの名無しさん mailto:sage [2024/07/21(日) 12:32:17.29 ID:BMrg5vDt.net] >>915 そこはFromのimplがないからと答えてくれる coherenceの制約を先回りして答えてくれるかどうかは質問次第 936 名前：デフォルトの名無しさん mailto:sage [2024/07/21(日) 13:57:28.77 ID:W0nR4Dwz.net] >>916 ありがと 調べたらその順だね そうなるとFrom<配列>だけを特別に用意した理由は配列が基本型だからだろうか HashMap::from(array)のコードを見ると HashMap::from_iter(array)とFromIteratorの実装を呼び出すだけなので 937 名前：デフォルトの名無しさん mailto:sage [2024/07/21(日) 16:06:46.61 ID:nMuf3u03.net] MapやSetのリテラルがないけどリテラルに近い感覚で初期化したい場合の代替策として用意されたのがFromの実装 938 名前：デフォルトの名無しさん mailto:sage [2024/07/21(日) 16:20:17.13 ID:BJsLblxy.net] _iterの5文字が節約できるメリットだけか 939 名前：デフォルトの名無しさん mailto:sage [2024/07/21(日) 16:39:36.83 ID:u5tRysNp.net] >>920 タイプアノテーションの要不要があるのでもっと節約できるよ 940 名前：デフォルトの名無しさん mailto:sage [2024/07/21(日) 16:43:19.24 ID:BJsLblxy.net] >>921 不要になる例を出して 941 名前：デフォルトの名無しさん mailto:sage [2024/07/21(日) 17:05:45.63 ID:QAZ3DYjh.net] FromがあるとIntoが使えるからHashMap返すときとか引数で渡すときに HashMap::from([..]) の代わりに [..].into() で書ける 型を明記するletだと大差ないかも let map: HashMap<K, V> = [..].into(); let map = HashMap::<K, V>::from([..]); 942 名前：デフォルトの名無しさん mailto:sage [2024/07/21(日) 17:22:33.98 ID:BJsLblxy.net] >>923 そこでタイプアノテーションが不要になる例はないよな 関数の引数型か返り型に書いている into()と書ける件も collect()と書けるから FromIteratorに対してFromもあるメリットは3文字節約できるだけか 943 名前：デフォルトの名無しさん mailto:sage [2024/07/21(日) 21:02:32.72 ID:eUhj6//q.net] dyn traits以外にinto使うなよ。変換するんだから let s = "Hello, world!"; let string = Into::<String>::into(s); じゃなくて let s = "Hello, world!"; let string = String::form(s); だろ。 944 名前：デフォルトの名無しさん mailto:sage [2024/07/21(日) 21:07:32.49 ID:BUmQiTHC.net] は？ 945 名前：デフォルトの名無しさん mailto:sage [2024/07/21(日) 22:10:59.79 ID:kEjkNYpd.net] >>922 use std::collections::HashMap; fn main() { let xs = [(1, "a"), (2, "b"), (3, "c")]; let map = HashMap::from(xs); println!("{:?}", map); } 946 名前：デフォルトの名無しさん mailto:sage [2024/07/21(日) 22:23:54.17 ID:vNf5wQaP.net] >>927 HashMap::from_iter(xs)で十分じゃね 947 名前：デフォルトの名無しさん mailto:sage [2024/07/21(日) 22:30:45.10 ID:kEjkNYpd.net] >>928 error[E0283]: type annotations needed for `HashMap<i32, &str, _>` --> src/main.rs:5:9 | 5 | let map = HashMap::from_iter(xs); | ^^^ ------- type must be known at this point | 948 名前：デフォルトの名無しさん mailto:sage [2024/07/22(月) 12:16:14.88 ID:7a9cZObY.net] 配列からのFromは機能が制限されている struct HashMap<K, V, S = RandomState> { ... } impl<K: Eq + Hash, V, S: BuildHasher + Default> FromIterator<(K, V)> for HashMap<K, V, S> { ... } impl<K: Eq + Hash, V, const N: usize> From<[(K, V); N]> for HashMap<K, V, RandomState> { ... } 949 名前：デフォルトの名無しさん mailto:sage [2024/07/22(月) 12:18:01.98 ID:7a9cZObY.net] つまりFromは重いデフォルトハッシャーに固定されてしまっている FromIteratorを使えば自由に速いものを利用できる let xxx = HashMap::<_, _, FxHash>::from_iter(array); 950 名前：デフォルトの名無しさん mailto:sage [2024/07/23(火) 01:07:15.84 ID:XvQFw5Nb.net] HashMap::from(配列)の場合は デフォルトハッシャーで困るユースケースは稀だから APIのエルゴノミクスのために意図的にRandomStateに固定してる そのおかけでタイプアノテーションなしで書ける タイプアノテーション無しの場合はデフォルト指定の型を優先的に使うよう Rustのコンパイラが改良されればこの辺の差はなくなる 951 名前：デフォルトの名無しさん mailto:sage [2024/07/23(火) 01:10:26.97 ID:XvQFw5Nb.net] >>931 >let xxx = HashMap::<_, _, FxHash>::from_iter(array); FxHashのところはFxBuildHasherだね let xxx = FxHashMap::from_iter(array);と書いたほうがいろいろ親切 親切設計のライブラリなら let xxx = AHashMap::from(array); のようにFromIteratorだけでなくFromも使える 952 名前：デフォルトの名無しさん [2024/07/23(火) 01:31:49.01 ID:Rfg4Mjqa.net] tupleをiteratorしたいんだが無理？ 953 名前：デフォルトの名無しさん mailto:sage [2024/07/23(火) 02:50:50.92 ID:l+hNtTPE.net] こういう意味？ let t = ("abcde", "fghijkl", "mno", "pqrstuvw", "xyz"); assert_eq!("abcdefghijklmnopqrstuvwxyz", Into::<[_; 5]>::into(t).into_iter().collect::<String>()); 954 名前：デフォルトの名無しさん mailto:sage [2024/07/23(火) 09:22:40.63 ID:iSDzXJU2.net] 同じ型だけの要素で構成されるtupleならいけそうだけど 色んな型ば混ざってるtupleはエラー出そう 955 名前：デフォルトの名無しさん mailto:sage [2024/07/23(火) 11:25:10.18 ID:ijWLrFq+.net] dynにすれば色んな型を混ぜられる 関数から返すときはBox<dyn ...>にする 例えば数値と文字列が混じる有名な例をRustでdynを使って書くと type FizzBuzz = Box<dyn std::fmt::Display>; fn fizz_buzz_iter() -> impl Iterator<Item=FizzBuzz> { 　(1..).map(|int| match (int % 3, int % 5) { 　　(0, 0) => Box::new("FizzBuzz") as FizzBuzz, 　　(0, _) => Box::new("Fizz"), 　　(_, 0) => Box::new("Buzz"), 　　(_, _) => Box::new(int), 　}) } fn main() { 　for x in fizz_buzz_iter().take(30) { 　　println!("{x}"); 　} } 956 名前：デフォルトの名無しさん mailto:sage [2024/07/23(火) 17:24:06.93 ID:hqmWVJB3.net] またFizzBuzzイテレータ書いてる…… 957 名前：デフォルトの名無しさん [2024/07/23(火) 21:36:57.26 ID:1jhTJKzb.net] >>936 Haskellだとタプルって構造体代わりだから、色んな型が混ざってる方が普通だけど…。 （ともすれば関数も入れるし。同じ型だけってのはリストのイメージ） Rustじゃ用途違うん？ 958 名前：デフォルトの名無しさん mailto:sage [2024/07/23(火) 21:58:12.50 ID:joaeWjir.net] タプルは型の制限なくバラバラでいいよ 今回はそれを>>934「iteratorしたい」なので 同じ型に揃えるためにdynかenumを使う 959 名前：デフォルトの名無しさん mailto:sage [2024/07/23(火) 23:07:54.81 ID:tKFzmUCx.net] ほとんどの言語でオブジェクトを返す時にヒープを使うから RustでもBox<dyn>を使っても構わないけど ライフタイムさえ満たしてやればヒープを使わずに&dynにできるよ use std::fmt::Display; type FizzBuzz<'a> = &'a dyn Display; fn fizz_buzz_iter<'a, T: Display>(i: &'a[T], s: &'a[&str; 3]) -> impl Iterator<Item = FizzBuzz<'a>> { 　(1..).map_while(|int| match (int % 3, int % 5) { 　　(0, 0) => Some(&s[0] as FizzBuzz), 　　(0, _) => Some(&s[1]), 　　(_, 0) => Some(&s[2]), 　　(_, _) => i.get(int).map(|int| int as FizzBuzz), 　}) } fn main() { 　let i: [_; 256] = std::array::from_fn(|i| i as u8); 　let s: [_; 3] = ["FizzBuzz", "Fizz", "Buzz"]; 　for x in fizz_buzz_iter(&i, &s).take(30) { 　　println!("{x}"); 　} } 960 名前：デフォルトの名無しさん [2024/07/23(火) 23:38:39.26 ID:QoNSkCmh.net] 「tupleでイテレートできないの？」という質問に「こういうイテレータなら異なる型を混ぜられるよ」と回答するあたりがいかにもな感じ 率直に「できる/できない」で回答した上で補足として書けばいいのに 961 名前：デフォルトの名無しさん mailto:sage [2024/07/23(火) 23:40:03.74 ID:38zrS1+w.net] トレイトオブジェクトをdynと呼ぶのは複オジだけ 962 名前：デフォルトの名無しさん mailto:sage [2024/07/23(火) 23:40:30.32 ID:38zrS1+w.net] >>942 それな 963 名前：デフォルトの名無しさん mailto:sage [2024/07/23(火) 23:49:18.56 ID:lLea54if.net] Rust 2018 editionからdyn必須に変わった 964 名前：デフォルトの名無しさん mailto:sage [2024/07/24(水) 00:02:23.05 ID:QMkBbV1F.net] できる/できないで言えばできるよ タプルの要素がすべて同じ型で要素数が12個以内ならFrom/Intoで配列に変換してイテレートする それ以外ならextension traitで自前のイテレータを返すメソッドをタプルに実装する 他にも方法あるけどこの2つが主 タプルの型・要素数、イテレート時の型を汎用化したい場合はマクロが必須でそこそこめんどくさい 特にヘテロなタプルを汎用的にイテレート用の型に揃えるのはめんどくさい 本当にタプルで管理するのが望ましいのか タプルで管理しつつイテレータで回すのがベストなのか まずはよく考えたほうがいいと思う 965 名前：デフォルトの名無しさん mailto:sage [2024/07/24(水) 00:15:33.28 ID:sAqPevwn.net] dynを使えば型が何種類でもいけてトレイト境界も使えて楽だろうけどdynは重い Fizz Buzzのように2種類の型で済むならEitherを使う 色んなトレイトを透過的に対応してくれている use either::Either::{self, Left, Right}; type FizzBuzz = Either<usize, &'static str>; fn fizz_buzz_iter() -> impl Iterator<Item = FizzBuzz> { 　(1..).map(|int| match (int % 3, int % 5) { 　　(0, 0) => Right("FizzBuzz"), 　　(0, _) => Right("Fizz"), 　　(_, 0) => Right("Buzz"), 　　(_, _) => Left(int), 　}) } 966 名前：デフォルトの名無しさん mailto:sage [2024/07/24(水) 00:35:21.34 ID:UKniupNy.net] リフレクションのサポートとかにもっと力入れてれば普通にできるんだろうけど、しゃあなし Rustはそういうの好かない言語だから 967 名前： 警備員[Lv.2][新芽] mailto:sage [2024/07/24(水) 00:44:54.58 ID:djH/Nw1D.net] rustって流行るかな 968 名前：デフォルトの名無しさん [2024/07/24(水) 03:12:39.74 ID:s3z853Sv.net] >>940 タプルをイテレーションしたい…。 リストとか、配列みたいに使いってことですよね？ Haskellでは無理ですが、Rustでは可能なのでしょうか？ （構造体代わりと言った通り、構造体をイテレーションしようと思わないですよね？） Python,RubyのリストとHaskellのそれみたいに、そもそもの意味が違う可能性もありますし…。 969 名前：デフォルトの名無しさん [2024/07/24(水) 03:25:04.27 ID:sCVmnNU/.net] >>935 let t = ("abcde", 123, "mno", "pqrstuvw", 456); for e Into::<[_; 5]>::into(t).into_iter() { println!("{:?}", e) } 無理ポorz 970 名前：デフォルトの名無しさん [2024/07/24(水) 03:30:03.16 ID:sCVmnNU/.net] >>946 それっぽいクレートがあるけどよう判らん これはどんな感じ？ https://crates.io/crates/tuple-iter 971 名前：デフォルトの名無しさん mailto:sage [2024/07/24(水) 03:57:10.87 ID:yTLgnmif.net] これは典型的なXY問題だから相手にするだけ無駄 質問者は本当に解決したい元の課題Xを素直に話すべき 自分の思い込みで勝手に判断して進めた二次的な課題Yについて質問しているからそれについては相手にしなくていい 972 名前：デフォルトの名無しさん mailto:sage [2024/07/24(水) 04:42:12.08 ID:sCVmnNU/.net] >>946 imple IntoIterator for (&str, u64, &str, &str, u64) { ... } で出来るかと思ったけど this is not defined in the current crate because tuples are always foreign 973 名前：デフォルトの名無しさん mailto:sage [2024/07/24(水) 05:38:42.31 ID:U0F2g2Py.net] dynやenumにしろと本質的なアドバイスをもらえているのに対応しようとしない人 974 名前：デフォルトの名無しさん mailto:sage [2024/07/24(水) 07:25:15.81 ID:Py4dd1Kh.net] たしかにXY問題だな 「異なる型が入り乱れてイテレートしたい」←何のために？ 「異なる型が入り乱れてタプルがある」←どうやってそれが出来た？ 975 名前：デフォルトの名無しさん [2024/07/24(水) 08:43:52.20 ID:NUYI7xpt.net] ・タプルは型を混合できる ・タプルはイテレートできない ・異なる型でのイテレートがしたいなら、タプルの代わりに Box<dyn Trait> のような動的型かenum (直和型) の配列を使う で良いんじゃない？ 976 名前：デフォルトの名無しさん mailto:sage [2024/07/24(水) 08:43:57.79 ID:sCVmnNU/.net] とりあえず出来ました struct Hoge<'a> { t: (&str, u64, &str, &str, u64) } impl<'a> IntoIterator for Hoge<'a> { type Item = Fuga<'a>; type IntoIter = std::vec::IntoIter<Self::Item>; fn into_iter(self) -> Self::IntoIter { vec![ Fuga::from(self.t.0), Fuga::from(self.t.1), Fuga::from(self.t.2), Fuga::from(self.t.3), Fuga::from(self.t.4), ].into_iter() } } みなさんありがとうございました 977 名前：デフォルトの名無しさん [2024/07/24(水) 08:50:34.05 ID:NUYI7xpt.net] XY問題だとか言うけど、上のFizzBuzイテレーターなんかはXとYのどちらとも関係ないでしょ 既にあるデータに対してイテレートする方法でなく、FizzBuzを0から生成するだけだから それをしつこく何度も書くあたりが本物 978 名前：デフォルトの名無しさん mailto:sage [2024/07/24(水) 09:24:46.95 ID:eaHzhPzb.net] >>959 それな 979 名前：デフォルトの名無しさん mailto:sage [2024/07/24(水) 09:30:08.78 ID:+W2StRcH.net] 意味のないFizzBuzzを散々書いておいて答えられなくなったら急に質問者を攻撃する複オジくん草 980 名前：デフォルトの名無しさん mailto:sage [2024/07/24(水) 12:35:19.94 ID:qFVR7Ywl.net] 必要な個数のタプルを配列に変換するコードでいいんじゃないかな これは長さ自由に機械的にマクロで生成できそう struct Wrapper<A, B, C, D, E>((A, B, C, D, E)); impl<A, B, C, D, E> From<Wrapper<A, B, C, D, E>> for [Tx; 5] where 　Tx: From<A> + From<B> + From<C> + From<D> + From<E>, { 　fn from(x: Wrapper<A, B, C, D, E>) -> Self { 　　[Tx::from(x.0.0), Tx::from(x.0.1), Tx::from(x.0.2), Tx::from(x.0.3), Tx::from(x.0.4)] 　} } impl<A, B, C, D, E> IntoIterator for Wrapper<A, B, C, D, E> where 　Tx: From<A> + From<B> + From<C> + From<D> + From<E>, { 　type Item = Tx; 　type IntoIter = std::array::IntoIter<Self::Item, 5>; 　 　fn into_iter(self) -> Self::IntoIter { 　　let x: [Self::Item; 5] = self.into(); 　　x.into_iter 981 名前：() 　} } [] [ここ壊れてます] 982 名前：デフォルトの名無しさん mailto:sage [2024/07/24(水) 12:36:33.67 ID:qFVR7Ywl.net] あとはタプルに登場する型を列挙して 例えばこんなコードを機械的に自動生成させてしまえばいいね type T1 = &'static str; type T2 = i64; type T3 = f64; enum Tx { T1(T1), T2(T2), T3(T3), } impl From<T1> for Tx { fn from(x: T1) -> Self { Self::T1(x) } } impl From<T2> for Tx { fn from(x: T2) -> Self { Self::T2(x) } } impl From<T3> for Tx { fn from(x: T3) -> Self { Self::T3(x) } } impl std::fmt::Display for Tx { 　fn fmt(&self, f: &mut std::fmt::Formatter) -> std::fmt::Result { 　　match self { 　　　Self::T1(x) => write!(f, "{x}"), 　　　Self::T2(x) => write!(f, "{x}"), 　　　Self::T3(x) => write!(f, "{x}"), 　　} 　} } 983 名前：デフォルトの名無しさん mailto:sage [2024/07/24(水) 12:38:12.03 ID:qFVR7Ywl.net] そうするとタプルの中の型の順番は任意でよくて タプルをラッパーにかませるだけで利用できるよ fn main() { 　let tuple = ("abcde", 123, "nop", 0.456, 789); 　for x in Wrapper(tuple) { 　　println!("{x}"); 　} 　for (i, x) in Wrapper((-1, "pi", 3, 3.14159, "END")).into_iter().enumerate() { 　　println!("{i}: {x}"); 　} } 984 名前：デフォルトの名無しさん mailto:sage [2024/07/24(水) 12:43:52.56 ID:mjGiit/q.net] 効いてる効いてるw 985 名前：デフォルトの名無しさん mailto:sage [2024/07/24(水) 12:49:36.37 ID:TJmYfYAi.net] 「XY問題だから相手にするだけ無駄」と言い放っておいてからの〜〜 986 名前：デフォルトの名無しさん mailto:sage [2024/07/24(水) 17:04:11.48 ID:1Kw3Uuff.net] もっと建設的な話題はないの？ 987 名前：デフォルトの名無しさん mailto:sage [2024/07/24(水) 19:14:00.84 ID:UKniupNy.net] 5chより建設的なコミュニティを列挙し移住を検討するのが目下最も建設的な話題である 988 名前：デフォルトの名無しさん [2024/07/24(水) 21:00:33.77 ID:bzm5y73f.net] 最近出た便利クレートの話とかすれば良いんじゃね？ 989 名前：デフォルトの名無しさん mailto:sage [2024/07/24(水) 22:25:44.31 ID:mF9Tvkg9.net] ベストな日付処理クレートについて議論しよう 990 名前：デフォルトの名無しさん mailto:sage [2024/07/25(木) 08:45:26.25 ID:q/t9CUhu.net] おすすめクレートの話はしてほしいな～ 991 名前：デフォルトの名無しさん mailto:sage [2024/07/25(木) 10:09:56.78 ID:P+cFrEvf.net] クレートの話をしてくれー、と 992 名前：デフォルトの名無しさん [2024/07/25(木) 22:41:22.06 ID:zdgCFOr2.net] クレートではないけれど今日リリースのRust 1.80でLazyCell, LazyLockが安定版に入ったよ グローバルな変数を外部クレート無しで書きやすくなる 993 名前：デフォルトの名無しさん mailto:sage [2024/07/25(木) 22:49:30.69 ID:9YYk7vP+.net] >>973 それ、OnceCell使ってたコードは全部置き換えた方がいい奴？ 994 名前：デフォルトの名無しさん [2024/07/25(木) 23:18:37.32 ID:zdgCFOr2.net] >>974 自分はそれを言えるほど詳しくないけど、必ずしも必要ではないと思う 依存クレートを減らせる点で嬉しいし、今から書くコードでは新しいものにして良いと思うけど、今使ってるものをすぐに置き換える必要があるとまでは思わない 特にライブラリを作ってる場合は、rustcを今日リリースされたばかりの最新バージョンに上げないとライブラリをビルドできなくなるということなので、もう少し待った方が良いかもしれない 995 名前：デフォルトの名無しさん mailto:sage [2024/07/26(金) 00:25:09.02 ID:/65SSmn2.net] OnceLockからLazyLockへ移行すると 変数宣言と初期化関数が離れていた可読性の問題が解決するとともに 例えばget_or_initを一箇所にするために一つ関数を用意したりするなどしていた手間も省けるようになるね そして何よりも最大のメリットはDerefによりアクセスできる利便性 996 名前：デフォルトの名無しさん mailto:sage [2024/07/26(金) 23:32:15.42 ID:/65SSmn2.net] とりあえず定番のこのあたりを置き換えた static RE: LazyLock<Regex> = LazyLock::new(|| Regex::new("...").unwrap()); static SE: LazyLock<Selector> = LazyLock::new(|| Selector::parse("...").unwrap()); 997 名前：デフォルトの名無しさん mailto:sage [2024/07/27(土) 11:02:49.38 ID:WfV9QQMJ.net] LazyLockよさそうね 998 名前：デフォルトの名無しさん mailto:sage [2024/07/27(土) 18:38:25.11 ID:U5WpGSyZ.net] 俺の今日のハマりポイントを紹介 bindgenにC++のコンストラクタを作らせると、データが壊れる よく調べたら公式ドキュメントのConstructor semanticsに書いてあった https://rust-lang.github.io/rust-bindgen/cpp.html コンストラクタを抜けたとき、C++とちがってRustは値をムーブしちゃうので struct内部を参照したポインタが変なところを参照してバグる 999 名前：デフォルトの名無しさん [2024/07/27(土) 19:30:58.99 ID:s18eFGvS.net] C++も部分的に使えるとはいえ、FFIするならCのAPIにしておく方が無難な気はする 1000 名前：デフォルトの名無しさん mailto:sage [2024/07/27(土) 20:04:50.53 ID:U5WpGSyZ.net] >>980 bindgenはFirefoxがプロダクトでたくさん使ってるって聞いて、いけると思ったんだ Firefoxは大半がC++だから 1001 名前：デフォルトの名無しさん [2024/07/28(日) 15:27:45.35 ID:v6kdbv5j.net] >>978 LazyLockさようなら に観えた 1002 名前：デフォルトの名無しさん mailto:sage [2024/07/28(日) 15:29:40.57 ID:v6kdbv5j.net] >>979 RustとC++は相性最悪 RustとCは相性良いバッチリ 1003 名前：デフォルトの名無しさん mailto:sage [2024/07/30(火) 01:24:35.90 ID:xgbf/AIH.net] >>979 この件って、RustはC++と比べて無駄にムーブするから遅いってこと？ 1004 名前：デフォルトの名無しさん mailto:sage [2024/07/30(火) 06:04:09.29 ID:RHAjweCG.net] 無駄な移動は消える cargo asmで生成コードを見ることでそれを確認できる 移動前と移動後のアドレスを表示させて最適化を阻害することで元は別々となる例も確認できる 1005 名前：デフォルトの名無しさん [2024/07/30(火) 12:06:12.26 ID:tiWzrJ23.net] >>984 ＞コンストラクタを抜けたとき、C++とちがってRustは値をムーブしちゃうので ＞struct内部を参照したポインタが変なところを参照してバグる って書いてるのに、読解力無い人？ 1006 名前：デフォルトの名無しさん mailto:sage [2024/07/30(火) 19:02:27.28 ID:dzXOiSL/.net] >>985 移動じゃなくてムーブね ここまでのレスで使われてる述語を踏襲すればいいよ 1007 名前：デフォルトの名無しさん mailto:sage [2024/07/30(火) 20:13:33.28 ID:VUdF4pDl.net] >>985 最適化のかかり具合でバグが消えたり現れたりする嫌なパターンだな 1008 名前：デフォルトの名無しさん mailto:sage [2024/07/30(火) 20:41:43.84 ID:+5mpqNgW.net] >>986 Rustを使えばそんなバグは起きない 参照のライフタイムは参照先より長くなることがコンパイル時点で保証される >>988 Rustならばそこでバグは起きようがない 1009 名前：デフォルトの名無しさん [2024/07/30(火) 22:41:22.15 ID:GjQxUZ/0.net] >>989 本人じゃないのに出しゃばらせて頂きますが…。 Rust単体じゃなくて、C++との相性問題ですよ。相性最悪って書いてるんだから。 起きようがないじゃなくて、実際に起きてるらしいじゃないですか。 最適化で治るのなら大したことじゃなくても、デバッグ時にハマるの確実な類のバグ。 将来的に全部Rustで書けば起きないような問題も、過渡期の今は良く起きます。 「Rustを使えば」「Rustなら」。 そうでしょうけど、実際問題ライブラリがなければ既存のC/C++ライブラリ使う場面は多々あるでしょう。 （枯れたライブラリならなおさら） これはRustに限らず、後続の言語全てが抱えている問題です。 1010 名前：デフォルトの名無しさん [2024/07/30(火) 22:49:06.91 ID:MqLM+D1V.net] 最適化じゃなくて単に移動の問題 Box::newで要素を直接ヒープに作れない (いちどスタックに作られてからコピーされる) のと同じで、コンストラクタを抜ける前に構造体が maybeuninit::assume_init で移動する その上で構造体のアドレスがC++のメソッドにthisポインタとして渡される際に問題を引き起こす、というように思える だとすると最適化の有無は関係なく起こる気がする ついでにいえば >>987 もあまり意味のない発言で、移動はムーブの訳語でもある (例えばC++の仕様の訳語に移動コンストラクタという表現がある) し、そもそもこの問題はムーブセマンティクスによるものでもない これはStringやVecが持つリソースを所有権ごと移動することで効率的に別の変数に割り当てるもので、構造体のアドレスのようなローレベルなものとは違うかと 1011 名前：デフォルトの名無しさん [2024/07/30(火) 22:59:00.85 ID:MqLM+D1V.net] 移動とムーブが仕様として別物だというなら、移動は英語でどう表現されてるんだ？ 1012 名前：デフォルトの名無しさん mailto:sage [2024/07/30(火) 23:00:06.83 ID:L/ylOhaJ.net] >>990 それはRust単体では全く発生しない問題だね C++とRustを併用する時にRustの知識を持たない人がハマるという話 FFI部分は両者の概念と挙動の違いの知識を持った人が作るべきだね 1013 名前：デフォルトの名無しさん mailto:sage [2024/07/30(火) 23:13:56.95 ID:EnloT7kO.net] >>979 >>値をムーブしちゃうのでstruct内部を参照したポインタが変なところを参照してバグる Rustでそのような自己参照はムーブでライフタイム切れとなるためバグは発生しなくて 自己参照を保ちたいならば値がムーブしなければよくて 値がムーブしないためにはスタック上でそのまま使うかヒープ上に確保して使えばよくて それを保証するためにRustではPinという枠組みがあって安全に取り扱えるようになってるよ 1014 名前：デフォルトの名無しさん [2024/07/30(火) 23:19:18.00 ID:MqLM+D1V.net] >>994 bindgenの作者に言ってあげればいいと思うよ ついでに改善したコードをPRしてコントリビュートしてみてはどうだろう 使用者のミスを擦るよりもずっと有意義なはず 1015 名前：デフォルトの名無しさん [2024/07/30(火) 23:48:00.88 ID:dZ3/RfBM.net] 同意 1016 名前：デフォルトの名無しさん [2024/07/31(水) 11:32:49.64 ID:yHR2oE13.net] 結合が密過ぎないかこの言語 1017 名前：デフォルトの名無しさん [2024/07/31(水) 11:35:31.65 ID:yHR2oE13.net] >将来的に全部Rustで書けば起きないような問題 さっさと仕事しろおまいらってことですね判ります 1018 名前：デフォルトの名無しさん [2024/07/31(水) 12:10:03.24 ID:yHR2oE13.net] >>985 Pin 1019 名前：デフォルトの名無しさん [2024/07/31(水) 12:10:59.00 ID:yHR2oE13.net] Pin<Arc<T>> 1020 名前：1001 [Over 1000 Thread ID:Thread.net] このスレッドは１０００を超えました。 新しいスレッドを立ててください。 life time: 65日 5時間 29分 33秒 1021 名前：過去ログ ★ [[過去ログ]] ■ このスレッドは過去ログ倉庫に格納されています

---

---

[ 新着レスの取得/表示 (agate) ] / [ 携帯版 ]

read.cgi ver5.27 [feat.BBS2 +1.6] / e.0.2 (02/09/03) / eucaly.net products.
担当:undef