Rust part21

**デフォルトの名無しさん** · 2023/08/15(火) 22:24:39.45

公式
https://www.rust-lang.org/
https://blog.rust-lang.org/
https://github.com/rust-lang/rust

公式ドキュメント
https://www.rust-lang.org/learn

Web上の実行環境
https://play.rust-lang.org

※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 part20
https://mevius.2ch.net/test/read.cgi/tech/1677771928/

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

**デフォルトの名無しさん** · 2023/10/08(日) 09:57:45.64

同等というより>>438と>>430は全く同じだな
空でなければpartitionでsmallerとrestに分けて
それぞれを再帰でqsortしてconcatenate

**デフォルトの名無しさん** · 2023/10/08(日) 10:16:57.79

次はHaskellまたはErlangでおながいしまつ

**デフォルトの名無しさん** · 2023/10/08(日) 10:38:24.03

in-placeなqsort書いてよ

**デフォルトの名無しさん** · 2023/10/08(日) 10:39:23.48

>>443
Haskell
qsort [] = []
qsort (x:xs) = qsort [y | y <- xs, y < x] ++ [x] ++ qsort [y | y <- xs, y >= x]

Erlang
qsort([]) -> [];
qsort([X|Xs]) ->
qsort([ Y || Y <- Xs, Y < X]) ++ [X] ++ qsort([ Y || Y <- Xs, Y >= X]).

**デフォルトの名無しさん** · 2023/10/08(日) 12:06:58.68

複オジは常にヒープアロケートするGC言語しか知らないのかな？
特定の言語の機能不足をGC言語の制約のように語るのはやめような

**デフォルトの名無しさん** · 2023/10/08(日) 14:27:21.60

rustより高度なライフタイム管理する言語ってないの？

**デフォルトの名無しさん** · 2023/10/08(日) 14:53:30.59

高度なライフタイム管理のベクトルがわからん
全データに参照カウンタをもたせて参照→存在を保証してるGC言語ならたくさんあるし
処理過程を生成する（書かせない）ことでライフタイムを意識させない関数型言語もある

**デフォルトの名無しさん** · 2023/10/08(日) 14:57:14.95

>>442
ScalaのListもOCamlの[]も単方向リストであってべクタではないのに唯一気付いていないおじさん

**デフォルトの名無しさん** · 2023/10/08(日) 15:04:22.44

それはそれとしてScalaのcase classはRustにも欲しいと思うことあり

**デフォルトの名無しさん** · 2023/10/08(日) 15:32:16.97

>>448
rustを置き換え可能な言語で
つまりゼロコスト抽象
大学の研究レベルのものとかでないのかな

**デフォルトの名無しさん** · 2023/10/08(日) 16:37:56.79

ランタイムコストなしのライフタイムチェックはシステムプログラミング言語だから必要な話で、そうでない言語ならGCで良い

shared xor mutableの静的な保証はGC言語でも嬉しい性質だと思うが、他の言語で採用例はあるのかね？

**デフォルトの名無しさん** · 2023/10/08(日) 18:19:11.05

enumのリストで書いてみたわ
rust不慣れだから所々おかしいかも
https://ideone.com/0Ro48L
enum List<T> {
Cons(T, Box<List<T>>),
Nil,
}
impl<T: Copy + PartialOrd> List<T> {
// 略
fn qsort(&self) -> Self {
match self {
List::Nil => List::Nil,
List::Cons(pivot, tail) => {
let (smaller, rest) = tail.partition(|x| *x < *pivot);
smaller.qsort().concat(&rest.qsort().prepend(*pivot))
}
}
}
}
fn main() {
let list = List::<i32>::nil().prepend(4).prepend(8).prepend(8).prepend(3).rev();
list.each(|n| print!("{}", n));println!("");
list.qsort().each(|n| print!("{}", n));println!("");
}

**デフォルトの名無しさん** · 2023/10/08(日) 19:36:48.46

