Rust part16

**デフォルトの名無しさん** · 2022/06/27(月) 08:17:03.45

公式
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/

**デフォルトの名無しさん** · 2022/08/31(水) 12:30:09.46

question markとかsemicolonで調べればいいんだよ

**デフォルトの名無しさん** · 2022/08/31(水) 12:34:08.26

例えば
question mark site:doc.rust-lang.org
で検索すれば必要な解説がすぐ見つかる

**デフォルトの名無しさん** · 2022/08/31(水) 12:53:27.03

>>593
公式に「チュートリアル」てあったっけ？
THE Book読めということかしらん？

>>594
Error propagationとかStatement and item terminatorぐらいしか記載無いんだけど……

>>595
公式の解説出てこないんだけど、公式には説明無いんかね？

**デフォルトの名無しさん** · 2022/08/31(水) 13:07:27.93

>>596
おお、ここまで指定すれば見つかりますな。公式トップに検索窓ぐらい欲しいところだけど。

**デフォルトの名無しさん** · 2022/08/31(水) 13:18:26.51

>>597
エラーとか文に関わるものということが分かれば、関連するリファレンス探すとっかかりにはなるんじゃないかと
少なくとも記号よりは検索しやすい

**デフォルトの名無しさん** · 2022/08/31(水) 13:39:17.87

所有権チェックはありがたいけど、lintみたいにビルドと分けた方が使い勝手よかったと思うがな。

**はちみつ餃子** ◆8X2XSCHEME · 2022/08/31(水) 13:42:22.79

>>597
> THE Book読めということかしら

せやで。
まあそれに限らなくてもいいけどどんな入門書でも ? の説明がないなんてことはないでしょ。
常識的な手順通りに学習してれば ? が大まかに何をする演算子なのかくらいは知っているはずだし、
エラー処理にかかわるものだと知ってればもっと細かいドキュメントを探すのにも苦労するってことはない。

なるべく一発で検索できたほうが便利というのはわからんでもないが、
演算子であると同時に制御構文の類でもあり、周辺の機能と連携するのできちんとした理解をしようとすれば
どうせ色々と見るはめになる。

**デフォルトの名無しさん** · 2022/08/31(水) 15:08:14.60

>>600
所有権チェックをなくすってどういうこと？
referenceが有効な間に元データをmoveした場合に警告だけ出してコード自体はコンパイルできるようにするとかそういうこと？

**デフォルトの名無しさん** · 2022/08/31(水) 16:15:20.37

コンパイル(ビルド)時に所有権チェックの結果を使ってメモリの解放処理を挿入してるんだから分けるのは無理

**デフォルトの名無しさん** · 2022/08/31(水) 16:22:04.68

ビルドしなくてももっと気軽にわかるようにしろってことか？
linterの領域外れてる気もするが

**はちみつ餃子** ◆8X2XSCHEME · 2022/08/31(水) 16:50:31.19

細かな所有権の整合性を後回しにしてとりあえず動く (ように見える) ところまでもっていきたいという気持ちはわからんもでない。
でもなー、そういうことすると整合性がとれてないままの未定義コードが世に溢れてしまうのは確実だろう。

**デフォルトの名無しさん** · 2022/08/31(水) 16:56:11.73

所有権周りのエラーって基本的なデータ構造に起因することが多いからなぁ
後から直そうとか思うと結局全部作り直すはめになるから
一度チェックなしモードとかで作っちゃうと永遠にそのままだろうね

**デフォルトの名無しさん** · 2022/08/31(水) 17:04:46.18

マンホールって卑猥な単語じゃね？

**デフォルトの名無しさん** · 2022/08/31(水) 19:07:16.13

>>592
そのうち、他の分野のライフサイクルみたいに、製造時、利用時といった感じで電力効率が語られるようになるんかね。

**デフォルトの名無しさん** · 2022/08/31(水) 20:09:18.42

>>601
the book読めというのはさすがに初心者殺しだと思うけどなぁ。

