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/ 615 名前：デフォルトの名無しさん [2022/08/31(水) 20:22:19.87 ID:3b0JioqE.net] 学習曲線をどうにかしようという気合はめちゃめちゃあるが、バカを賢くしようというつもりはないだろう 616 名前：はちみつ餃子 mailto:sage [2022/08/31(水) 20:35:16.89 ID:nTGfEW2M.net] >>609 えっ、なじみのない所有権システムとかも含めてめっちゃわかりやすく解説した the book を 用意してくれるなんてスゲー親切だと思うが、何が不満なんだ？ (俺自身は英語あんまりわからんので日本語訳を読んだ。) 617 名前：デフォルトの名無しさん mailto:sage [2022/08/31(水) 20:38:24.92 ID:SRFkQuBk.net] >>609 the bookは初心者のためのもの Rustを全く知らなくてもちゃんと順を追って理解できるように書かれている ？は自分でエラー処理を書くようになり、 さらに自分の関数でResultなどを返すようになり、 そこでErr(e) => return Err(e)などを書くようになり、 そこでのショートカット表現として必要になるものだから the bookでも同じ順で学べる ？をいきなり調べたい時や詳細を知りたい時は the Rust referenceを開いて🔍をクリックして question markと打てば該当ページに辿り着く 618 名前：デフォルトの名無しさん [2022/08/31(水) 20:53:00.34 ID:bW00GV9W.net] >>605 >>606 同意。 619 名前：デフォルトの名無しさん mailto:sage [2022/08/31(水) 21:03:24.41 ID:p14sgl1j.net] すべてがunsafeな世界になる 620 名前：デフォルトの名無しさん mailto:sage [2022/08/31(水) 21:22:41.70 ID:rT6IO02J.net] 生きている限り安全なんてない 621 名前：デフォルトの名無しさん mailto:sage [2022/08/31(水) 23:52:36.28 ID:X48LRlQ+.net] ポエムはいいです 622 名前：デフォルトの名無しさん mailto:sage [2022/09/01(木) 00:17:11.56 ID:gQhEx8vQ.net] そうそうポエムいいよなぁ みつヲ 623 名前：デフォルトの名無しさん mailto:sage [2022/09/01(木) 01:28:45.35 ID:v92yFclD.net] 今時、ネイティブ吐く必要なんて全くない tsでもvscのようなソフトが作れるんだし。 624 名前： ユーザーランドではネイティブはもはや不要だろ [] [ここ壊れてます] 625 名前：デフォルトの名無しさん mailto:sage [2022/09/01(木) 02:19:44.48 ID:UU16wx/t.net] もしかしてelectron知らないのかしら 626 名前：デフォルトの名無しさん mailto:sage [2022/09/01(木) 08:30:45.73 ID:+imQtRK+.net] スクリプトって知らないのかしらん？ 627 名前：デフォルトの名無しさん mailto:sage [2022/09/01(木) 09:29:49.86 ID:WQm7Gv/J.net] vscはコア部は全部C++だけど。 そのうえに薄くjs乗ってるだけやがな。 628 名前：デフォルトの名無しさん mailto:sage [2022/09/01(木) 09:46:54.90 ID:NH2cx+n6.net] Tauri (Rust) vs. Electron (C++)の戦いの結果… ＞ Electronの代替を目指す軽量なRust製フレームワーク「Tauri」 ＞ https://www.publickey1.jp/blog/22/electronrusttauri.html ＞ ＞ Electronはフロントエンドの基盤としてChromiumを組み込んでいますが、 ＞ Tauriでは代わりに各OSが備えているWebViewの機能を、抽象化レイヤのwry経由で呼び出すことで、 ＞ クロスプラットフォームを実現しつつChromiumを不要にしています。 ＞ フレームワーク内にChromiumを組み込まないことでセキュリティも向上すると、Tauri開発チームは説明しています。 　↓　「マジ？！」と思っていたらマジだった！！ ＞開発フレームワーク「Electron」に複数の脆弱性 ＞https://news.mynavi.jp/techplus/article/20220818-2426640/ ＞ ＞Electronは、HTML5やCSS、JavaScriptといったWeb技術を用いてデスクトップアプリケーションを開発することができるフレームワークで、 ＞Microsoft TeamsやVisual Studio Code（VSCode）、Discordなどの人気アプリケーションでも利用されている。 ＞今回のElectronの脆弱性に関する発表は、米国で開催されたサイバーセキュリティカンファレンス「Black Hat USA 2022」の次のセッションで行われたもの。 ＞研究チームがElectronを使用して開発された20のアプリケーションを調査し、そこで発見された複数の脆弱性について報告した。 ＞発見された脆弱性の一例としては、以下が挙げられている。 ＞・VS Codeにおけるリモートコード実行の脆弱性 ＞・Discordにおけるリモートコード実行の脆弱性 ＞・Microsoft Teamsにおけるクロスサイトスクリプティング脆弱性 ＞・ChromeのCSP（Content Security Policy）バイパスの脆弱性 ＞・V8のリモートコード実行の脆弱性 629 名前：デフォルトの名無しさん mailto:sage [2022/09/01(木) 12:18:02.95 ID:Wlby5VAy.net] >>621 そうなん？わりとネイティブが薄くてTSが主体だと思ってた。 630 名前：デフォルトの名無しさん mailto:sage [2022/09/02(金) 12:29:12.76 ID:EMfEx7SW.net] GUIがtsの時点でお察し やたらとモッサリしてんじゃん 631 名前：デフォルトの名無しさん mailto:sage [2022/09/02(金) 22:13:08.24 ID:06QeBluE.net] --emit asmで吐かれるアセンブラリストのフォーマットの資料ってどっかにある？ gas系っぽく見えるけどちょいちょい判らないのが・・・ 632 名前：デフォルトの名無しさん mailto:sage [2022/09/02(金) 22:55:35.95 ID:TRifMPKk.net] --emit=asm -C "llvm-args=-x86-asm-syntax=intel”とかで指定できるみたいよ 633 名前：デフォルトの名無しさん mailto:sage [2022/09/04(日) 14:45:48.94 ID:c9grlmUi.net] VScodeがもっさりは感じたことないな ネイティブのVSのほうが重すぎ 634 名前：デフォルトの名無しさん mailto:sage [[ここ壊れてます] .net] 関数の入出力はu8だけど関数内の計算はi32で行いたい場合って普通どんな感じで書くの？ 635 名前：デフォルトの名無しさん mailto:sage [2022/09/05(月) 15:19:35.29 ID:TAlRHagA.net] そんなユースケースあるの？ 636 名前：デフォルトの名無しさん mailto:sage [2022/09/05(月) 15:31:51.51 ID:TaR2CBOa.net] >>629 隔離スレでドヤりたいというユースケース 637 名前：デフォルトの名無しさん mailto:sage [2022/09/05(月) 15:54:23.38 ID:vyOP5LW0.net] いつも隔離スレのここが機能してくれて助かってます 638 名前：はちみつ餃子 mailto:sage [2022/09/05(月) 16:16:12.15 ID:QNR7HRCU.net] >>628 一旦変換すりゃいいだけなんじゃないの。 知らんけど。 639 名前：628 mailto:sage [2022/09/05(月) 17:50:42.31 ID:Y4+oTyIj.net] 例えばこんなの fn func(x: u8, y: u8) -> u8 { 　let x32 = x as i32; 　let y32 = y as i32; 　let z32 = (((x32 - y32) * 170) >> 16) + y32; 　return z32 as u8; } 4行使うのは冗長かなーと思わなくもなく・・・ テンポラリ変数の名前を考えるのもちょっと面倒だし 640 名前：デフォルトの名無しさん mailto:sage [2022/09/05(月) 17:54:10.85 ID:vXwuqGKm.net] >>633 シャドーイングできるからテンポラリの変数名は不要だよ let x = x as u32; でいい 641 名前：デフォルトの名無しさん mailto:sage [2022/09/05(月) 19:20:47.36 ID:g3RfqaIY.net] >>633 行数短くしたいだけなら fn func(x: u8, y: u8) -> u8 { 　let (x, y) = (x as u8, y as u8); 　(((x - y) * 170) >> 16) + y) as u8 } とは書けるけどやってることは全く同じだしこれで期待に応えられてるかは分からん 642 名前：デフォルトの名無しさん mailto:sage [2022/09/05(月) 19:21:35.07 ID:g3RfqaIY.net] >>635 2行目間違えた as i32 に読み替えて 643 名前：デフォルトの名無しさん mailto:sage [[ここ壊れてます] .net] >>633 その例は手動で最適化すると fn func(_x: u8, y: u8) -> u8 { 　y } それはともかく 行数を節約したいという間違った価値観を捨てることをおすすめ 644 名前：デフォルトの名無しさん mailto:sage [[ここ壊れてます] .net] x < y の場合考慮してなさそう 645 名前：デフォルトの名無しさん mailto:sage [2022/09/05(月) 21:53:26.61 ID:wI2HBmBd.net] ホントだごめん訂正 fn func(x: u8, y: u8) -> u8 { 　y - (x < y) as u8 } 646 名前：デフォルトの名無しさん mailto:sage [2022/09/06(火) 00:31:42.49 ID:EiVnVIDc.net] 結局u8で返すなら 途中でi32使わずとも 工夫するとu8のままだけで算出できちゃったりするわけか 647 名前：デフォルトの名無しさん mailto:sage [2022/09/06(火) 00:52:56.28 ID:uJFa29+7.net] 逆方向にシフトした場合は？ そんな用途があるのか知らんけど 648 名前：デフォルトの名無しさん mailto:sage [2022/09/06(火) 01:12:27.41 ID:EiVnVIDc.net] >>641 それはu8部分の下位8bitが常にゼロとなって 足しても引いても影響ないかな 649 名前：628 mailto:sage [2022/09/06(火) 11:02:40.94 ID:xGSGq1SQ.net] スタンダードな書き方みたいなのはないのかな なら>>634で行こうと思います あと>>633は右シフトを間違えていました 16ではなく8です 650 名前：デフォルトの名無しさん mailto:sage [2022/09/07(水) 08:11:56.26 ID:8saglJYc.net] Rustのバイトオーダーってそのターゲットのネイティブ(x64ならリトルエンディアン)で良いの？ 651 名前：デフォルトの名無しさん mailto:sage [2022/09/07(水) 08:24:04.31 ID:41cUJGIp.net] もちろん そして依存しないよう3種類用意されてる assert_eq!(0x01020304, u32::from_be_bytes([1, 2, 3, 4])); // big endian assert_eq!(0x04030201, u32::from_le_bytes([1, 2, 3, 4])); // little endian assert_eq!(XXX, u32::from_ne_bytes([1, 2, 3, 4])); // native endian 652 名前：デフォルトの名無しさん [2022/09/07(水) 23:31:51.68 ID:qqHULq33.net] native endianというのは初めて聞いたのですが、これはどういうものなのですか？ 653 名前：デフォルトの名無しさん [2022/09/07(水) 23:54:21.35 ID:En8I5Kb5.net] この場合 >>644も書いているようにコンパイルターゲット環境のエンディアンのこと 特にターゲット指定がなければ自分の使っているPC環境で通常はx64などlittle endianになりますが そこでleと指定してはダメで環境に応じて適切に対応させるためにneを使います 一方でAPIなどでエンディアンが指定されてる時は指定通りbeかleを使います 654 名前：デフォルトの名無しさん mailto:sage [2022/09/08(木) 00:04:41.95 ID:nmwPOGZ0.net] >>645 サンクス。u32とかにはfrom_leとかあるみたいですね。こっちの方が使う機会は多そう デフォルトのバイトオーダーを変更したり、変数やフィールド単位でバイトオーダーを設定する みたいな芸当は流石に無理なのかな・・・ググったけどそれっぽい情報は見つけられなかった 655 名前：デフォルトの名無しさん mailto:sage [2022/09/08(木) 00:19:17.65 ID:8UoQH6yi.net] >>648 操作に最適なバイトオーダーは使用CPUで決まるネイティブエンディアン だから原則としてネイティブエンディアンのみでプログラミングする 例外として外部とのやりとりなどエンディアン指定がある時はその境界で変換 656 名前：はちみつ餃子 mailto:sage [2022/09/08(木) 00:23:28.76 ID:MG9wnc1h.net] >>648 内部的に色々な表現を有りということにするならやりたい操作を個別に定義するしかないよ。 でも普通はそんな煩雑なことをしたくないから 内部的には一環した表現を使って必要な変換は入出力のみというのが一般的な構成だし、 言語やライブラリも基本的には一般的な構成に倣っている。 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 がそうなるみたい

---

---

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

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