>>449
目的はソートなので、
単方向リストを用いるかベクタを用いるかは実装方法の問題だから些細な話かな。
実用上もベクタで十分だから単方向リストの出番は滅多にないよね。

**デフォルトの名無しさん** · 2023/10/08(日) 20:05:18.10

で、みなさんは単方向リストを使う綺麗だけどクソ遅いコードを並べて何がしたいんですか？

**デフォルトの名無しさん** · 2023/10/08(日) 20:14:55.63

そんなの用途次第だろ
ど素人かよ

**デフォルトの名無しさん** · 2023/10/08(日) 20:19:50.77

>>454
>>439がガベージがどうこう言ってるのについてはどう思う？

**デフォルトの名無しさん** · 2023/10/08(日) 20:59:00.53

>>457
リストはガベージと裏表一体ですが何を問題にしていますか？
リスト化する時にconsセルの割り当てが発生します。
そしてリストから取り出す時に空のconsセルがガベージとして発生します。

**デフォルトの名無しさん** · 2023/10/08(日) 22:12:35.86

赤っ恥オジの言い訳草

**デフォルトの名無しさん** · 2023/10/08(日) 22:57:55.16

入れもの(メモリ)はどのデータ構造でも不可欠だからいずれもゴミが発生するのは仕方ない
ただしリスト(各セル|ノード)に比べてベクタは以下の点で有利
・まとめて確保解放ができる
・next pointer(の容量と処理)が不要
・リニアスキャンが速い
・ランダムインデックスアクセスも速い
そのためRustでもほとんどの用途でベクタが使われリストは少ない

**デフォルトの名無しさん** · 2023/10/08(日) 23:00:08.12

今どきはCPUキャッシュが効くかどうかが問題だから

**デフォルトの名無しさん** · 2023/10/08(日) 23:38:45.90

三連休使ってrustの勉強してるけど、ようやく慣れてきた
某openGLの本をMacでやっててDSL2のインストールに四苦八苦、、、
なんかこいつだけCargo.tomlの書き方が、、、
急ぎ足せずrustのとこにある蟹表示するやつ写経してクレートの追加覚えた
先は長いね、、、
頑張る

**453** · 2023/10/09(月) 01:16:03.20

>>444
>>455
https://ideone.com/Q0LqWM
これでクイックソートになってるはず？
なってなくても笑って許してほしい

**デフォルトの名無しさん** · 2023/10/09(月) 01:21:45.86

>>456
ソート済み配列のソートの計算量が最悪になるqsort実装の活用方法わかんないです
どういうときに有効なんですか？
標準ライブラリのソートアルゴリズム使った方が良いのでは

**デフォルトの名無しさん** · 2023/10/09(月) 01:24:15.18

リストと配列比較してるやつ全員馬鹿です

**デフォルトの名無しさん** · 2023/10/09(月) 13:24:27.74

そんな香具師いたか？

**デフォルトの名無しさん** · 2023/10/09(月) 18:01:30.12

appendできないListってダサい

**デフォルトの名無しさん** · 2023/10/09(月) 18:16:49.87

おるやん！

**デフォルトの名無しさん** · 2023/10/11(水) 15:06:20.59

Rust検索したらゲームの方が出てきてお前じゃないってなって情報収集が捗らない

**デフォルトの名無しさん** · 2023/10/11(水) 15:25:39.99

それで困ったこと今まで一度もないんだがどういう検索でそうなるの？
普段からゲーム関係の検索したりサイト閲覧してたりする？

**デフォルトの名無しさん** · 2023/10/11(水) 16:05:36.62

ゲームの方もやってますね
Rust初心者が簡単なゲーム作ろうとしてまして
(Pythonのpygameでブロック崩し作れる程度)
検索方法がまずいのかもしれませんね
描画したり、画像をはったり、それを縦横動かしたいだけなのですが
icedか？eguiか？みたいなとこまで来てるけど、まだ使い方がよくわからんですね
どこの関数が初期設定の一発実行で、どこの関数が60fpsの毎回実行なのかとか
プロではなく趣味なので言葉選びが毎回曖昧です

