Rust part14

**デフォルトの名無しさん** · 2022/02/12(土) 01:24:16.59

公式
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/

※C++との比較は専用スレへ
C++ vs Rust
https://mevius.5ch.net/test/read.cgi/tech/1619219089/

※次スレは原則>>980が立てること

前スレ
Rust part13
https://mevius.5ch.net/test/read.cgi/tech/1636247099/

**デフォルトの名無しさん** · 2022/03/12(土) 12:18:34.97

>>420
無知すぎるな
geigerは標準ライブラリを調べていない
そしてRustの標準ライブラリの中はもちろんunsafeだらけ
それなのにgeigerは一番肝心な標準ライブラリを調べていない

それはなぜか？
unsafeの正しい使用には全く問題がないからだ
unsafeを使ってそれを内部に閉じ込めて外部に安全なインタフェースのみ提供する
標準ライブラリを含めてライブラリはこの安全なインタフェースを提供している

**デフォルトの名無しさん** · 2022/03/12(土) 12:37:50.92

>>421
> geigerは標準ライブラリを調べていない
そんなことは>>316で書いたｗ
>>356 >>369でも言ってるとおり、ランタイム/VM＋標準ライブラリは「前提として」100%信用するｗ
この境界は区別しないとプログラム全体の安全性が定義できないし、それらの実装言語は何でもアリだからｗ

**デフォルトの名無しさん** · 2022/03/12(土) 12:45:28.26

rustは "安全な言語" じゃなくて "比較的安全なシステムプログラミング言語" だよ
議論のポイントがずれている

**デフォルトの名無しさん** · 2022/03/12(土) 12:50:29.49

unsafeを混在させたくないなら自分で書けばいいだけだよ
その選択ができることが他所とは違うところ

**デフォルトの名無しさん** · 2022/03/12(土) 12:53:38.99

>>422
愚かだな
どのプログラミング言語においても標準ライブラリに問題が発見されて修整されてが繰り返されてきた
標準ライブラリとなっけられているからといって100%信用できるわけがない
そこには何も保証がない

一方でRustならば標準か否かに関係なく保証ができる
unsafeを利用して安全なインタフェースを作った部分のみ人間がチェックすればライブラリ全体の安全性はRustの言語が保証できる
Rust以外の言語はライブラリ全体を人間がチェックしなければならない
Rustがこの点で全ての言語に対して優れていることは誰の目にも明らかだ

**デフォルトの名無しさん** · 2022/03/12(土) 13:01:02.47

で、おまえその優れた言語で何か書いてんの？え？actixのサーバー？コマンドラインのプログラム？(笑)

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

>>423
ずらしてるんだけどねｗ

>>424
残念ながら世の中の需要はそうなっていないから、>>335と言ってたわけだよｗ
分離できる言語は多いけどｗ

>>425
そこを保証するのは処理系側なんて、その言語の利用者側は100%信用するしかないんだよｗ
標準以外がunsafeを利用してたらもう終了ｗなんで理解できないのかなｗ

>>426
匿名掲示板でそういうのは聞かないだろ普通ｗお前が言ったらじっくりいろいろ聞いてやるよ(俺は言わないｗ)

**デフォルトの名無しさん** · 2022/03/12(土) 13:10:43.13

>>426
主要基本orミドルの書き換え
今はLi*uxというあるOSを全てRustで書き直すプロジェクトの統括責任者兼主席ブログラマやってます

**デフォルトの名無しさん** · 2022/03/12(土) 13:17:12.35

他所とは違う点は認めるのね

**デフォルトの名無しさん** · 2022/03/12(土) 13:22:49.30

>>429
そっちは読んでもいねーよｗ俺宛て以外読みたくないだろ面倒だからｗ
まあ返事はしなくても分かると思うけどｗ

**デフォルトの名無しさん** · 2022/03/12(土) 13:39:59.72

安全第一　品質第二

今日も一日ご安全に

**デフォルトの名無しさん** · 2022/03/12(土) 14:25:52.99

(unsafeじゃないから)ﾖｼｯ

