Rust part33

**デフォルトの名無しさん** · 2025/08/15(金) 17:49:30.70

公式
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 part32
https://mevius.5ch.net/test/read.cgi/tech/1755057787/
Rust part31 https://mevius.5ch.net/test/read.cgi/tech/1751545806/
Rust part30 https://mevius.5ch.net/test/read.cgi/tech/1748392296/

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

**デフォルトの名無しさん** · 2025/08/15(金) 17:59:47.23

5ch電源断とその際のバグにより
各板の現役スレ一部がタイミングの運で失われた模様
Rustはpart31とpart32両方が現役の状況であった

**デフォルトの名無しさん** · 2025/08/15(金) 20:39:09.07

5chのシステムっていまだにperlとかなんだっけ？

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

誰かRustで5chクローン作ってくれろ

**デフォルトの名無しさん** · 2025/08/15(金) 21:13:27.00

>>2
どういうバグ？

**デフォルトの名無しさん** · 2025/08/15(金) 21:42:40.40

昔から活発な板でdat一覧ファイル壊れたりロストするから排他制御や落ちた時の途中状態からのリカバリとかザルなのかもね

**デフォルトの名無しさん** · 2025/08/15(金) 21:48:40.45

Rustじゃ20年ぐらい掛かりそう

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

2ch初期からあるread.cgiとpostの読み書き基本掲示板機能部分だけなら1日で終わるけど
後から追加した外から見えない部分が絡み合って規模も読めないね

**デフォルトの名無しさん** · 2025/08/15(金) 22:49:05.86

難読よいしょw部
難読宝田真月部
難読オランザピン部
難読肉壺ワッショイ部
難読自己中部
難読承認欲求部
難読ゴキブリ部
難読助かりました部
難読宇宙人部
難読でんちゃでんちゃでんちゃちゃっちゃっちゃ～部
難読カービィ部
難読失敗作部
難読ADHD部
難読自開部
難読多動部
難読在日部
難読糖質部
難読人非人部
難読生まれも育ちもやまゆり園部
難読何ガン飛ばしてんだよオイ！！部
難読池沼部
難読トナラー部
難読表出ろこの野郎！部
難読マウント部
難読ホンモノ部
難読害悪部
難読ガガイのガイ部
難読syamu未満部
難読底辺部
難読インチュニ部

**デフォルトの名無しさん** · 2025/08/15(金) 23:02:17.30

山下スクリプト回りの対策で、エラーが出た時にそれが何故出てるエラーなのかすら
今の5chはもはやアンドキュメントだからな

**デフォルトの名無しさん** · 2025/08/15(金) 23:41:07.28

電源落ちたからって前スレまで消えるのは常識的には考えられない動きだけど5chはそういうものなんだな

**デフォルトの名無しさん** · 2025/08/16(土) 00:28:31.64

難読漢字部
ガイジの集まり
くたばれよ

みんなもポケモンゲットじゃぞ

**デフォルトの名無しさん** · 2025/08/16(土) 00:33:34.28

>>11
前スレのpart30は過去ログ倉庫へ移動されていたため無事だよ
part31は1000になっただけで過去スレへと隠れてなくて見えたままだったのが不運

**デフォルトの名無しさん** · 2025/08/16(土) 11:34:10.89

チューリップの中で再現性のない部分だけ消えなさい
バブルは消えた

**デフォルトの名無しさん** · 2025/08/16(土) 15:07:42.32

難読ロリコン部
難読僕のスマホ返せぇぇぇ！！部
難読とど田とどら部
難読ちぎゅ田ちぎゅら部
難読チーズホビー部
難読お薬手帳部
難読底辺部
難読積極奇異型アスペ部
難読電子障害者手帳部
難読自開部
難読穢多非人部
難読バ漢字部
難読ウィィィィィィィィッス部
難読チギュァァァァァァァァァァァァ部
難読動物園部
難読おかしな奴しかいないんだけど部
難読助かりました部
難読舌打ち部
難読類友部
難読ガイジ(ゲェジ)部
難読スタバ陽キャきっしょ部
難読僕も！僕も気持ちいいことしたい！！部
難読自己中部
難読Fラン大学中退部
難読トナラー部
難読スペシャルオリンピックス部
難読ひまわり学級部
難読ゴミ部
難読弱者男性部
難読アホロライ部

**デフォルトの名無しさん** · 2025/08/16(土) 17:15:18.32

