Rust part29

**デフォルトの名無しさん** · 2025/05/03(土) 00:47:30.13

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

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

**デフォルトの名無しさん** · 2025/05/13(火) 22:17:38.03

>>441
さすが汚コーダーと呼ばれるだけはあるな

**デフォルトの名無しさん** · 2025/05/14(水) 00:10:10.91

汚コーダーと言いたい気持ちもわかる
俺たちの時代は変数名は一文字で可能ならワンライナーで処理が終わるように工夫しまくってた。2行だったのが1行79文字に収まったぞ！的な
この美的感覚を共有できる仲間がいてくれて幸せである

**デフォルトの名無しさん** · 2025/05/14(水) 00:21:08.28

両方Okの場合だけx.or(y)と違う動作をさせたいと考えるならそう書けばいいと思う
match (x, y) {
(Ok(b1), Ok(b2)) => Ok(b1 || b2),
_ => x.or(y),
}

入力が増える場合は上の処理を関数にしたものをループ内で呼ぶ
forループとか使っとけばショートサーキットも簡単

あと本当にErrを捨ててもいいんであればResult<bool, &str>じゃなくて
Option<bool>を受け取って返す形にしておいたほうが扱いも楽だしスッキリする

**デフォルトの名無しさん** · 2025/05/14(水) 00:32:45.62

>>426のはOption<bool>化して最終的にNoneならErr(“ko”)にfallbackさせてるから
読みやすいかどうかは別にして考え方としてはわりと好み

**デフォルトの名無しさん** · 2025/05/14(水) 00:34:10.14

結局>>427でええやん

**デフォルトの名無しさん** · 2025/05/14(水) 13:32:41.36

AIチャットボットに「偽の記憶」を植え付けることで仮想通貨を盗む攻撃が報告される
2025年05月14日 12時00分
https://gigazine.net/news/20250514-web3-ai-agents-with-fake-memories/
>>プリンストン大学の研究チーム

過去に流通した誤情報に接触した人の半分が「正しい情報」と思っていて25％が何らかの手段で拡散している
2025年05月14日 11時25分
https://gigazine.net/news/20250514-fake-news/
>>総務省

**デフォルトの名無しさん** · 2025/05/14(水) 16:29:27.92

「Firefox」の開発リポジトリが「GitHub」に移行
https://forest.watch.impress.co.jp/docs/serial/yajiuma/2013958.html
https://github.com/mozilla-firefox/firefox
JavaScript 28.5%
C++ 28.1%
HTML 22.0%
C 10.5%
Python 2.9%
Kotlin 2.5%
Other 5.5%

**デフォルトの名無しさん** · 2025/05/14(水) 17:34:57.56

5次方程式に新公式を発見：ルートを超える新理論
2025.05.14 17:05:56 WEDNESDAY
https://nazology.kusuguru.co.jp/archives/177496
>>オーストラリアのニューサウスウェールズ大学（UNSW）で行われた研究
プログらまーも覚えるとよい

125年越しに解決したかもしれない「ヒルベルトの第6問題」とは？
2025年05月10日 15時00分
https://gigazine.net/news/20250510-hilberts-6th-problem-solved/

**デフォルトの名無しさん** · 2025/05/14(水) 19:02:58.62

Mercurialが積極的にRust化を進めていたのは少なからずFirefoxの影響があったと思うが
酷い梯子外しで草

**デフォルトの名無しさん** · 2025/05/14(水) 19:23:03.41

Mercurial は開発履歴管理で Git はパッチの連鎖管理という理念の違いがある。
それって結局は同じことじゃないのか……と思うんだけどやっぱり違うんだよな。
概念的に整理されていて理解しやすいのは Mercurual だけど、実務的に必要なのは Git。
ツールがどんな言語で書かれているとかはあまり関係なく、大規模開発だと Git のほうがやり易いというとても簡単な話。

**デフォルトの名無しさん** · 2025/05/14(水) 20:24:41.62