**デフォルトの名無しさん** · 2023/10/11(水) 17:42:19.71

なるほどそういう感じなのか

検索ワードに”game”とかも含んでるなら
月並みだけどprogrammingを足してみたりゲームの方にだけ特徴的なワード(surviveやsurvivalとか)を除外してみたりするといいんじゃないかな

**デフォルトの名無しさん** · 2023/10/11(水) 20:52:08.31

>>471
https://arewegameyet.rs/resources/tutorials/
とりあえずこの辺のチュートリアルから選んでやってみては？

**デフォルトの名無しさん** · 2023/10/11(水) 23:18:11.74

>>441
>>430がVec使用だから同等でないという話ならばRustにもリンクリストがあるよ
リンクリストに特化したパターンマッチング構文や結合構文はないけれど
例えばTをCopyせずそのまま使うならば

use std::collections::LinkedList;

fn qsort<T: PartialOrd>(mut list: LinkedList<T>) -> LinkedList<T> {
　if let Some(pivot) = list.pop_front() {
　　let (smaller, rest): (LinkedList<T>, LinkedList<T>) =
　　　list.into_iter().partition(|x| x < &pivot);
　　// concat
　　list = qsort(smaller);
　　list.extend([pivot]);
　　list.extend(qsort(rest));
　}
　list
}

fn main() {
　let list = LinkedList::from([9, 0, 7, 3, 6, 1, 2, 4, 8, 5]);
　println!("{:?}", list);
　println!("{:?}", qsort(list));
}

**デフォルトの名無しさん** · 2023/10/11(水) 23:57:55.35

はあ
馬鹿なんですね

**デフォルトの名無しさん** · 2023/10/12(木) 11:14:39.52

たしかに Rust ゲーム造り方で検索するとゲームの方ばっかり出る罠

**デフォルトの名無しさん** · 2023/10/12(木) 11:17:21.26

>>474
mut 使ったら負け

**デフォルトの名無しさん** · 2023/10/12(木) 12:51:53.05

>>477
そんな表層的なことを問題にするのは愚か

例えばmutを表層的に使っていない>>430はそこで呼び出しているpartitionとconcatそれぞれのなかでmutを使っている
当たり前だがデータを組み立てたり書き換える処理は全てmutにたどりつく

>>474でも表層的にmutを無くしたいだけならば同様にconcat関数を作りその中でmutを使えばいい

**デフォルトの名無しさん** · 2023/10/12(木) 12:52:32.93

>>477
そんな表層的なことを問題にするのは愚か

例えばmutを表層的に使っていない>>430はそこで呼び出しているpartitionとconcatそれぞれのなかでmutを使っている
当たり前だがデータを組み立てたり書き換える処理は全てmutにたどりつく

>>474でも表層的にmutを無くしたいだけならば同様にconcat関数を作りその中でmutを使えばいい

**デフォルトの名無しさん** · 2023/10/12(木) 13:19:12.59

mut使ったら負けとは俺は思わないが断じて表層的なことではない
本質的に重要な違いだからこそRustでは明確に区別してるわけなので
それにconcatもpartitionもmut使ってない

**デフォルトの名無しさん** · 2023/10/12(木) 13:31:42.25

単方向リストと両方向リストの区別もついていない馬鹿だからしょうがないね

**デフォルトの名無しさん** · 2023/10/12(木) 14:04:37.89

標準ライブラリのソース見たら
concatもpartitionもmut使ってるな
最終的にあらゆるmutになるのか

**デフォルトの名無しさん** · 2023/10/12(木) 14:35:37.70

すべてがmutになる森鴎外

**デフォルトの名無しさん** · 2023/10/12(木) 14:56:18.33

「ボクの考えた最強の汚コードを批判するな！」