Check Pointが見つけたと言ってるRust製のWindowsカーネルコンポーネントの脆弱性ってどのCVEか分かる人いない？
https://blog.checkpoint.com/research/microsoft-vulnerabilities-exposed-by-check-point-research/
https://msrc.microsoft.com/update-guide/vulnerability

**デフォルトの名無しさん** · 2025/08/16(土) 22:23:23.06

難読DSM部
難読さす障部
難読さすガイ部
難読動物園部
難読トナラー部
難読よいしょw部
難読ホンモノ部
難読頓服部
難読でんちゃでんちゃでんちゃちゃっちゃっちゃ～部
難読マスターベーション部
難読マウント部
難読ウィィィィィィィィッス部
難読syamu未満部
難読スマホ脳部
難読多動部
難読害悪部
難読電車(バス)代割引部
難読エッホエッホ部
難読てんかん部
難読ディズニー格安部
難読フレンド申請部
難読すいません、3種のチーズ牛丼特盛りに温玉付きでお願いします部
難読水用意しろ水。イライラするわぁ部
難読おかしな奴しかいないんだけど部
難読デスマフィン部
難読コンサータ部
難読ガイジ(ゲェジ)部
難読オランザピン部

**デフォルトの名無しさん** · 2025/08/17(日) 20:15:25.86

Windows更新プログラムﾊﾞｸﾞの温床Rust
馬鹿ｺｰﾀﾞを無理やり矯正したとこで馬鹿が治る筈もなく

**デフォルトの名無しさん** · 2025/08/17(日) 21:19:09.68

バグを無くせるプログラミング言語は存在しない
Rustはプログラミング言語の中では最も様々な安全性を保証してくれる
それ以上でもそれ以下でもない

**デフォルトの名無しさん** · 2025/08/17(日) 21:22:39.79

わかってねぇな
それじゃﾎﾝﾓﾉは育たないことを

**デフォルトの名無しさん** · 2025/08/17(日) 22:50:15.00

Rustは生き物ですらない
育児もディールもしない

**デフォルトの名無しさん** · 2025/08/18(月) 07:58:05.46

RustってIT土方専用言語になりそう

**デフォルトの名無しさん** · 2025/08/18(月) 08:11:30.19

GCC Rustはだいぶ前にメインラインにマージされたみたいだけど
クロス対応ってどこまで進んでいるんだ？
LLVMバックエンドがないマイコン系ISAもRustで開発できる感じ？

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

Rustは衰退しました。

**デフォルトの名無しさん** · 2025/08/18(月) 21:46:08.37

その書き込みもRust製のPingoraを通って投稿されてRust製のPingoraを通って皆が読んでるよ

**デフォルトの名無しさん** · 2025/08/18(月) 22:00:15.90

横長のGUIが衰退したら次は縦長のGUIが再発明されたりする
じゃあ再発明しても変化しない仕様はなんだ
0で割り算できない仕様とか

**デフォルトの名無しさん** · 2025/08/19(火) 19:22:34.36

COBOLみたいに固定長レコードを基本として基本的に動的アロケーションをしない方向のモダンな言語もあっていいと思う
Rustを待たずとも、あれはあれでメモリ安全の究極の形の一つ

**デフォルトの名無しさん** · 2025/08/23(土) 19:14:03.74

>複数の値 (いわゆる多値) を関数が返せる言語はそれほど多くない。
>LISP 系は多値のサポートがあることが多いけどそれ以外だと Go くらいじゃないかな？

Rustの()は値0個で(a,b,c)は値3個の多値
という認識で合ってますか？

**デフォルトの名無しさん** · 2025/08/23(土) 19:50:48.28

>>28
いいえ。
多値ではなくタプルです。

**デフォルトの名無しさん** · 2025/08/23(土) 21:56:54.53

夏のオージ演

**デフォルトの名無しさん** · 2025/08/23(土) 22:15:56.19

多値の取り扱いの仕方の一つがタプル
そしてRust公式にも Functions can use tuples to return multiple values. と明記されている
>>28の引用文についてRustは関数で多値を返すことができる言語の一つ

**デフォルトの名無しさん** · 2025/08/23(土) 22:45:01.43

Rustのタプルは多値で合っているが、言語によってはタプルというオブジェクト[のポインタ]を1つ返す場合もある。
そのような言語ではタプル≠多値で、Rustではタプル=多値。
Rustで関数がタプルを返す時に、各環境で可能なら複数のレジスタを使って返し、レジスタ返しの数を超えていれば、例えば呼び出し元スタックフレームの指定領域に直接書き込んで返す。
したがってRustは多値返しをサポートする言語。

