Rust part16

1 名前：デフォルトの名無しさん mailto:sage [2022/06/27(月) 08:17:03.45 ID:gDlfKP6u.net] 公式 https://www.rust-lang.org/ https://blog.rust-lang.org/ https://github.com/rust-lang/rust Web上の実行環境 https://play.rust-lang.org 日本語の情報 https://rust-jp.rs/ ※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 part15 https://mevius.5ch.net/test/read.cgi/tech/1652347700/ 657 名前：デフォルトの名無しさん mailto:sage [2022/09/08(木) 01:11:28.44 ID:U6/gufpm.net] >>648 変数やフィールドのメモリ上の表現� 658 名前：ｪ特定のエンディアンにしたいのであれば、 #[repr(C)] struct BeU32([u8; 4]); みたいな構造体を用意して impl Be32 { fn get(&self) -> u32 { u32::from_be_bytes(self.0) } fn ser (&mut self, v: u32) { self.0 = v.to_be_bytes(); } } こういうアクセサを実装すれば良いかと 何の役に立つのかはよくわからないけど、特定のエンディアンでシリアライズされたデータにそのままアクセスしたい場合とかに便利なのかな [] [ここ壊れてます] 659 名前：デフォルトの名無しさん mailto:sage [2022/09/08(木) 01:21:33.97 ID:5HeI/FQK.net] mansplainers 660 名前：デフォルトの名無しさん [2022/09/08(木) 15:55:57.30 ID:Vswe11EN.net] RustをOpenMPIに対応させるようなプロジェクトってありますか？ 661 名前：デフォルトの名無しさん mailto:sage [2022/09/08(木) 16:49:24.48 ID:mLv3aAxt.net] 「Rust OpenMPI」でGoogle検索 662 名前：デフォルトの名無しさん mailto:sage [2022/09/08(木) 18:02:42.70 ID:U6/gufpm.net] OpenMP なのか Open MPI なのかどっち 663 名前：デフォルトの名無しさん [2022/09/08(木) 20:45:38.87 ID:Vswe11EN.net] 知りたいのはOpenMPIの方です ググるとOpenMPIとOpenMPを勘違いしたと思われるRayonを紹介する記事が出てきたり、OpenMPがらみのサイトが出てきたり、なかなか状況が分かりません・・・・ 664 名前：デフォルトの名無しさん mailto:sage [2022/09/08(木) 20:53:50.25 ID:RwfCQI7B.net] 一番上のrsmpiは違うの 665 名前：デフォルトの名無しさん mailto:sage [2022/09/08(木) 21:56:17.41 ID:fa0yFdt8.net] MPIはHPC以外では使う必要ないです 機械学習でも有用だとは思いますが そもそもフレームワークが対応していないから 全部自前で作ってるような人以外は必要ないです 666 名前：デフォルトの名無しさん mailto:sage [2022/09/09(金) 01:14:31.51 ID:4b4Wyf25.net] Open MPIに限らずMPIはアプリから見たらただのライブラリだからRust側で特別な対応は不要で単にCの関数を呼び出せばよいだけでは 667 名前：デフォルトの名無しさん mailto:sage [2022/09/09(金) 08:12:49.36 ID:auDHI5c1.net] 良くありがちな奴だと思うけど struct ARGB32 {A: u8, R: u8, G: u8, B: u8,} みたいに書くとスネークケースじゃないと警告が出るけどどう書くのがRust流なの？ これ小文字にしちゃったら少なからず可読性が落ちるよね 668 名前：デフォルトの名無しさん [2022/09/09(金) 08:31:41.27 ID:WeF8ASv0.net] #[allow(non_snake_case)] しかしフィールド名だけ小文字にすれば不要 struct ARGB32 {a: u8, r: u8, g: u8, b: u8,} そして可読性が落ちると思わない 669 名前：デフォルトの名無しさん mailto:sage [2022/09/09(金) 09:24:21.25 ID:4b4Wyf25.net] 構造体名もCamelCaseでArgb32とすべきかな 670 名前：デフォルトの名無しさん mailto:sage [2022/09/09(金) 12:29:38.55 ID:6YdHvwwi.net] 識別子を極端に省略するのは良くないという現代のプログラミングの流儀と業界の略語でコンフリクトしてるよね。 略語を使わずに書くとこうかね？ Color<T>{alpha: T, red: T, green: T, blue: T} CMYはどうなるとか言い出すやつがいると面倒そうだけど。 671 名前：デフォルトの名無しさん mailto:sage [2022/09/09(金) 12:42:45.67 ID:VsTRsG1f.net] enum Color { Red, Blue, Green, RGB(u32, u32, u32), HSV(u32, u32, u32), HSL(u32, u32, u32), CMY(u32, u32, u32), CMYK(u32, u32, u32, u32), } 672 名前：デフォルトの名無しさん mailto:sage [2022/09/09(金) 13:41:22.02 ID:4b4Wyf25.net] 最低限ガイドには従った方が良いと思う https://rust-lang.github.io/api-guidelines/naming.html acronymはひとつ単語として扱うとあるから Rgb とか Argb とすべき あとは適当なグラフィック系ライブラリの実装を見て真似してみたら良いのでは 規約に従ってないライブラリも多いけど そもそも既存crate使えば独自にArgb型定義する必要もなくなるかもしれない 673 名前：はちみつ餃子 mailto:sage [2022/09/09(金) 14:02:11.22 ID:gp9Eay33.net] API ガイドラインってことは、 API として公開しない (内部的な) 名前は雑でいいってことだよね。 674 名前：デフォルトの名無しさん mailto:sage [2022/09/09(金) 14:15:33.61 ID:+r9uXbjm.net] >>661 個人的にはこっちの方が好きだけど 規約的にダメなら仕方ない 675 名前：デフォルトの名無しさん mailto:sage [2022/09/09(金) 14:42:45.26 ID:4b4Wyf25.net] >>666 非公開部分を将来公開APIにする可能性や、自分以外の誰かがソース読んでパッチ作ってくれる可能性考えると、 最初から内部も規約に従ったものにしておいた方が良いと思う そもそもひとつのプロジェクトの中で公開部分と非公開部分で異なる規約混在するのも嫌では 676 名前：デフォルトの名無しさん mailto:sage [2022/09/09(金) 15:18:27.40 ID:QLGZdL8Z.net] mozillaは公開できない関数名を使ってオープンソース化が数年遅れた過去があったなぁ。 677 名前：デフォルトの名無しさん mailto:sage [2022/09/09(金) 15:35:09.62 ID:7NqN1r1N.net] gameraとか？ 678 名前：デフォルトの名無しさん mailto:sage [[ここ壊れてます] .net] >>669 94年初リリースで98年ソース公開で 数年遅れるとは？ 679 名前：デフォルトの名無しさん mailto:sage [2022/09/09(金) 17:53:00.11 ID:rfSAUeXI.net] CreateFileW in windows::Win32::Storage::FileSystem - Rust ttps://microsoft.github.io/windows-docs-rs/doc/windows/Win32/Storage/FileSystem/fn.CreateFileW.html とかAPIガイドラインもクソもないけど名前だけRustに寄せたところでリファレンスドキュメント(MSDN)との差異が 拡大するだけでメリットはほとんど無いような 680 名前：デフォルトの名無しさん mailto:sage [2022/09/09(金) 21:16:36.10 ID:pyHRaXAz.net] JPEG、MPEG、PNG、HEVC・・・すでに略されている物をありがちな命名規則で書くと判りにくくなる 681 名前：デフォルトの名無しさん [2022/09/09(金) 22:46:34.35 ID:B0h43lqZ.net] >>673 同意 682 名前：デフォルトの名無しさん mailto:sage [2022/09/10(土) 00:32:32.71 ID:qBfKxAEz.net] >>663 その方向でやってみます というかこの構造体をArrayに沢山詰めようとすると初期化が難しいのか。どうしようか悩んだ結果こうしてみた #![no_std] const LEN: u32 = 640*480; let mut bitmap:[u32; LEN] = [0; LEN]; let mut bitmap:[ARGB32; LEN] = unsafe {core::intrinsics::transmute::<_, [ARGB32; LEN]>(bitmap)}; bitmap[0].red = 0xFF; アセンブラリストを見る限りは問題なさそう 683 名前：デフォルトの名無しさん mailto:sage [2022/09/10(土) 01:19:16.36 ID:BhJh8aSd.net] acronymを全部大文字にするか先頭だけ大文字にするかってそんなに大きな問題かな 一貫性のあるルールに従っていれば書き手や読み手として混乱することもないと思うんだが 684 名前：デフォルトの名無しさん [2022/09/10(土) 03:00:06.93 ID:Rsh0NV07.net] Ipv4なんて一瞬なんのことか分からんかったな 結局慣れで、一貫性以上に価値のある好みなんてのはない 685 名前：デフォルトの名無しさん [2022/09/10(土) 07:09:44.43 ID:2MfL7Eat.net] >>676 その一貫性が崩れるのがいやなんだろ。 ドキュメント・コメントでは全部大文字なのにコードでは先頭だけ大文字とか。 慣れの問題だが、今まで/一般的 に全部大文字で慣れてるものをこの時だけ先頭大文字に慣らせというのは抵抗感あって当たり前。 686 名前：デフォルトの名無しさん [2022/09/10(土) 07:12:21.94 ID:2MfL7Eat.net] >>676 問題の大小なんて誰も言ってない。 今までの慣れ/一般的な表記 を置き換えるのは抵抗感あるって話。 687 名前：デフォルトの名無しさん mailto:sage [2022/09/10(土) 12:37:11.73 ID:GXRB1/O5.net] 命名規則を利用する目的は可読性や開発効率の向上などのはず 一般的な表記から外れるのであればそれなりの理由が必要であろう 「命名規則に従ったから」では「目的より手段を優先している、合理性がない」などと 突っ込まれてもしょうがない 688 名前：デフォルトの名無しさん mailto:sage [2022/09/10(土) 13:03:13.98 ID:jQKLnU5m.net] JavaScriptのアイツは XmlHttpRequestと命名されるべきだったのか？ XMLHTTPRequestと命名されるべきだったのか？ 689 名前：デフォルトの名無しさん [[ここ壊れてます] .net] eXtend Markup Language Hyper Text Transfer Protocol Request 690 名前：デフォルトの名無しさん mailto:sage [[ここ壊れてます] .net] 完全に好みの問題と思うから何らかのルールで統一されてればどっちでも良いと思うけど、 LCD TV、nVidia、iOS IoT Hubなんかをどう表記するかとか変数名ならどうしようとか考えるのめんどいから 表記の慣例とか無視して全部キャメルケースにしちゃうな 691 名前：デフォルトの名無しさん mailto:sage [2022/09/10(土) 13:50:29.86 ID:TnGNUz3W.net] ルールから逸脱させるかどうか悩むならルールに合わせておくおじさんになった 692 名前：デフォルトの名無しさん [2022/09/10(土) 14:31:16.93 ID:/uHulLcW.net] Rustすれのレベルの低さにガッカリ Python質問すれとかみたいに和気あいあいとしてない殺伐にドッキリ 693 名前：デフォルトの名無しさん mailto:sage [2022/09/10(土) 14:56:40.59 ID:qBfKxAEz.net] >>675みたいに書いた場合 >let mut bitmap:[u32; LEN] = [0; LEN]; のmutが余計だと警告が出る。この場合実際に確保されるメモリ領域は書き込みも出来るスタックフレームだろうし mutを取っても動作上は問題ないと思うけど、mutがない領域に書き込むことになりプログラムの意味としては誤っている 参照先を強制的に書き換えるようなコードを書くと、とコードと警告と動作のミスマッチが起きる気がするけど なんか上手い書き方はないのだろうか この辺の低レイヤーの用途で参照先を書き換える話ってBookのReferenceやUnsafeあたりにもそれっぽい事書いてないし どこを見たらいいのか判らない 694 名前：デフォルトの名無しさん mailto:sage [2022/09/10(土) 15:47:06.47 ID:BhJh8aSd.net] >>675 ARGB32にDefault実装して let mut bitmap : [ARGB32; LEN] = Default::default(); とするのが良いかと repr(C)がついてない構造体のメモリ上での表現がどうなるかは保証されてないから元のコードが意図通り動作する保証はないと思う 695 名前：デフォルトの名無しさん mailto:sage [2022/09/10(土) 15:48:16.32 ID:vDnMZIxl.net] >>675 初期化難しいかな。こうとか https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=49327f78412221161809733ee34bf013 696 名前：デフォルトの名無しさん mailto:sage [2022/09/10(土) 15:54:53.07 ID:BhJh8aSd.net] >>687 [T; N] は N <= 27 までしかDefault実装されてなかったからこのコードじゃダメだった こっちならOK let mut bitmap: [ARGB32; LEN] = std::array::from_fn(|_i| Default::default()); 697 名前：デフォルトの名無しさん mailto:sage [[ここ壊れてます] .net] 最後の手段のtransmuteは安易に使うものじゃないと思う 698 名前：デフォルトの名無しさん mailto:sage [2022/09/10(土) 16:39:14.44 ID:qBfKxAEz.net] >>687 すみません。構造体にはrepr(packed)を付けています。u8がパディング無し4つ並ぶはず repr(C)だとCと同様にパディングされる可能性が出てくると思うのですが >>688 CloneとCopyを付ける方法に関してはどのような動作になるのか確信を持てていないです 原則コピーになるという情報は出てきますが、画像のバッファだし原則参照で必要なときだけ コピーしたいです(すでに初期化とは別のところで問題になっています。参照とコピーの 切り替え方法が判らない) 699 名前：デフォルトの名無しさん mailto:sage [2022/09/10(土) 18:12:40.24 ID:n3Y/KVD/.net] >>686 最初に定義した変数bitmapはmoveしてるだけだからmutは余計でいいと思うけど？ 700 名前：デフォルトの名無しさん mailto:sage [2022/09/10(土) 19:24:52.82 ID:qBfKxAEz.net] >>692 自分の理解があっているか不安なんですが、mutを付けずにletで宣言すると書き換わらない値として 書き込めないメモリ領域(例えば.textセクション)に配置されたりしないのか？というのが心配な点です 言語仕様上mutを付けない宣言でも必ず読み書き可能な領域に配置されるというのであればそれでかまわないと思いますが とりあえず手元のx64向けのコンパイラではmutを付けずともスタックフレームに配置されるようですが 組み込み向けなど他のコンパイラでも同様の動作を前提として問題ないのか判りません 古いバージョンのBookにはスタックやヒープの解説があったようですが ttp://web.mit.edu/rust-lang_v1.25/arch/amd64_ubuntu1404/share/doc/rust/html/book/first-edition/the-stack-and-the-heap.html#:~:text=Memory%20management&text=The%20stack%20is%20very%20fast,explicitly%20allocated%20by%20your%20program 最新版にこのページはないような・・・しかも >Rust ‘stack allocates’ by default, which means that basic values ‘go on the stack’. だとRAMを節約したいからROMに配置する実装もあり得ると読めなくもない 701 名前：デフォルトの名無しさん mailto:sage [[ここ壊れてます] .net] let bitmap:[u32; LEN] = [0; LEN]; let mut bitmap:[ARGB32; LEN] = unsafe {core::intrinsics::transmute::<_, [ARGB32; LEN]>(bitmap)}; これでいいってことじゃない？ 一個目のbitmapは実際書き込んでないからmut不要 二個目のbitmapは変数名同じだけど一個目とは別の変数で、こっちは次の行で書いてるからmut必要 702 名前：デフォルトの名無しさん mailto:sage [[ここ壊れてます] .net] あぁ言いたいことは分かった 確かにtransmuteしてるからバックエンドの挙動によっては変なことになりうるかもね ただそれは別にmutをつけても保証はされない気がする 703 名前：デフォルトの名無しさん mailto:sage [2022/09/10(土) 20:24:18.78 ID:BhJh8aSd.net] >>691 repr(packed)を指定した構造体のフィールドへのアクセスは未定義動作を引き起こす可能性があるからrepr(packed)は基本的には使わない方が良いよ https://doc.rust-lang.org/nomicon/other-reprs.html#reprpacked 確かにrepr(C)やrepr(Rust)はパディングされる可能性があるけど、フィールドのアラインメントを適切にするために必要なものなので パディングが問題になるならフィールドのメンバーの順序やサイズを見直すか、フィールドの値を読むのに std::ptr::read_unaligned を使う必要があるよ https://doc.rust-lang.org/std/ptr/fn.read_unaligned.html read_unalignedのドキュメントにも書いてあるけど、アライメントが不適切なフィールドへの参照を作るのすら未定義動作になるという落とし穴もあったり、 repr(packed)な構造体の取り扱いにはいろいろと注意が必要になるので、本当に必要なとき以外は使わない方が良いよ あと、repr(packed)はrepr(packed, Rust)と同じ意味になるので、構造体のフィールドがメモリ上でどのような配置になるかの保証はないよ フィールドの定義順とメモリ上での順序を同じにしたいのであれば repr(C) または repr(C, packed) と指定する必要があるよ いずれにせよ今回は全てのフィールドがu8だからrepr(C)でパディングが挿入されることはなく 無駄にメモリを消費することもないよ どうしてもパディング挿入が心配なら mem::size_ofやmem::align_ofを使って構造体のサイズとアライメントに関するアサーションを加えるのが良いと思う 704 名前：デフォルトの名無しさん mailto:sage [2022/09/10(土) 20:36:28.31 ID:BhJh8aSd.net] >>693 let a = ...; let mut a = a; みたいに書いた場合、一個目のaと二個目のaは別の変数扱いでそれぞれ個別に領域が割り当てられるよ 二個目のaに格納されるのはaの値で、ポインタじゃないから一個目のaが書き込み不可な領域に格納されていたとしても 二個目のaのために割り当てられた読み書き可能な領域に一個目のaの値がコピーされるような動作になるはず 最適化によって一個目のaと二個目のaが同じ領域を使い回すようになるかもしれないけど、二個目のa定義後はその領域に対する書き込みは可能なことが保証されてるはず transmuteを呼び出した場合も同じで、 transmute(a) という呼び出しをした場合transmuteに渡されるのはaの値なので、二個目のaの定義後は問題なくaに書き込めるはず ただし、transmuteに&aを渡して&mutに変換するみたいなことをすると未定義動作になるから注意は必要 https://doc.rust-lang.org/reference/behavior-considered-undefined.html > Mutating immutable data. All data inside a const item is immutable. Moreover, all data reached through a shared reference or data owned by an immutable binding is immutable, unless that data is contained within an UnsafeCell<U>. 705 名前：デフォルトの名無しさん [2022/09/11(日) 12:51:18.94 ID:6axTKkj4.net] >>693 ＞mutを付けずにletで宣言すると書き換わらない値として ＞書き込めないメモリ領域(例えば.textセクション)に配置されたりしないのか？というのが心配な点です しねーよ。 組み込みだろーがそれは変わらない。 letついて束縛変数といわれようが変数は変数。 706 名前：デフォルトの名無しさん mailto:sage [2022/09/11(日) 13:08:43.20 ID:3JeGkSLy.net] 今はしないけどそうなるような最適化は禁止されてないのでは 707 名前：デフォルトの名無しさん mailto:sage [2022/09/11(日) 13:49:03.04 ID:7UmicIsS.net] コンパイル時に値が確定してないとtextセクションに書けないでしょ 708 名前：デフォルトの名無しさん mailto:sage [2022/09/11(日) 13:55:35.90 ID:VMVpvyTB.net] そっちは定数でconstだしそうなる letはあくまでもimmutableな変数であり定数ではない 709 名前：デフォルトの名無しさん mailto:sage [2022/09/11(日) 13:57:25.52 ID:kEOVMHNm.net] コンパイル時に確定するような式なら最適化でありえるんじゃないの？ 710 名前：デフォルトの名無しさん mailto:sage [2022/09/11(日) 14:07:54.90 ID:VMVpvyTB.net] どのように最適化されようが constではなくlet x = ...ならば let mut x = x; とムーブして書き換え可能 これは言語のレベルで保証される そしてそのように使うならば最適化も無駄なことせずにtext segmentでなくdata segmentに置くだろう 711 名前：デフォルトの名無しさん mailto:sage [2022/09/11(日) 14:40:44.81 ID:ujBIW69o.net] CloneとCopyについて let mut bitmap:[u32; LEN] = [0; LEN]; let mut bitmap:[ARGB32; LEN] = unsafe {core::intrinsics::transmute::<[u32; LEN], [ARGB32; LEN]>(bitmap)}; と #[derive(Clone, Copy, Default)] ＆ let mut bitmap:[ARGB32; 16] = [ARGB32::default(); LEN]; で読み書きを bitmap[0].red = 0x80; let x = bitmap[0].red; bitmap[0].green = x; としてみたけど出力された読み書き部分のコードは同じでした。もっとでかい構造体じゃないとムーブかコピーかの区別は出来ないのかな >>696 マジか。Rustでもパディングの問題がつきまとうのか。でも >Accessing unaligned fields directly with e.g. packed.unaligned is safe however. って事は.redとかでアクセスする場合はコンパイラが良きに計らってくれるのでアクセス境界の問題は起きないって事かな？ 画像データのバイトやビットの並びなんてすでに決まっていてプログラムはそれに合わせるしかないのが普通でしょうし 勝手にパディングされても困ります 実は並行してCでも書いているんだけど構造体のパディングの制御は処理系依存らしくて移植性を優先すると データは整数の配列で持って論理演算とシフトで分解、構築するコードになってしまってます 712 名前：デフォルトの名無しさん mailto:sage [2022/09/11(日) 14:49:25.24 ID:FOB38Q8d.net] そのような実装はしたくないわけですか 713 名前：デフォルトの名無しさん [2022/09/11(日) 15:13:19.03 ID:/O1tQPyF.net] どの言語でも同じ Rustでも&mutでtransmuteしてもendian依存は避けられないな let mut x = 0x01020304_u32; let a = unsafe { std::mem::transmute::<&mut u32, &mut [u8; 4]>(&mut x) }; a[1] = 7; assert_eq!(x, 0x01020704); とlittle endianでは7の位置はこうなる 714 名前：デフォルトの名無しさん mailto:sage [2022/09/11(日) 18:54:24.82 ID:gEyGQ7vE.net] このスレでよく出てくる μt ってなんなん？ 音的に mut をそう書いてる異常者がいるだけかと思ってるんだけど、なにか別の意味を持った概念や機能だったりするの？ 715 名前：デフォルトの名無しさん mailto:sage [2022/09/11(日) 20:25:15.55 ID:FOB38Q8d.net] 自分も思ったけどブラウザによっては & mut がそうなるみたい 716 名前：デフォルトの名無しさん [2022/09/11(日) 20:27:57.44 ID:QYXgEc7E.net] >>708 そうなんだ。 717 名前：デフォルトの名無しさん mailto:sage [2022/09/11(日) 20:45:42.63 ID:hnVgjqVb.net] >>708 なるほど、ありがと。 異常者かと思って真面目に読む気が失せてたんだけど誤解だったか。 718 名前：デフォルトの名無しさん mailto:sage [2022/09/11(日) 21:25:51.88 ID:zZ32ojSE.net] HTMLの文字参照で& muがμ 719 名前：デフォルトの名無しさん mailto:sage [2022/09/11(日) 21:45:56.06 ID:ujBIW69o.net] 例えば pixel.alpha = in[0].alpha; pixel.red = in[0].red / 2; pixel.green = in[0].green / 2; pixel.blue = in[0].blue / 2; out[0] = pixel; と red = 0xFF & (in[0] >> 16); green = 0xFF & (in[0] >> 8); blue = 0xFF & in[0]; red /= 2; green /= 2; blue /= 2; pixel = 0xFF000000 & in[0]; pixel |= red << 16; pixel |= green << 8; pixel |= blue; out[0] = pixel; ではだいぶ見やすさが違うような 720 名前：デフォルトの名無しさん mailto:sage [2022/09/11(日) 21:47:41.04 ID:3JeGkSLy.net] >>704 パディングというかメモリアクセス時のアラインメントについてはCPUの仕様だから言語関係ないよ x86がunalignedなアクセスについてゆるゆるだから忘れられがちだけど雑に書いたプログラムをarmで動かしたりするとクラッシュする 今回はu8へのアクセスだからさすがにパディング入れられることはないと思うけどね 721 名前：デフォルトの名無しさん mailto:sage [2022/09/11(日) 21:50:14.96 ID:3JeGkSLy.net] >>712 シフト処理など隠蔽してくれるアクセサメソッド用意したらだいたい同じような読みやすさになるのでは 722 名前：デフォルトの名無しさん mailto:sage [2022/09/11(日) 23:45:21.14 ID:ujBIW69o.net] Rust固有じゃないけど移植性を改善する方法に1バイトずつ処理するという手があるけどこの実装は、今時の32bitや64bit環境で 相応にデバフが入るんですよね。MSVCでも8bitロード×8を64bitロード×1に最適化してくれなかったし >>713 そこを抽象化するのが処理系の仕事では。いまだに構造体でパース・・・みたいなコードを見かけるし >>714 読みやすさは改善しても今度は速度にデバフが入るような。こういうケースでアクセサメソッドを利用したとして 全てインライン展開＆最適化されますかね？一つでもコールやブランチが残ったら速度が結構落ちるだろうし 723 名前：デフォルトの名無しさん [2022/09/11(日) 23:59:30.49 ID:/O1tQPyF.net] >>707 色んなブラウザで見てみたけど &mut (分けて書くと & mut )が μt と表示されるのはバグってるchmateだけっぽい 724 名前：デフォルトの名無しさん mailto:sage [2022/09/12(月) 00:37:31.19 ID:5hhAOS+Q.net] &mut テスト 725 名前：デフォルトの名無しさん mailto:sage [2022/09/12(月) 01:00:12.66 ID:JkhjRZ+U.net] >>716 ほー、chmateはワザとunescapeしてるのか？ 5chがUnicode文字表示できるようになったんだし、そういうのはもう余計なお世話だな 726 名前：デフォルトの名無しさん [2022/09/12(月) 01:13:39.26 ID:D0TZxDhn.net] HTML等の文字参照を処理する場合でも μt (＝ & m u ; t )が μt となるのは正しいけど &mut (＝ & m u t )が μt となるの間違いだからこれはバグと思われる 727 名前：デフォルトの名無しさん mailto:sage [2022/09/12(月) 02:30:39.40 ID:JkhjRZ+U.net] あ、たしかにバグっぽい・・・ 728 名前：デフォルトの名無しさん mailto:sage [[ここ壊れてます] .net] 文字列参照に & mut なんてないからテキトーに解釈してるんでしょ 良し悪しは別にして html を扱うブラウザではそれほど珍しくはない 個人的には余計な事すんなとは思う 729 名前：デフォルトの名無しさん mailto:sage [2022/09/12(月) 07:14:45.53 ID:tyJETXG8.net] これはmateのバグです & x y z ; とセミコロンで終わる場合のみその部分を文字参照として解釈するのが正しいです 730 名前：デフォルトの名無しさん mailto:sage [2022/09/12(月) 07:33:21.32 ID:o/NFQNbK.net] &mut と書けば良いかな テスト → &mut 731 名前：デフォルトの名無しさん mailto:sage [2022/09/12(月) 07:34:32.06 ID:o/NFQNbK.net] & amp ; amp; を空白なしで書き込んだら & に変換されてしまった 実体参照複数回展開しているのかな &amp; 732 名前：デフォルトの名無しさん mailto:sage [2022/09/12(月) 08:15:16.27 ID:NGx/fsjU.net] ライブラリとかのコンポーネントの一部を作っているときに入出力だけ不定値として扱う方法ってありませんかね ガワ作って入出力を完全に外部に出さないとコードがみんな消えてしまうのは不便です 最適化レベルによる変化とか全然確認出来ないし 733 名前：デフォルトの名無しさん mailto:sage [2022/09/12(月) 08:36:58.55 ID:tyJETXG8.net] ちょっと意味がわからない こうなるはずだから困ることはないと思うけど ・最適化によってRustが定めている意味が変わることはない ・pub宣言しているものは中で呼ばれていなくても単体コンパイルで消えることはない ・pub宣言されていないものは中で呼ばれていなければ今後も誰からも呼ばれないためwarningが出て消える 734 名前：デフォルトの名無しさん mailto:sage [2022/09/12(月) 10:25:58.86 ID:o/NFQNbK.net] genericな関数だと呼び出し元がないとコード生成されないとか？ 735 名前：デフォルトの名無しさん mailto:sage [2022/09/12(月) 12:04:36.56 ID:tyJETXG8.net] その場合でも実際に使う型々でtestを書くだろうからcargo testで確認できるでしょ 736 名前：デフォルトの名無しさん mailto:sage [2022/09/12(月) 12:46:09.29 ID:SjJDv8F6.net] >>726 ありゃうちの環境の問題か。pub付けただけじゃ関数丸ごとなかったことにされる pub extern "C"でRust外の入出力にしてようやく消えなくなる もうちょっと調べてみる 737 名前：デフォルトの名無しさん mailto:sage [2022/09/12(月) 14:30:52.03 ID:o/NFQNbK.net] >>729 ちなみにターゲットはbinと(r)libのどっち？ binならpubでも消えるかも 738 名前：デフォルトの名無しさん mailto:sage [2022/09/12(月) 19:11:31.91 ID:2zIjStdY.net] >>730 変更してみた。staticlibだとpub付けても消える。rlibなら消えないようだ とりあえずrlibにしておいてある程度形になってきたら変更すればいいか コード自体はどっちでも大差ないだろうし 739 名前：デフォルトの名無しさん mailto:sage [2022/09/18(日) 01:08:32.32 ID:g4sMxKuf.net] [u32; LEN]と[ARGB32; LEN] の件、アラインメントが違うからtransmuteの時点でUBだけど 740 名前：デフォルトの名無しさん mailto:sage [2022/09/19(月) 02:33:25.46 ID:HMAR4dxa.net] Tauriで動画プレーヤー的なのを作るサンプルってどっかにある？ ただ再生するデータは既存のmp4ファイルなどではなくRustプログラムから渡したい あと再生、停止、コマ送り、シークなどの基本的な機能は実装したい 741 名前：デフォルトの名無しさん mailto:sage [2022/09/19(月) 07:48:35.44 ID:BbpMxDy4.net] TauriってWebアプリのサーバーサイドがRustで一体型プログラムになっているだけだろ？ そして既存のWeb技術を活かせるのがTauriの利点だろ？ そうならば例えばhls.jsなど既存の好みの動画配信再生フレームワークを使えばいいだけじゃないか？ Webサーバーサイドやったことあるならばフロントエンドからファイルに見えているものは本物のファイルである必要はなくサーバーサイドが算出していれば十分だろ？ 742 名前：デフォルトの名無しさん mailto:sage [2022/09/19(月) 12:27:41.81 ID:HMAR4dxa.net] >>734 >HLS ちょっと調べてみたけどHLSでいわゆるRAWデータを再生出来るという情報は見つけられていない 特にビデオが未圧縮データを扱えそうにない。オーディオは未圧縮FLACでいけるかもしれないけど 再生したいのがWebブラウザが対応していないデータなのでどうしようか考え中 ビデオはBMPのぱらぱら漫画でオーディオはHLSで未圧縮FLACとか？なんか無駄に実装量が増えるけど 743 名前：デフォルトの名無しさん mailto:sage [2022/09/19(月) 13:11:44.57 ID:PTk7Q+2G.net] その手のやつでオーバーヘッド減らすならOS毎にネイティブ実装するしかなくない？ 744 名前：デフォルトの名無しさん mailto:sage [2022/09/19(月) 18:38:49.00 ID:EybjBREq.net] なんとかtauri使うにしてもJSやらWASMやらで動画レンダリングするようなもの作らないとだめそう 745 名前：デフォルトの名無しさん mailto:sage [2022/09/19(月) 18:45:15.20 ID:npVSxydm.net] 実装を追加させない方法ってありますか？ 別個に渡されたふたつの型が同じであるという制約を付けたいという目的で 以下のようなトレイト Same を定義した場合、実装を追加できてしまうと破綻してしまうので、 なんらかの方法で制限できるだろうかという疑問です。 pub trait Same<T> {} impl<T> Same<T> for T {} // 使用例 pub fn foo<T, U>(x: T, y: U) where T: Same<U>, { } ちなみに目的を上述しましたけども実際には目的というよりは題材です。 つまり具体的な用途は考えておらず、質問はあくまでも「実装させない方法があるかどうか」です。 746 名前：デフォルトの名無しさん mailto:sage [[ここ壊れてます] .net] trait Sealed {} pub trait Same<T>: Sealed {} 747 名前：デフォルトの名無しさん mailto:sage [2022/09/19(月) 21:19:03.69 ID:EybjBREq.net] https://rust-lang.github.io/api-guidelines/future-proofing.html#sealed-traits-protect-against-downstream-implementations-c-sealed 748 名前：デフォルトの名無しさん mailto:sage [2022/09/19(月) 21:29:04.18 ID:Elo9mBmF.net] ふたつの型が同じという制約を付けたいなら TとUじゃなくTとTにすればいいじゃんか 749 名前：デフォルトの名無しさん mailto:sage [2022/09/19(月) 21:34:13.52 ID:jWPeXdq1.net] >>738 達成したいことが特にないらしいからなんとも言えないけど enum を使っても近いことはできるんじゃないかな。 enum Same{SameA(型A),SameB(型B)} みたいにしてやれば、Same 経由で扱う限り実装は増やせないぞ。 750 名前：デフォルトの名無しさん mailto:sage [2022/09/19(月) 22:48:26.11 ID:npVSxydm.net] >>739-740 実装を追加させないテクニックのひとつとして有用ですし紹介はありがたいです。 しかしそれだと Sealed を実装した型だけにしか使えず、 >>738 で示したような汎用的に型を比較するトレイトには使えないですよね。 この Same のように機能するトレイトに実装を追加させないというのは前提と考えて欲しいです。 >>741 そういうレスが付くことを避けたいから最後の文をつけたつもりなんですが……。 Rust の初心者として様々な言語機能を理解したいという立場で疑問に思った部分を抜き出し、 説明のために前提条件を設定したのであって、前提条件の部分自体は解決したい課題ではないです。 いわゆるXY問題というものの存在は承知しておりますので 解決したい大元の問題を示さないというのがモヤモヤするだろうなというのはわかります。 わかりますが、大元の問題というものはありません。 この範囲で完結するパズルだと思ってください。 751 名前：デフォルトの名無しさん mailto:sage [2022/09/20(火) 00:14:22.92 ID:nBuFqijL.net] 2つの矛盾してる要求を同時に実現は無理だわな 752 名前：デフォルトの名無しさん mailto:sage [2022/09/20(火) 00:42:08.53 ID:FykVNAq+.net] impl Foo for Tが存在する時点で他の型にFoo実装しようとするとconflictしなかったっけ 753 名前：デフォルトの名無しさん mailto:sage [2022/09/20(火) 00:43:28.04 ID:FykVNAq+.net] fundamentalな型に一通り実装しておけば良さそう 754 名前：デフォルトの名無しさん mailto:sage [2022/09/20(火) 00:48:25.82 ID:FykVNAq+.net] https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=02e7851289dd00c9ffc8679ad68644d9 755 名前：デフォルトの名無しさん mailto:sage [2022/09/20(火) 00:50:06.23 ID:FykVNAq+.net] fundamental云々はcoherent ruleの話でconflictとは関係なかったわ 756 名前：738 mailto:sage [2022/09/20(火) 01:17:29.77 ID:w2qVrruo.net] なるほど、 C++ と違って特殊化にならないからより狭い範囲の実装は追加できないんですね。 &T とか &mut T とかも先に実装しておけば追加の余地をなくせると。 &T とか &mut T とか以外にどういうのがありえますかね？ 757 名前：デフォルトの名無しさん mailto:sage [2022/09/20(火) 01:40:45.09 ID:lHbnVGdk.net] >>743 Sealedも<T>にすればいいんじゃないの https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=dadd7e289ec4e5bb9746015ac093a9bc 758 名前：738 mailto:sa [] [ここ壊れてます] 759 名前：ge mailto:2022/09/20(火) 01:53:09.66 ID:w2qVrruo.net [ >>750 ありがとうございます。 言われてみれば当然のような感じですがまだまだ私は Rust らしい考え方が出来ていないようです。 ] [ここ壊れてます] 760 名前：デフォルトの名無しさん mailto:sage [2022/09/20(火) 18:26:27.74 ID:p9SiwD2d.net] 「Linux」、バージョン6.1でRustを導入へ--トーバルス氏が明言 https://japan.zdnet.com/article/35193491/ 761 名前：デフォルトの名無しさん mailto:sage [2022/09/20(火) 20:25:26.21 ID:ckEqOjly.net] >>752 いいね ここ最近で一番いい知らせだわ 762 名前：デフォルトの名無しさん mailto:sage [2022/09/20(火) 20:46:56.46 ID:Di+jgu/u.net] 今のところデバドラだけという話だけど 基幹部分の新実装をRustで作りましたという 人が絶対現れるからそのときどうなるだろ 763 名前：デフォルトの名無しさん mailto:sage [2022/09/20(火) 20:51:48.09 ID:rUHkgvjw.net] 誰もvoldemort typeの名を呼ぼうとしない 764 名前：デフォルトの名無しさん mailto:sage [[ここ壊れてます] .net] MS AzureのCTOが「新しいプロジェクトでC/C++使うのはやめて 非GC言語が必要な状況ではRustを使うべき時だ」ってツイートしてるけど Visual StudioでもRustが最初からパッケージングされてるようになるのかな 765 名前：デフォルトの名無しさん mailto:sage [2022/09/22(木) 09:05:24.01 ID:e5bGjsaE.net] https://www.publickey1.jp/blog/22/cloudflarenginxrusthttppingoracdncpu31.html Cloudflare、NGINXに代えて自社開発のRust製HTTPプロキシ「Pingora」をグローバルCDNに採用。性能向上しつつCPUとメモリ消費を3分の1に 766 名前：デフォルトの名無しさん mailto:sage [2022/09/22(木) 13:36:58.59 ID:V4zanZlp.net] >>756 MSがRustの開発環境に投資するならVSCodeのエクステンションじゃない? いまさらVSに対応言語を追加する気はないでしょ どう考えてもWindowsユーザーは少ないだろうし 767 名前：デフォルトの名無しさん mailto:sage [[ここ壊れてます] .net] >>756 マーク・ルシノビッチ氏、Microsoft AzureのCTOなのか。 インサイドWindowsにはお世話になったわ。 768 名前：デフォルトの名無しさん mailto:sage [2022/09/23(金) 05:18:56.24 ID:I8UIrhRk.net] Iteratorに対するIntoIteratorのように Futureに対するIntoFutureということか しかも.awaitに対して自動適用だからもっと効果が大きいか 非同期を返すビルダーに対してFutureを返させるためのビルド完了指示メソッド呼び出しが不要となる 769 名前：デフォルトの名無しさん mailto:sage [2022/09/23(金) 08:24:08.00 ID:G8O+P73a.net] Rust analyzerが優秀過ぎてMSが入る余地なさそう PythonがMS Storeから落とせるみたいにインストールが楽になるとかならありそう VSに導入されたらそれはそれで面白いんだけど.Net言語との連携が強化されないと旨味がないな 770 名前：デフォルトの名無しさん mailto:sage [2022/09/23(金) 08:29:43.60 ID:exFn1ITS.net] Rustからから.Net? 意味ないやろ... 771 名前：デフォルトの名無しさん mailto:sage [2022/09/23(金) 10:08:58.99 ID:QyFSmn0+.net] 既存ライブラリがそのまま呼べるならお試しで部分的に新言語導入してみようとな 772 名前：る可能性もあるので意味はある [] [ここ壊れてます] 773 名前：デフォルトの名無しさん mailto:sage [[ここ壊れてます] .net] Rust/Cliとか余計なもの作られそう 774 名前：デフォルトの名無しさん [2022/09/23(金) 12:31:56.94 ID:aakQSAhx.net] >>758 VSCodeの方が対応は早いかもだが、VSに追加する気がないことは無いんじゃないかな 775 名前：デフォルトの名無しさん mailto:sage [2022/09/23(金) 17:48:32.43 ID:z6wpDrU6.net] >>762 書き方悪かったわ Rustで作った何かをC#とかから簡単に呼べるといいねって意味だった GoのCGoみたいな仕様だったら色んな意味で面白いと思う 776 名前：デフォルトの名無しさん [2022/09/23(金) 18:02:01.54 ID:bhLcJIv7.net] rust_analyzerの話題ついでに教えて欲しいのですが、保存なしで構文チェック等してくれるようにならないものなのですか？ 編集を破棄して保存前の状態にしたい時があるので、できれば自動で保存したくないのです Vim系プラグイン等を入れていれば無限に戻せるのかもしれないものの、Vimが使えない身としては困ってしまいます 777 名前：デフォルトの名無しさん mailto:sage [2022/09/23(金) 18:02:58.63 ID:exFn1ITS.net] >>766 ああそれならありだな まあ今でもC/C++とかで作ったdllなりをC#から呼び出せるから同じような感じでできるんじゃないかな 778 名前：デフォルトの名無しさん mailto:sage [2022/09/23(金) 18:04:41.93 ID:nucVVsrt.net] >>767 まあ普通はGitを使うからね 779 名前：デフォルトの名無しさん mailto:sage [2022/09/23(金) 18:05:33.15 ID:5/jqA4bf.net] C#も.Netも全く興味ないので知らないが PythonでもJavaScriptでも何でもRustで作ったライブラリなどを簡単に呼び出すことができる仕組みがそれぞれ整えられている 既存のものの置き換えは無意味だが新たに作られるものはRustで書くことが増えている 780 名前：デフォルトの名無しさん mailto:sage [2022/09/23(金) 21:26:00.89 ID:Oi43IjEf.net] repr(C)でCのフリしたRustじゃなくて、俺はありのままのRustが動いている世界線が見たいよ 781 名前：デフォルトの名無しさん [2022/09/23(金) 21:26:44.38 ID:bhLcJIv7.net] >>769 でも、破棄ならコミット後の状態にも戻せるぜ？ 782 名前：デフォルトの名無しさん mailto:sage [2022/09/23(金) 21:42:44.57 ID:KYVSlV2v.net] >>771 ABI安定化するまではFFIでextern "C"は避けられないよ 783 名前：デフォルトの名無しさん mailto:sage [2022/09/23(金) 21:53:19.36 ID:wlVyCNVq.net] >>773 そんなことすべきでない 自由にRust コンパイラによる最適化の余地を与える現在の方針がベスト 外部に公開しなきゃいけない時に外部に公開する部分だけを#[repr(C)]や#[wasm_bindgen]など指定すればよい 784 名前：デフォルトの名無しさん mailto:sage [2022/09/23(金) 23:40:33.31 ID:EyovOcQI.net] 双方でマーシャル/アンマーシャルが必要になって無駄だよね 785 名前：デフォルトの名無しさん [2022/09/23(金) 23:55:09.24 ID:9eaiNZZz.net] なるほど 786 名前：デフォルトの名無しさん mailto:sage [2022/09/23(金) 23:58:10.15 ID:SxK8BSHj.net] 対C/C++はそこまで必要ならそこもRustで書いちゃうから何ら問題はない 他の言語ではそれぞれもっと大きなオーバヘッドを持っているので誤差に収まり問題にならない 787 名前：デフォルトの名無しさん mailto:sage [2022/09/24(土) 00:06:07.91 ID:j2XeJCoN.net] やっぱエアプの複オジはわかってないなぁ 788 名前：デフォルトの名無しさん mailto:sage [2022/09/24(土) 00:11:50.36 ID:DaB/WDgt.net] >>774 pubなitemのABIに最適化関係ある？ なんかと混同してない？ 789 名前：デフォルトの名無しさん mailto:sage [2022/09/24(土) 00:14:18.76 ID:DaB/WDgt.net] もしかして repr(Rust) のこと言ってる？ 790 名前：デフォルトの名無しさん mailto:sage [2022/09/24(土) 03:05:40.90 ID:ugWjDAH5.net] Rustだけで閉じていればpubであっても自由に最適化されるからpubかどうかは関係ないでしょう 結局Rustの外に公開する部分だけの話に限られるからそこだけ相手毎に応じる現行の方式のままで構わないでしょう 791 名前：デフォルトの名無しさん [2022/09/24(土) 08:50:49.84 ID:pfcr5AFZ.net] C++やRustはABI決まってないのにC言語は何故ほぼ決まってるの？ 792 名前：デフォルトの名無しさん mailto:sage [2022/09/24(土) 09:11:44.18 ID:DaB/WDgt.net] >>781 dylibの場合pubは大いに関係あるよ 793 名前：デフォルトの名無しさん [2022/09/24(土) 09:15:16.80 ID:WR9fIR0K.net] ぶっちゃけあらゆるOSがC言語で書かれているあたりCの呪縛から逃れられないよ 794 名前：デフォルトの名無しさん [2022/09/24(土) 09:26:53.29 ID:rPP8Qygy.net] >>782 名前をプログラマが決められるからだよ 795 名前：デフォルトの名無しさん mailto:sage [2022/09/24(土) 09:44:37.12 ID:BCuennz9.net] >>782 むしろCは決まってるの？ 決まってるわけじゃなくて単純だし歴史も長いから結果的にほぼ変わらない&その現状に合わせて変わらない変更をしてるだけみたいなことをgccかなんかの中の人の記事で読んだ気がするんだけどデマなんかな 796 名前：はちみつ餃子 mailto:sage [2022/09/24(土) 10:38:04.73 ID:2HWwrIyG.net] 近年になって作られた高速リンカ mold の作者の話でも、 文書化されていない暗黙の仕様に何度もぶつかったみたいなことだったはず。 C 以外の言語 (処理系) もツールチェインは共通のものを使っている場合は結構あるし どれがどの挙動に依存しているかようわからんので安易に整理するわけにもいかず、 結局のところは C コンパイラとは長年に渡って協調してきたから細かい問題点が 解決されているというだけで、そんなにカッチリした仕様が確立しているわけではないと思う。 797 名前：デフォルトの名無しさん mailto:sage [2022/09/24(土) 11:00:33.46 ID:DaB/WDgt.net] CはCPUベンダーが呼び出し規約を文書化してるよ moldの話はELFやリンクに関連する話では 確かにABIのうちではあるけど言語ごとに異なる仕様になるようなものではないと思う 798 名前：デフォルトの名無しさん mailto:sage [2022/09/24(土) 11:33:36.58 ID:FWSMvJVe.net] AMD64の呼び出し規約をググるだけで2種類くらい出てくるのにコイツは何を言っているんだ？ >>786 呼び出し規約どころか構造体のレイアウトすら実装依存の部分があるよ 799 名前：デフォルトの名無しさん mailto:sage [2022/09/24(土) 13:14:15.81 ID:DaB/WDgt.net] >>789 そこでいう実装依存ってプラットフォームごとの差違のこと？ それとも同じプラットフォームでもツールチェイン依存でレイアウトが変わりうる場合があるの？ 800 名前：デフォルトの名無しさん [2022/09/24(土) 14:25:21.27 ID:PoJJisuz.net] cdeclとかstdcallみたいなやつ？ 801 名前：はちみつ餃子 mailto:sage [2022/09/24(土) 16:06:51.67 ID:2HWwrIyG.net] >>791 その段階ではあまり曖昧さはない。 リンクする前の状態はリンクに必要な情報一式が入ってるはずなんだけど、 その扱いが言語や処理系をまたぐとややこしくなることもあるってこと。 アーキテクチャによって扱いを変える必要がある場合もあるし。 802 名前：デフォルトの名無しさん [2022/09/24(土) 16:24:43.84 ID:PoJJisuz.net] >>792 コンパイラがリンカに渡す情報って統一規格があるの？ 803 名前：デフォルトの名無しさん mailto:sage [2022/09/24(土) 17:05:25.99 ID:7d8zqodE.net] >>793 別に統一されちゃいないがELFとかPEとか 804 名前：デフォルトの名無しさん [2022/09/24(土) 17:10:20.79 ID:GMpouZpq.net] じゃあ、そのオブジェクト・ファイル形式の仕様に問題があるってことでは？ 805 名前：はちみつ餃子 ◆8X2XSCHEME mailto:sage [[ここ壊れてます] .net] >>795 ELF に置き換わるときにオブジェクトファイルの仕様の曖昧さはほとんど解消されていると思う。 ただ現実には全てが正しく実装されているわけではなく、 場合によっては正しかったほうを間違った側にあわさざるを得ないとかいう場合もある。 仕様がどうこう言ったって、実装が間違っていたって現実にもう動いているものがあるのなら変えられんのよ。 そういう歴史的負債がどんどん積み重なってわけわからんようになる。 806 名前：デフォルトの名無しさん mailto:sage [2022/09/24(土) 19:08:36.35 ID:eDCmZTMq.net] ARMの規約 https://github.com/ARM-software/abi-aa 807 名前：デフォルトの名無しさん mailto:sage [2022/09/24(土) 22:13:22.85 ID:DaB/WDgt.net] 元々の他言語からrust呼び出す話ならそのレベルの話は関係ないでしょ LLVMがよしなにやってくれるのでは 808 名前：デフォルトの名無しさん [2022/09/24(土) 22:29:32.09 ID:GMpouZpq.net] ARM64ほどの絶対的パワーは必要ないので、ARM63で価格が120円くらいのチップになりませんかね？ 809 名前：デフォルトの名無しさん mailto:sage [2022/09/25(日) 08:24:33.85 ID:j3K9KjV7.net] Option<NoneZeroUsize>などを使えば IDやカウンタなどの用途でOption<usize>などを使っていたものを 半分のメモリサイズで済むようになるの？ 810 名前：デフォルトの名無しさん mailto:sage [2022/09/25(日) 11:42:14.43 ID:sQFmQmse.net] >>799 任せてください。符号ビット省略しておきますね 811 名前：デフォルトの名無しさん [2022/09/25(日) 15:32:52.52 ID:F2Viqk5M.net] Microsoftがやりそうなことだけど、Rustに独自拡張を含めたりとかしてほしくない 812 名前：デフォルトの名無しさん mailto:sage [2022/09/25(日) 17:24:00.83 ID:xalR35FT.net] Linuxはカーネル開発の為に今まさにRustに独自拡張を含ませようとしてるのに Microsoftはダメなの？ 813 名前：デフォルトの名無しさん mailto:sage [2022/09/25(日) 17:34:47.30 ID:4B3i10Bx.net] try_new()とかtry_reserve()とか元々ないのが不思議だったし導入の良いきっかけとなっただけ 814 名前：デフォルトの名無しさん mailto:sage [2022/09/25(日) 17:57:47.12 ID:6lgwXJxi.net] 言語自体forkして独自のエコシステムを構築しようとしなければ別に良いのでは 815 名前：デフォルトの名無しさん mailto:sage [2022/09/25(日) 18:09:02.84 ID:6wI0gbs/.net] 正直LinuxにRustなんて辞めればいいのに・・・ 816 名前：デフォルトの名無しさん mailto:sage [2022/09/25(日) 18:14:08.03 ID:Td47G6We.net] Rustに限った話じゃないんだけどそれなりに複雑なロジック(例えばデコーダやパーサ)の実践的なテストの 作り方の解説とかどっかにある？例えばJPEGやPNG、MP3、AVIとかを扱うようなコードを想定 関数単体のテストはともかく、結合した状態で全てのコードを動かそうとすると入力パターンがどんどん増えるし パディングビットにゴミがあっても問題ないかなどを考慮しだすと更に膨れあがる さらに歴史が長いフォーマットだと、そもそも仕様をどう定義するのかという点が問題になることもあるし 817 名前：デフォルトの名無しさん mailto:sage [2022/09/25(日) 18:21:16.44 ID:xalR35FT.net] テストがすごいのはSQLite 818 名前：デフォルトの名無しさん mailto:sage [[ここ壊れてます] .net] >>803 別に独自拡張とか入れてないだろ コンパイラへの機能追加は全部本体に入れていてnightlyで使える状態だし Linuxカーネル向けのallocなんかは単にライブラリであって言語自体がforkしてるわけではない 819 名前：デフォルトの名無しさん mailto:sage [2022/09/25(日) 19:57:21.62 ID:6lgwXJxi.net] >>806 なんかまずいことでもあるの？ 820 名前：デフォルトの名無しさん [2022/09/25(日) 19:59:47.96 ID:Rxhh3DJ9.net] >>810 迷走と凋落、そして黒歴史化。 821 名前：デフォルトの名無しさん mailto:sage [2022/09/25(日) 20:07:26.82 ID:58piYD8Z.net] >>807 メディアのエンコーディングのことはさっぱりしらんけど、一般的には結合テストじゃなくて、単体テストでパターンは網羅すべし できるんならやればいいけど、結合テストで入力の網羅なんて普通はやらない 822 名前：デフォルトの名無しさん mailto:sage [2022/09/25(日) 20:26:59.51 ID:Td47G6We.net] >>812 条件分岐で関数Aを呼ぶべき所を間違えてA'を呼んでいて出力結果がちょっと変・・・というのをさっきやらかした 関数そのものに問題はないし処理内容がちょっと違うだけなので実行は出来てしまうのがいやらしい で、テストを作ろうとしたけどどうしようか悩み中 823 名前：デフォルトの名無しさん mailto:sage [2022/09/25(日) 20:37:27.14 ID:lhW/fB5K.net] そういうのは呼び出し側の単体でええんちゃうの 824 名前：デフォルトの名無しさん mailto:sage [2022/09/25(日) 21:09:49.29 ID:j1+dHWho.net] >>807 歴史があり、曖昧さが残るフォーマットの再実装はできればやりたくない仕事だな。 対応する仕様を現代で最低限必要なものを取捨選択して決め打ちで実装しつつ、考慮漏れでクリティカルなものは取り入れていく方式でやるしかないよ。 歴史あるフォーマットの曖昧な対応を追体験する作業は、不毛だからできれば既存実装におまかせすべき。 825 名前：デフォルトの名無しさん mailto:sage [2022/09/25(日) 21:31:04.61 ID:Td47G6We.net] >>814 中間コンポーネントの単体テストって普通どうやるんだろ 後段のコンポーネントを切り離してテストするのか？繋げたままテストするのか？ 切り離せるようにするとその部分にバグが入り込む余地が生まれるし >>815 歴史が長いと仕様上○○であるがこれに準拠しないアプリやデータが少なからず存在するため △△のような実装がベターだみたいなのが沢山あるからねぇ そしてこの手の情報はググっても網羅するのが難しい 826 名前：デフォルトの名無しさん mailto:sage [2022/09/25(日) 21:51:09.44 ID:6lgwXJxi.net] >>811 Linux側にメリットがないと言ってる？ 827 名前：デフォルトの名無しさん mailto:sage [2022/09/25(日) 21:51:47.84 ID:PDKGWlWe.net] >>816 > 中間コンポーネントの単体テストって普通どうやるんだろ 中間の意味がよく分からんけど>>813みたいな話なら関数A、関数A'をモックにしてテストする たいていのテストツールではモックの呼び出し回数のテストができる 828 名前：デフォルトの名無しさん mailto:sage [2022/09/25(日) 21:53:52.45 ID:j1+dHWho.net] >>816 JavaみたいにDIが発展しているタイプの言語だと中間コンポーネント� 829 名前：ｪ呼び出すコンポーネントはモックをインジェクトしてやって、適切なメソッドが呼び出されたかのテストとかよく書くね。 けど、正直Rustを含む他の言語で中間のレイヤだけ独立してテスト書くようなこだわりはあまり見たことも書いたこともないなぁ。 モジュール設計の考え方が変わるからかな？ [] [ここ壊れてます] 830 名前：デフォルトの名無しさん mailto:sage [2022/09/25(日) 22:41:02.05 ID:Td47G6We.net] 今作っているのだとこんな感じかな？ 関数C(データの前処理、処理単位への分割) ↓ 関数B(処理全体の制御)→関数A'(処理1-2) ↓ 関数A(処理1-1) >>818,819 その場合モックへ切り替える機構はどうするんだろ そのためにコードを書き換えていてはミスが入り込む可能性が高くなるし、条件付きコンパイルも同様のリスクがある てかThe Rustのテストの所を見ても関数の呼び出し状況をテストする方法とかは書いていないんだよな なんかその辺を良い感じに可視化してくれるツールとかあるんだろうか 831 名前：デフォルトの名無しさん mailto:sage [2022/09/26(月) 00:07:36.94 ID:h/WE7ZWH.net] >>820 すまん rust だと cargo test で単体テストを実施するみたいだけど mook/stub をどうやって使うかはよくわからんかったわ C++ とかだと googlemook とか使ってテスト用のモッククラスを作って入れ替えるかたちだね 832 名前：デフォルトの名無しさん mailto:sage [2022/09/26(月) 00:33:03.55 ID:TCGzsvbI.net] mockall使うとか 833 名前：デフォルトの名無しさん mailto:sage [2022/09/26(月) 06:28:19.26 ID:p/pWEmYs.net] cargo testで関数テスト、モジュールテスト、モジュール間テストなどあらゆるテストをやっているけどダメなの？ 834 名前：デフォルトの名無しさん mailto:sage [2022/09/26(月) 06:47:39.41 ID:h/WE7ZWH.net] >>823 >>820 > その場合モックへ切り替える機構はどうするんだろ に答えてやってくれ 835 名前：デフォルトの名無しさん mailto:sage [2022/09/26(月) 19:21:24.42 ID:kI3cAlPQ.net] モックやスタブは別モジュール化しておいて mod tests内では本物モジュールをuseする代わりにそれをuseするだけじゃないの？ 836 名前：デフォルトの名無しさん mailto:sage [2022/09/26(月) 19:31:47.69 ID:V9yeC/LF.net] あと#[cfg(test)]でそれをuse そして#[cfg(not(test))]で本物use 837 名前：デフォルトの名無しさん mailto:sage [2022/09/26(月) 19:31:51.25 ID:i/jndsoD.net] 他の言語でもユーティリティを使わずに、DIやモックを自分でやったことがないんだろうな 説明が面倒だ 838 名前：デフォルトの名無しさん mailto:sage [2022/09/26(月) 19:38:20.09 ID:V9yeC/LF.net] >>827 テスト以外の開発の話でも フレームワークに依存してやってる人は 単純なこと含めて本質的なことを理解してない人が多く フレームワークなしでは何も分からず何も出来なくなってしまう例を時々見かける 839 名前：デフォルトの名無しさん mailto:sage [2022/09/26(月) 21:10:39.16 ID:qW/k82Qg.net] cfg使えば良いじゃないって人は#ifまみれで一見しただけじゃ 何がどう動くんだか判らないCのコードを正当化するつもりなのだろうか Rustは人間が注意すれば問題ないみたいな考えはレガシーで時代遅れだ という思想の言語だと思っているんだが違うのかな 840 名前：デフォルトの名無しさん mailto:sage [2022/09/26(月) 21:41:35.64 ID:w5YNQb64.net] >>829 #ifは使わないし cfg(test)はテスト分離のため必須でしょ どんな環境でも魔法は無いよ 841 名前：デフォルトの名無しさん mailto:sage [2022/09/26(月) 23:33:07.51 ID:h/WE7ZWH.net] >>829 cfg使わないで済むいい方法があるなら書いてよ... 842 名前：デフォルトの名無しさん mailto:sage [2022/09/27(火) 01:17:35.37 ID:OwORQ6vn.net] mod tests に cfg(test) は必要だとして 依存性の注入にはtrait使えって事なのでは 843 名前：デフォルトの名無しさん mailto:sage [2022/09/27(火) 07:51:04.95 ID:f9SEu4pT.net] traitで置き換え可能にするのが面倒というのはありそうだな。 844 名前：デフォルトの名無しさん mailto:sage [2022/09/27(火) 08:15:53.87 ID:SBVoZTui.net] AMD64のデフォルトのオペランドサイズは32bitなのにusizeが64bitなのは何でなのかな 845 名前：デフォルトの名無しさん mailto:sage [2022/09/27(火) 11:05:22.42 ID:OwORQ6vn.net] size_tが64bitだからでは 846 名前：はちみつ餃子 mailto:sage [2022/09/27(火) 12:28:55.13 ID:ozjafOA0.net] >>834 usize はポインタのサイズということになっている。 847 名前：デフォルトの名無しさん mailto:sage [[ここ壊れてます] .net] >>831 単体テストで、依存を分離するのは当然のことすぎてみんな説明が億劫になってる C++だろうがRubyだろうが、モックやスタブを使って、関数同士やクラス同士の依存を切り分けてテストするのは当たり前 そうしないとそもそも単体テストにならないじゃん わかってる人にしかわからないであろう簡略な説明をすると、テスト用のエントリポイントで、テストに使うモックオブジェクトを指定するだけだよ そういうことができるようにあらかじめコード設計しておかないといけないがな 考えてなかったならリファクタが必要 848 名前：デフォルトの名無しさん mailto:sage [2022/09/27(火) 19:48:22.41 ID:J8MleXan.net] そんなフワフワした説明されても... 849 名前：デフォルトの名無しさん mailto:sage [2022/09/27(火) 19:51:56.44 ID:AWnlNGZp.net] 本物と異なり決まった値を返す送信元スタブと 本物と異なりassertだけする送信先モックを mod testsの中では本物の代わりにuseするだけだよね 入れ替えちゃうからtrait制約で本物も偽物も受け付け対応とかわざわざする必要ないよね 850 名前：デフォルトの名無しさん mailto:sage [2022/09/28(水) 00:44:24.76 ID:JQpGo85s.net] >>839 useしたモックをどうやって注入すんの 関数の引数もstatic変数でも良いけど、テスト対象の実装がモックも本物も選択的に使えるようにするならば、 genericな型を受け付けるような実装にしておかないといけないのでtraitが登場するのでは それともmod testsの外もcfgで置き換えると言っている？ 851 名前：デフォルトの名無しさん mailto:sage [2022/09/28(水) 00:48:00.37 ID:JQpGo85s.net] 要は use imp::Foo; fn target(foo: Foo) {} がテスト対象だとして mod tests { use mock::Foo; #[test] fn test() { target(Foo::new()); } } してもコンパイル通らないよね targetがimp::Fooもmock::Fooも受け付けるようにするにはtraitが必要では 852 名前：デフォルトの名無しさん mailto:sage [2022/09/28(水) 07:20:15.72 ID:1i04Jlqk.net] traitが無い言語では無理ってこと？？ 853 名前：デフォルトの名無しさん mailto:sage [2022/09/28(水) 11:35:17.56 ID:RLf9Yg7w.net] >>842 他の言語は他のやり方でやってるだけだろ 854 名前：デフォルトの名無しさん mailto:sage [2022/09/29(木) 01:43:05.00 ID:xXycU9Ev.net] u32 を格納する型が必要になり、また、逆に u32 に変換する必要もあるという状況で せっかくだから u32 に変換可能な型は受け入れようと考えてこんなコードを書きました。 しかしエラーになります。 struct Code(u32); impl<T: Into<u32>> From<T> for Code { fn from(x: T) -> Self { Code(x.into()) } } impl From<Code> for u32 { fn from(Code(x): Code) -> Self { x } } 結果的に自分自身への変換を許すことになってしまうのが既存 (標準ライブラリ) の定義と衝突しているという理屈は理解しているのですが、 問題を解消するためにこの定義が受け入れる範囲から自分自身 (Code) は除外するように うまく制約を付ける方法は思いつきません。 そもそもこんなところで勝手に変換するのがよくない作法だとかそういうのは脇に置いて 「自分自身だけ除外するような制約」を上手いこと表現できませんかね？ 855 名前：デフォルトの名無しさん mailto:sage [2022/09/29(木) 02:16:48.63 ID:zId7dOnm.net] 無い 856 名前：デフォルトの名無しさん mailto:sage [2022/09/29(木) 02:20:01.39 ID:7xp1eqla.net] そっかー 857 名前：デフォルトの名無しさん mailto:sage [2022/09/29(木) 02:40:21.97 ID:U5dWXlr2.net] そういうのはIntoCodeみたいな感じで別トレイトにすることが多い気がする https://docs.rs/axum/latest/axum/response/trait.IntoResponse.html 858 名前：デフォルトの名無しさん [2022/09/30(金) 02:17:04.59 ID:Yj/X+hjS.net] 初歩的なことですまんけどさ メソッド内で↓みたいなのってよく見るけど、こう言うのってself.asdfのまま使用するのに比べてどういった利点があるの？ let asdf = self.asdf; 859 名前：デフォルトの名無しさん mailto:sage [2022/09/30(金) 10:23:40.27 ID:1sTGpNyR.net] 名前を短くする目的が99パー 860 名前：デフォルトの名無しさん mailto:sage [2022/09/30(金) 11:00:13.39 ID:tNhbOFxw.net] クロージャーで構造体のフィールドにアクセスすると構造体ごとムーブしちゃうんでそれ対策じゃないかな 2021で対策されたからどんどん減ってくだろうけど https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=ebea0bd9611104e7a90eb8dfcb9899c9 861 名前：デフォルトの名無しさん mailto:sage [2022/09/30(金) 12:43:57.87 ID:NYKsqXq4.net] 書き方は違うけどフィールドそれぞれに対して処理を行う場合に抜け漏れがないことをコンパイラにチェックさせる目的でローカル変数にすることはある let Foo { foo, bar. baz } = self; としておくと後続の処理で使わないフィールドがあったときにコンパイラが警告してくれる 構造体に新たにフィールド追加した場合も分割代入の箇所でコンパイルエラーになるので修正必要箇所を洗い出すことができる 862 名前：デフォルトの名無しさん mailto:sage [2022/09/30(金) 13:52:13.77 ID:yzoXDHK/.net] >>851 なんかすごくモヤモヤする 863 名前：デフォルトの名無しさん mailto:sage [2022/09/30(金) 14:15:24.65 ID:oHn8O8ll.net] 本人は俺ってスゲー、天才やん！ って思ってるんだろうけど後でコード見たらなんでこんなイミフなことしてるんだ？バカじゃねーの ってなるパターンかと まあこういう工夫をすること自体は悪くない 864 名前：デフォルトの名無しさん mailto:sage [2022/09/30(金) 14:42:00.50 ID:M1og6e+j.net] フィールドそれぞれに処理をするシチュエーションがわからない 865 名前：デフォルトの名無しさん mailto:sage [2022/09/30(金) 14:50:06.85 ID:temvUu5a.net] >>851 俺もそのdestructuring assignment自体は使いまくる しかし目的が漏れチェックとは違うのでこうだな let Self { foo, bar, .. } = self; 866 名前：デフォルトの名無しさん mailto:sage [2022/09/30(金) 14:55:47.39 ID:t/wNXSJY.net] >>851 これいいな 867 名前：デフォルトの名無しさん [2022/09/30(金) 15:59:33.74 ID:XmkFmofe.net] こうやって自己満足の意味不明なコードが量産されていく 868 名前：デフォルトの名無しさん mailto:sage [2022/09/30(金) 16:19:08.34 ID:GH/ZHf2N.net] 全フィールド舐めるのが重要な処理ってシリアライズとかだろうか そんな小手先のテクニックとかじゃなくてproc_macro組んだ方がいいと思う シリアライズしたいだけならserde使って#[derive(Serialize)] これも結局proc_macroだわな 869 名前：デフォルトの名無しさん mailto:sage [2022/09/30(金) 17:36:27.38 ID:NYKsqXq4.net] コマンドライン引数や設定ファイルの定義をclap::Argやserde::Deserializeで宣言的にやって、 それらを処理するところで分割代入してローカル変数にして処理してる 人間が意識的に気をつける必要がある箇所を極力減らしたい気持ちでやっている 好き嫌いあるかも知れないけど趣味プロダクトだしコーディングの意図をコメントに残してるから許せ 870 名前：デフォルトの名無しさん mailto:sage [2022/10/01(土) 02:29:47.97 ID:hYwRxeDD.net] >>844 impl<T: Into<u32>> From<T> for Code {}の定義はFromの反射性と衝突するから間違ってる。 Into<u32>を受け付けたいなら関数のパラメタの型をT: Into<u32> or impl Into<u32>にすればいい。 まあ、実装上の規約として必要なんで内部ではtrait IntoFooはパターンとして使われるけど外に漏らすようなものでもない。 871 名前：デフォルトの名無しさん mailto:sage [2022/10/01(土) 02:38:45.63 ID:6voBA5Ft.net] &(T, U)と(&T, &U)って等価ですか？ 872 名前：デフォルトの名無しさん mailto:sage [2022/10/01(土) 05:47:36.69 ID:6w1pI6Co.net] 等価ではありません 873 名前：デフォルトの名無しさん [[ここ壊れてます] .net] アドレスを考えれば明白に別物 一方で let t = (123, "abc"); let (x, y) = &t; と自動マッチングしてくれて &t の型は &(i32, &str) x の型は &i32 y の型は &&str となる つまり&(T, U)が(&T, &U)に分割代入される 874 名前：デフォルトの名無しさん mailto:sage [2022/10/02(日) 10:11:02.15 ID:vdaryILR.net] test 875 名前：デフォルトの名無しさん mailto:sage [2022/10/03(月) 22:39:32.97 ID:zgM1XF6F.net] amd64ターゲットでアセンブラリストを吐かせてみたらr13が全く使用されていないんだけど r14、r15よりr13を空けておく理由がなにかあるのかな 876 名前：デフォルトの名無しさん mailto:sage [2022/10/03(月) 23:46:41.15 ID:cMmfYMlm.net] >>865 そんな不吉なレジスタなんか使うな！ 877 名前：デフォルトの名無しさん [2022/10/04(火) 00:38:55.95 ID:1GTeu6AF.net] うまく表現できないのですが、cやc++なら部分から始められる(動くものが作ることができる)のですけど、rustはそんな気がしないというか 伝わりにくいかもしれませんけど 878 名前：デフォルトの名無しさん mailto:sage [2022/10/04(火) 00:52:50.22 ID:4fgdKnMe.net] そういう事象をちゃんと論理がとおった表現ができないからrustが使えないんだよきみは！ 879 名前：デフォルトの名無しさん mailto:sage [[ここ壊れてます] .net] 作りたいものの設計のイメージがc++でできているならそれをrust化するのは比較的簡単だろうしそれができないならrustの基本的な理解が足りないだけかと 880 名前：デフォルトの名無しさん mailto:sage [[ここ壊れてます] .net] Rustはデータ構造を最初に設計しないといけないというのはあるな C++でもちゃんとそういうやり方が出来てるなら素直に移行できるだろうけど 雑にポインタ持ち回ったり実装の都合でアドホックに相互参照入れちゃったりする人には厳しいだろう 881 名前：デフォルトの名無しさん mailto:sage [2022/10/04(火) 08:55:50.45 ID:fDq9dWrD.net] C系は良くも悪くも動いてしまうんよな そんで知らぬ間に副作用まみれになっている 882 名前：デフォルトの名無しさん mailto:sage [2022/10/04(火) 09:10:45.14 ID:9SKodj4D.net] >>867 慣れの問題も大きいのでは 883 名前：はちみつ餃子 mailto:sage [2022/10/04(火) 09:22:15.67 ID:P4nmisNi.net] 雑に始めてから整理していくスタイルなら C++ のほうがやりやすいというのは理解できる。 でも雑に始めたら整理する機会などないのが現実。 884 名前：デフォルトの名無しさん [2022/10/04(火) 09:24:31.25 ID:BONyu2jp.net] >>867 ですが、 部分から始められるというのは、部分的な学習からということです ここまで学習すればここまではできるとか rustでは最初のプログラムを作るにもたくさんのことを知らなければならないというか Haskellをかじったことがあり、とても興味深いのですが わかりにくい独り言に、レスをくださってありがとうございました 885 名前：はちみつ餃子 mailto:sage [2022/10/04(火) 09:48:05.73 ID:P4nmisNi.net] >>874 > 部分的な学習から できない。 部分的に学習して何かができたように見えても必ず間違ったものを書いているのが C++ というもの。 学習を進めていくにつれて間違っていたことに何度も気づくのでうんざりした経験があるだろ？ 886 名前：デフォルトの名無しさん mailto:sage [2022/10/04(火) 10:23:23.92 ID:5od2FDFX.net] 部分的な学習ってのは C with classes -> STL -> move みたいな感じじゃない？ 他人のコード読むなら全部必要だけど、独習してる分には最初テンプレートとかなくてもいけるでしょ 887 名前：デフォルトの名無しさん mailto:sage [2022/10/04(火) 12:43:12.54 ID:7zYgBA5I.net] >>875 >>876 横からだけど、「部分的な学習」はもっと手前のところ。初心者でも 空のコード->リテラル->関数呼出->ライブラリ使用->変数定義・使用 あたりで使い方が広がるんだけど、Rustは関数呼出-変数あたりに概念のデカイ塊がある。 このあたりをまとめて覚えないと機能するプログラムを組めないので、学習者には辛い状態が続く。 Rustはc++以上に挫折しやすいと思う。 888 名前：デフォルトの名無しさん mailto:sage [2022/10/04(火) 12:54:59.39 ID:zVqHX6VA.net] 借用と実体(所有権)を常に意識しなきなならんからね Cだと全部ポインタ使うから意識しないんだけどね 889 名前：デフォルトの名無しさん mailto:sage [2022/10/04(火) 13:01:26.34 ID:NJ6V6LdV.net] どんなプログラミング言語でもいいから何か言語を学習済みの人にとって 他の言語を学習するのは部分的に段階的にすることが可能だよ もちろんRustでも同じで初心者向けの学習本 The Rust Programming Language https://doc.rust-jp.rs/book-ja/ を順番に少しずつ進めれば部分的に段階的に学習できるよ 890 名前：デフォルトの名無しさん mailto:sage [2022/10/04(火) 13:14:23.44 ID:fXb8hG+g.net] >>877 段階を経ず一気に進める無謀なことをする人だけが挫折するかもしれないが無謀なその人が悪い >>878 いきなりそこまで進める人は単なる無謀者 まずは他の言語と同じ使い方 ・実体のコピー ・参照（＝借用） のみ使っている限り所有権なんて知らなくてよい 参照を戻り値としない限りライフタイムも知る必要ない まずは部分的な学習をすればいい その後で所有権とライフタイムを学べばよい 891 名前：はちみつ餃子 mailto:sage [2022/10/04(火) 13:25:41.11 ID:P4nmisNi.net] >>877 > 関数呼出-変数あたりに概念のデカイ塊がある C++ にもある。 あるのに中途半端な状態で間違った使い方が出来てしまうのが問題の根源。 まともに機能していないことに気づかずに 機能するプログラムを作れていると誤解して後になって結局は行き詰る。 >> 878 意識する必要はある。 コンパイラが検証してくれないのだからむしろ C のほうが強く意識する。 892 名前：デフォルトの名無しさん mailto:sage [2022/10/04(火) 13:37:36.16 ID:pLeAl7hn.net] まずは(Copy実装型の)数値演算だけやって変数と関数の使い方を覚えればいいだけじゃん 所有権なんて出て来ないぜ その後にようやく数値の配列をやってその参照渡しと可変参照渡しを学ぶ といったように順番にちよっとずつ学習していけば全くの初心者でも躓くことはない 893 名前：デフォルトの名無しさん mailto:sage [2022/10/04(火) 13:44:23.36 ID:0vVjyJiG.net] 相変わらず複オジはクソだな 894 名前：デフォルトの名無しさん mailto:sage [2022/10/04(火) 13:49:35.50 ID:ez1nu7fa.net] 部分的な学習ができないと主張してるやつは、いきなり無茶なことをしてるバカだけだな。 895 名前：デフォルトの名無しさん mailto:sage [2022/10/04(火) 14:54:07.07 ID:zVqHX6VA.net] >>880 でも標準機能の中でその理解が必要なんだよ into_iterとかiterとか その辺は本当にちゃんと理解してないとまともなループする書けない 896 名前：デフォルトの名無しさん mailto:sage [2022/10/04(火) 15:06:46.90 ID:ZhUau2yw.net] 言語の学習ではあまりないと思うけど複数のコンポーネントを全て完動させないと到達出来ない領域があるのは確か レイヤーが下がるとそう言うのも珍しくない 897 名前：デフォルトの名無しさん mailto:sage [2022/10/04(火) 15:37:58.58 ID:attOzucb.net] >>885 それは一気に全てを理解しないといけないと思い込んでるアホ人間だから 初心者のうちはfor文なんてざっくりした理解で十分に学習をどんどん進められる 後にIntoIteratorを理解する段階になってようやくfor文を完全に正解に理解すればよい 898 名前：デフォルトの名無しさん mailto:sage [2022/10/04(火) 15:56:25.04 ID:NBwKbSDK.net] 初心者がなんか言ってるwww 899 名前：デフォルトの名無しさん mailto:sage [2022/10/04(火) 16:01:39.35 ID:zVqHX6VA.net] >>887 いやそれは無理があるだろ 所有権と借用の理解は型変換の時にも必須 collectとか使うときにも必須 競プロみたいな数値だけ扱うようなプログラムならかけるけど 900 名前：デフォルトの名無しさん mailto:sage [2022/10/04(火) 16:03:22.02 ID:LLFCSjL7.net] >>886 それは言語の学習と関係ないよね Rust固有の話でもないね つまり今回の話と全く関係ないでしょう ちなみにそういう時はサンプルコードなどをまずは魔法の呪文とブラックボックスとして受け入れましょう そして一つずつ把握する範囲を広げていけばよいのです 失敗する人は最初から全てを把握しようとする人だけです 901 名前：はちみつ餃子 mailto:sage [2022/10/04(火) 16:06:42.76 ID:P4nmisNi.net] >>885 問題点が分かってきた。 「部分的な学習」というのは項目をひとつきちんと理解してから次の項目の学習に移るみたいなスタイルを前提としているんじゃないか？ 俺が思ってた学習スタイルは「概念が存在していることは知っている」という程度の全体像から解像度を上げていくような方向性だった。 機能は互いに連携するので「この部分は完璧にわかっているけど他はまだ」なんて状況は有りえんし、そういう学習方法できちんと身につくとは思わない。 (もちろん人によってやりやすいスタイルはあるのだろうけども、個人的にはオススメ出来ない。) 流し読み程度でも入門書を一度読めば (細かい借用規則を覚えていなくても) iter を使うくらいは出来るよ。 そこから何度でも読んで細かい理解を深めていくんだよ。 902 名前：デフォルトの名無しさん mailto:sage [2022/10/04(火) 16:09:22.52 ID:Yud6QviI.net] >>889 キチガイは黙っていろ どんな世界でもそんなに一気に大きく手を広げて学習しようとして上手くいくわけがない 単純に一つずつやっていくのが正しい collectなんて後で困らん そもそもイテレータ使わなきゃcollectは出て来ない ぶっ飛んだことを書き込んでいることを自覚しろ 903 名前：デフォルトの名無しさん mailto:sage [2022/10/04(火) 16:10:09.70 ID:froE0MIe.net] これがいつもの複オジ演w 904 名前：デフォルトの名無しさん mailto:sage [2022/10/04(火) 16:15:28.56 ID:Qrm8xufh.net] >>889 collectを使わなくてもプログラムを書けるから少しずつ学習していく方法でも支障はないし collectを一旦は魔術だとみなして仕組みの詳細まで把握せずに利用して進めていく学習方法でも支障はないし FromIteratorなんてあとから学べば十分ですよ 905 名前：デフォルトの名無しさん mailto:sage [2022/10/04(火) 16:17:47.88 ID:zVqHX6VA.net] いやcollectをここまで安全かつ効率よく実装してる言語はないのにそれを使わないのは論外 906 名前：デフォルトの名無しさん mailto:sage [2022/10/04(火) 16:19:54.90 ID:zVqHX6VA.net] 戦国時代に例えるならここに名刀があります ワタクシは未熟だからこの刀は使いませんと言って 戦に出て殺されるみたいな話 その名刀を最初から使えるように訓練すべき 907 名前：デフォルトの名無しさん mailto:sage [2022/10/04(火) 16:20:34.14 ID:QGiHkjYG.net] 馬鹿じゃねぇの 908 名前：デフォルトの名無しさん mailto:sage [2022/10/04(火) 16:26:15.56 ID:Qrm8xufh.net] >>895 使いたいならば使えばよいだけですよ 初心者がFromIteratorの仕組みまで理解しないとcollectを使っちゃいけないのですか？ この場合の『部分的に学習』とはcollectの機能の一部をまずは表層的にのみ理解して使ってみることです そしてこの『部分的に学習』は可能です 909 名前：デフォルトの名無しさん mailto:sage [2022/10/04(火) 16:29:20.57 ID:BXFwwNrI.net] 隔離スレに帰れ 910 名前：デフォルトの名無しさん mailto:sage [2022/10/04(火) 16:29:25.15 ID:zVqHX6VA.net] いやだから「表層的な学習」だとコンパイルすら通せないんだって 911 名前：デフォルトの名無しさん mailto:sage [2022/10/04(火) 16:31:30.86 ID:zVqHX6VA.net] 何度も言ってるけどRustはコンパイルを通せば 意図してないエラーはまず起きないし Nullで落ちるなんてこともない 912 名前：デフォルトの名無しさん mailto:sage [2022/10/04(火) 16:35:17.34 ID:vFqvnIUB.net] 頭がいいと思い込んでる馬鹿がいきなり複雑な難しいことに挑戦して失敗して 難しい！とわめく馬鹿パターンはどんな分野でもある その馬鹿が>>896 913 名前：デフォルトの名無しさん mailto:sage [2022/10/04(火) 17:00:26.62 ID:zVqHX6VA.net] 「段階的学習」というのは数学や物理においては成立する言葉だがプログラミングにおいては成立しない なぜなら「知識の差」が普遍的に影響を受けてしまうから 例えば数学では代数学の理論を知らなくても初等整数論は学べるがプログラミングではそのようなことはないとわかる 914 名前：デフォルトの名無しさん mailto:sage [2022/10/04(火) 17:01:28.47 ID:zVqHX6VA.net] 例えばアルゴリズムの問題もそう 「知らない」ことが致命的になり得る 915 名前：デフォルトの名無しさん mailto:sage [2022/10/04(火) 17:06:11.40 ID:zVqHX6VA.net] collectを知らないものが自前でfor文で同じことを実装していたらどうなるだろうか？ レビューで指摘され赤っ恥を書かされてプライドはズタズタ それが原因で鬱になるかもしれん さらにパフォーマンス悪くなる 精神的にも肉体的にもダメージを負うことになる 916 名前：デフォルトの名無しさん mailto:sage [2022/10/04(火) 17:18:30.46 ID:vFqvnIUB.net] >>905 真逆だ 初心者の学習過程ならばcollectを使わずに実装することは適切な練習問題だ その段階を経てからcollectを学習した者こそ身に付く 917 名前：デフォルトの名無しさん mailto:sage [2022/10/04(火) 17:46:08.51 ID:5flxOiHV.net] 段階的学習って↓を読み進めればいいだけじゃないの？ https://doc.rust-jp.rs/book-ja/ 918 名前：デフォルトの名無しさん mailto:sage [2022/10/04(火) 18:05:45.53 ID:qunzxQTR.net] >>907 その通りなんだけど Rustは段階的な学習ができない！と主張している変な人がいるのよ 919 名前：デフォルトの名無しさん mailto:sage [2022/10/04(火) 18:41:19.07 ID:NDareeYW.net] この複オジ演パターンはもうみんな気づいてるよね 920 名前：デフォルトの名無しさん mailto:sage [2022/10/04(火) 18:43:17.38 ID:ye813FXw.net] 赤い人をNGしときゃいいやん 921 名前：デフォルトの名無しさん mailto:sage [2022/10/04(火) 19:01:55.07 ID:7zYgBA5I.net] >>907 初心者・初学者に「the bookを読め」はさすがにむちゃだろ。 やっぱり「初心者はRust使わず他の言語から勉強しろ」が正解なのかね。 922 名前：デフォルトの名無しさん mailto:sage [2022/10/04(火) 19:07:38.54 ID:gMN5eNCr.net] >>891 さすが餃子さん分かってらっしゃる 最初は大まかな理解→もう少し詳細な理解→最後に完璧な理解という解像度の段階的な学習を中心に 項目や範囲を広げていく網羅度の段階的な学習を組み合わせることでRustの学習を含めて一般的な事柄にも適用できる 923 名前：はちみつ餃子 mailto:sage [2022/10/04(火) 20:17:29.13 ID:P4nmisNi.net] >>911 そこで言ってる「初心者」は「Rust の初心者」ではなく「プログラミングの初心者」の意味？ そうだとすると the book はちょっとハードルが高いということはあるかもしれんな。 でも C++ と比較すると C++ のほうがもっとハードルが高いと思う。 コンパイラが検出しないところで未定義に入り込むことがあまりに多い。 初心者が間違うのは当然のことだが、正しいのか間違っているのかわからないというのは間違っていることが明白であるよりもしんどい。 そこで間違ったまま邁進できるようなメンタルの持ち主はそれはそれで遠からず行き詰るし。 924 名前：デフォルトの名無しさん [2022/10/04(火) 20:27:55.40 ID:9Mq2x6bG.net] >>867 ですが、 >>876 さんがおっしゃることが僕の意図を言い当てています c++を使わなくなって 15年は経ちますが、その頃の c++にはテンプレートはありましたがスマートポインタやラムダ式、その他諸々のモダンな機能はまだありませんでした(と思います) クラス付きのCの部分で仕事をしていました モダンなc++へ再入門するか、rustを学ぶか迷って rustに触れて今に至りました 925 名前：デフォルトの名無しさん mailto:sage [2022/10/04(火) 20:36:11.60 ID:pQmQIrKs.net] >>914 C程度の予備知識があるならば >>907のRust Bookだけで容易に段階的に学習できるから何ら問題は起きず大丈夫 926 名前：デフォルトの名無しさん mailto:sage [2022/10/04(火) 21:10:32.92 ID:d7kGndGU.net] 所有権も借用も生存期間も理解してなければ メソッド呼び出し一つ満足にできないんだから それら無しに動くものが作れるわけない 学習自体は言語に限らずどんな学習でも部分的段階的にやるもの それ以外の方法なんてないんだから論点ずれてる 927 名前：デフォルトの名無しさん mailto:sage [[ここ壊れてます] .net] >>916 それはさすがに無知すぎやろ Rustは数値など所有権とは無縁な型で構成されているから 所有権なんて理解しなくてもプログラムを組める 段階的に後から所有権を学ぶことができる 928 名前：デフォルトの名無しさん mailto:sage [2022/10/04(火) 23:03:40.79 ID:HL14YOAo.net] >>917 所有権も知らずにイキってた人はさすがに言う事が違うねぇww 929 名前：デフォルトの名無しさん mailto:sage [2022/10/04(火) 23:58:47.13 ID:vxOZn4OH.net] 数値型って所有権がっつり関係してると思うけど 930 名前：デフォルトの名無しさん mailto:sage [2022/10/05(水) 00:06:13.80 ID:SE95U4Vu.net] >>919 数値型はCopyを実装しているので所有権は無くムーブも起きない 931 名前：デフォルトの名無しさん mailto:sage [2022/10/05(水) 02:07:12.38 ID:1K+My+/e.net] 数値型だけで>>867の言う「動くもの」を作ってみれば？ 932 名前：デフォルトの名無しさん mailto:sage [2022/10/05(水) 02:59:14.45 ID:P8+KCirf.net] 所有権は実在しない幻影 lifetimeとvarianceだけを見つめなさい 933 名前：デフォルトの名無しさん mailto:sage [2022/10/05(水) 03:09:52.75 ID:Ybu4BU3z.net] どうも段階的にやれると思ってる人はデータタイプを数値に限定してる気がする 数値はコピー可能でありRustのサンプルとしてよく使われるが コピー可能なオブジェクトというのは普通のアプリケーションでは効率が悪すぎて使わない つまり所有権の理解は必須なのだよ 934 名前：デフォルトの名無しさん mailto:sage [2022/10/05(水) 03:15:49.43 ID:UScD8/ ] [ここ壊れてます] 935 名前：dK.net mailto: 初学者にマウント取りするだけで、ステップアップの具体的なノウハウを示したり 理解しやすいドキュメントを整備提供したりできない積極的に導けない人間ばかりの コミュニティが形成されてる言語は決して流行らない 行き着く先は*BSDのような”魔法使い以外は帰れ帰れ”した結果の荒涼とした世界 [] [ここ壊れてます] 936 名前：デフォルトの名無しさん mailto:sage [2022/10/05(水) 03:19:22.28 ID:Ybu4BU3z.net] 数値といっても機械学習などで使うバカでかいTensorオブジェクトをコピーしたい人はいないだろう コピーして効率よく処理できる仕組みがないからmoveが生まれた 937 名前：デフォルトの名無しさん mailto:sage [2022/10/05(水) 03:20:04.62 ID:Ybu4BU3z.net] 段階的なんてものは存在しない 理解してるかしてないか 938 名前：デフォルトの名無しさん mailto:sage [2022/10/05(水) 05:31:48.70 ID:wne70pEz.net] >>921 Hollow world から始めなさいよw https://doc.rust-lang.org/rust-by-example/hello.html >>925 そもそも初学者って言ってるのに > 数値といっても機械学習などで使うバカでかいTensorオブジェクトをコピーしたい人はいないだろう とか頭おかしい 939 名前：デフォルトの名無しさん [2022/10/05(水) 07:53:16.44 ID:MzMPKgoE.net] 初学者にマウント取りたいやつがイキってる 940 名前：デフォルトの名無しさん mailto:sage [2022/10/05(水) 10:48:19.99 ID:gF0QOXVU.net] 初学者にしてもスタイルは人それぞれだろうし皆がどうやってrust習得したか語ってくれた方が参考になりそう 自分はlifetimeが導入される前からrust触ってたからコンパイラに追加される機能を適宜試してみながら体で覚えた 941 名前：デフォルトの名無しさん mailto:sage [2022/10/05(水) 11:23:13.56 ID:1F438Xk1.net] 初級者はHello, world!からって、かつての初級者はBASICから並みに罠じゃね ほとんどのHello, world!は現代のプログラミングで必須の要素が欠落しまくっているからな 942 名前：デフォルトの名無しさん mailto:sage [2022/10/05(水) 11:28:02.85 ID:BbaUEliB.net] 複オジも100点オジも もう少しRust勉強してからレスするか 大人しくしとくかどっちかにしてくれ 943 名前：デフォルトの名無しさん mailto:sage [2022/10/05(水) 11:28:25.81 ID:tZ9pwx2f.net] コンパイル、ビルドができるまでの説明だし 944 名前：デフォルトの名無しさん mailto:sage [2022/10/05(水) 11:34:33.18 ID:+5Cy2zf0.net] ホロウワールドは何かのネタ？ 945 名前：デフォルトの名無しさん mailto:sage [2022/10/05(水) 12:32:57.65 ID:OxlYZjk9.net] 今担当してる作業が、あるまとまった処理を上手く対応付けするとちょっと複雑な数値演算処理だけに置き換えられるので、 その数値演算ライブラリを作っているのだけど、確かに所有権は全く出て来ない。 入出力は配列(スライス)の参照渡しと可変参照渡しとなっていてライフタイム明記も無し。 所有権を学ぶ前に参照(借用)だけで十分に色んな実践ができると思う。 そして参照は他の言語でも配列などは参照渡しになるから、新たにスライスだけ覚えればRustを段階的に学ぶことができる。 946 名前：デフォルトの名無しさん mailto:sage [2022/10/05(水) 12:36:28.49 ID:+KHGV4+/.net] 俺はずっとJavaメインで、遊びでlispとかHaskellとか触る程度で低レイヤは触ってなかったんだけど、Rustでここまで現代的に書けるならアリだなって触り始めたクチだな。 947 名前：デフォルトの名無しさん mailto:sage [2022/10/05(水) 12:59:55.95 ID:EKfM3pGK.net] >>930 まずハロワやれと言われるレベルの初級者ってプログラミング自体初めてやるようなレベルの人でしょ それならあれこれ教えたところでどうせ理解不能になるだけなのでとりあえず動くものを作らせることには意味がある 948 名前：デフォルトの名無しさん [2022/10/05(水) 13:37:41.28 ID:Pj9P59N0.net] ただいまんこのあとは シコシコちんちん　シコシコ　イソチンチン 949 名前：デフォルトの名無しさん [2022/10/05(水) 13:47:37.30 ID:X575+w0V.net] かい 950 名前：デフォルトの名無しさん mailto:sage [2022/10/05(水) 15:06:32.60 ID:wne70pEz.net] >>930 何を勘違いしてるんだよw ハロワはプログラミングの勉強じゃなくて>>932も書いてる通り環境の勉強だぞ お前の言う必須の要素が何を指してるのか知らんけど例えばif文の勉強したい時に動かせるかどうかは重要だろ 951 名前：デフォルトの名無しさん mailto:sage [2022/10/05(水) 16:08:34.41 ID:l3k0CCzl.net] >>934 （安全な）参照は所有権の上に成り立っているよ 952 名前：デフォルトの名無しさん mailto:sage [2022/10/05(水) 16:19:48.70 ID:7FrBhgJk.net] >>940 それも真 しかし>>934のような使い方だと所有権を意識する必要すらないのも真 同様に>>934のような使い方だと参照のライフタイムを意識する必要がないのも真 これは類似なものとしてC言語を使っている時に常に所有権とライフタイムを意識する必要性があるわけではないことも同様に例示される 953 名前：デフォルトの名無しさん mailto:sage [2022/10/05(水) 17:04:57.53 ID:NuKocPG+.net] 噛み合ってない理由がわかった 競プロ勢が多いんだな 数値しか扱わないなら ベターCとして書くことは容易だからね 954 名前：デフォルトの名無しさん mailto:sage [2022/10/05(水) 17:33:30.37 ID:66O9N6nP.net] 競プロじゃないけどトレイトとかよく判らないから安定しているCとしてしか使っていないわ 955 名前：デフォルトの名無しさん mailto:sage [2022/10/05(水) 17:33:54.20 ID:mBRaD/Kx.net] >>942 競プロ勢による書き込みが見当たらないこの状況で 妄想により幻覚が見えているのか？ 956 名前：デフォルトの名無しさん mailto:sage [[ここ壊れてます] .net] 競プロ勢の炙り出しには成功したみたいだな 957 名前：デフォルトの名無しさん mailto:sage [2022/10/05(水) 23:31:57.40 ID:lcOrUuZN.net] 色々書いたうちCLI程度の規模のプログラムだと大半は所有権の移動がなくて所有権の意識が薄いな オブジェクトをnewするところは厳密には移動と言えるかも知れないが単なる値返しと捉えるだろう あとはオブジェクトの参照を渡していくだけたから単なる参照渡し 958 名前：デフォルトの名無しさん mailto:sage [2022/10/05(水) 23:44:31.07 ID:V7HNybPt.net] 毎日毎日息を吐くように嘘を吐く複オジ 控え目に言っても頭おかしい 959 名前：デフォルトの名無しさん mailto:sage [2022/10/05(水) 23:56:41.83 ID:nYqhDlIA.net] 数値型だけでは動くものが作れないことに気がついたみたいだな Rustで所有権を理解せずに動くものを作るなんて柱を使わずに家を建てるようなもの 960 名前：デフォルトの名無しさん mailto:sage [2022/10/06(木) 00:08:02.42 ID:aXzDwmUt.net] >>946 関数が値返しと引数可変参照渡しへの書き込みだけならプログラムの規模や種類に関係なくそんなもんだろ 所有権が出てくる幕はない もちろんライフタイムも出てこない 961 名前：デフォルトの名無しさん mailto:sage [2022/10/06(木) 00:34:26.13 ID:XbdFr8Zd.net] そういう点では所有権が出てこなくてもかなりの範囲のプログラムを書けるよ 962 名前：はちみつ餃子 mailto:sage [2022/10/06(木) 00:34:32.05 ID:rLXZsLBm.net] >>949 いくつかの自明な場合にはライフタイムを省略しても暗黙のルールが適用されるから書かなくてもよいだけで、ライフタイムが存在しないわけではないよ。 その暗黙のルールが比較的自然に定義されてるってことなんだろうね。 963 名前：デフォルトの名無しさん mailto:sage [2022/10/06(木) 00:37:42.29 ID:4kCBwc0q.net] >>951 それは違うな >>949のケースは参照返しをしていないのだからライフタイムは出て来ない ライフタイムの存在を意識する必要もない 964 名前：デフォルトの名無しさん mailto:sage [2022/10/06(木) 01:26:52.37 ID:v2j3J5Hy.net] 動くものってなんだよ 965 名前：デフォルトの名無しさん mailto:sage [2022/10/06(木) 01:33:20.48 ID:QZHh62Nh.net] Rustを使ってると、参照を返すようなコードはだんだん避けるようになるかもしれないな 966 名前：デフォルトの名無しさん mailto:sage [2022/10/06(木) 01:59:47.45 ID:iRnDWdOb.net] 競プロみたいにmain関数のみ データ型は数値のみ データ構造は固定配列のみ サイズも高々数百から数千程度なのでスタック確保でオッケー 配列への参照のみ必要 結果は固定配列を新しく作ってそこに詰めていく これなら所有権など一切いらない 967 名前：デフォルトの名無しさん [2022/10/06(木) 02:04:59.09 ID:MtARpYSM.net] この件は数値型や競プロは一切関係ない ヒープを使うVecやStringやそれらを含む構造体を返しても『値返し』となる点がポイント 『参照返し』とならないため『ライフタイム』は登場せず『所有権』を意識する必要もない そして『値返し』だけでも様々な実用的なプログラムをRustで作ることができる 968 名前：デフォルトの名無しさん mailto:sage [2022/10/06(木) 02:07:29.97 ID:iRnDWdOb.net] ついにlinux kernelにRustがマージされた模様 969 名前：デフォルトの名無しさん mailto:sage [2022/10/06(木) 02:38:59.47 ID:v2j3J5Hy.net] >>95 970 名前：4 個人的にはdangling pointetとか内部オブジェクトを書き換えられる心配しなくて良くなるから 他の言語より積極的に参照返すようになってる気がする [] [ここ壊れてます] 971 名前：デフォルトの名無しさん mailto:sage [2022/10/06(木) 06:12:47.90 ID:QjC44cq3.net] 参照返しの安全性を保証できるRustいいよな 参照返しを使わず値返しだけでもかなり広い範囲のことを処理できる点も同意 972 名前：デフォルトの名無しさん mailto:sage [2022/10/06(木) 14:46:06.11 ID:wkSQkKsv.net] 値返しとか参照返しなんて言葉をRustで使うなよw 973 名前：デフォルトの名無しさん mailto:sage [[ここ壊れてます] .net] 参照を返す時のみ ライフタイムの概念が登場 だから参照返しと値返しの区別は実質的に重要 もちろんRustでは常に(広義の)値返しとなる そして参照返しとは参照を(広義の)値返しすること 参照返しの対義語として(狭義の)値返しを使ってもよい 974 名前：デフォルトの名無しさん mailto:sage [[ここ壊れてます] .net] 構造体など参照以外の値がlifetime持つ場合もある 参照だけ区別するのはなぜ 975 名前：デフォルトの名無しさん mailto:sage [[ここ壊れてます] .net] ここでいうlifetimeはlifetimeパラメーターのこと 976 名前：デフォルトの名無しさん mailto:sage [[ここ壊れてます] .net] >>962 それはそのフィールドが参照を返しているね 構造体がライフタイムを持つのはそのような時 977 名前：デフォルトの名無しさん mailto:sage [[ここ壊れてます] .net] > 値返しとか参照返し これはどこに定義された用語ですか？ それともオレオレ用語ですか？ https://en.wikipedia.org/wiki/Evaluation_strategy > 3.1 Call by value > 3.2 Call by reference 値渡し参照渡しは昔からよく聞くけど 978 名前：デフォルトの名無しさん mailto:sage [2022/10/06(木) 15:37:35.04 ID:mTG1aBjr.net] 最初に言い出したのは >>952 > >>951 > それは違うな > >>949のケースは参照返しをしていないのだからライフタイムは出て来ない これか 979 名前：デフォルトの名無しさん mailto:sage [2022/10/06(木) 15:37:37.36 ID:ry4GAtyf.net] >>965 それは関数の引数としての渡し方だから返し方とは独立ではないか 980 名前：デフォルトの名無しさん mailto:sage [2022/10/06(木) 15:38:40.62 ID:QZHh62Nh.net] Return by Referenceも知らんのか・・・ 981 名前：デフォルトの名無しさん mailto:sage [2022/10/06(木) 15:40:52.32 ID:mTG1aBjr.net] どこに定義されてる用語なのかを知りたいだけよｗ 982 名前：デフォルトの名無しさん mailto:sage [2022/10/06(木) 15:45:23.29 ID:JBcgzpIo.net] Rustでは参照返しが有る時だけライフタイムパラメータが付くんよ 例えば3つの参照返しが有る時に3つのライフタイムが異なれば3つのライフタイムパラメータが付くんよ だから参照返しが有るか無いか区別されてしまうんよ 983 名前：デフォルトの名無しさん mailto:sage [2022/10/06(木) 16:06:44.80 ID:sWKfpE/G.net] 結局Rustにおける値と参照とは何かを知るためには所有権の理解が必須なワケよ 984 名前：デフォルトの名無しさん mailto:sage [2022/10/06(木) 16:15:24.55 ID:B9K2Q0k5.net] by valueの意味が他の言語とは違うからな 985 名前：デフォルトの名無しさん mailto:sage [2022/10/06(木) 16:23:06.37 ID:bcHprxpF.net] >>971 参照を返さない限り所有権の理解は不要 Rustでは配列も構造体も更にはヒープを用いるVecやString等も値として返される つまり参照を返さなくてもある程度の広範囲のプログラムを書くことができる 986 名前：デフォルトの名無しさん mailto:sage [2022/10/06(木) 16:33:59.37 ID:mb1xnKf4.net] ムーブのことも忘れないでください 987 名前：デフォルトの名無しさん mailto:sage [2022/10/06(木) 16:37:24.79 ID:JMKkrzgh.net] >>974 ムーブする必要ないよな 参照渡しだけしていれば所有権は出て来ないな 988 名前：デフォルトの名無しさん mailto:sage [2022/10/06(木) 16:42:22.59 ID:bM/kk4ia.net] 所有権要らないならRust要らないじゃんって思いながらずっと読んでる どういう結論に持っていきたいの 989 名前：デフォルトの名無しさん mailto:sage [2022/10/06(木) 16:44:20.49 ID:QZHh62Nh.net] 釣りが目的で書き込んでるひとと、それに付き合ってレスしてるひとがいるからわけわからん 990 名前：デフォルトの名無しさん mailto:sage [2022/10/06(木) 16:49:39.04 ID:+ZB5z2+t.net] 参照渡しだけして参照返しをしなければ 所有権もライフタイムも出てこないからそれらを意識することもない 結果として所有権とライフタイムを理解していなくてもそのスタイルでプログラムを組むことが出来てしまう 991 名前：デフォルトの名無しさん mailto:sage [2022/10/06(木) 17:03:06.06 ID:HCQdlFdq.net] >>976 rust 学習の話だろ？ 未来永劫所有権の理解は不要なんて誰も言ってないと思うが 992 名前：デフォルトの名無しさん [2022/10/06(木) 18:43:34.42 ID:rjzElph2.net] 逆にrustだとどういう時に参照返しが必要になるの？ 993 名前：はちみつ餃子 mailto:sage [2022/10/06(木) 18:48:14.82 ID:rLXZsLBm.net] >>980 Rust 特有の事情なんかないよ。 C/C++ でポインタや参照で返すときと同じだよ。 994 名前：デフォルトの名無しさん mailto:sage [2022/10/06(木) 19:17:16.58 ID:mTG1aBjr.net] 「参照で返す」「参照を返す」って表現する人　←わかる 「参照返し」と言い続ける人　←？？？ 995 名前：デフォルトの名無しさん mailto:sage [[ここ壊れてます] .net] 同じだろ 参照を渡すことを参照渡し 参照を返すことを参照返し 996 名前：デフォルトの名無しさん mailto:sage [[ここ壊れてます] .net] 値渡し参照渡しで言うと依然として単なる値渡しなのに ただポインタを渡してるだけでそれを 「ポインタ渡し」とか言い出したり ひどいやつだと「参照渡し」だと言いはったり そういうのを過去にC言語界隈で見てきたから気になったんよ 独自解釈による珍妙なワードはこの世に必要ないと思うでしょ >>983 そうですかボクからはもう何も言うことはありません 997 名前：デフォルトの名無しさん mailto:sage [[ここ壊れてます] .net] >>984 それは君が区別すべきことを理解できていないから混乱している 会話や説明では何と何を区別するかが重要 もちろんRustでは常に指定した型そのものが渡され返される だから区別するとしたら実体を渡したり返したりするのかその参照を渡したり返したりするのかが焦点となる したがって参照渡しや参照返しという言葉がぴったり適して使われている 998 名前：デフォルトの名無しさん mailto:sage [[ここ壊れてます] .net] あとポインタへのポインタを「ダブルポインタ」って呼んじゃう人もいたな このスレでは「所有権の複製」ってのもあったな 999 名前：デフォルトの名無しさん mailto:sage [[ここ壊れてます] .net] >>986 英語でもダブルポインタと言うし何を問題にしているのかわからん 自分勝手な線引きやルールがあってそこから外れると融通が効かなくなるダメな人かね？ 1000 名前：デフォルトの名無しさん [[ここ壊れてます] .net] ゲームの方のRustで、ホロライブのRustのSeason3が終わるから検索汚染も減るかもな 1001 名前：デフォルトの名無しさん mailto:sage [[ここ壊れてます] .net] 参照で返すことを「参照返し」と言った途端ブチギレするのマジで意味不明なんだがその呼び方を否定するとどんなメリットがあるのだろうか 1002 名前：デフォルトの名無しさん mailto:sage [2022/10/06(木) 20:19:33.91 ID:bM/kk4ia.net] 意味不明なら言及しなくていいよ 1003 名前：デフォルトの名無しさん mailto:sage [2022/10/06(木) 20:27:57.49 ID:RK7Fg483.net] >>984を見るとCでポインタで渡すことをポインタ渡しと言われるだけで発狂するようだからその人はキチガイ 1004 名前：デフォルトの名無しさん mailto:sage [2022/10/06(木) 20:52:03.93 ID:lx27AXhR.net] 参照はピリリと辛い 1005 名前：デフォルトの名無しさん mailto:sage [2022/10/06(木) 20:52:48.54 ID:mb1xnKf4.net] 他への参照を持つ実体を返すのは値返しか参照返しかはたまた別の何かか なんて考えたくない 1006 名前：デフォルトの名無しさん mailto:sage [2022/10/06(木) 20:58:52.86 ID:EteQ2MpB.net] 「ポインタ渡し」がNGなら「ポインタを渡すこと」も日本語でそう表現していいよと言語の開発者がわざわざお墨付き与えなければNGだと思う 1007 名前：デフォルトの名無しさん mailto:sage [2022/10/06(木) 21:00:15.33 ID:99NRyDSB.net] 今回はRustの段階的学習の話だから、これだけのことではないかい。 参照返しが含まれていなければ、ライフタイムを把握する必要がなく、所有権を学習していない段階でも、そのプログラムを書くことができる。 参照返しが含まれていれば、ライフタイムを把握する必要があり、所有権を学習した以降となる。 1008 名前：デフォルトの名無しさん mailto:sage [2022/10/06(木) 21:05:33.19 ID:DNbAbwmR.net] 複オジwを相手にしちゃうからww 1009 名前：デフォルトの名無しさん mailto:sage [2022/10/06(木) 21:09:49.66 ID:Re0G7B20.net] ぼくちゃんrust入門者 ライフタイム注釈だけはどうにかならなかったのとか思った でもいろいろ満足 tauriやるぞう 1010 名前：デフォルトの名無しさん mailto:sage [2022/10/06(木) 21:23:30.56 ID:xIsaLol7.net] ホント毎日毎日アホなこと書いてるなぁ 釣られちゃうRust入門者は少し不憫 1011 名前：デフォルトの名無しさん mailto:sage [2022/10/06(木) 21:26:14.68 ID:ccGjPy8L.net] >>995 所有権を学ぶのを後ろへずらすことでRust学習の難易度を大きく下げられそうね 1012 名前：デフォルトの名無しさん mailto:sage [2022/10/06(木) 21:35:40.63 ID:jyraEk4K.net] などと言う嘘つき初心者w 1013 名前：1001 [Over 1000 Thread.net] このスレッドは１０００を超えました。 新しいスレッドを立ててください。 life time: 101日 13時間 18分 37秒 1014 名前：過去ログ ★ [[過去ログ]] ■ このスレッドは過去ログ倉庫に格納されています

---

---

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

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