[過去ﾛｸﾞ] Rust part16 (1002ﾚｽ)
上下前次1-新
このｽﾚｯﾄﾞは過去ﾛｸﾞ倉庫に格納されています｡
次ｽﾚ検索 歴削→次ｽﾚ 栞削→次ｽﾚ 過去ﾛｸﾞﾒﾆｭｰ
694: 2022/09/10(土)20:06 ID:xD3pa07u(1/2) AAS
let bitmap:[u32; LEN] = [0; LEN];
let mut bitmap:[ARGB32; LEN] = unsafe {core::intrinsics::transmute::<_, [ARGB32; LEN]>(bitmap)};
これでいいってことじゃない？
一個目のbitmapは実際書き込んでないからmut不要
二個目のbitmapは変数名同じだけど一個目とは別の変数で、こっちは次の行で書いてるからmut必要
695: 2022/09/10(土)20:13 ID:xD3pa07u(2/2) AAS
あぁ言いたいことは分かった
確かにtransmuteしてるからバックエンドの挙動によっては変なことになりうるかもね
ただそれは別にmutをつけても保証はされない気がする
696(1): 2022/09/10(土)20:24 ID:BhJh8aSd(4/5) AAS
>>691
repr(packed)を指定した構造体のフィールドへのアクセスは未定義動作を引き起こす可能性があるからrepr(packed)は基本的には使わない方が良いよ
外部ﾘﾝｸ[html]:doc.rust-lang.org
確かにrepr(C)やrepr(Rust)はパディングされる可能性があるけど、フィールドのアラインメントを適切にするために必要なものなので
パディングが問題になるならフィールドのメンバーの順序やサイズを見直すか、フィールドの値を読むのに std::ptr::read_unaligned を使う必要があるよ
外部ﾘﾝｸ[html]:doc.rust-lang.org
read_unalignedのドキュメントにも書いてあるけど、アライメントが不適切なフィールドへの参照を作るのすら未定義動作になるという落とし穴もあったり、
repr(packed)な構造体の取り扱いにはいろいろと注意が必要になるので、本当に必要なとき以外は使わない方が良いよ
あと、repr(packed)はrepr(packed, Rust)と同じ意味になるので、構造体のフィールドがメモリ上でどのような配置になるかの保証はないよ
フィールドの定義順とメモリ上での順序を同じにしたいのであれば repr(C) または repr(C, packed) と指定する必要があるよ
省3
697: 2022/09/10(土)20:36 ID:BhJh8aSd(5/5) AAS
>>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に変換するみたいなことをすると未定義動作になるから注意は必要
省2
698: 2022/09/11(日)12:51 ID:6axTKkj4(1) AAS
>>693
＞mutを付けずにletで宣言すると書き換わらない値として
＞書き込めないメモリ領域(例えば.textセクション)に配置されたりしないのか？というのが心配な点です
しねーよ。
組み込みだろーがそれは変わらない。
letついて束縛変数といわれようが変数は変数。
699: 2022/09/11(日)13:08 ID:3JeGkSLy(1/3) AAS
今はしないけどそうなるような最適化は禁止されてないのでは
700: 2022/09/11(日)13:49 ID:7UmicIsS(1) AAS
コンパイル時に値が確定してないとtextセクションに書けないでしょ
701: 2022/09/11(日)13:55 ID:VMVpvyTB(1/2) AAS
そっちは定数でconstだしそうなる
letはあくまでもimmutableな変数であり定数ではない
702: 2022/09/11(日)13:57 ID:kEOVMHNm(1) AAS
コンパイル時に確定するような式なら最適化でありえるんじゃないの？
703: 2022/09/11(日)14:07 ID:VMVpvyTB(2/2) AAS
どのように最適化されようが
constではなくlet x = ...ならば
let mut x = x; とムーブして書き換え可能
これは言語のレベルで保証される
そしてそのように使うならば最適化も無駄なことせずにtext segmentでなくdata segmentに置くだろう
704(1): 2022/09/11(日)14:40 ID:ujBIW69o(1/3) AAS
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;
省10
705: 2022/09/11(日)14:49 ID:FOB38Q8d(1/2) AAS
そのような実装はしたくないわけですか
706: 2022/09/11(日)15:13 ID:/O1tQPyF(1/2) AAS
どの言語でも同じ
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の位置はこうなる
707(1): 2022/09/11(日)18:54 ID:gEyGQ7vE(1) AAS
このスレでよく出てくる μt ってなんなん？
音的に mut をそう書いてる異常者がいるだけかと思ってるんだけど、なにか別の意味を持った概念や機能だったりするの？
708(2): 2022/09/11(日)20:25 ID:FOB38Q8d(2/2) AAS
自分も思ったけどブラウザによっては & mut がそうなるみたい
709: 2022/09/11(日)20:27 ID:QYXgEc7E(1) AAS
>>708
そうなんだ。
710: 2022/09/11(日)20:45 ID:hnVgjqVb(1) AAS
>>708
なるほど、ありがと。
異常者かと思って真面目に読む気が失せてたんだけど誤解だったか。
711: 2022/09/11(日)21:25 ID:zZ32ojSE(1) AAS
HTMLの文字参照で& muがμ
712(1): 2022/09/11(日)21:45 ID:ujBIW69o(2/3) AAS
例えば
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];
省9
713(1): 2022/09/11(日)21:47 ID:3JeGkSLy(2/3) AAS
>>704
パディングというかメモリアクセス時のアラインメントについてはCPUの仕様だから言語関係ないよ
x86がunalignedなアクセスについてゆるゆるだから忘れられがちだけど雑に書いたプログラムをarmで動かしたりするとクラッシュする
今回はu8へのアクセスだからさすがにパディング入れられることはないと思うけどね
714(1): 2022/09/11(日)21:50 ID:3JeGkSLy(3/3) AAS
>>712
シフト処理など隠蔽してくれるアクセサメソッド用意したらだいたい同じような読みやすさになるのでは
715: 2022/09/11(日)23:45 ID:ujBIW69o(3/3) AAS
Rust固有じゃないけど移植性を改善する方法に1バイトずつ処理するという手があるけどこの実装は、今時の32bitや64bit環境で
相応にデバフが入るんですよね。MSVCでも8bitロード×8を64bitロード×1に最適化してくれなかったし
>>713
そこを抽象化するのが処理系の仕事では。いまだに構造体でパース・・・みたいなコードを見かけるし
>>714
読みやすさは改善しても今度は速度にデバフが入るような。こういうケースでアクセサメソッドを利用したとして
全てインライン展開＆最適化されますかね？一つでもコールやブランチが残ったら速度が結構落ちるだろうし
716(1): 2022/09/11(日)23:59 ID:/O1tQPyF(2/2) AAS
>>707
色んなブラウザで見てみたけど
&mut (分けて書くと & mut )が μt と表示されるのはバグってるchmateだけっぽい
717: 2022/09/12(月)00:37 ID:5hhAOS+Q(1) AAS
&mut テスト
718: 2022/09/12(月)01:00 ID:JkhjRZ+U(1/2) AAS
>>716
ほー、chmateはワザとunescapeしてるのか？
5chがUnicode文字表示できるようになったんだし、そういうのはもう余計なお世話だな
719: 2022/09/12(月)01:13 ID:D0TZxDhn(1) AAS
HTML等の文字参照を処理する場合でも
μt (＝ & m u ; t )が μt となるのは正しいけど
&mut (＝ & m u t )が μt となるの間違いだからこれはバグと思われる
720: 2022/09/12(月)02:30 ID:JkhjRZ+U(2/2) AAS
あ、たしかにバグっぽい・・・
721: 2022/09/12(月)06:45 ID:hsi1XO0i(1) AAS
文字列参照に & mut なんてないからテキトーに解釈してるんでしょ
良し悪しは別にして html を扱うブラウザではそれほど珍しくはない
個人的には余計な事すんなとは思う
722: 2022/09/12(月)07:14 ID:tyJETXG8(1/3) AAS
これはmateのバグです
& x y z ; とセミコロンで終わる場合のみその部分を文字参照として解釈するのが正しいです
723: 2022/09/12(月)07:33 ID:o/NFQNbK(1/4) AAS
&mut と書けば良いかな
テスト → &mut
上下前次1-新書関写板覧索設栞歴
あと 279 ﾚｽあります
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ AAｻﾑﾈｲﾙ
ぬこの手 ぬこTOP 0.026s