**デフォルトの名無しさん** · 2022/03/12(土) 14:33:29.78

ﾖｼｯ!!
#![forbid(unsafe_code)]
fn main() { maybe_safe::read_address_4byte(0); }
※全文は>>321 参照

**デフォルトの名無しさん** · 2022/03/12(土) 14:34:41.57

>>312だったｗ

**デフォルトの名無しさん** · 2022/03/12(土) 14:42:01.36

>>434
その>>312を見たが作った関数がunsafeなのにunsafe宣言をしていない
ルールを守らずにunsafeを使用してはいけない
ルールもわからない初心者ならばunsafeを使うな

**デフォルトの名無しさん** · 2022/03/12(土) 14:48:42.84

>>435
前にも同じこと言われて
>>314
>>316
となり、以降まともな反論ないんだけどｗ
しかもこのやり取り何度目？ｗｗｗｗ

**デフォルトの名無しさん** · 2022/03/12(土) 14:49:50.97

次スレワッチョイつけてくれや
マジでうっとおしい

**デフォルトの名無しさん** · 2022/03/12(土) 14:53:48.90

#![forbid(unsafe_code)]
fn main() { maybe_safe::read_address_4byte(0); }

(unsafeじゃないから)ﾖｼｯ
　　　 ∧　　/ヽ
　　　/／￣￣＼|
　　 ∠＿╋＿＿〉
　　/　①八①　ヽ＿
　工ﾆf(_人_)ｴ二|′)ヽ
　　＼ヽヽノノノヘ |
⊂⌒)_＞―――′イ (＿)
　`ー､_ノ/￣ヽ　｜
　　＿|｜　 |　｜
　　(　人＿ノ　Λ
　　＼ス￣￣ﾚ-Λ ＼
　　(￣　)　/ /　＼ﾉ＼
　　￣￣　(　ヽ　＼_)
　　　　　　＼ノ
※全文は>>312参照

**デフォルトの名無しさん** · 2022/03/12(土) 14:59:12.25

だから、比較的安全、ということでいいでしょ
オフィシャルも含めてそれはみな承知のことだよ

**デフォルトの名無しさん** · 2022/03/12(土) 15:04:06.13

比較的安全という「希望的推測ができる」だけで、実際にはC/C++と全く変わらないｗ
前にも言ったけど、ミニマムなunsafe領域を含む「設計意図としてのunsafe」が示せるだけｗ

**デフォルトの名無しさん** · 2022/03/12(土) 15:17:24.76

全く変わらないというのは、同じものを同じ人がCとRustで書いたとき、問題が起きる確率は変わらないだろうということ？

**デフォルトの名無しさん** · 2022/03/12(土) 15:24:02.56

>>440
違いを理解しよう

C/C++では安全性の保証は無し
ライブラリ含めて全てのプログラムに対して相互に関係する影響について人間が全てチェックしなければならない

Rustでは言語がすなわちコンパイラが安全性の保証をすることができる
unsafeを使った部分のみその影響範囲が閉じていることを人間がチェックするだけでよい

**デフォルトの名無しさん** · 2022/03/12(土) 16:06:48.08

作り方の問題で言語の理解がしっかりしてればどちらも同じように出来るｗ
機械的な保証があるかないかが問題で、その分はunsafeがある時点で保証できなくなるだけｗ
ただし、Rustには作り方に制限があるため、その作法でC/C++が実装された場合の話にはなる、というだけの話ｗ
C/C++で作法を守らない部分の責任は人間側で負う必要があるｗ
C/C++とRustどちらも保証はできないｗ

**デフォルトの名無しさん** · 2022/03/12(土) 16:09:18.50

Unsafe使ってたらSafeじゃない理論ってC#でもFFI使ってたらUnsafeってことでいいの？

**デフォルトの名無しさん** · 2022/03/12(土) 16:28:56.66

C#はunmanagedなコード以外でunsafeを使用する動機がないので懸念点がない上に、外部の何かへのアクセスが前提で、managedなオブジェクトの書き換えはあまり発生しない。
例外的にmanagedなオブジェクトを書き換える場合でも、unmanagedコードがロジック自体を持たないのが普通。
他方Rustは所有権の制限を適用しない目的などでオブジェクトを書き換えるため、それ自体がロジックの一部となっている。
例えば他のライブラリやシステムコールを利用してるなど、明確に分かるものがあればまだいいが、そういうのがないただのデータ構造に対するロジックなどにもunsafeが適用されるため、利用者側からは想定すらできず、それらを発見するためのツールが必要になってる状況も踏まえ、事態は深刻である。
そして多すぎるunsafeのせいで、それらを利用者側が正確に分類・把握できない、もしくは気付いてすらいないのが現状ｗ
実験室向けの簡単なコードならそれでよくとも、製品レベルのコードでそれは致命的であるため、安易な「安全宣言」は悲劇しか生まないｗ

Run cargo-geiger!
💀💀💀☢☢☢☢💀💀💀 !!!! Rust is ☢UNSAFE☢ !!!! 💀💀💀☢☢☢☢💀💀💀

**デフォルトの名無しさん** · 2022/03/12(土) 16:29:32.03

C#はFFI使わなくてもぬるぽ（ぬるり？）できるから最初からunsafeかと
せぐふぉじゃなければセーフというなら話は別だけど

Rustはunsafeな範囲を可視化できてその範囲指定が正しいことを機械的に保証できるから
C/C++に比べて比較的安全（安全性を担保しやすい）って話なんだけど
0か100でしか考えない人間にはこの差が見えないのかもしれないな

**デフォルトの名無しさん** · 2022/03/12(土) 16:33:40.22

「Rustはunsafeな範囲を可視化できてその範囲指定が正しいことを機械的に保証でき」ないのですよｗ
機械的に保証できるのは俺の言い方だとミニマムな部分だけｗ

Run cargo-geiger!
💀💀💀☢☢☢☢💀💀💀 !!!! Rust is ☢UNSAFE☢ !!!! 💀💀💀☢☢☢☢💀💀💀

**デフォルトの名無しさん** · 2022/03/12(土) 16:39:30.29

変な言い回しするから言いたいことがよく分からない
自分でunsafe書いてなくても、依存関係がunsafeを濫用してたらアプリケーション全体としてはunsafeじゃないか
という主張なんだよねたぶん

**デフォルトの名無しさん** · 2022/03/12(土) 16:51:59.88

俺の主張の大事な点は2つだよ
・安全とするにはunsafeと宣言すべき関数を機械的に決めることが出来ない
・安全のために所有権に厳しい制約を課しているが、その厳しさからunsafeを使う動機が常に言語内にある

これらから導かれる推測は多岐にわたるけど、分かりやすい結論として
Run cargo-geiger!
💀💀💀☢☢☢☢💀💀💀 !!!! Rust is ☢UNSAFE☢ !!!! 💀💀💀☢☢☢☢💀💀💀
という警鐘を鳴らしているだけｗ

**デフォルトの名無しさん** · 2022/03/12(土) 16:57:57.83

一つ目言ってる意味がもう分からないんだけど
普通に言ってくれ

**デフォルトの名無しさん** · 2022/03/12(土) 16:59:02.17

わっチョイの議論が出てるけど個人的には過疎るから賛成できない
この人は語尾wでNGすればいいだけと思う

**デフォルトの名無しさん** · 2022/03/12(土) 17:05:16.49

>>450
普通に言った。何が分からないのか言ってくれｗ

**デフォルトの名無しさん** · 2022/03/12(土) 17:10:56.57

安全のために所有権に厳しい制約を課しているが、その厳しさからunsafeを使う動機が常に言語内にある

わからんでもないかもしれん

**デフォルトの名無しさん** · 2022/03/12(土) 17:38:29.48

＞・安全とするにはunsafeと宣言すべき関数を機械的に決めることが出来ない

安全とするには～する必要がある
なら分かるが、

安全とするには～出来ない
なので主張がわからんという話でしょ

**デフォルトの名無しさん** · 2022/03/12(土) 17:44:06.44

>>448
『自分でunsafe書いてなくても、依存関係がunsafeを濫用してたらアプリケーション全体としてはunsafeじゃないか
という主張』は
実際に使われているモジュールでそういう例があるならば成り立つ
しかし現実にはunsafeなモジュールは存在しなくて
>>445はその例を挙げることすら出来ていない
机上の空論を繰り返しているのみ

**デフォルトの名無しさん** · 2022/03/12(土) 17:47:55.25

>>453
その場合ですらunsafeは使っても構わない
そのunsafeを使った局所的な部分に影響が閉じ込められていて安全なインタフェースのみ公開されていればよい
そしてRustコンパイラは残り全体の安全性を保証できる

**デフォルトの名無しさん** · 2022/03/12(土) 18:12:42.07

いい加減無視することを覚えとけ
こんなの相手にするから調子乗るんだぞ

**デフォルトの名無しさん** · 2022/03/12(土) 18:22:27.94

>>454
(安全とするにはunsafeと宣言すべき関数)を機械的に決めることが出来ない
こう書けば分かるのだろうかｗｗｗｗ

>>455
issueがないとでも思ってるの？ｗｗｗｗ

>>456
「そのunsafeを使った局所的な部分に影響が閉じ込められてい」る前提がおかしいｗ
安全なインタフェースとは誰が判断するの？ｗｗｗｗ
どうなってたら安全なの？ｗｗｗｗ
それを人間が判断する以上、どこまでも間違いは起きるよｗ

Run cargo-geiger!
💀💀💀☢☢☢☢💀💀💀 !!!! Rust is ☢UNSAFE☢ !!!! 💀💀💀☢☢☢☢💀💀💀

**デフォルトの名無しさん** · 2022/03/12(土) 18:34:51.66

反応してるやつも同レベルの荒らしだから、いっしょくたにあぼーんしましょうね

**デフォルトの名無しさん** · 2022/03/12(土) 18:41:59.36

>>451
これが正解
末尾wは煽りたいだけだから対話する気がないし

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

例えばTokioを使ってUnsafe由来の変な落ち方する例とかが有ればUnsafe使ったライブラリ全然信頼できねーなって同意すると思う

**デフォルトの名無しさん** · 2022/03/12(土) 22:12:28.43

与えられたコードがunsafeかどうかを判定するルーチンHがあればいいんだろ

**デフォルトの名無しさん** · 2022/03/13(日) 00:20:04.81

>>461
https://www.google.com/search?q=tokio+issue+unsafe
全部調べてないと証明できないのであればあるｗ
これ以外に存在しないかどうかは不明だが、お前が信用するしないで事実が変わるわけじゃないｗ

>>462
そうだね

Run cargo-geiger!
💀💀💀☢☢☢☢💀💀💀 !!!! Rust is ☢UNSAFE☢ !!!! 💀💀💀☢☢☢☢💀💀💀

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

次スレはワッチョイつけますから覚悟しておいてください
それまでの命だ
せいぜい楽しむがいい

**デフォルトの名無しさん** · 2022/03/13(日) 16:28:13.28

>>463
読んでみました
・質問者がunsafeの言葉を使い間違えてました
・ランタイムを何度も複数回スタートさせていました　(そしてunsafeな状況は起きていない)
などで
(unsafeを使って)安全でないインタフェースを公開してしまったわけではないようです

>>464
反対です
過疎ってRustが不利になるだけなので
皆がワッチョイ無しスレも立てる結果となるでしょう

**デフォルトの名無しさん** · 2022/03/13(日) 16:46:41.64

>>465
皆というかあなたがね

**デフォルトの名無しさん** · 2022/03/13(日) 17:06:55.70

スレの終わりに切り替えて結構すんなりワッチョイスレに移行できたスレ多いよ。途中でもうまくいくかはよくわからん。
何れにせよ、スレが機能してないよりは過疎のほうがマシだな

**デフォルトの名無しさん** · 2022/03/13(日) 17:17:53.93

変化が多い言語でデファクトも定まってないし、ワッチョイ付けてもたぶん過疎らないと思うけどな

**デフォルトの名無しさん** · 2022/03/13(日) 17:27:03.14

そもそもみんなまともにrustの話をしたいのに
おじさんが関係ない自演で横から茶々入れるから
みんなめんどくさくなっていなくなるのよ
その自覚はある？

**デフォルトの名無しさん** · 2022/03/13(日) 17:37:09.51

ワッチョイスレはもうあるぞ
ここからさらにワッチョイスレ作っても分岐して打ち捨てられたワッチョイスレが増えていくだから先にこっち消費してくれ

https://mevius.5ch.net/test/read.cgi/tech/1532697692/

**デフォルトの名無しさん** · 2022/03/13(日) 17:47:33.76

>>465
質問者？issueで質問者って何の話してんだよｗ
全部読んで少なくともその中にないことを証明するんだぞｗ
どこを読んでそう書いてあったのかすらないのでは、証明にはならないｗ
約 567,000 件あるけどなｗ

Run cargo-geiger!
💀💀💀☢☢☢☢💀💀💀 !!!! Rust is ☢UNSAFE☢ !!!! 💀💀💀☢☢☢☢💀💀💀

**デフォルトの名無しさん** · 2022/03/13(日) 17:50:57.99

今回のやつはずっと同じIDの上に
文面から即NGできるにもかかわらずしつこく構ったやつらが悪い

反省しろ

**デフォルトの名無しさん** · 2022/03/13(日) 18:17:55.15

かつて自治厨と言われた俺の手腕を発揮してやるよ
最近はそこまでの情熱は無くなったが去年あたりからrust始めたからまともに議論したいのよ

**デフォルトの名無しさん** · 2022/03/13(日) 18:37:10.97

荒らされるよりは過疎るほうがマシ
ワッチョイひとつでこの手合はピターッと来なくなるから

**デフォルトの名無しさん** · 2022/03/13(日) 18:40:27.18

そう思うならさっさとワッチョイスレ立てればいいじゃん
なんでやらないの？

**デフォルトの名無しさん** · 2022/03/13(日) 18:42:49.11

ﾜｯﾁｮｲ有りRustスレは既に>>470にあるので使い分ければよい
ここはﾜｯﾁｮｲ無しRustスレなので次スレもﾜｯﾁｮｲ無しで行く
両方あれば全員に不満はない

**デフォルトの名無しさん** · 2022/03/13(日) 18:50:17.44

使ってないスレを再使用するのはスレを無駄にしないという点では有意なんだけど、勢いもスレ順も変だから人はあんまり来ないのよね。で、何も知らずに来た人が荒らしにかまってしまう。
何れにせよ15がワッチョイ無しというのはありえない選択肢。

**デフォルトの名無しさん** · 2022/03/13(日) 19:25:23.33

>>477
ここはﾜｯﾁｮｲ無しRustスレの系統
だからここの次スレはﾜｯﾁｮｲ無しで確定している

ﾜｯﾁｮｲ有りRustスレは立てられても放置されるという歴史がある
再び放置スレを増やすようなことをしてはいけない
以下に現存するﾜｯﾁｮｲ有りRustスレがある

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

Rust part6【ﾜｯﾁｮｲ】
https://mevius.5ch.net/test/read.cgi/tech/1532697692/

**デフォルトの名無しさん** · 2022/03/13(日) 19:30:16.97

自分たちが他スレ嵐てんのに自分たちにワッチョイ付ける訳ない。己のやってることを顧みろ

**デフォルトの名無しさん** · 2022/03/13(日) 19:30:24.22

>>477
そう思うならワッチョイスレ盛り上げろよ
せめてpart6埋めてからワッチョイpart7を立てて盛り上げる方向にしろよ

**デフォルトの名無しさん** · 2022/03/13(日) 19:33:25.71

>>478
歴史と言いながらサンプル少ないっすね

**デフォルトの名無しさん** · 2022/03/13(日) 19:35:38.48

「荒らされるよりは過疎るほうがマシ」って言いながらこのスレに書き込んでワッチョイpart6使ってないのってどういうことなの

**デフォルトの名無しさん** · 2022/03/13(日) 19:38:33.24

そんなにワッチョイが嫌なんだね。じゃあ次スレはワッチョイ有りにしよう。別にデメリット殆ど無いし。

**デフォルトの名無しさん** · 2022/03/13(日) 19:39:58.52

それ語尾wがワッチョイなし立ててそっちが盛り上がって使われないワッチョイpart15が打ち捨てられる未来しか見えない

**デフォルトの名無しさん** · 2022/03/13(日) 19:41:14.03

>>483
ﾜｯﾁｮｲ有りRustスレは既に2つもある >>478
ここﾜｯﾁｮｲ無しRustスレの次スレはもちろんﾜｯﾁｮｲ無し
両方あれば全員に不満はない

**デフォルトの名無しさん** · 2022/03/13(日) 19:42:49.67

>>484
フェアでいいじゃない。やってみようよ

**デフォルトの名無しさん** · 2022/03/13(日) 19:43:29.58

>>486
やってみてもいいけどワッチョイなしが過疎ったら責任とって埋めろよ

**デフォルトの名無しさん** · 2022/03/13(日) 19:45:38.16

>>487
ワッチョイなしじゃなくてワッチョイありざ過疎ったらの間違い

**デフォルトの名無しさん** · 2022/03/13(日) 19:53:00.16

次スレ自体はどうするん？
>>980 が新規で立てるか >>980付近で既存スレの古いスレに誘導するのか

**デフォルトの名無しさん** · 2022/03/13(日) 19:59:09.05

ここﾜｯﾁｮｲ無しRustスレはいつも通り
ﾜｯﾁｮｲ無しで次スレを立てることになる
ﾜｯﾁｮｲ有りRustスレは既に2つある>>478
両方あれば全員に不満はない

**デフォルトの名無しさん** · 2022/03/13(日) 20:25:42.25

よしでは方針を発表しよう

そのﾜｯﾁｮｲありスレはおじさんが謎にageてるから
いまだに存在しているものと認識している
つまり既に侵食済みなので捨てる

Part15からﾜｯﾁｮｲありスレとして継続していく
異論がなければこれで行く

**デフォルトの名無しさん** · 2022/03/13(日) 20:39:16.20

確かによく見たら4は腐ってるな
でも6は使えるだろ。使ってくれ

**デフォルトの名無しさん** · 2022/03/13(日) 20:40:29.94

>>491
それで行こう

**デフォルトの名無しさん** · 2022/03/13(日) 20:41:14.82

それはﾜｯﾁｮｲに効果がないことを示してるだけでは
報復のような行動や分断を産む議論は思う壺だと思う
黙ってNGに放り込めばいい

**デフォルトの名無しさん** · 2022/03/13(日) 20:55:14.52

そもそもワッチョイにデメリットは無くてメリットだけなんだからカジュアルに入れればいいじゃん。
一人だけ急にここはワッチョイ無しスレの系譜なんて言い出した人もいるけど。そんな系譜無いし。

**デフォルトの名無しさん** · 2022/03/13(日) 20:58:11.86

デメリットはどうせ分裂してワッチョイ15という過疎放置スレが無駄に出来ることだけなので、そうなった時にちゃんと埋めてくれるならなんのデメリットもない

**デフォルトの名無しさん** · 2022/03/13(日) 21:04:18.91

ワッチョイ必要だと思うならごちゃごちゃ言わずにさっさと自分で立てろよ
スレ立てくらい出来るだろ

**デフォルトの名無しさん** · 2022/03/13(日) 21:19:00.22

ﾜｯﾁｮｲだから過疎ったんじゃなくてスレを複数作ったから過疎ったってことよ
スレを使い分けようって時点で問題児だらけデース！ってアピールしてるよ

今回のunsafeおじさんが暴れてた頃に誰もﾜｯﾁｮｲスレに誘導しなかったところを見ると、存在すら忘れてたんじゃないか？
https://mevius.5ch.net/test/read.cgi/tech/1532697692
↑火種になりそうな人、話題は全部ﾜｯﾁｮｲに誘導しようね。火種に触る人もﾜｯﾁｮｲに行こうね

**デフォルトの名無しさん** · 2022/03/13(日) 21:35:47.25

タイトルが同じだと数字が小さいスレに人がよりつかないのは当然なので
質スレと議論スレにでも分割して議論スレをワッチョイスレとして新たに始めればいいんじゃない？
議論したいってことみたいだから

誰も立てないからここ2回連続してスレ立てたけど
立てたらワッチョイガーとか繰り返し言われるのはさすがに腹が立つよ
問題は荒らしを相手にしてる人たちなのに

**デフォルトの名無しさん** · 2022/03/13(日) 21:48:32.41

ま、次スレからワッチョイでいいやん
荒らし目的の人はサヨナラしてくれていいやん
スレがノイズまみれになるのは目が滑ってしんどい

**デフォルトの名無しさん** · 2022/03/13(日) 21:51:18.28

強引な変更には断固反対
少なくとも現状のワッチョイなしのスレも残すべき

**デフォルトの名無しさん** · 2022/03/13(日) 21:54:24.52

>>500
せやなー、次からワッチョイありで

>>501
荒らしたいの？

**デフォルトの名無しさん** · 2022/03/13(日) 22:12:56.56

別にワッチョイにしたかったら両方作ればええやんｗ
俺は両方に反応するからｗ
ワッチョイなら一週間はNG設定変えなくていいんじゃないのｗ
ただ被るやついても俺のせいにするなよｗ

Run cargo-geiger!
💀💀💀☢☢☢☢💀💀💀 !!!! Rust is ☢UNSAFE☢ !!!! 💀💀💀☢☢☢☢💀💀💀

**デフォルトの名無しさん** · 2022/03/13(日) 22:14:37.13

荒らしてるのはGoの連中だろ。
報復するべし。

**デフォルトの名無しさん** · 2022/03/13(日) 22:16:30.17

この程度の勢いのスレではそう簡単にワッチョイ被らない

**デフォルトの名無しさん** · 2022/03/13(日) 22:19:11.42

いや・・・前1日で4人被ってたぞ俺にｗ割と人の多い地域で割と大手のプロバイダだから被りやすいんだｗ
まあ俺は言ったからなｗ

Run cargo-geiger!
💀💀💀☢☢☢☢💀💀💀 !!!! Rust is ☢UNSAFE☢ !!!! 💀💀💀☢☢☢☢💀💀💀

**デフォルトの名無しさん** · 2022/03/13(日) 22:24:37.54

どうでもええよ
今後もワッチョイの無いスレに書き込むし
スレが無ければワッチョイ無しで立てるから

**デフォルトの名無しさん** · 2022/03/13(日) 22:49:01.50

ワッチョイスレの方が過疎化して完走できないことになると誰でも予想できる

**デフォルトの名無しさん** · 2022/03/14(月) 01:57:42.50

rustならわっちょいつける方がらしくはあるな。言語思想がそういう感じだし。

**デフォルトの名無しさん** · 2022/03/14(月) 06:10:44.25

たし蟹

**デフォルトの名無しさん** · 2022/03/14(月) 07:47:11.82

Linux環境のrustでkbhit関数（キーイベントの取得）ってありますでしょうか？
コンソールアプリ（ゲーム）を作ときに使用しようと思ってまして

**デフォルトの名無しさん** · 2022/03/14(月) 08:02:53.43

真面目な質問はワッチョイありに書き込んでワッチョイ無しスレから誘導すればいいよ。

ワッチョイ無しスレは過疎らないし、ワッチョイスレは荒らしNGできるし文句言うやつは荒らし以外おるまい。
スレの再利用もできるしな。

**デフォルトの名無しさん** · 2022/03/14(月) 11:19:45.82

https://tech.aptpod.co.jp/entry/2021/12/03/070000

これとかそれっぽい？
でもcratesはそれっぽい名前の奴ほど放置ライブラリという特長があるから正直調べ方がわからん

**デフォルトの名無しさん** · 2022/03/14(月) 12:57:45.51

Linuxでコンソールアプリだとncursesが思い浮かぶ
Rustでは使ったことないけど

https://crates.io/crates/ncurses

**デフォルトの名無しさん** · 2022/03/14(月) 13:19:49.96

あ、そうか。コンソールアプリか。じゃあcrosstermでいいのかも
https://docs.rs/crossterm/0.5.5/crossterm/enum.KeyEvent.html

**デフォルトの名無しさん** · 2022/03/14(月) 13:24:17.18

kbihitぽいのなら自分はtermion使ってます。
https://github.com/redox-os/termion/blob/master/examples/keys.rs

**デフォルトの名無しさん** · 2022/03/14(月) 16:56:04.09

# 俺様はcrosstermに一票ｗ
cargo install cargo-edit cargo-geiger
cargo new crossterm_example
cd crossterm_example
cargo add crossterm
cat >src/main.rs <<EOF
use std::time::Duration;
use crossterm::event::{poll, read, Event, KeyCode};
use crossterm::terminal::{enable_raw_mode, disable_raw_mode};
use std::io::Error;
fn main() -> Result<(), Error> {
enable_raw_mode()?;
loop {
if poll(Duration::from_millis(1_000))? {
let event = read()?;
println!("Event::{:?}\r", event);
if event == Event::Key(KeyCode::Esc.into()) {
break;
}
} else {
println!(".\r");
}
}
disable_raw_mode()
}
EOF
cargo build
cargo run
cargo geiger

# Run cargo-geiger!
# 💀💀💀☢☢☢☢💀💀💀 !!!! Rust is ☢UNSAFE☢ !!!! 💀💀💀☢☢☢☢💀💀💀

**デフォルトの名無しさん** · 2022/03/14(月) 23:31:15.69

>>511
Rustで書いてもstdinへの設定自体は他の言語の時と全く同じ
以下C言語風でRust的に書けるnixクレート使用

まずstdinがエコーされたり改行まで入力されないのを解除
let mut stdin = stdin();
let mut termios = tcgetattr(stdin.as_raw_fd())?;
termios.local_flags &= !(LocalFlags::ECHO | LocalFlags::ICANON);
tcsetattr(stdin.as_raw_fd(), SetArg::TCSANOW, &termios)?;
これでstdin.read()で1文字ずつ入力キーを得られる

次に入力がない時にブロックされないように設定
let mode = fcntl(stdin.as_raw_fd(), FcntlArg::F_GETFL)?;
let mode = OFlag::from_bits_truncate(mode);
fcntl(stdin.as_raw_fd(), FcntlArg::F_SETFL(mode | OFlag::O_NONBLOCK))?;
これで入力がなくてもstdin.read()がすぐに返ってくる

あとは自分の好きな仕様で例えば
let mut input = [0; 1];
let code = match stdin.read(&mut input) {
Ok(_) => Some(input[0]),
Err(ref err) if err.kind() == ErrorKind::WouldBlock => None,
Err(err) => Err(err)?,
};
これで入力ASCIIコードがOptionで得られる

他にも例えば非同期とチャネルを使ってインタフェースを洗練して
ノンブロッキングにせずともread()とチャネルへのsend()を繰り返す
というキー入力専用の非同期タスクを作って
使う側ではチャネルからpoll_recv()で入力があるか見るとか
あるいはそもそも入力なしという状態を得る必要がないならば
その非同期タスクでread()がある度に指定クロージャを呼び出すなど

**デフォルトの名無しさん** · 2022/03/14(月) 23:33:12.59

ちなみにstdinからのASCIIコード取得では不満で
もっとrawレベルのイベントが欲しいならば
libevdevをRustで扱えるevdev-rsを使う

**デフォルトの名無しさん** · 2022/03/16(水) 14:04:08.44

turbo rustはまだですか？