Rust用のJITコンパイラ・インタプリタ的なものはありませんか？
PythonやJavaScriptのようにコンパイル時間を待たずにデバッグしたいんです。

**デフォルトの名無しさん** · 2025/05/14(水) 20:46:01.38

RustもGo言語のように、消えてゆく運命ですか？

**デフォルトの名無しさん** · 2025/05/14(水) 20:52:07.16

>>461
371 デフォルトの名無しさん sage 2025/05/14(水) 20:25:52.45 ID:u4PNt/Ez
TypeScriptを(C++等のように機械語に)コンパイルする方法が知りたいです(´・ω・)

**デフォルトの名無しさん** · 2025/05/14(水) 20:55:34.77

>>462
C++標準委員会がRustを参考にしたコーダー用Safe C++（C++呼び出し専用の限定版）を作ればC++に回帰する可能性があるけど、そんな動きは無いから当面安泰じゃない？

**デフォルトの名無しさん** · 2025/05/14(水) 21:44:29.60

コンパイラから全ソースコードが見えていて好きなだけ時間を使ってチェックさせるのか
商用を含め様々な出所のコンパイル済みバイナリでもリンク(静的、動的)して動かすのか
役割と責務が違う

**デフォルトの名無しさん** · 2025/05/14(水) 23:43:28.56

>>457
FirefoxはメインがC+のまま変わっていない
Rust化した部分はレポジトリが別

**デフォルトの名無しさん** · 2025/05/15(木) 10:01:15.43

>>460
それはよくある勘違いで、Gitのコミットはパッチではなくスナップショット
常に完全なスナップショットを持っているためにコミット間の差分の導出は極めて容易であり、
あたかもGitが差分ベースであるかのような使い勝手のコマンド体系を実現することに成功している
その結果>>460のような誤解も多い

**デフォルトの名無しさん** · 2025/05/15(木) 10:04:11.94

>>467
それは実装上の話で、ここではパラダイムの話をしてる。

**デフォルトの名無しさん** · 2025/05/15(木) 10:47:00.15

>>468
それ信頼できる出典ある？
仮にGitのコミットが(実装はさておきメンタルモデル上は)パッチだとしたら、rebaseやcherry-pickで新しいコミットが作られるのは変だと思わないのかな

**デフォルトの名無しさん** · 2025/05/15(木) 11:20:07.09

Claude 3.7 with extended thinking 様によると

Gitはスナップショットベースのシステムで、各コミットはファイルシステム全体の完全なスナップショットを保存します（最適化されていますが）。一方、Mercurialは変更セット（changeset）という概念で差分ベースの履歴を管理します。

この根本的な違いがGitの操作モデルに影響しています。rebaseやcherry-pickが新しいコミットを作成するのは、Gitがスナップショットモデルを採用しているからこそ自然です。既存のスナップショットを新しい文脈に適用すると、新しい状態のスナップショットが必要になります。

パラダイムと実装は密接に関連しており、Gitの設計思想はLinus Torvaldsが述べているように内部データモデルから生まれています。このモデルがGitの分散性、ブランチ操作の柔軟性、大規模プロジェクトでの優位性につながっています。

**デフォルトの名無しさん** · 2025/05/15(木) 11:24:57.24

>>447-448
記述量多いけど観る分には判り易い

**デフォルトの名無しさん** · 2025/05/15(木) 11:31:00.68

>>465
>コンパイラから全ソースコードが見えていて好きなだけ時間を使って

Cargo の build 遅いしディスクの容量も喰いまくる(消せるけど)
そこまでやるなら他人(自分のであっても別cratesのとき)のstruct/traitを組み合わせて追加しても良い仕様にして欲しいな

**デフォルトの名無しさん** · 2025/05/15(木) 12:17:35.74

>>472
Orphan Ruleが破れるのは致命的
第三者に勝手に実装されてしまう
これは必須ルール

**デフォルトの名無しさん** · 2025/05/15(木) 12:44:18.74

