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/ 597 名前：デフォルトの名無しさん [[ここ壊れてます] .net] Amazonがプログラミング言語「Rust」を使っている理由 https://japan.zdnet.com/article/35183866/ Amazon Web Services（AWS）は、同社のエンジニアたちがプログラミング言語「Rust」を 使っている大きな理由として、エネルギー効率の高さを挙げる。 AWSは早くからRustを採用し、GoogleやMicrosoftとともにRust Foundationの創設にも携わった。 現在もRustの普及に熱心に取り組んでいる。 AWSのソフトウェアエンジニアで、Rustの普及に取り組む、 Shane Miller氏と主任エンジニアのCarl Lerche氏の投稿によれば、 Rustはメモリー安全性を高め、セキュリティ関連の不具合を減らす役に立つだけでなく、 PythonやJavaよりもはるかに「エネルギー効率に優れている」という。 Amazonは、2025年までにデータセンターの100％を再生エネルギーでまかなうという目標を掲げ、 データセンターの環境負荷の軽減に取り組んでいる。 Rustの採用はその一翼を担うという。 Rustで構築されたAWSサービスの例としては、 コンテナーアプリ用のサーバーレスプラットフォーム「Lamba」を支える「Firecracker」、 「Amazon Simple Storage Service（S3）」「Amazon Elastic Compute Cloud（EC2）」、 コンテンツ配信ネットワーク「Amazon CloudFront」、 LinuxベースのコンテナーOS「Bottlerocket」がある。 「CやRustが他の言語よりもエネルギー効率に優れていることに驚きはない。 衝撃的なのは、その違いの大きさだ。CとRustを広範に採用すれば、 控えめに見積もってもコンピュートに使用されるエネルギーの量を50％削減できる可能性がある」と Miller氏は述べ、その根拠として、C、GoogleのGo、Lua、Python、Ruby、Fortranなどをはじめとする 複数の言語のエネルギー効率を相対的に示した研究結果を紹介している。 598 名前：デフォルトの名無しさん mailto:sage [2022/08/31(水) 10:44:22.32 ID:nTGfEW2M.net] >>590 そういう基本的なのはチュートリアルに書いてあるんだから何をあらためて検索する必要があるっていうんだ？ 599 名前：デフォルトの名無しさん mailto:sage [2022/08/31(水) 12:13:30.34 ID:Fgf/9Zy6.net] >>590 文法は場当たり的に学ばないで初学者向けドキュメント読んだ方が良いと思うけどそれは置いておいて、 rust operatorでググって出てくるこれ参照して演算子の意味調べてもう一度ググれば良いのでは それすらめんどくさい？ https://doc.rust-lang.org/book/appendix-02-operators.html 600 名前：デフォルトの名無しさん mailto:sage [2022/08/31(水) 12:30:09.46 ID:836P0mbg.net] question markとかsemicolonで調べればいいんだよ 601 名前：デフォルトの名無しさん mailto:sage [2022/08/31(水) 12:34:08.26 ID:J/OAC0EF.net] 例えば question mark site:doc.rust-lang.org で検索すれば必要な解説がすぐ見つかる 602 名前：デフォルトの名無しさん mailto:sage [[ここ壊れてます] .net] >>593 公式に「チュートリアル」てあったっけ？ THE Book読めということかしらん？ >>594 Error propagationとかStatement and item terminatorぐらいしか記載無いんだけど…… >>595 公式の解説出てこないんだけど、公式には説明無いんかね？ 603 名前：デフォルトの名無しさん mailto:sage [[ここ壊れてます] .net] >>596 おお、ここまで指定すれば見つかりますな。公式トップに検索窓ぐらい欲しいところだけど。 604 名前：デフォルトの名無しさん mailto:sage [[ここ壊れてます] .net] >>597 エラーとか文に関わるものということが分かれば、関連するリファレンス探すとっかかりにはなるんじゃないかと 少なくとも記号よりは検索しやすい 605 名前：デフォルトの名無しさん mailto:sage [2022/08/31(水) 13:39:17.87 ID:lcZ+Kyy5.net] 所有権チェックはありがたいけど、lintみたいにビルドと分けた方が使い勝手よかったと思うがな。 606 名前：はちみつ餃子 mailto:sage [2022/08/31(水) 13:42:22.79 ID:nTGfEW2M.net] >>597 > THE Book読めということかしら せやで。 まあそれに限らなくてもいいけどどんな入門書でも ? の説明がないなんてことはないでしょ。 常識的な手順通りに学習してれば ? が大まかに何をする演算子なのかくらいは知っているはずだし、 エラー処理にかかわるものだと知ってればもっと細かいドキュメントを探すのにも苦労するってことはない。 なるべく一発で検索できたほうが便利というのはわからんでもないが、 演算子であると同時に制御構文の類でもあり、周辺の機能と連携するのできちんとした理解をしようとすれば どうせ色々と見るはめになる。 607 名前：デフォルトの名無しさん mailto:sage [2022/08/31(水) 15:08:14.60 ID:Fgf/9Zy6.net] >>600 所有権チェックをなくすってどういうこと？ referenceが有効な間に元データをmoveした場合に警告だけ出してコード自体はコンパイルできるようにするとかそういうこと？ 608 名前：デフォルトの名無しさん [2022/08/31(水) 16:15:20.37 ID:bi3oBo/Y.net] コンパイル(ビルド)時に所有権チェックの結果を使ってメモリの解放処理を挿入してるんだから分けるのは無理 609 名前：デフォルトの名無しさん mailto:sage [2022/08/31(水) 16:22:04.68 ID:UXqUoG+N.net] ビルドしなくてももっと気軽にわかるようにしろってことか？ linterの領域外れてる気もするが 610 名前：はちみつ餃子 mailto:sage [2022/08/31(水) 16:50:31.19 ID:nTGfEW2M.net] 細かな所有権の整合性を後回しにしてとりあえず動く (ように見える) ところまでもっていきたいという気持ちはわからんもでない。 でもなー、そういうことすると整合性がとれてないままの未定義コードが世に溢れてしまうのは確実だろう。 611 名前：デフォルトの名無しさん mailto:sage [2022/08/31(水) 16:56:11.73 ID:LCT5ihCl.net] 所有権周りのエラーって基本的なデータ構造に起因することが多いからなぁ 後から直そうとか思うと結局全部作り直すはめになるから 一度チェックなしモードとかで作っちゃうと永遠にそのままだろうね 612 名前：デフォルトの名無しさん mailto:sage [2022/08/31(水) 17:04:46.18 ID:BdHQqSBt.net] マンホールって卑猥な単語じゃね？ 613 名前：デフォルトの名無しさん mailto:sage [2022/08/31(水) 19:07:16.13 ID:th8cAM8K.net] >>592 そのうち、他の分野のライフサイクルみたいに、製造時、利用時といった感じで電力効率が語られるようになるんかね。 614 名前：デフォルトの名無しさん mailto:sage [2022/08/31(水) 20:09:18.42 ID:iogMBVhq.net] >>601 the book読めというのはさすがに初心者殺しだと思うけどなぁ。 公式に絶壁の学習曲線をどうにかしようという意識はあるのかしらん？ 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は安易に使うものじゃないと思う

---

---

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

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