**デフォルトの名無しさん** · 2023/10/12(木) 14:58:53.27

>>482
ネタじゃなくマジで言ってるならRustは辞めとけ
絶望的に向いてない

**デフォルトの名無しさん** · 2023/10/12(木) 15:06:20.95

複オジが劣化したのだろうか
それとも複オジ劣化版が新たに出現したのだろうか

**デフォルトの名無しさん** · 2023/10/12(木) 15:24:09.95

mutを使わずにできることは読み出しとムーブとコピーだけ

**453** · 2023/10/12(木) 19:51:44.10

今度はDartで書いてみた
3.0でパターンマッチがちょっと強化されたらしい？
3.0新登場のスイッチ式の=>の右側には式だけしか書けない？
dartにはそもそもpartitionはない？
というわけで>>445のHaskell方式で書いてみた（程遠いけど）

List qsort(List list) {
return switch (list) {
[] => [],
[var pivot, ...var rest] => qsort(rest.where((x) => x < pivot).toList()) + [pivot] + qsort(rest.where((x) => pivot <= x).toList())
};
}

**453** · 2023/10/12(木) 23:01:31.11

こういう書き方もできた
こっちのほうが雰囲気出てるかな？

List qsort(List list) {
return switch (list) {
[] => [],
[var x, ...var xs] => qsort([for (var y in xs) if (y < x) y]) + [x] + qsort([for (var y in xs) if (x <= y) y])
};
}

**デフォルトの名無しさん** · 2023/10/13(金) 08:06:18.09

>>482
RustはCと同じ高速で動作する手続き型言語だから少なくとも最下層はmutが基本になる
たとえばイテレータからVecへcollectする場合
特殊ケースはunsafe最適化
一般ケースはlet mut vec = Vec::new();してextend

その一方でプログラミングする時はその最下層を意識しなくても知らなくてもいい
mutを必要としないiter.collect()と抽象的に書ける

**デフォルトの名無しさん** · 2023/10/13(金) 08:24:52.90

最強Rust始めたわい
mutの話が出てるから質問
シャドーイングっていう性質使えばmutなくても書けそうな気がしてる(まだ書けてない)んだけど
シャドーイングしたときと、mutではメモリの動き何か変わるのかな？と

シャドーイング
let z = x + y;
その後z使って処理
let z = x - y; // z宣言して前回のz上書き
その後z使って処理

**デフォルトの名無しさん** · 2023/10/13(金) 12:19:34.60

>>491
それを1億行書いたとする。たぶんスタック溢れるんじゃね？

**デフォルトの名無しさん** · 2023/10/13(金) 12:43:08.68

1億行書く意味が分からんが
そんな問題ではないだろw

**デフォルトの名無しさん** · 2023/10/13(金) 18:31:34.80

ドロップしないの？

**デフォルトの名無しさん** · 2023/10/13(金) 19:31:02.96

ちょっと前にJSONシリアライズでの最適化の話出たけど
goは空気感が不安になるよな

rust->システムプログラミングよりの言語で、速度やらいろいろうるさそうなやつが
集まってて、そんなやつらの作るライブラリだからパフォーマンスとか心配しなくてよさそう

C#->.NET開発チームが毎年長文ブログでがんばってるアピール

go->言語機能とかほぼ完成しちゃってるんだろうが
アピールもない、この空気感

**デフォルトの名無しさん** · 2023/10/13(金) 19:35:26.71

https://devblogs.microsoft.com/dotnet/performance-improvements-in-net-8/
今年の.netのパフォーマンス改善はこれ

goはシンプル言語で標準ライブラリも最小限だから
もうあまりやることないのか?

**デフォルトの名無しさん** · 2023/10/14(土) 14:19:51.05

>>491
不使用領域は再利用されるから単純な順次処理ならシャドーイングで十分