Rust の型システムの原型になった Haskell では Orphan Rule のような制限はないから技術的には制限しない選択も可能ではあるはずだけど
通常は避けるべきと考えられているし、警告も出るし、コンパイル時間にもかなり悪影響だし、良いことは少ない。

必須というほどではないかもしれないけど、あまりにも割に合わないとは言える。

**デフォルトの名無しさん** · 2025/05/15(木) 13:12:18.94

Googleが開発した進化的AI「AlphaEvolve」は未知のアルゴリズムや未解決数学問題の新解法を発見可能、すでにGoogle内部ではAI開発やチップ設計の効率化に活用されている
2025年05月15日 11時06分
https://gigazine.net/news/20250515-google-ai-algorithm-alphaevolve/

**デフォルトの名無しさん** · 2025/05/15(木) 13:17:27.73

>>474
例えば第三者のクレートを利用した時
そこで標準ライブラリの型に対して標準では実装されていない標準ライブラリのトレイトの実装があっても通ってしまう
これは誤動作につながるからOrphan Ruleは必須かと
標準ライブラリ以外の型に対しても同様で第三者に実装権限を与えるのは禁じる必要がある

**デフォルトの名無しさん** · 2025/05/15(木) 13:55:31.05

>>476
それは攻撃やミスに対する脆弱性を封じるという意味で制約が必須と言ってる？
こっちは (技術的な) 実現可能性という意味で必須な制約ではない (があえて制約を無くすことのデメリットが大きい) と言ってるので主旨が異なる。

**デフォルトの名無しさん** · 2025/05/15(木) 14:15:21.28

>>477
Orphan Ruleなしでも脆弱性を封じることができるならば技術的な実現可能性があると言えるかもしれない
そうでないならばOrphan Ruleは必須

**デフォルトの名無しさん** · 2025/05/15(木) 14:33:19.68

グローバルに適用させようとしたらそりゃ問題が起きるわ
拡張をスコープにいれる場合はモジュール内にuseステートメント書けばいいだけ

**デフォルトの名無しさん** · 2025/05/15(木) 14:47:58.27

C#で言う拡張メソッドをやりたいのに、Orphan Ruleが邪魔をする
次のeditionでは廃止してほしいね

**デフォルトの名無しさん** · 2025/05/15(木) 14:53:04.88

脆弱性とか全然関係ないよな

**デフォルトの名無しさん** · 2025/05/15(木) 14:54:41.56

>>479
それは違うよ
それは自分で拡張用トレイトを作って、自作以外を含めた任意の型に対して実装して使う時に、自分で範囲を限定する時の話だね。
そうではなく、普通に必要のためuseしている標準やクレートのトレイトが、勝手に第三者によって実装されてしまうことを防ぐのがOrphanルール

**デフォルトの名無しさん** · 2025/05/15(木) 14:57:48.33

>>480
Rustでは、自由に拡張メソッド用のトレイトを自作して、既存の型に実装して自由にメソッド拡張できます。
Orphanルールは邪魔しません。

**デフォルトの名無しさん** · 2025/05/15(木) 15:04:23.65

>>481
もしOrphanルールがないと、トレイトの作成者でも型の作成者でもない第三者によって、勝手に型にトレイトが実装されてしまうため、その実装によっては脆弱性が生じる可能性があります。

**デフォルトの名無しさん** · 2025/05/15(木) 15:35:40.67

>>484
トレイトの実装は可視性の指定をバイパスできないし、そもそも可視性はセキュリティのための機構ではない
その気になりゃ本来不可視なメンバにアクセスすることなんて普通に可能だし、
もしクレートの作者に悪意があって、利用者が不用意にバージョン上げる阿呆なら、サプライチェーン攻撃によってマルウェアを仕込むことなど造作もない

**デフォルトの名無しさん** · 2025/05/15(木) 15:59:53.54

