Rust part25

**デフォルトの名無しさん** · 2024/07/31(水) 00:46:26.17

公式
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 part24
https://mevius.5ch.net/test/read.cgi/tech/1716759686/

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

**デフォルトの名無しさん** · 2024/08/16(金) 14:28:26.26

>>249
それだけならできるよ

**デフォルトの名無しさん** · 2024/08/16(金) 14:28:39.39

>>248
こんなのZigならcomptime付ければ解決だろ

**デフォルトの名無しさん** · 2024/08/16(金) 14:43:23.29

>>252
グローバル変数、すなわち、タスクやスレッドが排他制御して安全に扱える話をしているところで、comptime？？

**デフォルトの名無しさん** · 2024/08/16(金) 15:12:00.16

Rustでもコンパイル時に作れるものは簡単にグローバルな定数にできる
問題なのは HashMap みたいなヒープを使うもので、LazyLockが必要になるのもほぼこのようなもののためだと思う
初期化した以降は不変な操作しかしない定数のような使い方をする場合でもMutexが必要なのは仕方ないという感じなのか

**デフォルトの名無しさん** · 2024/08/16(金) 15:14:27.12

>>254
すまんこれは勘違い
不変ならLazyLockだけで足りそうだ

**デフォルトの名無しさん** · 2024/08/16(金) 15:20:06.84

>>254
読み出しだけならMutexは不要

static READ_ONLY: LazyLock<Vec<i32>> = LazyLock::new(|| vec![1, 2, 3]);
assert_eq!(*READ_ONLY, [1, 2, 3]);

**デフォルトの名無しさん** · 2024/08/16(金) 17:40:52.16

LazyLockは油断するとデッドロックの要因になりそうだな
初期化が単純なうちはいいけど

**デフォルトの名無しさん** · 2024/08/16(金) 18:31:48.52

LazyLockは排他制御をRust1.0からあるstd::sys::Onceに任せている
その部分はOS依存だが例えばLinuxなどの場合、
未初期化か初期化中か初期化済かなどの状態を示すatomic整数で管理している
そして初期化実行は最初のスレッドのみで起きてそこでの競合は起きないことを保証している

一方で、あるLazyLock利用変数Aの初期化関数で資源Xを利用している時に、
資源Xをロックしたままの状態でその変数Aに最初にアクセスすればデッドロックとなりうる
これは一般的な話と同じなので今回特有の問題ではない
いわゆる資源ロック優先順序付けをA＞Xとするだけで回避できる

ちなみに、LazyLock初期化後のT読み出し追加コストはその状態整数を見ることだけになり、
「初期化済」状態でずっと変わらないため分岐予測もおそらくずっと成功
そのためコストは気にせずに使える

**デフォルトの名無しさん** · 2024/08/17(土) 01:30:12.83

小さなTauri v1アプリをv2 RCにアップグレードしたら
リリースビルドのファイルサイズが2倍になったんだが

ファイルサイズ小さいのが売りじゃなかったのか？
6MBが12MBになったぞ

**デフォルトの名無しさん** · 2024/08/17(土) 13:50:23.56

TauriのことはJavaScript/TypeScriptスレでやれよ

**デフォルトの名無しさん** · 2024/08/17(土) 14:00:58.13

>>260
Rust のバイナリにリンクする部分は Rust の話じゃね？

**デフォルトの名無しさん** · 2024/08/17(土) 14:22:14.92

もしRustやRustの汎用ライブラリのバージョンを変えてバイナリサイズが増えたのならRustの話なのでここでやればいい
しかしアプリのバージョンを変えてサイズが増えたのだからアプリの話であってRustスレで語ることはなにもない

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

もしかしてTauriがRustのライブラリだと知らない人？

**デフォルトの名無しさん** · 2024/08/17(土) 14:30:56.85

Rustに問題があると読めそうな文章なら手段を選ばずに排除する人

**デフォルトの名無しさん** · 2024/08/17(土) 15:23:05.55

rustコードをコンパイルしたwasmバイナリが増えたってこと？

**デフォルトの名無しさん** · 2024/08/17(土) 15:45:50.91

>>265
Tauriは各OSの他のアプリと同様に各ネイティブで動作するためwasmは関係ない
TauriはWebブラウザと同じ立場なので同様にJavaScriptとwasmが使えるが
そこでのwasmのコードはどのWebブラウザやTauriからも独立していて関係がない

**デフォルトの名無しさん** · 2024/08/17(土) 15:53:49.31