mutが欲しくなる理由の１つは繰り返し処理だな（長さ不定のリストの集計とか）
関数型言語みたいに再帰使えばmutなしでも何とかなるけど慣れないとややこしい

あとは全部作り直すのが不合理なデータの部分的な書き換えでもmut使いたい

**デフォルトの名無しさん** · 2023/10/14(土) 19:31:37.47

for文で値を変えるカウンタとかフラグとかもmutじゃないと書けないな。
まぁ for 文より iter で書けという一派も多いかもしれんけど。

**デフォルトの名無しさん** · 2023/10/14(土) 19:57:12.00

モジュールの内部では (性能上の理由で) mut を使っても、
外側に見せるインターフェイスは
(不自然ではない範囲で) mut を避けるのは自然な方針だと思う。

**デフォルトの名無しさん** · 2023/10/15(日) 09:39:38.68

Cで書いたプログラムを Rustで書いたらこうなります
っていうのをひたすら集めた本がほしい

**デフォルトの名無しさん** · 2023/10/15(日) 10:09:58.67

全銀システムでJavaの信頼が失墜した今こそrustのチャンスだな

**デフォルトの名無しさん** · 2023/10/15(日) 11:00:17.07

全銀はまだCOBOLだろ
ほんといつもいつも嘘ばっかりだな

**デフォルトの名無しさん** · 2023/10/16(月) 10:19:13.28

>>500
似たような動機で描かれた本とかブログは観たことあるけど
Rustっぽくないコードばっかりでうんざりする面もある

**デフォルトの名無しさん** · 2023/10/16(月) 10:21:08.50

全銀協のフォーマットって今も変わってないんだろうけど
半角カタカナだらけでRustで扱うのは大変かも知れないね

**デフォルトの名無しさん** · 2023/10/16(月) 10:35:49.58

扱う文字については適当なライブラリを整備すればそんなに問題にならなさそうに思うが

**デフォルトの名無しさん** · 2023/10/16(月) 11:26:02.88

>>505
＞扱う文字については適当なライブラリを整備すれば

外字ばかりとかでそれが大変なんじゃないの？知らんけど

**デフォルトの名無しさん** · 2023/10/16(月) 12:22:46.59

半角しかないのに外字とは

**デフォルトの名無しさん** · 2023/10/16(月) 13:30:20.84

今のうちに Rust でﾊﾝｶｸｶﾀｶﾅ自由自在な crate 造っておけば
将来ライセンス料でｼｯﾎﾟﾘ儲かりますか？

**デフォルトの名無しさん** · 2023/10/17(火) 11:40:48.89

Rustに慣れるとCのifで()付け忘れたわ

**デフォルトの名無しさん** · 2023/10/19(木) 14:52:32.31

Vec の iter() と into_iter() の違いは？

**デフォルトの名無しさん** · 2023/10/19(木) 14:53:04.92

Vec の iter() と into_iter() の違いは？

**デフォルトの名無しさん** · 2023/10/19(木) 15:12:31.11

>>510
引数に着目するといい。
into_iter はムーブするが iter は借用する。

**デフォルトの名無しさん** · 2023/10/20(金) 01:20:11.96

>>500
その発想がすでに間違ってる
根本が違うから同じようには書けない

**デフォルトの名無しさん** · 2023/10/20(金) 06:13:09.90

Cで安全に書いたときと同じ生成コードにはなるけどRustでは抽象度の高い表現をするからなあ
例えばメモリのある範囲の領域を順に読み取る(書き込む)というC言語だとポインタをインクリメントしていくだけの場合でも
Rustだとまずメモリの領域をスライスという安全な抽象表現で扱い可変性もライフタイムも付随してスライスが指す元の安全に確保されている領域(配列やベクタなど)も必須というところからスタート
そのうえでスライスのイテレータにより必ずその範囲内のみを順に安全に指し示す参照(または可変参照)が次々と得られて順に読み取る(書き込む)ことが達成される
さらにRustではこれをfor文ではなく抽象度の高いイテレータメソッドチェーンで書くことも多いからCコードとの対応はますます難しくなるね