>>485
そんな悪意のある話はしていません。
第三者が公の型に公のトレイトを実装できてしまうと、その第三者にとっては意図通りの必要なことが実現できたとしても、他者にとっては必ずしもそうではないためその差異が穴になりうるという話です。

**デフォルトの名無しさん** · 2025/05/15(木) 16:01:34.05

>>480
既存の構造体に新しいメソッドを生やしたいだけならextension traitで可
既存traitに新しいメソッドを生やしたいならextension trait + blanket implで実質同じことが可
拡張メソッド1つじゃなくtraitと実装の最低2つを定義しないといけないがそんなに気になるほどではない

Swiftの拡張メソッドのように既存インターフェースに後から適合させるのはRustでは無理

**デフォルトの名無しさん** · 2025/05/15(木) 16:08:57.33

>>486
だからそれはグローバルに適用した場合の話でしょ
そりゃ問題起きる

**デフォルトの名無しさん** · 2025/05/15(木) 16:19:46.85

>>488
理解できてないのかな？
例えば標準ライブラリのトレイトに話を限ったとしても、自分で使いたいからuseしたり、preludeで自動的にuseされたりするよね。
そのトレイトが標準ライブラリでは実装されてない型に対して、第三者が実装できてしまうことを防ぐのがOrphanルール。
標準ライブラリではない一般クレートに話を拡張しても同じ。

**デフォルトの名無しさん** · 2025/05/15(木) 16:39:03.48

既存の構造体に既存のtraitを

**デフォルトの名無しさん** · 2025/05/15(木) 16:52:22.68

barクレートとbazクレートがどっちもfooクレートに依存してて
それぞれで個別にimpl FooTrait for FooTypeを定義してたら
barクレートとbazクレートを両方使うときに衝突して困る

**デフォルトの名無しさん** · 2025/05/15(木) 17:01:11.21

>>489
それは型定義ともトレイト定義とも異なるクレートでのトレイト実装という現状禁止されている行為が仮に許可された場合、
コンパイルパスに入ってさえいれば暗黙的に実装がインポートされる仕様になる、とあなたが勝手に想定しているからでしょ
もし対応するなら、実装を含むモジュールを明示的にuseさせるような仕様になるだろうし、
そういった面倒を避けるためにorphan ruleがある、と考えることもできる

**デフォルトの名無しさん** · 2025/05/15(木) 18:02:56.74

例えばu32型にその値を半分にするメソッドhalf()を生やしたいとしたら自作トレイトHalfを用意してu32に実装してやればメソッド拡張できて
そのトレイトHalfをuseすれば第三者もその恩恵に授かってhalf()メソッドを使えるわけだけど

仮にOrphan ruleがない世界だと
u32型には実装されていないstd::ops::Negトレイトも誰でも実装できてしまう
先ほどのhalf()メソッドはuse dareka::Halfした時のみ使えるから自己責任で済んだけど
今回は別目的でuse std::ops::Negしてる人にもu32型にneg()が生えてしまう
本来はu32型の変数xに対して-xはコンパイルエラーとなるけど
今回はneg()が使えて-xがコンパイル通ってしまう
しかも実装の内容によってはその-xの挙動が不明だ

**デフォルトの名無しさん** · 2025/05/15(木) 19:36:05.04

ポケモン協会は秘密にしてるけど、たぶんポケモン世界にはイジメ属性みたいなのもあって仲間ポケモンを自殺に追い込んだりしてると思う。
それとか孕ませポケモンがトレーナーをレイプしたりだとか、逆にトレーナーがポケモンと獣姦 (?) したりだとかいう醜聞もいっぱいあるに違いない。
ポケモン協会はそういうのを隠さずに公開すべき。

**デフォルトの名無しさん** · 2025/05/15(木) 19:37:43.21

ごめんなさい。
誤爆しました。

**デフォルトの名無しさん** · 2025/05/15(木) 20:29:13.48

俺だってシャワーズとセックスしたいよ

**デフォルトの名無しさん** · 2025/05/15(木) 22:09:10.96