tauriはネイティブ部分とwebviewでプロセス間通信させて動いてるんだっけか

**デフォルトの名無しさん** · 2024/08/17(土) 15:55:16.69

tauri は基本的にはその環境にあるウェブコントロールを使う。
生成される実行ファイルにリンクされるのは外部のウェブコントロールとの橋渡しに過ぎないからそんなに大きくないはずなのに……なんで？
っていう話。

**デフォルトの名無しさん** · 2024/08/17(土) 16:01:00.63

tauriは糞

**デフォルトの名無しさん** · 2024/08/17(土) 16:05:04.51

TauriはGUI以外のロジックをTS/JS側で書くかRust側で書くかみたいな話もあるよな

**デフォルトの名無しさん** · 2024/08/17(土) 16:32:34.13

>>268
ウェブコントロールなんて分かりづらい言葉を使わずにWebViewと言ってくれ

**デフォルトの名無しさん** · 2024/08/17(土) 16:36:42.10

>>261
numpyのバージョン上げたら動かなくなったなどと言ってpythonやnumpyのスレではなくCのスレに乗り込んでるようなもんだぞ

**デフォルトの名無しさん** · 2024/08/17(土) 16:47:26.11

https://tauri.app/v1/guides/building/app-size/
Tauri v1のページだけど、ここに書いてある手法自体はたぶんv2でも有効だから比較調査してみるとよし

**デフォルトの名無しさん** · 2024/08/17(土) 16:50:47.17

>>272
TauriはRust部分もちゃんと使うフレームワークだぞ
アプリとして必要な処理をRustで書いてそれをJS/TSから呼んだり、データをRust側とフロント側で受け渡したりできる
ほぼTS/JSだけで書くこともできるけど、逆にUI以外のロジックはRustをメインに書くといった使い方もできる

実際のプロジェクトでどう使われてるのかは自分も知らないけど

**デフォルトの名無しさん** · 2024/08/17(土) 16:53:38.16

一般的にバイナリサイズは動的リンクの共有ライブラリの使用が多ければその分だけ小さくなり逆は大きくなる
だからバイナリサイズとプログラム全体のサイズは関係がない
そのver.1とver.2でバイナリに含まれていないライブラリの変化を調べて違いを投稿してください

**デフォルトの名無しさん** · 2024/08/17(土) 16:55:44.18

ビルドはCargoを使うし、「生成されたバイナリが大きい」みたいな問題もRustのカテゴリーで良い思う
フロント側に使ってるReactやVueについての質問ならJS/TSスレで聞くべきだけど

**デフォルトの名無しさん** · 2024/08/17(土) 17:04:38.57

>「生成されたバイナリが大きい」みたいな問題もRustのカテゴリーで良い思う
意味わからんわwww

**デフォルトの名無しさん** · 2024/08/17(土) 17:19:21.92

解決するかはともかく、質問先としてはJavascriptスレよりはRustスレの方が回答してもらえる可能性が高いじゃん
公式のリポジトリのissue見ろって話になるかもしれないけど

**デフォルトの名無しさん** · 2024/08/17(土) 17:24:48.12

>>259のレスを見落としてるせいでバイナリサイズの話が唐突な話に見えてるのだったらすまん

**デフォルトの名無しさん** · 2024/08/17(土) 17:35:27.19

まずは動的リンクしているライブラリの変化を調べなよ
例えばもしそれが減ってるなら
依存していた外部ライブラリの不自由さから解放されて状況が良くなっている話の可能性もある

**デフォルトの名無しさん** · 2024/08/17(土) 17:40:36.43

普通にissueで報告したらええやん
Rustのバージョンもビルド方法もビルドオプションも変えてないんやろ？

**デフォルトの名無しさん** · 2024/08/17(土) 17:47:51.42

>>279
むしろ>>259のレスが総スカンくらう理由だぞ
環境情報も無く自分で調べたり切り分けをした痕跡が全く見えないから

**デフォルトの名無しさん** · 2024/08/17(土) 18:16:28.63

試しにTauri v1とv2-RCのscaffold同士で比較してみる

共にWindows 11のrustc 1.80.1 (x86_64-pc-windows-msvc)で
フロントエンドはnpm/Vanilla/TypeScriptを選択する

# v1
cargo create-tauri-app
npm run tauri build

src-tauri\target\release\v1-test.exe 5,271 KB

# v2
cargo create-tauri-app --rc
npm run tauri build