**デフォルトの名無しさん** · 2023/10/20(金) 06:56:18.50

unsafe {
Rust で C ポインタやりたいなら
let p = *mut hoge;
p+=1;
std::slice::from_raw_part(p. 1)[0] = hage;
}

**デフォルトの名無しさん** · 2023/10/20(金) 09:04:11.56

>>513
同じように書けないからこそ対比したものが欲しいと言う話だろうに

**デフォルトの名無しさん** · 2023/10/20(金) 09:27:32.12

>>516
クソでたらめだが真面目に実装するとマジ面倒
>>515 方式だと
#[derive(Debug)]
struct Hoge {a: u8, b: u8, c: u8}
impl Hoge {
pub fn new(a: u8, b: u8, c: u8) -> Self {Hoge{a, b, c}}
}

fn main() {
let hoge: Vec<Hoge> = vec![Hoge::new(1, 2, 3), Hoge::new(4, 5, 6), Hoge::new(7, 8, 9)];
println!("{:?}", hoge);
let mut p = &hoge[0] as *const Hoge as usize;
p += 2 * std::mem::size_of::<Hoge>();
unsafe { std::slice::from_raw_parts_mut(p as *mut Hoge, 1)[0] = Hoge::new(8, 3, 1); }
println!("{:?}", hoge);
}
>>514 方式だと
let p = &hoge[0] as *const Hoge as *mut Hoge;
unsafe { std::slice::from_raw_parts_mut(p, 3)[2] = Hoge::new(8, 3, 1); }
でちょっとマシになるくらい

**デフォルトの名無しさん** · 2023/10/20(金) 09:40:03.83

マクロでウヒヒ

**デフォルトの名無しさん** · 2023/10/20(金) 11:03:08.72

近代的な言語の仕組みってのは大規模なプログラムをどうやってまとめるかという方向で進歩してるから
小さなサンプルで比較しても設計理念は身につかんのだ。

**デフォルトの名無しさん** · 2023/10/20(金) 13:13:02.21

設計理念を身につける話なんて誰もしとらんだろw

**デフォルトの名無しさん** · 2023/10/20(金) 15:12:25.73

してないから問題だと述べてるんだが。
俺が学生のときに英語の長文の全ての単語の横に(単語ごとに！)日本語の単語を書いてたやつがいたことを思い出したわ。
本に載る程度の規模(ひとつあたり数ページくらい？)のプログラムを対比するってのはそういうことだよ。
言語の設計理念に基づいた構造こそが重要で、構造を論じるほどの規模にならないならたいした違いは見えてこない。

**デフォルトの名無しさん** · 2023/10/20(金) 16:07:06.67

CでもPythonでもRustでも全部の行にあほみたいなコメント描く香具師はうざいけど
Rustのcrateでdocsにcomment100%達成するためにはアホなコメント描かされてダサい設計思想だと思う

**デフォルトの名無しさん** · 2023/10/20(金) 16:34:14.75

>>521
日本語の設計理念wが身についてないみたいだなw

**デフォルトの名無しさん** · 2023/10/20(金) 17:24:55.57

unsafe使うならCでいいんだよなw

**デフォルトの名無しさん** · 2023/10/20(金) 19:40:13.76

>>524
それは違う
unsafeを使ってsafeなインターフェースを提供する部分だけ人間が安全性を保証すれば
それ以外の部分はすべてRustが安全性を保証してくれる
その方針でRustの標準ライブラリやunsafeを用いる一部クレートが作られている

**デフォルトの名無しさん** · 2023/10/20(金) 20:06:04.22

>>525
もちろん品質が保証されてるライブラリは使うよ
現時点でここまでライブラリが揃ってるから自前でunsafeを書く必要は感じない

**デフォルトの名無しさん** · 2023/10/21(土) 12:29:35.28