**デフォルトの名無しさん** · 2025/08/24(日) 06:23:07.67

分野によって用語の意味にブレがあるからそういうのを厳密に考えてもあんまり意味ない。
狭義の多値は継続 (continuation) に複数の値が渡ることをいうのでたぶん >>28 はその意味で言ってて、その意味ではタプルは多値ではない。
単なる言語ユーザの目線ではタプルにまとめて受け渡すことと複数の値を受け渡すことには何も違いはないから同一視しても何も困らないよ。
形式論理とかの世界の話。

**デフォルトの名無しさん** · 2025/08/24(日) 06:51:31.37

重要なことはオーバーヘッドの有無
タプルをオブジェクトの一種として扱う言語はオブジェクトを用意してそのアドレス単値のみを渡すため間接アクセスのオーバーヘッドが生じる
タプルを多値として扱うRustは多値として渡せるためオーバーヘッドが生じない
もちろんRustではタプルをBoxに入れることでアドレス単値のみ返すことも可能でオブジェクト方式の言語は常にそれをしていることになる

**デフォルトの名無しさん** · 2025/08/24(日) 07:38:29.67

アーキテクチャによって ABI は違うかもしれないけど一般的な実装としては
関数の返却値が大きい時は呼出し側でメモリを確保してそれを隠れた引数として渡すようなメカニズムになってる。
返却値はスタックを介さない。
これは C++ でも同じ。

**デフォルトの名無しさん** · 2025/08/24(日) 07:52:38.38

>>35
ほぼ合っているが一部だけ違う
間違ってる部分は「スタックを介さない」
正解は「スタックを介す」ことで高速に引き渡す

サイズの大きな値を返す場合
具体的には呼び出し元でスタックポインタを増減することでスタックフレームを拡大してその確保領域のアドレスを隠れた引数としてレジスタ渡しする
呼び出された関数側ではその確保領域に直接書き込んで値を返す

ヒープ領域を確保して受け渡す方式と比べるとメモリ領域確保のコストがない点とスタック上でそのままメモリキャッシュに乗る点で有利

**デフォルトの名無しさん** · 2025/08/24(日) 07:56:09.24

ちなみにRustでx64アーキテクチャの時
16バイトまでならレジスタ渡しになり上記スタック領域は使われないため更に速い

**デフォルトの名無しさん** · 2025/08/24(日) 08:16:24.05

ごめん、肝心なところ書き間違えてる
✕ 16バイトまでならレジスタ渡し
○ 16バイトまでならレジスタ返し

**デフォルトの名無しさん** · 2025/08/24(日) 10:58:20.04

言語が多値返却をサポートしてるかどうかというのは文法としてサポートしてるかどうかという意味

文法的にはサポートしてないけど「〇〇使えば多値返却できる」のは当たり前
一般的なプログラミング言語で「Functions can use 〇〇 to return multiple values」の〇〇に当てはまるものがない言語は無いので意味がない

文法的にサポートしているかどうかと内部実装がどの程度最適化されるのかはまた別の話

**デフォルトの名無しさん** · 2025/08/24(日) 11:01:04.53

多値が返せるか？の意味なんて、ユーザ的には戻り値の分割代入ができるか？ってだけだし
ダラダラ言わずに返せますで終わりでよくね

**デフォルトの名無しさん** · 2025/08/24(日) 11:17:14.32

Rustは多値を返す機能があるだけでなく
その実装も本当に多値を返すため効率よく実行も速いことが特徴

**デフォルトの名無しさん** · 2025/08/24(日) 11:34:24.43

>>40
仕様を読むときは言語の理屈や用語をわかってないとちゃんと読めない。

複数の要素をひとつにまとめたもの (タプルや構造体) をひとつ返すというのと複数の値を返せるというのは違うことなんだが、
Rust では同一視することにしたというならそれはそれで同一視しているという理屈をわかってないといけない。

**デフォルトの名無しさん** · 2025/08/24(日) 11:46:57.61

>>42
それは屁理屈
プログラマとしては多値を返せる機能があればよいわけで、
それがタプルという形で実現されていようが困ることは何一つない
逆に、タプルをサポートしていればそれだけで十分であり、
タプルでない多値をサポートするメリットが何もない

**デフォルトの名無しさん** · 2025/08/24(日) 11:50:38.02