それはもはやトランスアニマルじゃねーの
いくら翻訳がグダグダだからってそこまで人間性失うのはいかがなものかと

**デフォルトの名無しさん** · 2025/05/15(木) 22:20:07.26

>>457,466
ほかの言語と同じように外部ライブラリ/crateを除外してある今回の数字が正しそうね

**デフォルトの名無しさん** · 2025/05/15(木) 23:29:18.99

>>493
Orphanルールの説明で第三者による実装同士がぶつかりエラーを引き起こすためという話を見かけるけど
ぶつからなくても単独でもそういう支障があるんだよな

**デフォルトの名無しさん** · 2025/05/16(金) 06:25:07.48

悲報！Rust版AV1デコーダーがCより5%遅い問題が解決できず、カネで解決しようとする
https://www.memorysafety.org/blog/rav1d-perf-bounty/

**デフォルトの名無しさん** · 2025/05/16(金) 07:42:42.67

>>500
詳細を見るとこれはRustとLLVMの改善に大きく寄与しそうだな
(1) Rustコードの問題
(2) Rustコンパイラの問題
(3) RustコンパイラからLLVMへの問題
(4) LLVMの問題
これらは密接に関係していて(1)を完璧にしていても
(4)の問題から逆連鎖して(1)で対応するためのコード調整をしなければいけないようだ
本件をきっかけに様々な改善が期待できるので世界全体に役立つだろう

**デフォルトの名無しさん** · 2025/05/16(金) 07:44:33.05

LLVMを用いている様々な言語にも恩恵ありそうだ

＞驚くべきことに、Clang 18 でビルドされたバージョンは、Clang 17 でビルドされたバージョンよりもパフォーマンスが劣ることがわかりました (~3% 遅い)。
＞このリグレッションの原因は不明ですが、Clang全体で一貫性があり、対応するLLVMバックエンドを使用していることがわかりました。

**デフォルトの名無しさん** · 2025/05/16(金) 08:19:21.12

Rust は将来的に LLVM をやめる計画じゃなかったっけ？
うろ覚えなので勘違いかもしれんけど。

**デフォルトの名無しさん** · 2025/05/16(金) 08:21:41.68

>>503
GCC Rustは継続的にやってるみたいだけど、別にLLVMはやめないでしょ

**デフォルトの名無しさん** · 2025/05/16(金) 08:42:23.59

今日公開のRust 1.87.0でio::pipeが追加された
今までなかったことが不思議

**デフォルトの名無しさん** · 2025/05/16(金) 09:10:56.72

>>500
対象国に対して賞金が安すぎる
しかもRust処理系の方に手を入れた場合はアプリケーションの改善をした人と山分けになる可能性が高いし、
一般的な有効性を証明してRust処理系にマージされないといけないというのはハードルが高すぎる
残念ながら複おじが期待するような結果になる可能性は低いと言わざるを得ない

**デフォルトの名無しさん** · 2025/05/16(金) 09:12:43.25

>>505
Stdio::piped()が10年前からある
無名パイプはOS依存かつプロセス間だから汎用化は安定化に時間がかかったのかな

**デフォルトの名無しさん** · 2025/05/16(金) 09:41:55.75

>>500,506
フルで$20,000でも米国の1人月かぁ、しかも成功報酬だから最適化を舐め腐ってるけど
Rustに入れ込んでる一定数はひと山当てたい連中だから売名プロモーションとして参加するだろうね

**デフォルトの名無しさん** · 2025/05/16(金) 11:10:05.92

リンク先見たら初っ端からsafe rustを諦めているから
何の為のプロジェクトか意味不明になりかけている

**デフォルトの名無しさん** · 2025/05/16(金) 11:35:21.65

>>509
unsafeからsafeを創り出す新たな安全パターンを見つけたら、それを使うのは問題ない
その部分だけ徹底的に人の手で安全管理して、それ以外の安全をRustコンパイラに任せることができる
それらのうち特に汎用パターンを集めたものが標準ライブラリという視点もある