公式に絶壁の学習曲線をどうにかしようという意識はあるのかしらん？

**デフォルトの名無しさん** · 2022/08/31(水) 20:22:19.87

学習曲線をどうにかしようという気合はめちゃめちゃあるが、バカを賢くしようというつもりはないだろう

**はちみつ餃子** ◆8X2XSCHEME · 2022/08/31(水) 20:35:16.89

>>609
えっ、なじみのない所有権システムとかも含めてめっちゃわかりやすく解説した the book を
用意してくれるなんてスゲー親切だと思うが、何が不満なんだ？
(俺自身は英語あんまりわからんので日本語訳を読んだ。)

**デフォルトの名無しさん** · 2022/08/31(水) 20:38:24.92

>>609
the bookは初心者のためのもの
Rustを全く知らなくてもちゃんと順を追って理解できるように書かれている

？は自分でエラー処理を書くようになり、
さらに自分の関数でResultなどを返すようになり、
そこでErr(e) => return Err(e)などを書くようになり、
そこでのショートカット表現として必要になるものだから
the bookでも同じ順で学べる

？をいきなり調べたい時や詳細を知りたい時は
the Rust referenceを開いて🔍をクリックして
question markと打てば該当ページに辿り着く

**デフォルトの名無しさん** · 2022/08/31(水) 20:53:00.34

>>605
>>606
同意。

**デフォルトの名無しさん** · 2022/08/31(水) 21:03:24.41

すべてがunsafeな世界になる

**デフォルトの名無しさん** · 2022/08/31(水) 21:22:41.70

生きている限り安全なんてない

**デフォルトの名無しさん** · 2022/08/31(水) 23:52:36.28

ポエムはいいです

**デフォルトの名無しさん** · 2022/09/01(木) 00:17:11.56

そうそうポエムいいよなぁ

みつヲ

**デフォルトの名無しさん** · 2022/09/01(木) 01:28:45.35

今時、ネイティブ吐く必要なんて全くない
tsでもvscのようなソフトが作れるんだし。
ユーザーランドではネイティブはもはや不要だろ

**デフォルトの名無しさん** · 2022/09/01(木) 02:19:44.48

もしかしてelectron知らないのかしら

**デフォルトの名無しさん** · 2022/09/01(木) 08:30:45.73

スクリプトって知らないのかしらん？

**デフォルトの名無しさん** · 2022/09/01(木) 09:29:49.86

vscはコア部は全部C++だけど。
そのうえに薄くjs乗ってるだけやがな。

**デフォルトの名無しさん** · 2022/09/01(木) 09:46:54.90

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のリモートコード実行の脆弱性

**デフォルトの名無しさん** · 2022/09/01(木) 12:18:02.95

>>621
そうなん？わりとネイティブが薄くてTSが主体だと思ってた。

**デフォルトの名無しさん** · 2022/09/02(金) 12:29:12.76

GUIがtsの時点でお察し
やたらとモッサリしてんじゃん

**デフォルトの名無しさん** · 2022/09/02(金) 22:13:08.24

--emit asmで吐かれるアセンブラリストのフォーマットの資料ってどっかにある？
gas系っぽく見えるけどちょいちょい判らないのが・・・

**デフォルトの名無しさん** · 2022/09/02(金) 22:55:35.95

--emit=asm -C "llvm-args=-x86-asm-syntax=intel”とかで指定できるみたいよ

**デフォルトの名無しさん** · 2022/09/04(日) 14:45:48.94

VScodeがもっさりは感じたことないな
ネイティブのVSのほうが重すぎ

**デフォルトの名無しさん** · 2022/09/05(月) 15:09:06.52

関数の入出力はu8だけど関数内の計算はi32で行いたい場合って普通どんな感じで書くの？

**デフォルトの名無しさん** · 2022/09/05(月) 15:19:35.29

そんなユースケースあるの？

**デフォルトの名無しさん** · 2022/09/05(月) 15:31:51.51