関数型最強(キリω
ですねわかります

**デフォルトの名無しさん** · 2023/10/21(土) 21:43:10.75

Linuxでも、結局のところ「C言語でいいじゃん」という結論になりそうよね
リーヌスもなんかやっぱRustはなぁ・・・ってトーンダウンしてきてるし

**デフォルトの名無しさん** · 2023/10/22(日) 00:35:28.61

>>528
カーネルなんて低レイヤーのポインタ操作とかビット演算しかしないからな

**デフォルトの名無しさん** · 2023/10/22(日) 00:50:06.85

Linux カーネルの中にだって Rust が適している場所も
あるといえば有るだろうけど現時点でそれなりに検証が済んで
安定して動いているものを「置き換え」するほどではないだろうな。

適しているからといって各部を別の言語で書いたりすると
接続箇所で面倒になったりもするし。

**デフォルトの名無しさん** · 2023/10/22(日) 11:49:16.17

カーネルで流行らないならもう流行るところないんじゃ…

**デフォルトの名無しさん** · 2023/10/22(日) 19:50:36.55

どの言語からどの言語への場合でも既に動いているものを別の言語に移植するだけだとコストがかかる
それでもスクリプト言語からRustへ置き換えるなら実行速度と省メモリの効果がコストを上回りやすいためよく行われている

一方でC/C++からRustへ換えても実行速度と省メモリの効果はない
だからシステム設計を変えるなど大きな更改タイミングでRust化することが多い
特にマイクロサービス化されているものは個別に更改できるためシステム全体の一部Rust化に向いている

最も向いておらずハードル高いのがモノリシックになっているOSカーネル
その場合でも分離されているデバイスドライバは最近のデバイス複雑化と更新対応の多さからもRust化が向いているため進んでいる

**デフォルトの名無しさん** · 2023/10/22(日) 19:58:13.61

>>531
もうちょっと上位のレイヤーなら良いと思うけどね
Cでバッファオーバーランするようなプログラムって
結局Rustでもunsafe使わざる終えないような処理なので

**デフォルトの名無しさん** · 2023/10/22(日) 21:57:00.47

構造体をキャストするものでも、hoge_storage_t みたいに最大サイズを規定するパターンと
char foo[0]; を積極的に利用するパターンと真っ二つにわかれるしねぇ
後者はRustでどうすんだろ

**デフォルトの名無しさん** · 2023/10/22(日) 22:15:56.13

結局構造体もパケットのバイト列にパックするからね
その時unsafeを使うことになる

**デフォルトの名無しさん** · 2023/10/22(日) 22:45:30.49

構造体はunsafeいらん
タグ無し共用体はunsafe

**デフォルトの名無しさん** · 2023/10/22(日) 23:15:20.26

流行るから価値ある、流行らないから価値なしって評価基準はジャパニーズカルチャーのガラパゴス

**デフォルトの名無しさん** · 2023/10/22(日) 23:23:05.72

>>534
後者も普通に表現できるしCとのFFIも可能

**デフォルトの名無しさん** · 2023/10/22(日) 23:28:57.61

Redox（https://www.redox-os.org/）みたいなRust製のUnix系OSプロジェクトならもうあるし
無理してLinuxに食い込む必要はないと思うんだけどLinux開発者でもRust使いたい人はいるんでしょ
Linuxは一部のモジュールがRust製になる程度で中核は最後までCで通すと思う
というかRustで置き換えるなら名前変えてほしい

**デフォルトの名無しさん** · 2023/10/23(月) 00:13:38.68

>>539
まあカーネルで使ってる基本的なデータ構造(赤黒木、ハッシュテーブル、双方向リスト)
kref(リファレンスカウント)などは外せないからね
無理に組み合わせるとかえってキツい気がする

**デフォルトの名無しさん** · 2023/10/23(月) 05:58:05.37

>>533
実際にはCでもバッファオーバーランしないからRustでは、unsafe必要ないでしょ