**デフォルトの名無しさん** · 2025/05/16(金) 11:41:45.02

今になって気が付いたじゃなくて、言語仕様で例外を投げられないから無視してただけでは
> We noticed that the existence of panicking code significantly increased stack usage. Similarly to how panicking/formatting code prevented crucial inlining in bounds checking code until moved out of the function, panicking code also increased stack usage and spills.

>>510
タラレバがでかい

**デフォルトの名無しさん** · 2025/05/16(金) 11:42:09.71

>>509
標準ライブラリの内部でも unsafe はたくさん使われてるぞ。
unsafe をどう「閉じ込める」かが Rust プログラムの構成の肝心な部分だ。
速度チューニングのために閉じ込めきれなかったのなら失敗と言えるが unsafe がただちに悪いわけではない。

**デフォルトの名無しさん** · 2025/05/16(金) 11:48:07.99

panic(エラー処理)を関数内に収めるからregisterが足りなくなり易くなるからspillさせるためにスタック多めにして、コードサイズも大きくなるのは最初から分かってたでしょうよ

**デフォルトの名無しさん** · 2025/05/16(金) 12:31:41.93

unsafeは禁止なのにpanic!はOKって何考えて設計してんの

**デフォルトの名無しさん** · 2025/05/16(金) 12:37:23.64

速度にシビアなコードを書く時は関数にpanic呼び出しが残っていたら当然負け
まずはpanicを生じさせないイテレータなどで書き
インデックスアクセスを避けられない時は様々な工夫とヒントをコンパイラに与えて境界チェックを回避
それでも回避できない部分が残れば最後の手段unsafe安全閉じ込め
他の言語なら全体の安全保証を捨てるか遅さを我慢するかの二択

**デフォルトの名無しさん** · 2025/05/16(金) 12:56:20.34

一番初歩的なゼロ除算はchecked_divがidiomaticだけど、
ttps://stackoverflow.com/questions/66602948/is-there-a-way-to-catch-division-by-zero-errors-without-checking-in-advance

実際に0除算を実行してハードウェア例外を発生させるコードの例(回避できない部分と仮定)として、
> それでも回避できない部分が残れば最後の手段unsafe安全閉じ込め
>>515の言うこれをゼロ除算で具体化するとどうなるの？

**デフォルトの名無しさん** · 2025/05/16(金) 13:18:06.79

>>516
除数をstd::num::NonZero型にするとpanicコードは入らない

**デフォルトの名無しさん** · 2025/05/16(金) 13:42:02.34

>>517
病気かな

**デフォルトの名無しさん** · 2025/05/16(金) 13:49:45.88

>>518
実際にかつてそれで対応したことがありアセンブリコードも確認している

**デフォルトの名無しさん** · 2025/05/16(金) 13:54:06.57

>>519
要求されてるのは>>515「それでも回避できない部分が残れば最後の手段unsafe安全閉じ込め」™の具体例だからサッと出せば良い

**デフォルトの名無しさん** · 2025/05/16(金) 14:18:57.81

>>520
safeなstd::num::NonZero使用で対応できているためunsafeの必要がない

**デフォルトの名無しさん** · 2025/05/16(金) 15:05:55.72

>>521
御託はもういいからお前はsafe縛りでAV1デコーダを書き直してCと同等の速度を達成してこい

**デフォルトの名無しさん** · 2025/05/16(金) 15:14:15.36

>>522
金と暇を用意してくれたらな
それから最高速を求める時にsafe縛りの必要はない
unsafeを安全に閉じ込められる枠組みが見つかればそれを実行してきたのがRustの歴史
その恩恵で皆がsafe Rustでパフォーマンスを出すことができる

**デフォルトの名無しさん** · 2025/05/16(金) 15:24:17.43

なんかよくわかんねーけどCより5%遅いらしいな

**デフォルトの名無しさん** · 2025/05/16(金) 15:38:32.38