>>629
隔離スレでドヤりたいというユースケース

**デフォルトの名無しさん** · 2022/09/05(月) 15:54:23.38

いつも隔離スレのここが機能してくれて助かってます

**はちみつ餃子** ◆8X2XSCHEME · 2022/09/05(月) 16:16:12.15

>>628
一旦変換すりゃいいだけなんじゃないの。知らんけど。

**628** · 2022/09/05(月) 17:50:42.31

例えばこんなの
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行使うのは冗長かなーと思わなくもなく・・・
テンポラリ変数の名前を考えるのもちょっと面倒だし

**デフォルトの名無しさん** · 2022/09/05(月) 17:54:10.85

>>633
シャドーイングできるからテンポラリの変数名は不要だよ
let x = x as u32;
でいい

**デフォルトの名無しさん** · 2022/09/05(月) 19:20:47.36

>>633
行数短くしたいだけなら

fn func(x: u8, y: u8) -> u8 {
　let (x, y) = (x as u8, y as u8);
　(((x - y) * 170) >> 16) + y) as u8
}

とは書けるけどやってることは全く同じだしこれで期待に応えられてるかは分からん

**デフォルトの名無しさん** · 2022/09/05(月) 19:21:35.07

>>635
2行目間違えた
as i32 に読み替えて

**デフォルトの名無しさん** · 2022/09/05(月) 21:29:56.32

>>633
その例は手動で最適化すると
fn func(_x: u8, y: u8) -> u8 {
　y
}

それはともかく
行数を節約したいという間違った価値観を捨てることをおすすめ

**デフォルトの名無しさん** · 2022/09/05(月) 21:38:39.53

x < y の場合考慮してなさそう

**デフォルトの名無しさん** · 2022/09/05(月) 21:53:26.61

ホントだごめん訂正
fn func(x: u8, y: u8) -> u8 {
　y - (x < y) as u8
}

**デフォルトの名無しさん** · 2022/09/06(火) 00:31:42.49

結局u8で返すなら
途中でi32使わずとも
工夫するとu8のままだけで算出できちゃったりするわけか

**デフォルトの名無しさん** · 2022/09/06(火) 00:52:56.28

逆方向にシフトした場合は？
そんな用途があるのか知らんけど

**デフォルトの名無しさん** · 2022/09/06(火) 01:12:27.41

>>641
それはu8部分の下位8bitが常にゼロとなって
足しても引いても影響ないかな

**628** · 2022/09/06(火) 11:02:40.94

スタンダードな書き方みたいなのはないのかな
なら>>634で行こうと思います

あと>>633は右シフトを間違えていました
16ではなく8です

**デフォルトの名無しさん** · 2022/09/07(水) 08:11:56.26

Rustのバイトオーダーってそのターゲットのネイティブ(x64ならリトルエンディアン)で良いの？

**デフォルトの名無しさん** · 2022/09/07(水) 08:24:04.31

もちろん
そして依存しないよう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

**デフォルトの名無しさん** · 2022/09/07(水) 23:31:51.68

native endianというのは初めて聞いたのですが、これはどういうものなのですか？

**デフォルトの名無しさん** · 2022/09/07(水) 23:54:21.35

この場合 >>644も書いているようにコンパイルターゲット環境のエンディアンのこと
特にターゲット指定がなければ自分の使っているPC環境で通常はx64などlittle endianになりますが
そこでleと指定してはダメで環境に応じて適切に対応させるためにneを使います
一方でAPIなどでエンディアンが指定されてる時は指定通りbeかleを使います

**デフォルトの名無しさん** · 2022/09/08(木) 00:04:41.95

>>645
サンクス。u32とかにはfrom_leとかあるみたいですね。こっちの方が使う機会は多そう
デフォルトのバイトオーダーを変更したり、変数やフィールド単位でバイトオーダーを設定する
みたいな芸当は流石に無理なのかな・・・ググったけどそれっぽい情報は見つけられなかった