>>43
実際に (複数の要素をタプルなどにまとめるのではなく) 多値をサポートしてる言語はあるわけだが、ディスってんの？
言語の理屈の構成の仕方の話であって言語としてのメリットの話なんかしてない。

**デフォルトの名無しさん** · 2025/08/24(日) 11:58:39.52

多値をサポートしてる言語の例としてGoが上で挙げられているけどさ
Goはタプルがなくてみんな困っている
タプルがある言語では多値がなくて困った話は聞かれない
機能として『タプル ⊃ 多値』だからだよ

**デフォルトの名無しさん** · 2025/08/24(日) 12:05:10.36

Goでタプルがなくて辛いという話は聞いたことがないな
最適化の観点抜きで機能的に他でカバーできるから不要と言ってしまうと、
例えばオブジェクトは全部ヒープに置いてスマポの所有権移動だけにしてしまえば複雑なムーブは不要となり遥かにシンプルになる
それはそれで一つの考え方だが、Rustはそういう言語ではないと思っているのだろう？

**デフォルトの名無しさん** · 2025/08/24(日) 12:08:19.32

返却された値がスタック上でどう扱われるかというのは言語仕様でなく最適化の問題だから、そこはRustではなくLLVMの話
言語仕様としては「Rustではタプルを簡単に作れる」「タプルの中身を別々の変数に束縛できる」というだけ
多値返却の目的からすればこれで十分だし、多くの言語はこれに相当する

Goは本当に多値返却という仕様で、これはタプルを返すのとは違う
そもそもタプルが言語仕様になくて、関数の返り値でだけ多値を返せるという変わった仕様
だから、2つの戻り値を返す関数を1変数で受け取ることができなかったりする
(Rustでいえば「戻り値を分解せず1つのタプル変数 t で受け取る -> t.0, t.1 のようにアクセスする」という書き方がGoではできない)

だから言語仕様としての話をしたいのか、「関数から複数の戻り値を返す」という目的の話をしたいのかで話は変わる
後者については、最近の多くの言語ではサポートしてるし、そんなに話がズレることもない
前者の意味でなら、Rustは多値返却の構文を持つ言語とは違う

**デフォルトの名無しさん** · 2025/08/24(日) 12:16:23.06

Goの多値とRustのタプルは同じ
どちらも実装は多値として返すため多値レジスタ返しが可能ならばそうするため効率が最も優れている
関数定義もほぼ同じ
func foo() (type1, type2) {…
fn foo() -> (type1, type2) {…

**デフォルトの名無しさん** · 2025/08/24(日) 12:16:31.50

バカなやつほど抽象度の区別ができない
バカなやつほどオレオレ定義で用語を使う
バカなやつほど主語を書かない

本当に相手にする価値があるか考えよう
改善の見込みがないバカなら何を書いても時間の無駄でしかない

**デフォルトの名無しさん** · 2025/08/24(日) 12:26:32.12

多値を抽象化して機能を強化したものがタプルだもんね
だから多値でできることは全てタプルでもできるんだよ
タプルを持つ言語は機能の低い多値を別途持つ必要がない

**デフォルトの名無しさん** · 2025/08/24(日) 12:50:55.19

「タプルがあれば十分」は殆どのケースでは同意するけど、Goに限ってはそうする理由があるんだよ
エラーを多値で返す仕様かつ、エラー処理を明示的に書かせる思想の言語だから
value, err := foo()
のように err がコード上に表れるようにする必要があって、これはタプルだとまずい
t := foo() と書けてしまうと「タプルの2要素目がエラー」というのが見えなくなる

これは割とGo特有の事情で、Result型や例外を使う言語だとタプルでも困らない

言語仕様というのは他の部分も含めた全体的なデザインとして考えるものだから、「Rustではタプルで困らない」が正しくても、他の言語含めて全てそうだとは言えない

**デフォルトの名無しさん** · 2025/08/24(日) 12:56:30.01

>>49
>バカなやつほど抽象度の区別ができない
>バカなやつほどオレオレ定義で用語を使う
>バカなやつほど主語を書かない

汚コーダーの特徴が濃縮されてるね
3番目は「書かない」というより「書けない」だと思う

**デフォルトの名無しさん** · 2025/08/24(日) 13:02:12.19

原始的な剥き出しの多値を扱う必要のない言語においては、タプル多値があれば多値をサポートしているという結論でいいんじゃないかな