デコーダーの主要部分はC版の頃からアセンブラで書かれてて、Rustはグルーコードに過ぎないみたい

**デフォルトの名無しさん** · 2025/05/16(金) 15:41:24.82

えぇ・・・

**デフォルトの名無しさん** · 2025/05/16(金) 16:18:41.85

pub const fn checked_div(self, rhs: Self) -> Option<Self> {
if intrinsics::unlikely(rhs == 0 || ((self == Self::MIN) && (rhs == -1))) {
None
} else {
// SAFETY: div by zero and by INT_MIN have been checked above
Some(unsafe { intrinsics::unchecked_div(self, rhs) })
}
}

NonZero使ったら最適化で分岐が消える場合があるってことだろうけど
チェックタイミングがNonZero化するときに移動しただけだよね
もしくは定数由来だからチェックが不要になったか

**デフォルトの名無しさん** · 2025/05/16(金) 19:03:43.29

>>527
checkなくコストゼロでpanicもなく安全にu64 / NonZero<u64>の除算やNonZero<u64>→u64の変換などができる
ゼロ保証のない変数からNonZeroを作るには必ずチェックコストがかかるが以降は除数として何度使ってもコストゼロ

元が穴のないCコードならどこかで何らかの方法でゼロにならないことを保証しているはず
それに準拠する形を取ることができればCとRustは同じコストで同じ速さになる
もし元のCコードにゼロ保証する仕組みが全く見当たらないならばそれは穴のあるコードが見つかったことになる

**デフォルトの名無しさん** · 2025/05/16(金) 19:13:36.61

>>528
病気だな。

要求されてる「それでも回避できない部分が残れば最後の手段unsafe安全閉じ込め」™の具体例を上げやすいように、
「それでも回避できない部分」を簡潔に作り出すのが手間なら、ループ最深部の(0かも知れない)除算を想定した上で「unsafe安全閉じ込め」™をサッと挙げたらどうですか？
と言う話のはずなのに、この受け答え。

**デフォルトの名無しさん** · 2025/05/16(金) 19:16:32.12

>>529
unsafe使わずにsafe Rustで実現できている
何のためにunsafeを使えと言ってるのか理解できない

**デフォルトの名無しさん** · 2025/05/16(金) 19:17:47.42

>>528
> それに準拠する形を取ることができればCとRustは同じコストで同じ速さになる

こんな単純化を信じているのが大勢いて、信者の一人>>500記事が現実を突きつけられているのに
>>528はまだ受け入れられない。

**デフォルトの名無しさん** · 2025/05/16(金) 19:19:01.24

>>530
対象国居住者とタッグ組んで参加してください。

**デフォルトの名無しさん** · 2025/05/16(金) 19:23:03.68

>>525
> Rustはグルーコードに過ぎないみたい

グルーコードに過ぎないのに、最大限努力した結果で5%も性能差が出ている事実がインパクトある。

**デフォルトの名無しさん** · 2025/05/16(金) 19:29:28.60

>>531
何を解決してほしいのか具体的に言おう
panicもcheckも必要なく安全にsafe Rustで実現する方法は既に使えた

**デフォルトの名無しさん** · 2025/05/16(金) 19:33:14.79

当然ながら元々はボトルネックを特定した上で部分的にアセンブラで書いているのだろうし、
当時のスキルをもってすれば今5%も差が出ているならまずは原因箇所の特定くらいは簡単にできそうなもんだが、
なぜこんな解像度の低い状態で丸投げしているのか謎
オリジナルの開発をやった人がいなくなっちゃったのかもね
もはやRust関係ないけど

**デフォルトの名無しさん** · 2025/05/16(金) 19:35:12.11

>>531
何を解決してほしいのか具体的に言おう
panicもcheckも必要なく安全にsafe Rustで割り算を実現する方法は既に伝えた

**デフォルトの名無しさん** · 2025/05/16(金) 19:39:18.59