**デフォルトの名無しさん** · 2022/09/08(木) 00:19:17.65

>>648
操作に最適なバイトオーダーは使用CPUで決まるネイティブエンディアン
だから原則としてネイティブエンディアンのみでプログラミングする
例外として外部とのやりとりなどエンディアン指定がある時はその境界で変換

**はちみつ餃子** ◆8X2XSCHEME · 2022/09/08(木) 00:23:28.76

>>648
内部的に色々な表現を有りということにするならやりたい操作を個別に定義するしかないよ。
でも普通はそんな煩雑なことをしたくないから
内部的には一環した表現を使って必要な変換は入出力のみというのが一般的な構成だし、
言語やライブラリも基本的には一般的な構成に倣っている。

**デフォルトの名無しさん** · 2022/09/08(木) 01:11:28.44

>>648
変数やフィールドのメモリ上の表現が特定のエンディアンにしたいのであれば、
#[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(); }
}
こういうアクセサを実装すれば良いかと

何の役に立つのかはよくわからないけど、特定のエンディアンでシリアライズされたデータにそのままアクセスしたい場合とかに便利なのかな

**デフォルトの名無しさん** · 2022/09/08(木) 01:21:33.97

mansplainers

**デフォルトの名無しさん** · 2022/09/08(木) 15:55:57.30

RustをOpenMPIに対応させるようなプロジェクトってありますか？

**デフォルトの名無しさん** · 2022/09/08(木) 16:49:24.48

「Rust OpenMPI」でGoogle検索

**デフォルトの名無しさん** · 2022/09/08(木) 18:02:42.70

OpenMP なのか Open MPI なのかどっち

**デフォルトの名無しさん** · 2022/09/08(木) 20:45:38.87

知りたいのはOpenMPIの方です
ググるとOpenMPIとOpenMPを勘違いしたと思われるRayonを紹介する記事が出てきたり、OpenMPがらみのサイトが出てきたり、なかなか状況が分かりません・・・・

**デフォルトの名無しさん** · 2022/09/08(木) 20:53:50.25

一番上のrsmpiは違うの

**デフォルトの名無しさん** · 2022/09/08(木) 21:56:17.41

MPIはHPC以外では使う必要ないです
機械学習でも有用だとは思いますが
そもそもフレームワークが対応していないから
全部自前で作ってるような人以外は必要ないです

**デフォルトの名無しさん** · 2022/09/09(金) 01:14:31.51

Open MPIに限らずMPIはアプリから見たらただのライブラリだからRust側で特別な対応は不要で単にCの関数を呼び出せばよいだけでは

**デフォルトの名無しさん** · 2022/09/09(金) 08:12:49.36

良くありがちな奴だと思うけど
struct ARGB32 {A: u8, R: u8, G: u8, B: u8,}
みたいに書くとスネークケースじゃないと警告が出るけどどう書くのがRust流なの？
これ小文字にしちゃったら少なからず可読性が落ちるよね

**デフォルトの名無しさん** · 2022/09/09(金) 08:31:41.27

#[allow(non_snake_case)]
しかしフィールド名だけ小文字にすれば不要
struct ARGB32 {a: u8, r: u8, g: u8, b: u8,}
そして可読性が落ちると思わない

**デフォルトの名無しさん** · 2022/09/09(金) 09:24:21.25

構造体名もCamelCaseでArgb32とすべきかな

**デフォルトの名無しさん** · 2022/09/09(金) 12:29:38.55

識別子を極端に省略するのは良くないという現代のプログラミングの流儀と業界の略語でコンフリクトしてるよね。
略語を使わずに書くとこうかね？

Color<T>{alpha: T, red: T, green: T, blue: T}

CMYはどうなるとか言い出すやつがいると面倒そうだけど。

**デフォルトの名無しさん** · 2022/09/09(金) 12:42:45.67

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),
}

**デフォルトの名無しさん** · 2022/09/09(金) 13:41:22.02

