[過去ログ]
Rust part16 (1002レス)
Rust part16 http://mevius.5ch.net/test/read.cgi/tech/1656285423/
上
下
前
次
1-
新
通常表示
512バイト分割
レス栞
このスレッドは過去ログ倉庫に格納されています。
次スレ検索
歴削→次スレ
栞削→次スレ
過去ログメニュー
664: デフォルトの名無しさん [sage] 2022/09/09(金) 12:42:45.67 ID:VsTRsG1f 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), } http://mevius.5ch.net/test/read.cgi/tech/1656285423/664
665: デフォルトの名無しさん [sage] 2022/09/09(金) 13:41:22.02 ID:4b4Wyf25 最低限ガイドには従った方が良いと思う https://rust-lang.github.io/api-guidelines/naming.html acronymはひとつ単語として扱うとあるから Rgb とか Argb とすべき あとは適当なグラフィック系ライブラリの実装を見て真似してみたら良いのでは 規約に従ってないライブラリも多いけど そもそも既存crate使えば独自にArgb型定義する必要もなくなるかもしれない http://mevius.5ch.net/test/read.cgi/tech/1656285423/665
666: はちみつ餃子 ◆8X2XSCHEME [sage] 2022/09/09(金) 14:02:11.22 ID:gp9Eay33 API ガイドラインってことは、 API として公開しない (内部的な) 名前は雑でいいってことだよね。 http://mevius.5ch.net/test/read.cgi/tech/1656285423/666
667: デフォルトの名無しさん [sage] 2022/09/09(金) 14:15:33.61 ID:+r9uXbjm >>661 個人的にはこっちの方が好きだけど 規約的にダメなら仕方ない http://mevius.5ch.net/test/read.cgi/tech/1656285423/667
668: デフォルトの名無しさん [sage] 2022/09/09(金) 14:42:45.26 ID:4b4Wyf25 >>666 非公開部分を将来公開APIにする可能性や、自分以外の誰かがソース読んでパッチ作ってくれる可能性考えると、 最初から内部も規約に従ったものにしておいた方が良いと思う そもそもひとつのプロジェクトの中で公開部分と非公開部分で異なる規約混在するのも嫌では http://mevius.5ch.net/test/read.cgi/tech/1656285423/668
669: デフォルトの名無しさん [sage] 2022/09/09(金) 15:18:27.40 ID:QLGZdL8Z mozillaは公開できない関数名を使ってオープンソース化が数年遅れた過去があったなぁ。 http://mevius.5ch.net/test/read.cgi/tech/1656285423/669
670: デフォルトの名無しさん [sage] 2022/09/09(金) 15:35:09.62 ID:7NqN1r1N gameraとか? http://mevius.5ch.net/test/read.cgi/tech/1656285423/670
671: デフォルトの名無しさん [sage] 2022/09/09(金) 16:00:26.66 ID:wraz5iEP >>669 94年初リリースで98年ソース公開で 数年遅れるとは? http://mevius.5ch.net/test/read.cgi/tech/1656285423/671
672: デフォルトの名無しさん [sage] 2022/09/09(金) 17:53:00.11 ID:rfSAUeXI 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)との差異が 拡大するだけでメリットはほとんど無いような http://mevius.5ch.net/test/read.cgi/tech/1656285423/672
673: デフォルトの名無しさん [sage] 2022/09/09(金) 21:16:36.10 ID:pyHRaXAz JPEG、MPEG、PNG、HEVC・・・すでに略されている物をありがちな命名規則で書くと判りにくくなる http://mevius.5ch.net/test/read.cgi/tech/1656285423/673
674: デフォルトの名無しさん [] 2022/09/09(金) 22:46:34.35 ID:B0h43lqZ >>673 同意 http://mevius.5ch.net/test/read.cgi/tech/1656285423/674
675: デフォルトの名無しさん [sage] 2022/09/10(土) 00:32:32.71 ID:qBfKxAEz >>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; アセンブラリストを見る限りは問題なさそう http://mevius.5ch.net/test/read.cgi/tech/1656285423/675
676: デフォルトの名無しさん [sage] 2022/09/10(土) 01:19:16.36 ID:BhJh8aSd acronymを全部大文字にするか先頭だけ大文字にするかってそんなに大きな問題かな 一貫性のあるルールに従っていれば書き手や読み手として混乱することもないと思うんだが http://mevius.5ch.net/test/read.cgi/tech/1656285423/676
677: デフォルトの名無しさん [] 2022/09/10(土) 03:00:06.93 ID:Rsh0NV07 Ipv4なんて一瞬なんのことか分からんかったな 結局慣れで、一貫性以上に価値のある好みなんてのはない http://mevius.5ch.net/test/read.cgi/tech/1656285423/677
678: デフォルトの名無しさん [] 2022/09/10(土) 07:09:44.43 ID:2MfL7Eat >>676 その一貫性が崩れるのがいやなんだろ。 ドキュメント・コメントでは全部大文字なのにコードでは先頭だけ大文字とか。 慣れの問題だが、今まで/一般的 に全部大文字で慣れてるものをこの時だけ先頭大文字に慣らせというのは抵抗感あって当たり前。 http://mevius.5ch.net/test/read.cgi/tech/1656285423/678
679: デフォルトの名無しさん [] 2022/09/10(土) 07:12:21.94 ID:2MfL7Eat >>676 問題の大小なんて誰も言ってない。 今までの慣れ/一般的な表記 を置き換えるのは抵抗感あるって話。 http://mevius.5ch.net/test/read.cgi/tech/1656285423/679
680: デフォルトの名無しさん [sage] 2022/09/10(土) 12:37:11.73 ID:GXRB1/O5 命名規則を利用する目的は可読性や開発効率の向上などのはず 一般的な表記から外れるのであればそれなりの理由が必要であろう 「命名規則に従ったから」では「目的より手段を優先している、合理性がない」などと 突っ込まれてもしょうがない http://mevius.5ch.net/test/read.cgi/tech/1656285423/680
681: デフォルトの名無しさん [sage] 2022/09/10(土) 13:03:13.98 ID:jQKLnU5m JavaScriptのアイツは XmlHttpRequestと命名されるべきだったのか? XMLHTTPRequestと命名されるべきだったのか? http://mevius.5ch.net/test/read.cgi/tech/1656285423/681
682: デフォルトの名無しさん [] 2022/09/10(土) 13:20:38.77 ID:AMhmGX9g eXtend Markup Language Hyper Text Transfer Protocol Request http://mevius.5ch.net/test/read.cgi/tech/1656285423/682
683: デフォルトの名無しさん [sage] 2022/09/10(土) 13:38:53.61 ID:D1Nb21qC 完全に好みの問題と思うから何らかのルールで統一されてればどっちでも良いと思うけど、 LCD TV、nVidia、iOS IoT Hubなんかをどう表記するかとか変数名ならどうしようとか考えるのめんどいから 表記の慣例とか無視して全部キャメルケースにしちゃうな http://mevius.5ch.net/test/read.cgi/tech/1656285423/683
684: デフォルトの名無しさん [sage] 2022/09/10(土) 13:50:29.86 ID:TnGNUz3W ルールから逸脱させるかどうか悩むならルールに合わせておくおじさんになった http://mevius.5ch.net/test/read.cgi/tech/1656285423/684
685: デフォルトの名無しさん [] 2022/09/10(土) 14:31:16.93 ID:/uHulLcW Rustすれのレベルの低さにガッカリ Python質問すれとかみたいに和気あいあいとしてない殺伐にドッキリ http://mevius.5ch.net/test/read.cgi/tech/1656285423/685
686: デフォルトの名無しさん [sage] 2022/09/10(土) 14:56:40.59 ID:qBfKxAEz >>675みたいに書いた場合 >let mut bitmap:[u32; LEN] = [0; LEN]; のmutが余計だと警告が出る。この場合実際に確保されるメモリ領域は書き込みも出来るスタックフレームだろうし mutを取っても動作上は問題ないと思うけど、mutがない領域に書き込むことになりプログラムの意味としては誤っている 参照先を強制的に書き換えるようなコードを書くと、とコードと警告と動作のミスマッチが起きる気がするけど なんか上手い書き方はないのだろうか この辺の低レイヤーの用途で参照先を書き換える話ってBookのReferenceやUnsafeあたりにもそれっぽい事書いてないし どこを見たらいいのか判らない http://mevius.5ch.net/test/read.cgi/tech/1656285423/686
687: デフォルトの名無しさん [sage] 2022/09/10(土) 15:47:06.47 ID:BhJh8aSd >>675 ARGB32にDefault実装して let mut bitmap : [ARGB32; LEN] = Default::default(); とするのが良いかと repr(C)がついてない構造体のメモリ上での表現がどうなるかは保証されてないから元のコードが意図通り動作する保証はないと思う http://mevius.5ch.net/test/read.cgi/tech/1656285423/687
688: デフォルトの名無しさん [sage] 2022/09/10(土) 15:48:16.32 ID:vDnMZIxl >>675 初期化難しいかな。こうとか https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=49327f78412221161809733ee34bf013 http://mevius.5ch.net/test/read.cgi/tech/1656285423/688
689: デフォルトの名無しさん [sage] 2022/09/10(土) 15:54:53.07 ID:BhJh8aSd >>687 [T; N] は N <= 27 までしかDefault実装されてなかったからこのコードじゃダメだった こっちならOK let mut bitmap: [ARGB32; LEN] = std::array::from_fn(|_i| Default::default()); http://mevius.5ch.net/test/read.cgi/tech/1656285423/689
690: デフォルトの名無しさん [sage] 2022/09/10(土) 16:11:30.59 ID:sOVkY8n5 最後の手段のtransmuteは安易に使うものじゃないと思う http://mevius.5ch.net/test/read.cgi/tech/1656285423/690
691: デフォルトの名無しさん [sage] 2022/09/10(土) 16:39:14.44 ID:qBfKxAEz >>687 すみません。構造体にはrepr(packed)を付けています。u8がパディング無し4つ並ぶはず repr(C)だとCと同様にパディングされる可能性が出てくると思うのですが >>688 CloneとCopyを付ける方法に関してはどのような動作になるのか確信を持てていないです 原則コピーになるという情報は出てきますが、画像のバッファだし原則参照で必要なときだけ コピーしたいです(すでに初期化とは別のところで問題になっています。参照とコピーの 切り替え方法が判らない) http://mevius.5ch.net/test/read.cgi/tech/1656285423/691
692: デフォルトの名無しさん [sage] 2022/09/10(土) 18:12:40.24 ID:n3Y/KVD/ >>686 最初に定義した変数bitmapはmoveしてるだけだからmutは余計でいいと思うけど? http://mevius.5ch.net/test/read.cgi/tech/1656285423/692
693: デフォルトの名無しさん [sage] 2022/09/10(土) 19:24:52.82 ID:qBfKxAEz >>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に配置する実装もあり得ると読めなくもない http://mevius.5ch.net/test/read.cgi/tech/1656285423/693
メモ帳
(0/65535文字)
上
下
前
次
1-
新
書
関
写
板
覧
索
設
栞
歴
あと 309 レスあります
スレ情報
赤レス抽出
画像レス抽出
歴の未読スレ
AAサムネイル
Google検索
Wikipedia
ぬこの手
ぬこTOP
0.015s