ここでは全部一人のせいにしているけど
だぶん「unsafe安全閉じ込め」™オジwと複オジは別人で
都合悪なると仮病になる

>>535
懸賞記事内にリンク記事があるよ

>>534,536
たぶん「unsafe安全閉じ込め」™が何のことか具体的に知りたいだけでは
仮病してると複オジと同レベルだぞw

**デフォルトの名無しさん** · 2025/05/16(金) 19:45:26.73

>>537
「unsafe安全閉じ込め」の例はRust標準ライブラリに無数にあるからそれを知りたいとは思わなかった
興味ある部分についての標準ライブラリのソースを読んでくださいでおしまい

**デフォルトの名無しさん** · 2025/05/16(金) 19:48:17.71

いつもの人間が判断するだけの事に名前を付けたのね

**デフォルトの名無しさん** · 2025/05/16(金) 19:49:07.71

そうなると複オジ本人だなw

**デフォルトの名無しさん** · 2025/05/16(金) 20:03:38.49

>>537
一通り読んだけど、c2rustのunsafeコードを修正する際に適用することにしている、一般的に高速化に寄与すると考えられる作法を紹介しているだけで、
実行時のパフォーマンスについての詳細な分析結果は特に見つけられなかった
プロジェクトの概要なんかも見てると金貰って開発する上で結構厳しくQCD管理されてるみたいだから、
どうしても自分達で解決できないというよりは単に切羽詰まってるから助けてくれという感じなのかね

**デフォルトの名無しさん** · 2025/05/16(金) 20:14:28.07

複オジは仮病だろうけど、最近の話題でこんな画像があった

統合失調症のブログが話題に「全てがわかる。すべてのすべて」
https://pbs.twimg.com/media/Gpy43ktaYAYMz9w.jpg

**デフォルトの名無しさん** · 2025/05/16(金) 23:32:05.70

>>513
この種の速さ命のプログラミングではpanicコードを完全に排除するためその問題は起きない

**デフォルトの名無しさん** · 2025/05/16(金) 23:35:06.70

テックポエム量産してるのは>>542に近いのでは
論理的には違っていると自覚はあるから「ポエム」と称するけど
異常脳神経が「分かった」シグナルを発して仕方がないのだろう

**デフォルトの名無しさん** · 2025/05/16(金) 23:48:27.11

このGoスレレスなんて>>542のイチゴの例そのものね

> Goはルーン文字と同じ運命をたどりそうだな
> 紙が普及した時代に原始的な彫刻文字は流行らない
> 時代に合わせて形を変えないと

**デフォルトの名無しさん** · 2025/05/17(土) 02:16:37.18

>>545
頭おかしいのはみんな気づいてるからいいとして、せめてコテにしてNGさせてくれよな
延々中身のない仕様も理解していないレスバを目にするのも辛いしな
よりに寄ってこんな過疎スレに来なくていいのに

**デフォルトの名無しさん** · 2025/05/17(土) 07:06:56.82

科学＋ 5ch

20種近くも検出された新しい「量子状態」は、量子コンピューター飛躍の鍵になるか [すらいむ★]
2025/05/16(金) 22:52:02.48
http://egg.5ch.net/test/read.cgi/scienceplus/1747403522/
>>これまで理論上の存在と考えられてきた量子状態の検出に、国際研究チームが初めて成功した。量子情報の保存や論理演算の基盤として応用することで、量子コンピューターの未来を変える鍵となるかもしれない。

※犯罪の手口が判明するのか

**デフォルトの名無しさん** · 2025/05/17(土) 07:42:04.23

>延々中身のない仕様も理解していないレスバ

潰し屋だな

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

全能感があるだけ幸せなのでは？自分は真逆で老化がはじまったんかと思うぐらい

**デフォルトの名無しさん** · 2025/05/17(土) 10:25:49.04

糖質というより発達系だろ
間違いを認めたら負けみたいな中華メンタルも持ち合わせてるけどあれは病気じゃなくて人間性の問題