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/ 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ユーザーは少ないだろうし

---

---

[ 続きを読む ] / [ 携帯版 ]

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