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/07(日) 12:50:43.08

次世代スレの方もﾜｯﾁｮｲ付ければ例のバカが寄り付かないことがほぼほぼ実証されつつあるので
あとは過疎を恐れず移行すれば万事解決です

**デフォルトの名無しさん** · 2022/08/07(日) 13:58:05.65

まだ実証されてないってことね
じゃあバスで

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

過疎やん

【ﾜｯﾁｮｲあり】プログラミング言語 Rust
https://mevius.5ch.net/test/read.cgi/tech/1514107621/

**デフォルトの名無しさん** · 2022/08/11(木) 07:14:02.75

structに不変なフィールドを持たせるにはどうしたらいいのですか？
const定数ではなく、インスタンスごとに初期化時に値を設定したら、その後は変更不可能。
他のフィールドは変更可能でも。

**はちみつ餃子** ◆8X2XSCHEME · 2022/08/11(木) 10:33:56.78

>>557
直接的にメンバに指定を付けることは出来ない。
Rust のアクセス制御はモジュールが基本単位になっていて、
「メンバに pub が付いていない」「そのモジュールの中でメンバを変更することがない」ならば変更不可能なメンバになる。

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

>>558
ありがとうございます。

**デフォルトの名無しさん** · 2022/08/13(土) 13:13:02.04

>>45-47
https://www.youtube.com/watch?v=k8x2DiNz4iU

**デフォルトの名無しさん** · 2022/08/13(土) 13:54:36.73

>>560
言語としてのRustにはピクリとも興味がわかなかったが
なんだか急にRustに興味がわいてきたぞー

**デフォルトの名無しさん** · 2022/08/16(火) 13:03:21.19

VSCode + CodeLLDB + LLDBでデバッグしているのですが、ポインタに関して見方がよくわかりません
Borrowed pointer typeの参照先の値ってデバッガ上でどうやったら見れるんですか？

**デフォルトの名無しさん** · 2022/08/18(木) 15:17:30.09

参考までに、mutはドイツ語で勇気の意味です。

**デフォルトの名無しさん** · 2022/08/19(金) 15:36:33.17

スレチ

**デフォルトの名無しさん** · 2022/08/19(金) 15:56:19.49

今の時代ってcc++rustなんて、低レイヤーをやってる人以外は不要だな
Java Script全盛のこの時代にいちいちコンパイルするなんて面倒で仕方ない

**デフォルトの名無しさん** · 2022/08/19(金) 17:51:45.38

釣りは隔離スレでどうぞ

**デフォルトの名無しさん** · 2022/08/21(日) 14:52:30.50

RUST大流行だな
ほんと紛らわしい

**デフォルトの名無しさん** · 2022/08/21(日) 17:28:20.00

この言語開発した人、Swiftにいっちゃったみたいだけど追い出されたの？

**デフォルトの名無しさん** · 2022/08/21(日) 21:36:56.87

確か燃え尽き症候群で自分から離れたんじゃなかったかな

**デフォルトの名無しさん** · 2022/08/22(月) 11:06:04.53

嘘のようにボロ負けしたんだろうな

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

ジャバスクリプト全盛の時代にネイティブこんぱいらなんて
不要だろ。
jsでカーネルのラードンをつくる猛者まで出てきた

**デフォルトの名無しさん** · 2022/08/25(木) 01:05:28.98

Arc<HashMap<T1, T2>>みたいにした場合って、どの範囲でスレッドセーフになるんですか？

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

範囲はHashMap全体たが
Arc単体で提供するスレッドセーフはimmutableな共有所有のみ
その例だとHashMapは読み取り専用になる
他を要求するなら他と組み合わせる

まずArcは置いといて単独所有の時
整数やブールならAtomicXxxでスレッドセーフ
一般的な型ならMutex<T>
読み取り同時複数ならRwLock<T>
それぞれコストが異なるので使い分ける

その上で共有所有ならArc<.....>をそれらの上に被せる

**デフォルトの名無しさん** · 2022/08/25(木) 02:06:21.10

T1, T2がSend/Syncな前提だよね？

**デフォルトの名無しさん** · 2022/08/25(木) 21:50:49.35

もちろんTがSync+Sendの時のみ
Arc<T>はSync+Sendとなる

**デフォルトの名無しさん** · 2022/08/25(木) 23:42:19.60

条件を満たせなければコンパイラが指摘してくれるところがRustの良さ
間違えていても安全でなくてもコンパイルが通ってしまい実行時に酷い目に合う従来の言語

**デフォルトの名無しさん** · 2022/08/26(金) 03:34:10.56

Test

**デフォルトの名無しさん** · 2022/08/26(金) 10:06:51.61

>>576
コンパイル通ったら安心と思い込む馬鹿

**デフォルトの名無しさん** · 2022/08/26(金) 10:39:24.20

そいつには触れるな

**デフォルトの名無しさん** · 2022/08/26(金) 16:17:33.63

>>578
思い込みで誤読しているあんたが馬鹿っぽい
>>576にはそんなこと書かれていない

**デフォルトの名無しさん** · 2022/08/27(土) 02:23:31.10

>>578
日本語読めないバカ

**デフォルトの名無しさん** · 2022/08/27(土) 03:03:50.30

>>578
うちの会社にもいるわ
ビルド出来たってドヤ顔のバカ
そんなものは、ある程度の言語の知識があればいいだけ。

**デフォルトの名無しさん** · 2022/08/27(土) 13:37:40.60

デバッグスキル0の奴がビルドだけでOKとか思いたがるんだわ。

**デフォルトの名無しさん** · 2022/08/27(土) 14:27:59.40

>>582
その会社ヤバくない？
大丈夫？

**デフォルトの名無しさん** · 2022/08/27(土) 19:09:11.54

確証バイアスかな？

**デフォルトの名無しさん** · 2022/08/27(土) 20:57:03.41

>>585
お前ヤバくない？
大丈夫？

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

最強無敵言語age

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

>>587
入門者相手には最強だよな。

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

急に書き込み減ったけどもう飽きられたの？
Scalaのときもそうだったけどエンジニアがこういう読みにくい言語で現場を遊び散らかして負債だけ残すの何とかして欲しいわ

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

?の意味とか;の違いとか、すぐに調べられないからバッドノウハウ化しているよね。FAQとかダメダメだし。
せめて検索性に配慮して記号を決めればな。?::くらいにしても問題ないだろうに。

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

ピークを過ぎた感はある
Scalaで遊んでたのはDDDとか高レイヤの好きな意識高い系が中心だったからまあそこまで酷い負債にはなってないけど、
その点Rustの負債はタチが悪そうだな

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

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などをはじめとする
複数の言語のエネルギー効率を相対的に示した研究結果を紹介している。

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

>>590
そういう基本的なのはチュートリアルに書いてあるんだから何をあらためて検索する必要があるっていうんだ？

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

>>590
文法は場当たり的に学ばないで初学者向けドキュメント読んだ方が良いと思うけどそれは置いておいて、
rust operatorでググって出てくるこれ参照して演算子の意味調べてもう一度ググれば良いのでは
それすらめんどくさい？
https://doc.rust-lang.org/book/appendix-02-operators.html

**デフォルトの名無しさん** · 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に対応させるようなプロジェクトってありますか？