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/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必要

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

あぁ言いたいことは分かった
確かにtransmuteしてるからバックエンドの挙動によっては変なことになりうるかもね
ただそれは別にmutをつけても保証はされない気がする

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

>>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を使って構造体のサイズとアライメントに関するアサーションを加えるのが良いと思う

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

>>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>.

**デフォルトの名無しさん** · 2022/09/11(日) 12:51:18.94

>>693
＞mutを付けずにletで宣言すると書き換わらない値として
＞書き込めないメモリ領域(例えば.textセクション)に配置されたりしないのか？というのが心配な点です

しねーよ。
組み込みだろーがそれは変わらない。
letついて束縛変数といわれようが変数は変数。

**デフォルトの名無しさん** · 2022/09/11(日) 13:08:43.20

今はしないけどそうなるような最適化は禁止されてないのでは

**デフォルトの名無しさん** · 2022/09/11(日) 13:49:03.04

コンパイル時に値が確定してないとtextセクションに書けないでしょ

**デフォルトの名無しさん** · 2022/09/11(日) 13:55:35.90

そっちは定数でconstだしそうなる
letはあくまでもimmutableな変数であり定数ではない

**デフォルトの名無しさん** · 2022/09/11(日) 13:57:25.52

コンパイル時に確定するような式なら最適化でありえるんじゃないの？

**デフォルトの名無しさん** · 2022/09/11(日) 14:07:54.90

どのように最適化されようが
constではなくlet x = ...ならば
let mut x = x; とムーブして書き換え可能
これは言語のレベルで保証される

そしてそのように使うならば最適化も無駄なことせずにtext segmentでなくdata segmentに置くだろう

**デフォルトの名無しさん** · 2022/09/11(日) 14:40:44.81

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でも書いているんだけど構造体のパディングの制御は処理系依存らしくて移植性を優先すると
データは整数の配列で持って論理演算とシフトで分解、構築するコードになってしまってます

**デフォルトの名無しさん** · 2022/09/11(日) 14:49:25.24

そのような実装はしたくないわけですか

**デフォルトの名無しさん** · 2022/09/11(日) 15:13:19.03

どの言語でも同じ
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の位置はこうなる

**デフォルトの名無しさん** · 2022/09/11(日) 18:54:24.82

このスレでよく出てくる μt ってなんなん？
音的に mut をそう書いてる異常者がいるだけかと思ってるんだけど、なにか別の意味を持った概念や機能だったりするの？

**デフォルトの名無しさん** · 2022/09/11(日) 20:25:15.55

自分も思ったけどブラウザによっては & mut がそうなるみたい

**デフォルトの名無しさん** · 2022/09/11(日) 20:27:57.44

>>708
そうなんだ。

**デフォルトの名無しさん** · 2022/09/11(日) 20:45:42.63

>>708
なるほど、ありがと。
異常者かと思って真面目に読む気が失せてたんだけど誤解だったか。

**デフォルトの名無しさん** · 2022/09/11(日) 21:25:51.88

HTMLの文字参照で& muがμ

**デフォルトの名無しさん** · 2022/09/11(日) 21:45:56.06

例えば
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;
ではだいぶ見やすさが違うような

**デフォルトの名無しさん** · 2022/09/11(日) 21:47:41.04

>>704
パディングというかメモリアクセス時のアラインメントについてはCPUの仕様だから言語関係ないよ
x86がunalignedなアクセスについてゆるゆるだから忘れられがちだけど雑に書いたプログラムをarmで動かしたりするとクラッシュする

今回はu8へのアクセスだからさすがにパディング入れられることはないと思うけどね

**デフォルトの名無しさん** · 2022/09/11(日) 21:50:14.96

>>712
シフト処理など隠蔽してくれるアクセサメソッド用意したらだいたい同じような読みやすさになるのでは

**デフォルトの名無しさん** · 2022/09/11(日) 23:45:21.14

Rust固有じゃないけど移植性を改善する方法に1バイトずつ処理するという手があるけどこの実装は、今時の32bitや64bit環境で
相応にデバフが入るんですよね。MSVCでも8bitロード×8を64bitロード×1に最適化してくれなかったし

>>713
そこを抽象化するのが処理系の仕事では。いまだに構造体でパース・・・みたいなコードを見かけるし

>>714
読みやすさは改善しても今度は速度にデバフが入るような。こういうケースでアクセサメソッドを利用したとして
全てインライン展開＆最適化されますかね？一つでもコールやブランチが残ったら速度が結構落ちるだろうし

**デフォルトの名無しさん** · 2022/09/11(日) 23:59:30.49

>>707
色んなブラウザで見てみたけど
&mut (分けて書くと & mut )が μt と表示されるのはバグってるchmateだけっぽい

**デフォルトの名無しさん** · 2022/09/12(月) 00:37:31.19