最低限ガイドには従った方が良いと思う
https://rust-lang.github.io/api-guidelines/naming.html
acronymはひとつ単語として扱うとあるから Rgb とか Argb とすべき

あとは適当なグラフィック系ライブラリの実装を見て真似してみたら良いのでは
規約に従ってないライブラリも多いけど

そもそも既存crate使えば独自にArgb型定義する必要もなくなるかもしれない

**はちみつ餃子** ◆8X2XSCHEME · 2022/09/09(金) 14:02:11.22

API ガイドラインってことは、 API として公開しない (内部的な) 名前は雑でいいってことだよね。

**デフォルトの名無しさん** · 2022/09/09(金) 14:15:33.61

>>661
個人的にはこっちの方が好きだけど
規約的にダメなら仕方ない

**デフォルトの名無しさん** · 2022/09/09(金) 14:42:45.26

>>666
非公開部分を将来公開APIにする可能性や、自分以外の誰かがソース読んでパッチ作ってくれる可能性考えると、
最初から内部も規約に従ったものにしておいた方が良いと思う
そもそもひとつのプロジェクトの中で公開部分と非公開部分で異なる規約混在するのも嫌では

**デフォルトの名無しさん** · 2022/09/09(金) 15:18:27.40

mozillaは公開できない関数名を使ってオープンソース化が数年遅れた過去があったなぁ。

**デフォルトの名無しさん** · 2022/09/09(金) 15:35:09.62

gameraとか？

**デフォルトの名無しさん** · 2022/09/09(金) 16:00:26.66

>>669
94年初リリースで98年ソース公開で
数年遅れるとは？

**デフォルトの名無しさん** · 2022/09/09(金) 17:53:00.11

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)との差異が
拡大するだけでメリットはほとんど無いような

**デフォルトの名無しさん** · 2022/09/09(金) 21:16:36.10

JPEG、MPEG、PNG、HEVC・・・すでに略されている物をありがちな命名規則で書くと判りにくくなる

**デフォルトの名無しさん** · 2022/09/09(金) 22:46:34.35

>>673
同意

**デフォルトの名無しさん** · 2022/09/10(土) 00:32:32.71

>>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;
アセンブラリストを見る限りは問題なさそう

**デフォルトの名無しさん** · 2022/09/10(土) 01:19:16.36

acronymを全部大文字にするか先頭だけ大文字にするかってそんなに大きな問題かな
一貫性のあるルールに従っていれば書き手や読み手として混乱することもないと思うんだが

**デフォルトの名無しさん** · 2022/09/10(土) 03:00:06.93

Ipv4なんて一瞬なんのことか分からんかったな
結局慣れで、一貫性以上に価値のある好みなんてのはない

**デフォルトの名無しさん** · 2022/09/10(土) 07:09:44.43

>>676
その一貫性が崩れるのがいやなんだろ。
ドキュメント・コメントでは全部大文字なのにコードでは先頭だけ大文字とか。
慣れの問題だが、今まで/一般的に全部大文字で慣れてるものをこの時だけ先頭大文字に慣らせというのは抵抗感あって当たり前。

**デフォルトの名無しさん** · 2022/09/10(土) 07:12:21.94

>>676
問題の大小なんて誰も言ってない。
今までの慣れ/一般的な表記を置き換えるのは抵抗感あるって話。

**デフォルトの名無しさん** · 2022/09/10(土) 12:37:11.73

命名規則を利用する目的は可読性や開発効率の向上などのはず
一般的な表記から外れるのであればそれなりの理由が必要であろう
「命名規則に従ったから」では「目的より手段を優先している、合理性がない」などと
突っ込まれてもしょうがない

**デフォルトの名無しさん** · 2022/09/10(土) 13:03:13.98

JavaScriptのアイツは
XmlHttpRequestと命名されるべきだったのか？
XMLHTTPRequestと命名されるべきだったのか？

**デフォルトの名無しさん** · 2022/09/10(土) 13:20:38.77