src-tauri\target\release\v2rc-test.exe 10,076 KB

やっぱりv2の方が2倍ぐらい大きいんじゃないの？

**デフォルトの名無しさん** · 2024/08/17(土) 18:41:27.25

今も小さい方のバイナリも生成できていることから
Rustとは無関係な話であると切り分けできてよかったね

**デフォルトの名無しさん** · 2024/08/17(土) 18:46:42.10

tauriのことはjavascriptの範囲 (ｷﾘｯ)
って書いてたやつが的外れなのは変わらない

**デフォルトの名無しさん** · 2024/08/17(土) 19:34:46.59

全部issueで聞くべきなのでこのスレは存在意義がないんだよね

**デフォルトの名無しさん** · 2024/08/17(土) 21:17:58.40

tauri2で
cargo tauri android init
cargo tauri android dev
ってやったらエミュレーターでスプラッシュ画面までは出るんだけど
コンテンツのところで↓みたいなエラーになるんだけど試した人いる？
error sending request for url
(http://127.0.01:1430/)

**デフォルトの名無しさん** · 2024/08/17(土) 21:22:36.94

>>286
アドバイスしても反応ないからもういいのだろう

**デフォルトの名無しさん** · 2024/08/17(土) 21:26:19.66

Tauri v1もv2も動的リンクしているライブラリはいっしょだよ

**デフォルトの名無しさん** · 2024/08/17(土) 21:28:39.15

Rustの話ならともかく
Rust製の個別のアプリの話は知ってる人がたまたまいたらラッキー
他の言語のスレでも同じ

**デフォルトの名無しさん** · 2024/08/17(土) 22:26:04.77

>>290
>他の言語のスレでも同じ
同じじゃないでしょ
君はvscodeがTypeScript製だからといって
バージョンアップで問題が発生したら
TypeScriptスレに書き込みするのかい？

Tauriでもバックエンドやプラグイン開発の話ならわかるんだけどさ

**デフォルトの名無しさん** · 2024/08/17(土) 22:55:19.71

Rust言語自体の話以外は
もし誰からの反応が無くても当然だから
反応が来ることをアテにするな、という意味だぞ

一方でTauriはRustのクレイトの一つだから
ここで話題にすること自体は全く問題がない
version 2.0の人柱なんてレアな話に誰も反応がなくて当たり前

**デフォルトの名無しさん** · 2024/08/17(土) 23:48:49.41

WebでのWasmバイナリなら各利用者ブラウザによるリアルタイムのダウンロードとなりサイズを気にするけど、
WebブラウザやTauriアプリのバイナリのサイズはどうでもいいって立場。

**デフォルトの名無しさん** · 2024/08/18(日) 01:26:09.33

倍といっても所詮は 5MB 増しでしかないならたいしたことではないとは言えるが……。
でも益なく増えてるのなら改善が望ましいのは確かだし、益があるならどんな益なのか知っておきたくもあるよ。

**デフォルトの名無しさん** · 2024/08/18(日) 02:36:20.00

複おじに振り回されっ放しのバカばっか

**デフォルトの名無しさん** · 2024/08/18(日) 08:12:37.69

>>283
そのexeは解凍できないん？中にjs/ts要素と一緒にリンクライブラリが入っとるだろうからそれ比較すればと思った

**デフォルトの名無しさん** · 2024/08/18(日) 13:27:09.96

tauri って新しいので servo 使うようになるんじゃなかったっけ？
それでバイナリサイズ増えてるんじゃ？

servo 使うようになるのは tauri 自身のコアコンセプト否定してる感じがして謎いが。

**デフォルトの名無しさん** · 2024/08/18(日) 14:43:03.93

こいつ前からずっと1人でWebView推してるおじさんでしょ
変なのが居着いちゃったな

**デフォルトの名無しさん** · 2024/08/18(日) 15:04:00.99

tauriのスレはちゃんとあるからそっちいけば？
【Electron】ﾊｲﾌﾞﾘｯﾄﾞｱﾌﾟﾘ開発総合【Cordova】 [無断転載禁止]©2ch.net
https://mevius.5ch.net/test/read.cgi/tech/1498985597/

**デフォルトの名無しさん** · 2024/08/18(日) 23:46:45.47

Tauri自体はcrates.ioにもある普通のRustのcrateで普通にRustのコードを書いてcargoで開発するものだから
それらcrateやRustコードやcargoの話はここでやっても構わない
Rust以外の話はこのスレの対象外
多少の脱線に限れば他の話題と同様に許容範囲

**デフォルトの名無しさん** · 2024/08/19(月) 00:46:11.66

許容範囲が広いなら、話題に反応しない自由も大きくなってしまう
すべての話題・情報をノーカットで処理すべきと思う人は
反応しない自由は容認できないだろう
知らんけど

**デフォルトの名無しさん** · 2024/08/19(月) 03:37:53.96

「Rustは良い」の結論に結びつかない話題はスレチです

**デフォルトの名無しさん** · 2024/08/19(月) 08:28:41.87

君らは
僕が選んだ（rust）は凄い
でしょ？
iPhone絶対正義やってる人と一緒

**デフォルトの名無しさん** · 2024/08/19(月) 08:33:51.85

>>303
個人的にはZig至上派でRustはC++よりマシという思いでやってる

**デフォルトの名無しさん** · 2024/08/19(月) 11:20:06.32

Xで、Hideyuki Tanakaは、Rust信者の典型的な説を言ってると思うけど、
ほとんど同意できない。

**デフォルトの名無しさん** · 2024/08/19(月) 11:57:13.33

無課金という選択がすごい
二刀流でも三刀流でもできるのは課金しないからだ
有限のリソースがといって宗教を一つしか選べない人達が戦争を始める

**デフォルトの名無しさん** · 2024/08/19(月) 12:14:50.01

Rustはすごい
だからRustスレにいる俺はすごい
俺が知らない話題がRustスレにあると自分がすごくない気がするから許せない

**デフォルトの名無しさん** · 2024/08/19(月) 15:34:27.05

RustよりZigのほうがすごい

**デフォルトの名無しさん** · 2024/08/19(月) 16:46:33.01

米国国防総省のDARPA、CからRustへのコード変換を自動化する「TRACTOR」プログラムを開始
https://atmarkit.itmedia.co.jp/ait/spv/2408/14/news045.html

**デフォルトの名無しさん** · 2024/08/19(月) 17:48:38.35

あ、zig要らなくなったな

**デフォルトの名無しさん** · 2024/08/19(月) 18:09:59.20

C/C++からRustへの変換こそ自然言語処理技術を使えばいいのに

**デフォルトの名無しさん** · 2024/08/19(月) 18:18:10.95

プログラムって、計画とかそっちの意味のプログラムかい

**デフォルトの名無しさん** · 2024/08/19(月) 22:28:35.76

>>304
1.0になるまで黙ってろ

**デフォルトの名無しさん** · 2024/08/19(月) 23:09:53.72

Cがやるような低レイヤ側だったらZigの方がシンプルだと思う
自分は式や型の表現力の高さの点でRustが好きだけど、これが強みになるのってより上位のレイヤーな気がする
RustでFFI用のC互換のコードを書こうとするとRustの管理を回避するためのコードが必要で、それが煩雑になりがち (基本的にunsafeが必要だったり、オブジェクトをCに渡すために Box から into_raw するのが必要だったり)

**デフォルトの名無しさん** · 2024/08/19(月) 23:37:07.40

>>314
低レイヤも全てRustで書くことに支障はない
Cと連携する場合でもFFI部分はパターン化していてすぐ書けるから困らない

**デフォルトの名無しさん** · 2024/08/19(月) 23:47:50.44

低レイヤと高レイヤを別言語にしたら接続箇所がいくらか煩雑になるが
全部 Rust にすれば低レイヤ部分は unsafe ばっかりで Rust の良さが活きてこない。
低レイヤで便利な言語は高レイヤでは抽象度の不足などで使い勝手が悪い。

全部が楽ってことはないので煩雑さをどこに持ってくるかの問題じゃないの。
ある程度は煩雑な部分があるのは仕方がないとして仕方ない部分を (快適とは言えずとも) 及第点に出来てれば十分に良い言語でしょ。

**デフォルトの名無しさん** · 2024/08/19(月) 23:57:37.03

>>316
unsafeばっかりになる、が妄想思い込み

**デフォルトの名無しさん** · 2024/08/20(火) 09:21:19.12

変なことやることになった時にはRustのアロケーター指定面倒でZigはその辺楽だなってなる

**デフォルトの名無しさん** · 2024/08/20(火) 10:15:16.56

同一言語内で失敗例と成功例があるのは客観的事実だから
「言語を変えたら成功した」という因果関係は妄想と言われても仕方ない

**デフォルトの名無しさん** · 2024/08/20(火) 10:46:28.17

>>317
理想的に設計できればいいけど現実はそうではない。
ホスト環境ありの高レイヤで unsafe まみれにならないのは標準ライブラリが慎重に設計されてるからで、標準の設計と同じくらいに上手くやれる人は稀。
そりゃカスなプログラマだからだろって言われればそのとおりだがだいたいの現場はカスなもんなんだよ。

**デフォルトの名無しさん** · 2024/08/20(火) 12:23:22.63

標準ライブラリのunsafeノウハウて、まとまっていたっけ？

**デフォルトの名無しさん** · 2024/08/20(火) 14:02:00.57

うまくまとまってしまうとunsafeじゃなくても良くなる

**デフォルトの名無しさん** · 2024/08/20(火) 17:21:26.26

unsafeまみれにならないのは、Rustが苦手な良いアルゴリズムを知らない人。
そういう人が圧倒的に多いので多数派意見になっているだけ。

**デフォルトの名無しさん** · 2024/08/20(火) 18:19:19.40

unsafeまみれにならないように工夫すれば、unsafeまみれにならない
だからこそ、unsafeまみれにならないように工夫すべきである、と私は思いますね

**デフォルトの名無しさん** · 2024/08/20(火) 18:55:32.33

CやZigで作ったあとにAIで安心安全なRustに変換でいいんじゃね？
あ、それだとRust必要ないかも

**デフォルトの名無しさん** · 2024/08/20(火) 20:54:37.99

いうてRustはまだまだ発展途上でしょ。このケースはunsafeなしでも安全性を推論可能でコンパイルできる。みたいなケースは今後もどんどん増えていくんじゃないの？

**デフォルトの名無しさん** · 2024/08/20(火) 21:23:27.30

実際unsafeの安全性を証明するための研究も結構行われてるしな
Cみたいになんでもありだとかなり厳しいけど
Rustならunsafeといってもそれなりに制約があって研究としてもやりやすいらしい

**デフォルトの名無しさん** · 2024/08/20(火) 21:28:14.77

こゆことなんよ
https://x.com/atalocke/status/1599076649341194242

Zig is the new C.

Rust is the new C++.

Go is the new Java.

WASM is the new JS.

**デフォルトの名無しさん** · 2024/08/20(火) 21:53:19.45

>>325
変換して生成させるかゼロから指示して生成させるかどちらが効率的かは意見が分かれるが、

**デフォルトの名無しさん** · 2024/08/20(火) 21:54:44.32

一般的にAIに生成させる場合は少なくとも以下の3つが必須とされる
(1) AIが安全なコードを生成できること
(2) 生成物の安全性を人間が確認できること
(3) 安全性とは別にAIのミスや暴走を食い止めるため人間がレビュー確認できること

**デフォルトの名無しさん** · 2024/08/20(火) 21:55:11.06

(1)は生成AIにとってかなり難しく様々な安全なパターンの学習をさせても間違いが起きるうる
生成先がRustならばコンパイルが通る条件など指定で間違いを防げる
(2)も生成先がC/C++やマシン語だと難関だがRustならばコンパイラに任せられる
(3)は(1)(2)によりRustを読める人材が今後も必要になることを意味する
さらに核心部分はAIに任せず人間が書くことで対AIの安全性を確保する考え方もある
したがってRustを書ける人材も必要とされる

**デフォルトの名無しさん** · 2024/08/20(火) 22:02:42.33

生成AIは既存物の変換処理は苦手でしょ
自然言語処理でやれないの？

**デフォルトの名無しさん** · 2024/08/20(火) 22:26:06.21

>>325のようにCで書いてAIにRustへ変換させることが出来るようになったと仮定しても
Rustを直接書いて開発できる人と比べて不利と思われる
さらに保守性の面では二重管理となってしまう

**デフォルトの名無しさん** · 2024/08/20(火) 22:41:15.58

すでにCで書かれてるものをRustで書きなおすのが時間と人材の無駄なのであって、イチから作るのであればRustでいいのでは…？

**デフォルトの名無しさん** · 2024/08/20(火) 22:46:48.76

>>323
[補足]
「Rustでは上手く書けないアルゴリズム」を知らない人は、そもそも、
unsafeまみれにならない、ということが言いたかった。
「Rustでは上手く書けないアルゴリズム」を知らない人が圧倒的に多いので多数派意見になっている。

**デフォルトの名無しさん** · 2024/08/20(火) 22:49:18.72

>>335
[さらに補足]
・C言語は、どんなアルゴリズムでも(分け隔てなく効率良く)書ける。
・Rustは、unsafeの範囲内のでは限られたアルゴリズムだけが効率よく書け、
　それ以外のアルゴリズムは、効率が落ちてしまう。

**デフォルトの名無しさん** · 2024/08/20(火) 23:44:10.92

CPUから見たメモリは何でも自由にできるunsafeな存在だからさ
一番下ではunsafeな操作が必須な存在となることは当たり前さ
そのためunsafeだらけのRust標準ライブラリがそこをカバーしているのさ
だから普通のプログラマーはunsafeを使わずにプログラミングできるのさ

**デフォルトの名無しさん** · 2024/08/21(水) 00:04:15.03

過去一キショい語尾のキャラ作り

**デフォルトの名無しさん** · 2024/08/21(水) 03:19:43.62

>>336
最初からそう言えば良いのにωωω=2πf

**デフォルトの名無しさん** · 2024/08/21(水) 03:32:22.83

>>336
Cで安全に書けるならば
Rustでもそれをライブラリとして提供できる
利用者にとってその中身がunsafeかどうかは気にする必要がない
例えばRustの標準ライブラリは何千ものunsafeブロックが含まれている

**デフォルトの名無しさん** · 2024/08/21(水) 10:09:51.68

>>339
Rust は清書用(キリっ

**デフォルトの名無しさん** · 2024/08/21(水) 10:57:58.35

>>340
>Cで安全に書けるならば
>Rustでもそれをライブラリとして提供できる
問題は本当にCで安全に書けているのかわからないところ
アルゴリズム系は安全性がそれなりに担保されているからsafeラッパーを提供するのは難しくない
難しいのはFFI

**デフォルトの名無しさん** · 2024/08/21(水) 17:22:42.80

このスレにはRust理解してないガイジしかおらん

**デフォルトの名無しさん** · 2024/08/21(水) 18:51:27.99

オレはコンシューマ寄りであまり理解せずにRust書いてる
ほとんどSQL文のWEB APIだけど

**デフォルトの名無しさん** · 2024/08/21(水) 19:17:17.31

サーバーやクラウドでCPUとメモリの使用リソース節約のために参照とライフタイム使いまくるプログラミングもあれば
リソースは金をかければよいだけだからとヒープ使いまくりのお大尽プログラミングもある
後者は技術力が低くてもいける

**デフォルトの名無しさん** · 2024/08/21(水) 20:29:33.23

有能な技術者を揃えて手間もかけて倍の性能を出すよりは機械を二台にするほうがコスト安ってのが昔の考え方だったんだよ。
高いのは設備より人の時間だったの。
いわゆる富豪的プログラミングという概念が生まれたのもそのときはちゃんと合理的な話だった。
だけど今は設備投資した上でまだ性能が要るという段階までコスト・性能の要求が厳しくなってきて揺り戻しが起こってる。

**デフォルトの名無しさん** · 2024/08/21(水) 22:37:24.76

Rustでライフタイム付きの構造体を書いたことがなく書けない人とかな
Cでポインタを含む構造体を扱うより楽なのに

**デフォルトの名無しさん** · 2024/08/22(木) 00:18:39.99

同意

**デフォルトの名無しさん** · 2024/08/22(木) 00:33:56.97

そういう話ではないと思うけど、既存のC/C++のコードで構造体がポインタや参照 (C++のみ) を持ってた場合、それをRustに移植しようとすると面倒なケースはあるよね
元の設計でも参照先よりも自身の寿命が短いならライフタイム注釈を付けられるけど、そうでなければunsafeとポインタにするか Rc などに置き換えるかになる？

**デフォルトの名無しさん** · 2024/08/22(木) 00:54:54.13

>>349
指してる先の寿命が短い危険なC/C++コードが
複雑で巧妙な条件管理でぎりぎりダングリングポインタとなることを上手く避けている
ように見えて実はある条件が揃った場合にはアウト、とかな

つまりunsafeでそのまま移植するとそのまま致命的バグが残ってしまう
根本から設計しなおせないならばRcと弱参照で致命的バグ回避か

**デフォルトの名無しさん** · 2024/08/22(木) 13:30:25.79

今、FirefoxとChromeってどっちがRust率高いんだろ？

JSONパーサーがC++からRustになった「Google Chrome 128」、ゼロデイ脆弱性の修正も
https://forest.watch.impress.co.jp/docs/news/1617607.html