&mut テスト

**デフォルトの名無しさん** · 2022/09/12(月) 01:00:12.66

>>716
ほー、chmateはワザとunescapeしてるのか？
5chがUnicode文字表示できるようになったんだし、そういうのはもう余計なお世話だな

**デフォルトの名無しさん** · 2022/09/12(月) 01:13:39.26

HTML等の文字参照を処理する場合でも
μt (＝ & m u ; t )が μt となるのは正しいけど
&mut (＝ & m u t )が μt となるの間違いだからこれはバグと思われる

**デフォルトの名無しさん** · 2022/09/12(月) 02:30:39.40

あ、たしかにバグっぽい・・・

**デフォルトの名無しさん** · 2022/09/12(月) 06:45:23.29

文字列参照に & mut なんてないからテキトーに解釈してるんでしょ
良し悪しは別にして html を扱うブラウザではそれほど珍しくはない
個人的には余計な事すんなとは思う

**デフォルトの名無しさん** · 2022/09/12(月) 07:14:45.53

これはmateのバグです
& x y z ; とセミコロンで終わる場合のみその部分を文字参照として解釈するのが正しいです

**デフォルトの名無しさん** · 2022/09/12(月) 07:33:21.32

&mut と書けば良いかな
テスト → &mut

**デフォルトの名無しさん** · 2022/09/12(月) 07:34:32.06

& amp ; amp; を空白なしで書き込んだら & に変換されてしまった
実体参照複数回展開しているのかな
&

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

ライブラリとかのコンポーネントの一部を作っているときに入出力だけ不定値として扱う方法ってありませんかね
ガワ作って入出力を完全に外部に出さないとコードがみんな消えてしまうのは不便です
最適化レベルによる変化とか全然確認出来ないし

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

ちょっと意味がわからない
こうなるはずだから困ることはないと思うけど

・最適化によってRustが定めている意味が変わることはない
・pub宣言しているものは中で呼ばれていなくても単体コンパイルで消えることはない
・pub宣言されていないものは中で呼ばれていなければ今後も誰からも呼ばれないためwarningが出て消える

**デフォルトの名無しさん** · 2022/09/12(月) 10:25:58.86

genericな関数だと呼び出し元がないとコード生成されないとか？

**デフォルトの名無しさん** · 2022/09/12(月) 12:04:36.56

その場合でも実際に使う型々でtestを書くだろうからcargo testで確認できるでしょ

**デフォルトの名無しさん** · 2022/09/12(月) 12:46:09.29

>>726
ありゃうちの環境の問題か。pub付けただけじゃ関数丸ごとなかったことにされる
pub extern "C"でRust外の入出力にしてようやく消えなくなる
もうちょっと調べてみる

**デフォルトの名無しさん** · 2022/09/12(月) 14:30:52.03

>>729
ちなみにターゲットはbinと(r)libのどっち？
binならpubでも消えるかも

**デフォルトの名無しさん** · 2022/09/12(月) 19:11:31.91

>>730
変更してみた。staticlibだとpub付けても消える。rlibなら消えないようだ
とりあえずrlibにしておいてある程度形になってきたら変更すればいいか
コード自体はどっちでも大差ないだろうし

**デフォルトの名無しさん** · 2022/09/18(日) 01:08:32.32

[u32; LEN]と[ARGB32; LEN] の件、アラインメントが違うからtransmuteの時点でUBだけど

**デフォルトの名無しさん** · 2022/09/19(月) 02:33:25.46

Tauriで動画プレーヤー的なのを作るサンプルってどっかにある？
ただ再生するデータは既存のmp4ファイルなどではなくRustプログラムから渡したい
あと再生、停止、コマ送り、シークなどの基本的な機能は実装したい

**デフォルトの名無しさん** · 2022/09/19(月) 07:48:35.44

TauriってWebアプリのサーバーサイドがRustで一体型プログラムになっているだけだろ？
そして既存のWeb技術を活かせるのがTauriの利点だろ？
そうならば例えばhls.jsなど既存の好みの動画配信再生フレームワークを使えばいいだけじゃないか？
Webサーバーサイドやったことあるならばフロントエンドからファイルに見えているものは本物のファイルである必要はなくサーバーサイドが算出していれば十分だろ？

**デフォルトの名無しさん** · 2022/09/19(月) 12:27:41.81

>>734
>HLS
ちょっと調べてみたけどHLSでいわゆるRAWデータを再生出来るという情報は見つけられていない
特にビデオが未圧縮データを扱えそうにない。オーディオは未圧縮FLACでいけるかもしれないけど
再生したいのがWebブラウザが対応していないデータなのでどうしようか考え中

ビデオはBMPのぱらぱら漫画でオーディオはHLSで未圧縮FLACとか？なんか無駄に実装量が増えるけど