eXtend Markup Language Hyper Text Transfer Protocol Request

**デフォルトの名無しさん** · 2022/09/10(土) 13:38:53.61

完全に好みの問題と思うから何らかのルールで統一されてればどっちでも良いと思うけど、
LCD TV、nVidia、iOS IoT Hubなんかをどう表記するかとか変数名ならどうしようとか考えるのめんどいから
表記の慣例とか無視して全部キャメルケースにしちゃうな

**デフォルトの名無しさん** · 2022/09/10(土) 13:50:29.86

ルールから逸脱させるかどうか悩むならルールに合わせておくおじさんになった

**デフォルトの名無しさん** · 2022/09/10(土) 14:31:16.93

Rustすれのレベルの低さにガッカリ
Python質問すれとかみたいに和気あいあいとしてない殺伐にドッキリ

**デフォルトの名無しさん** · 2022/09/10(土) 14:56:40.59

>>675みたいに書いた場合
>let mut bitmap:[u32; LEN] = [0; LEN];
のmutが余計だと警告が出る。この場合実際に確保されるメモリ領域は書き込みも出来るスタックフレームだろうし
mutを取っても動作上は問題ないと思うけど、mutがない領域に書き込むことになりプログラムの意味としては誤っている
参照先を強制的に書き換えるようなコードを書くと、とコードと警告と動作のミスマッチが起きる気がするけど
なんか上手い書き方はないのだろうか

この辺の低レイヤーの用途で参照先を書き換える話ってBookのReferenceやUnsafeあたりにもそれっぽい事書いてないし
どこを見たらいいのか判らない

**デフォルトの名無しさん** · 2022/09/10(土) 15:47:06.47

>>675
ARGB32にDefault実装して
let mut bitmap : [ARGB32; LEN] = Default::default();
とするのが良いかと
repr(C)がついてない構造体のメモリ上での表現がどうなるかは保証されてないから元のコードが意図通り動作する保証はないと思う

**デフォルトの名無しさん** · 2022/09/10(土) 15:48:16.32

>>675
初期化難しいかな。こうとか

https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=49327f78412221161809733ee34bf013

**デフォルトの名無しさん** · 2022/09/10(土) 15:54:53.07

>>687
[T; N] は N <= 27 までしかDefault実装されてなかったからこのコードじゃダメだった
こっちならOK

let mut bitmap: [ARGB32; LEN] = std::array::from_fn(|_i| Default::default());

**デフォルトの名無しさん** · 2022/09/10(土) 16:11:30.59

最後の手段のtransmuteは安易に使うものじゃないと思う

**デフォルトの名無しさん** · 2022/09/10(土) 16:39:14.44

>>687
すみません。構造体にはrepr(packed)を付けています。u8がパディング無し4つ並ぶはず
repr(C)だとCと同様にパディングされる可能性が出てくると思うのですが

>>688
CloneとCopyを付ける方法に関してはどのような動作になるのか確信を持てていないです
原則コピーになるという情報は出てきますが、画像のバッファだし原則参照で必要なときだけ
コピーしたいです(すでに初期化とは別のところで問題になっています。参照とコピーの
切り替え方法が判らない)

**デフォルトの名無しさん** · 2022/09/10(土) 18:12:40.24

>>686
最初に定義した変数bitmapはmoveしてるだけだからmutは余計でいいと思うけど？

**デフォルトの名無しさん** · 2022/09/10(土) 19:24:52.82

>>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に配置する実装もあり得ると読めなくもない

**デフォルトの名無しさん** · 2022/09/10(土) 20:06:33.59

let bitmap:[u32; LEN] = [0; LEN];
let mut bitmap:[ARGB32; LEN] = unsafe {core::intrinsics::transmute::<_, [ARGB32; LEN]>(bitmap)};

これでいいってことじゃない？
一個目のbitmapは実際書き込んでないからmut不要
二個目のbitmapは変数名同じだけど一個目とは別の変数で、こっちは次の行で書いてるからmut必要