Rust part11

**デフォルトの名無しさん** · 2021/06/17(木) 00:24:12.56

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

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

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

**デフォルトの名無しさん** · 2021/06/19(土) 01:15:49.18

>>1 おつ

**デフォルトの名無しさん** · 2021/06/19(土) 01:20:06.41

>>1
乙

**デフォルトの名無しさん** · 2021/06/19(土) 02:14:18.53

勉強中でいまいちよくわかってないんだけどさ
よくRsutでメモリの扱いが安全になるとか言われてるけど、これって解放忘れを防いでくれるだけであって、オーバーフローを防いでくれるものではないわけ？
それとも登場する全ての型がオーバーフローしないような仕組み(スタックプロテクター以上の何か)があるの？

**デフォルトの名無しさん** · 2021/06/19(土) 03:26:44.04

>>4
型のオーバーフローっていうのは算術オーバーフロー(桁あふれ)のことかな？
であればここを読むといいと思う
https://doc.rust-lang.org/book/ch03-02-data-types.html#integer-overflow

**はちみつ餃子** ◆8X2XSCHEME · 2021/06/19(土) 04:22:00.60

スタックプロテクターの話題を出すってことは
バッファオーバーフロー (バッファオーバーラン) のことじゃないかな。

配列は大きさの情報を持っているし、
配列の一部の範囲を受け渡すときはポインタでなくスライスで扱うのが Rust の基本的な設計になってる。
ポインタと違ってスライスは範囲の情報を持っているのでチェック可能で、チェックする仕様になってるよ。
溢れたら panic する。
(もちろん unsafe な操作をしたらいくらでも危険な操作は出来る。)

絶対に溢れないことがコンパイル時に見抜ける場合であれば
チェックしないように最適化したりすることもあるし、
チェックする場合でも現代的な CPU ではほぼ確実に分岐予測が成功するから
処理速度が遅くなる分は十分に小さいとかいう話があったはず。

**デフォルトの名無しさん** · 2021/06/19(土) 09:47:40.12

バッファオーバーフローのことなのか
Safe Rustでは基本的に発生しないが仕組みというより
unsafeなコードを書く人が要求された安全性を保証するという約束の上に成り立ってる

Rustの要求するメモリ安全性を保証するためには
unsafeなコードでポインタをdereferenceする前にout-of-boundsかどうかのチェックが必要

**デフォルトの名無しさん** · 2021/06/19(土) 14:15:48.54

境界チェックなんて他の言語でもあるし、別にそこがRustの特別な強みではないんだよな
それよりは、

> これって解放忘れを防いでくれるだけであって

だけじゃなくて、use-after-freeとか、
思わぬ箇所でオブジェクトが変更されることによるデータ競合とか、
をコンパイル時にチェックできるのが強い

詳細はThe Book 4章に
https://doc.rust-lang.org/book/ch04-02-references-and-borrowing.html
日本語版はこっち
https://doc.rust-jp.rs/book-ja/ch04-02-references-and-borrowing.html

**デフォルトの名無しさん** · 2021/06/19(土) 15:41:11.20

解放忘れ（メモリーリーク）はRustは
保証してないのでは？

**デフォルトの名無しさん** · 2021/06/19(土) 16:32:09.25

Rc/Arc以外でメモリリークって起こるの？

**デフォルトの名無しさん** · 2021/06/19(土) 16:52:09.35

Box::leakして返された参照を捨てるとメモリリーク起こせる

**デフォルトの名無しさん** · 2021/06/20(日) 02:45:16.68

最近勉強始めたんだが、正直ムズイ

特にwinapiのポインタ引数が(構造体のポインタではなく)DWORDで定義されてたりするので、
キャストするのが超絶面倒臭い
microsoftはcrate修正してほしい

まあ、rustというよりwinapiの問題なんだが……

**はちみつ餃子** ◆8X2XSCHEME · 2021/06/20(日) 02:57:43.41

わかる。
DWORD とポインタをカジュアルに同一視する API はまだマシなほうで、
Rust は文字列をスライスで扱うから単純にポインタに変換してもヌル終端されてないのがクソめんどい。
文字列を渡すとかすごく普通にあることなんで、それがこんなに面倒くさいの勘弁して欲しい。

**デフォルトの名無しさん** · 2021/06/20(日) 06:34:35.27

普通に書いててwinapiとか使う機会ないと思うけどOS機能を直接触る必要のあるライブラリでも書いてるのかな?

**デフォルトの名無しさん** · 2021/06/20(日) 15:00:11.94

OS層に近いAPI全く使わないならrustやc++とかデメリットの方が多いような。

**デフォルトの名無しさん** · 2021/06/20(日) 16:38:08.85

俺も最近Rust勉強してるんだけど、GC無しでのメモリ管理が最高に気持ちいい
何もかもRustで書きたくなる

**デフォルトの名無しさん** · 2021/06/20(日) 17:33:03.51

ワイは基本moveってところが気に入ってる
参照をもって回るんじゃなくて
実態をmoveで渡してmoveで返されるとき清々しいのを感じる

**デフォルトの名無しさん** · 2021/06/20(日) 17:51:48.27

システムコールや低レベルなライブラリをいい感じに安全にラップしてくれるcrateが提供されてるのはrustの良いところ

**デフォルトの名無しさん** · 2021/06/20(日) 19:32:30.59

moveって最適化ビルドだと消えたりしてるのかな？

**デフォルトの名無しさん** · 2021/06/20(日) 21:04:33.39

moveが消えるとは？
moveがコンパイルされた結果のmemcpyなどが消えることはある

**デフォルトの名無しさん** · 2021/06/20(日) 22:37:40.54

>>13
Rustのスライスは、ほぼPascal文字列だから、Cよりも古くから作法や
概念は存在している。
しかし、なぜCがPascal文字列ではなく0終端文字列にしたのかには
理由があって、文字列の途中(部分文字列)を扱わない場合においては効率が良いから。
0終端文字列の欠点は、部分文字列を扱おうとするととたんに面倒なことになること。
ただ、strcmpみたいなものを書いたり、字句解析を書いたりするときには、効率は良い。
字句解析では決定性オートマトンの理論がグラフ的(状態遷移図的)になっており、
Cの0終端文字列とはとても相性が良い。
そして、コンパイラの実行時間の大部分は、実測してみると、意外にも字句解析が占めている。
字句解析は単純ではあるが、量が多いので1クロックの差がものをいう世界である。
ただ、Pascal文字列(スライス)が字句解析でも有利に働く場面はあるにはあるが。
どちらの方式が一方的に優れているとはいえない。

**デフォルトの名無しさん** · 2021/06/20(日) 22:45:58.47

>>21
すまん。今調べたら、Pascal文字列は、配列の先頭に文字数が
入っている特殊な形式で、スライスとはまた違うものだった。
今まで誤解していたわ。
Pascal文字列はダメだわ、全く意味無し。

ただ、俺が言いたかったのは、Rustのスライス方式も古くから概念自体は存在し、
Win32APIでもGetTextExtentPoint32()なんかが、ポインタと、その後に続く
文字数の両方を指定する方式を取っている。
このやり方は、文字列の中に 0x00 を埋め込まなくても部分文字列を扱えて
便利は便利。もしこれを部分文字列の場所を少しずつ変えていくようなの場合に、
0終端文字列でやろうとすると、効率が悪くなる。
ただ、いつでもスライスの方が0終端文字列より効率が良いという訳ではない。
それが>>21で言いたかったこと。決定性や非決定性オートマトンの考え方で字句解析を
する際には、Cの0終端文字列はスライスより効率が良い。

**デフォルトの名無しさん** · 2021/06/20(日) 22:54:46.58

読む価値無い文章をダラダラ書いちゃうのって
なんらかの障害なんやろな

**デフォルトの名無しさん** · 2021/06/21(月) 00:08:08.49

>>22
そのせいでPascal文字列は長さ255文字までに制限されてたのよな。

**デフォルトの名無しさん** · 2021/06/21(月) 00:46:14.79

結論は、Rustがそんなにすばらしい言語とは到底思えないということだ。

**デフォルトの名無しさん** · 2021/06/21(月) 02:03:12.76

ええんやで

**デフォルトの名無しさん** · 2021/06/21(月) 03:36:25.54

>>25 まぁ用途によるやろ
発展途上なところもあるし､そもそもRustが向いてないような用途もある

**デフォルトの名無しさん** · 2021/06/21(月) 07:39:35.72

>>13
様々な文字列処理をしたことがある人になら自明ですが
文字列を扱う場合は￥0終端よりもスライスのほうが圧倒的に有利です
例えば何段か深いディレクトリの絶対パスが与えられた時に各ディレクトリのリストを返す（つまりsprit）時
￥0終端方式だと元の文字列を書き換え破壊しない限りコピーが発生してしまいます
スライス方式だと書き換えもコピーも発生しません

これは正規表現によるパターンマッチングでも同じで￥0終端方式だと結果である部分文字列をコピーしなければ返せません
またHTMLやJSONなどの様々な構造データの解析結果でもそうです
JSON文字列を解析して内部構造化表現にする時もスライス方式ならば文字列のコピーが発生せずに済むわけです

**デフォルトの名無しさん** · 2021/06/21(月) 08:53:58.31

>>28
>文字列を扱う場合は￥0終端よりもスライスのほうが圧倒的に有利です

有利だろうが何だろうが、APIや過去の資産を活用するのに面倒という事実は何も変わらないが

**デフォルトの名無しさん** · 2021/06/21(月) 09:07:04.10

そういやRustの std::ffi::OsString って￥0終端なんだっけ？

**デフォルトの名無しさん** · 2021/06/21(月) 09:43:03.40

>>30
違う
null terminatedはCString

**デフォルトの名無しさん** · 2021/06/21(月) 11:29:12.30

>>29 FFIのことを考えつつスライスの恩恵(境界チェックなど)も受けるなら今のRustの文字列に最後に\0を入れるようにしたらいいと思ったけどなんでしないんやろ
\0分の1バイトぐらい今のPCじゃ問題にならないはず

**デフォルトの名無しさん** · 2021/06/21(月) 11:49:33.30

>>32
従来の &str (部分文字列) とnul終端文字列を区別しないといけないけど
型で区別しようとすると結局今のCStr/CStringと同じになるのでは
文字列は部分文字列含め全部Stringみたいにヒープアロケーションするなら良いけどさすがに効率が悪すぎる

**デフォルトの名無しさん** · 2021/06/21(月) 12:03:56.90

これps5は60fpsでます？？

**デフォルトの名無しさん** · 2021/06/21(月) 12:11:12.63

Rust違いです
ってかゲームのほうのRustって個別スレ無いんだね

**デフォルトの名無しさん** · 2021/06/21(月) 12:12:05.66

FFIが必要な箇所で
let cstr = std::ffi::CString::new(str);
すれば済む話だからね

Win32APIだと\0終端の2バイト文字も渡したりするからCStringでも使い勝手悪そう
let wcstr: Vec<u16> = std::ffi::CString::new(str).to_str().unwrap().encode_utf16().collect();
で動くかな（試してない）
こっちは自分で'\0'足す方が簡単かもしれない

**デフォルトの名無しさん** · 2021/06/21(月) 12:43:27.64

>>28
気持ちは分かるし、実際、その例に挙がっているケースではそうなんだけど、
字句解析は、コンパイラ理論の状態遷移図に基いて行うと効率が良いが、
それは 0 終端文字列の方が効率が良い。

**デフォルトの名無しさん** · 2021/06/21(月) 12:53:52.20

何度も言うが、全面的にスライスが良いならC言語でも0終端文字列をやめに
してしまえばいいのだが、そういう訳ではない。
>>28 に挙がっているようなケースで、自分も同じような気持ちになったことは有るが、
一方で 0終端文字列の方が効率が良い例も少なからず存在しているので全面的に
スライス方式に変えてしまうのは難しい。
一番単純な例を書けば、英大文字の部分だけを読み飛ばす場合、

(1) ptrが0終端文字列を挿している場合:
while ( *ptr >= 'A' && *ptr <= 'Z' ) ptr++;

(2) (ptr, len)でスライス文字列を表現している場合 :
int cnt = 0;
while ( cnt < len && *ptr >= 'A' && *ptr <= 'Z' ) {ptr++; cnt++;}

後者だと、cnt < len と cnt++; の部分が追加されて効率が落ちる。

**デフォルトの名無しさん** · 2021/06/21(月) 13:02:34.21

Linuxカーネル開発における「Rust」採用の動き、グーグルとISRGがさらなる後押し
https://japan.zdnet.com/article/35172646/

> Googleは、ウェブサーバーソフトウェアの「Apache HTTP Server」向けのモジュールをRustによるモジュールで置き換えるというISRGのプロジェクトも支援している。

**デフォルトの名無しさん** · 2021/06/21(月) 13:11:18.52

windows apiを使ってメッセージダイアログボックスを表示するサンプルが載ってるサイト教えてください

**デフォルトの名無しさん** · 2021/06/21(月) 13:25:05.28

>>38
今のcpuとコンパイラの最適化で両者にどれくらいの性能差があるか示したベンチマークなどある？

rustでも文字列末尾に0を差し込めば同じことはできるので、本当に速くなるなら最適化の手法として採用しても良いかもしれない

**デフォルトの名無しさん** · 2021/06/21(月) 13:41:31.99

>>41
試しに手元の環境で1GB分やってみたが1割くらい差があるね
コンパイラはgcc9
でもRustの文字列ってnull文字含むことができるんじゃなかったっけ？試したことないけど

**デフォルトの名無しさん** · 2021/06/21(月) 13:52:57.02

>>40

use winapi::um::winuser::*;

fn main() {
let str: Vec<u16> = "Hello, world!".encode_utf16().chain(Some(0)).collect();
unsafe{
MessageBoxW(std::ptr::null_mut(), str.as_ptr() , str.as_ptr(), MB_OK);
}
}

**デフォルトの名無しさん** · 2021/06/21(月) 14:00:39.66

設計判断ってのは常にトードオフの選択だからな
ヌル終端にすることで得られるものと失うものを天秤にかける必要がある

得られるものしか見ないやつは設計からは手を引け

**デフォルトの名無しさん** · 2021/06/21(月) 14:01:15.31

トレードオフね
あー恥ずかし

**デフォルトの名無しさん** · 2021/06/21(月) 14:13:19.21

ああトードオフは重要だよな

**デフォルトの名無しさん** · 2021/06/21(月) 14:31:05.42

>>38
ptrとlenが分かってるなら別途カウントアップしていかなくても
どの位置のptrまで読めばいいか最初に分かるんじゃない？

**デフォルトの名無しさん** · 2021/06/21(月) 14:45:15.77

Rustってなんでprintlnの後にビックリマークあるの？

**デフォルトの名無しさん** · 2021/06/21(月) 14:51:45.48

>>47
確かに。end_ptrとの比較で終了判定した場合は(1)と差はなかった
比較一個分くらいなら今どきのプロセッサの並列実行で
十分吸収できるということかな

**デフォルトの名無しさん** · 2021/06/21(月) 14:58:01.41

>>48
printlnは関数じゃなくマクロだから
ちなみにマクロにしてる理由は引数の型と個数が不定だから

**デフォルトの名無しさん** · 2021/06/21(月) 15:29:27.47

>>43
先輩ありがとうございます！

**デフォルトの名無しさん** · 2021/06/21(月) 15:40:08.22

そういや、可変長引数を直接書けないからRustはクソって言う人はまだ見た事ないな
あんまり使わないからかな？

**デフォルトの名無しさん** · 2021/06/21(月) 16:23:01.35

>>42
文字列中にNULが含まれないことを前提とした最適化だから
NUL含む場合は使えないという制約はあるね
Cの文字列と同じ制約だから実用上あまり困らないんじゃないのかな知らんけど

**デフォルトの名無しさん** · 2021/06/21(月) 16:29:47.09

>>52
Cで可変長引数使いたくなるのってprintf系関数以外なんかある？

**デフォルトの名無しさん** · 2021/06/21(月) 16:52:01.19

>>54
ない
標準関数ではprintfとscanfだけ

**デフォルトの名無しさん** · 2021/06/21(月) 17:01:59.90

>>47
なるほど、こういうことかな：
(2)' (ptr, len)でスライス文字列を表現している場合 :
int btm = ptr + len;
while ( ptr < btm && *ptr >= 'A' && *ptr <= 'Z' ) {ptr++;}

>>49
差は少なくはなるが、無くなるわけではない。
ptr < btm という部分が残るから。整数比較命令と条件jmp命令の
合計2命令はまだ(1)より多い。

**デフォルトの名無しさん** · 2021/06/21(月) 17:23:50.71

>>56
そりゃ命令数に差があるのは当然だけど
現代的なプロセッサの並列発行や分岐予測を考慮して
なおパフォーマンス差があるかを見たかっただけなので
そちらは実際測定して差を確認できた？

**デフォルトの名無しさん** · 2021/06/21(月) 17:32:00.25

議論するのそこ？
むしろセキュリティ(バッファオーバーランの危険性)とパフォーマンスを秤にかけて
rustはセキュリティの方を採用したってだけじゃない？

パスカル文字列なんて昔からあったわけだし

**はちみつ餃子** ◆8X2XSCHEME · 2021/06/21(月) 17:54:38.56

>>52
どうしてもやりたければビルダーパターンでまとめてから渡すイディオムが確立してるから
そんなに不満にもならないんじゃない？

**デフォルトの名無しさん** · 2021/06/21(月) 18:00:00.24

>>58
いや安全な方を選んだってのはそのとおりだと思うけど
理論上遅いはずってのを実際測るとそうでもなかったってのはよくある話で
そこが気になっただけ

**デフォルトの名無しさん** · 2021/06/21(月) 18:49:34.95

>>60
rustが組み込みも視野に入れている以上、現代的なプロセッサは当てにできないと思う
8bitマイコンとかでrustが動くのかどうかはわからないけど

**デフォルトの名無しさん** · 2021/06/21(月) 19:12:19.82

>>61
別にRustはあらゆるアーキテクチャでのパフォーマンスを保証するつもりはないと思うけどね
実際測定してるのはTier1環境だけだろうし

**デフォルトの名無しさん** · 2021/06/21(月) 21:14:54.92

winapiクレートを使うことってもうなくね？
Microsoft公式のwindiwsクレートの方がよっぽど使いやすいよ

**デフォルトの名無しさん** · 2021/06/21(月) 21:47:08.31

>>38
＞(1) ptrが0終端文字列を挿している場合:
＞while ( *ptr >= 'A' && *ptr <= 'Z' ) ptr++;

その場合でも、まず与えられたデータが0終端しているかどうかを確認する必要がありますよね。
データがどこから来るのかは、
ネット上の通信相手か
ディスク上のファイルか
メモリ上の他言語等APIかになりますが、
いずれも盲目的に信頼せずに処理する必要があります。

そして小さいデータならばどんな処理方法でも誤差になるのでしょうが、
大きなデータの場合は>>28のように元はJSONとかHTMLのように構造をもっており、
その解析結果である各一部分が対象文字列になります。
すると0終端させた方がわずかに速く扱える可能性があるからといって、元の大きなデータから毎回コピーして0終端文字列を作る場合と、
コピーをせずにスライスのまま部分文字列を扱う場合との、比較になるのでははいでしょうか？

**デフォルトの名無しさん** · 2021/06/21(月) 22:00:11.19

>>64
>元の大きなデータから毎回コピーして0終端文字列を作る場合

どこからコピーの話が出た？

**デフォルトの名無しさん** · 2021/06/21(月) 22:22:17.51

>>65
変更したくない文字列"あいうえおかきくけこ"から部分文字列"かき"を取り出す場合、
スライス式だと元の文字列の[5:7]の範囲という形で表現できるからコピー不要だけど
ナル終端式だと"く"が邪魔で"かき\0"にできないからどこかに"かき"のコピーが必要になる

って話が>>28に出てる

**デフォルトの名無しさん** · 2021/06/21(月) 22:57:58.01

>>66
なるほど、理解した

**デフォルトの名無しさん** · 2021/06/21(月) 22:58:56.43

その比較は部分文字列をコピーするかスライスで表現するかの違いであって
0終端文字列のメリット・デメリットとは少し違うんじゃない？
0終端でも同じようにスライスを(ptr, len)で作ればコピーは不要

**デフォルトの名無しさん** · 2021/06/21(月) 23:46:42.70

>>68
> 0終端でも同じようにスライスを(ptr, len)で作ればコピーは不要

それをやってしまうとその部分文字列に対して0終端のメリットが効かなくなるわけで
コピーしないとメリットを得られないというのがデメリットになってる

**デフォルトの名無しさん** · 2021/06/22(火) 02:10:06.59

つまり部分文字列を扱う場合は、コピーが発生する0終端方式が不利になりますね。
具体的にファイルパスからディレクトリ部分を得るとか、URLからホスト名を得るとか、元データを破壊したくない時は0終端方式だとコピーするしかないです。
つまり一貫してRustのように始点＆長さ方式の方が、有利かつメモリ安全ではないでしょうか？

さらに文字列比較の場合も長さ方式よりも0終端方式が不利です。
これはCのmemcmpとstrcmpの比較に還元されますが、
memcmpは64bit比較やSIMD利用ができるからです。

**デフォルトの名無しさん** · 2021/06/22(火) 02:44:25.97

&strって3つの意味があると思うんだよね
1: 文字列リテラル
2: Stringの参照
3: 部分文字列
文字列リテラルとStringは終端にNULLを付けるようにして(今まで通りlenやcapは残す)､部分文字列は部分文字列を意味する別の型を作ればいいと思った
こうすることでRust側ではlenやcapを使い､C側ではNULL終端を利用できるという状態になる(Stringや&strをRustで使ってもCで使ってもゼロコスト)
もしNULL終端ではない部分文字列をCで使いたければStringに変換すれば使えるようになる(これはコストがかかるけどCの文字列も同じ問題を抱えてるので問題なし)

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

>>70
それやるには文字列がimmutableでなければならないから、それによって生じるスペースコストとどっちをとるかって話だな。
それにimmutableな文字列って、部分変更に相当する処理をする場合に逆にコピーが必要になるし。
どっちにしても一概に、コピー不要だからこっちが有利、みたいな話にはならんかと。

**デフォルトの名無しさん** · 2021/06/22(火) 12:15:08.38

rustで初心者がハマるポイントを初心者が紹介します

・所有権の概念が難しい
・何をするにしても外部ライブラリが必要（乱数生成など）
・ポインタが難しい

**デフォルトの名無しさん** · 2021/06/22(火) 12:16:52.83

・検索すると同名のゲームの話ばかり出てくる

**デフォルトの名無しさん** · 2021/06/22(火) 12:26:02.44

・static変数の扱いが面倒臭い

**デフォルトの名無しさん** · 2021/06/22(火) 12:52:20.13

>>64
>その場合でも、まず与えられたデータが0終端しているかどうかを確認する必要がありますよね。
「0終端文字列」
というのは、必ず0終端されている文字列の事なので確認は不要。
それを明確にするために、C言語では、const char *pszText; のように、
psz という接頭辞をつける流儀がある。
psz = pointer to string ending with zero.
　　　「0で終端している文字列へのポインタ」
という意味。これは、単なる const char *ptr; とは意味が異なる。
char c = 'A';
const char *ptr = &c;　　// 単なる文字へのポインタ。0終端されていない。
char szText[] = "Hello";　// 0終端文字列。0終端されている。
const char *pszText = szText;　// 0終端文字列へのポインタ。0終端されている。

**デフォルトの名無しさん** · 2021/06/22(火) 13:23:35.92

>>76
ファイルから読んだデータをpszHogeに格納するときにゼロ終端の要件満たしてるか確認する必要あるよねって話だぞ

**デフォルトの名無しさん** · 2021/06/22(火) 13:25:24.28

>>74がマジで深刻すぎる
ついでに加藤純一っていうゲーム実況者とかとじゅんっていうRust/Scala使いがいるのも紛らわしい

**デフォルトの名無しさん** · 2021/06/22(火) 13:35:53.88

>>76
>というのは、必ず0終端されている文字列の事なので確認は不要。

という考えで脆弱性を量産してきたC言語の負の歴史を顧みて
Rustを始めとした新しい言語は異なる文字列表現を採用してるわけだ

**デフォルトの名無しさん** · 2021/06/22(火) 14:06:03.07

>>77
コンピュータの世界で「確認」とは、データの中を検査するという意味で
使われるが、そういうことは不要。
自分で末尾に 0 を書き込む必要があるだけ。

**デフォルトの名無しさん** · 2021/06/22(火) 14:15:33.98

そこで確認不要とか言ってるからユーザにヌル文字含んだ文字列渡されて死ぬのでは

**デフォルトの名無しさん** · 2021/06/22(火) 14:51:42.58

セキュアプログラムは面倒だからなー
数値のオーバーフローチェックとかみんなやらないでしょ？
アップキャストして値に結果を放り込んでチェックした後、
ダウンキャストするとか面倒すぎる

**デフォルトの名無しさん** · 2021/06/22(火) 15:18:09.96

>>73
Cより面倒臭そうω

**デフォルトの名無しさん** · 2021/06/22(火) 15:19:46.85

>>76
そこまで出鱈目な話初めて聴いたわ

**デフォルトの名無しさん** · 2021/06/22(火) 15:22:37.78

>>81
そういう外部からの入力に対するエラーチェックはするのは当然だが、
0終端文字列でやる場合には、ファイルのバイト数だけ読み込んで、
一番最後に 0 を書き込んでおくとそれ以上まで進むことはない。
途中の 0 に関してはスライス方式でも同じ問題が残る。
途中に 0 が有っても大丈夫な様に作るだけ。

**デフォルトの名無しさん** · 2021/06/22(火) 15:24:47.81

>>84
ちなみに、リアルワールドでは俺は名プログラマだと評価されているぞ。

**デフォルトの名無しさん** · 2021/06/22(火) 15:27:25.45

良いプログラムを作るための基本ポリシー：
・外部データと内部データは明確に分ける。
・外部データを内部データに入れる場合は、エラーチェックを徹底的にする。
・内部データに関しては、原則的には完全に正しいことを前提にしてプログラム
　して良い。ただし、プログラムのミスのための念のためのチェックはしても良い。

**デフォルトの名無しさん** · 2021/06/22(火) 15:47:48.20

>>87
３番目のチェックはアサーション（assert）だと思うけどあれはコードを読む人に背景の条件を明示する意味もあるね
逆にアサーション以外の余計なチェックはコードを読む人を混乱させる可能性がある

**デフォルトの名無しさん** · 2021/06/22(火) 16:20:58.03

ヌル終端はパンチカードが現役だった時代に数バイトケチった名残

互換性のためにサポートしなきゃいけないのは理解できるが
今の時代にヌル終端が優れてるとかそれをデフォルトにしろってのは控えめに言って頭おかしい

**デフォルトの名無しさん** · 2021/06/22(火) 16:22:09.51

>>87
外部と内部の定義プリーズ

**デフォルトの名無しさん** · 2021/06/22(火) 16:30:14.48

>>90
外部でーたとしては、他にも有ると思うが、一例としては、

1. 他人が自由に書けるファイルから読み取ったばかりのデータ。
　(アプリケーション内部にリソースデータとして内蔵し、安全性が
　テスト済みであるようなファイルは内部データとみなしても良い場合も有る。)

2. 安全対策を徹底したいライブラリの場合は、ライブラリを使う側が関数に
　渡してきたテキストデータや引数の値。
　ただし、このようなものまで徹底的にチェックするとなれば遅くなるので、
　設計思想によっては、NO-CHECK、または、軽いチェックだけで済ましても良い。

3. OSの場合は、同様なものとして、APIを呼び出した側が渡してきたデータ。
　これは、安全性チェックは徹底して行う必要がある。

4. データベースソフトなどの場合も、2や3に準ずる。どこまで安全チェックするかは、
　使用目的や用途、設計思想による。

**デフォルトの名無しさん** · 2021/06/22(火) 16:34:27.28

ちょっと緩くないか？

**デフォルトの名無しさん** · 2021/06/22(火) 16:48:00.98

信頼境界線の引き方は諸説あるだろ。

**デフォルトの名無しさん** · 2021/06/22(火) 19:06:39.53

一般に、アプリの外に置いてあるファイルはチェックした方が良いが、
その中でも、テキストファイルは、信頼置け無い事が多いのでチェックは必要。
アプリの外に置いてあっても、バイナリデータだと人が手書きすることはないため、
設計思想にもよるが、安全チェックはある程度省略しても良いと考える流儀もありえる。

**デフォルトの名無しさん** · 2021/06/22(火) 19:33:50.85

結局アプリケーションがどう使われるか次第でしょ
アプリケーション作成時の前提が利用シーンの増加により後から覆されるなんてことは良くあることだから
性能要件がない限り最初から安全側に倒しておくのが合理的

**デフォルトの名無しさん** · 2021/06/23(水) 11:02:20.62

constデフォルトあたりの話ってgoto禁止論みたいになっている気がする
理由を理解していないがとりあえずそうしておけみたいな人を少なからず見かけるような

>>94
パーサーがガバガバで細工したセーブデータで乗っ取られるゲームのことか

**デフォルトの名無しさん** · 2021/06/23(水) 14:27:15.67

>>95
MS製のリンカ(link.exe)の入力するlibraryファイル(*.lib)には、
ヘッダ部分にシンボルがアルファベット順にソートされたシンボルテーブル
が入っている。ソートされていることを前提にバイナリサーチが出来るので
シンボルを検索するのが高速になるとされる。バイナリサーチは、ソート
されているデータに対してのみ正しく検索できて、もしソートされていなければ
間違った結果になる。
しかし、link.exeが*.libを入力する時、ちゃんとシンボルテーブルのシンボル
がソートされたかどうかチェックしているかと言うと、定かではない。
だから、もし、サードパーティー製のツールが*.lib を作成した時、
ソートにミスがあったりすると、link.exeはundefined symbolエラーを出すか、
リンクには成功するが、実行段階でアプリが起動できなかったり途中でダウン
してしまうかも知れない。その様な場合、何が原因かは分からないであろうが、
多分、実際、検査はされてない。

**デフォルトの名無しさん** · 2021/06/23(水) 14:30:46.54

>>97
実際は、サードパーティー製ツールも、ちゃんと*.libのヘッダのシンボルテーブルの
シンボルはソートしており、その部分にはバグはないので、それがソートされてない
*.libは基本的には存在しない。
ただし、*.libをバイナリエディタで開いて手作業で間違って変更したりすると
ソートされていないものが出来上がる。
それをlink.exeに入力しても、link.exeは、そのことに関してのエラーは出さない
だろう。

**デフォルトの名無しさん** · 2021/06/23(水) 16:29:36.30

Rustのスレだよね？

**デフォルトの名無しさん** · 2021/06/23(水) 17:44:15.71

小学生が大人に九九暗唱してみせれば微笑ましいが
大人が大人に九九暗唱してみせるなら不気味で滑稽である

**デフォルトの名無しさん** · 2021/06/23(水) 18:25:31.65

意図通りに動かないバグにつながるという話と
バッファオーバーフローみたいな脆弱性につながるという話は別だよね

**デフォルトの名無しさん** · 2021/06/23(水) 19:58:13.96

再帰を使って1x1=1から9x9=81までの答えだけを書く場合
どうやって書けますか？

**デフォルトの名無しさん** · 2021/06/23(水) 20:12:50.89

fixコンビネータを使う

**デフォルトの名無しさん** · 2021/06/23(水) 22:38:48.46

>>102
題意に沿ってるか分からんけど

fn main() {
f(1, 1);
}

fn f(a: u32, b: u32) {
//println!("{}x{}={}", a, b, a * b);
println!("{}", a * b);
match (a, b) {
(9, 9) => return,
(_, 9) => f(a+1, 1),
(_, _) => f(a, b+1),
}
}

**デフォルトの名無しさん** · 2021/06/23(水) 23:13:30.14

実践的な話をするとRustは末尾再帰最適化が出来ないからなるべく再帰は使わないほうがいいと思う

**デフォルトの名無しさん** · 2021/06/24(木) 01:50:53.81

宿題かなんかだろう。
Rustで宿題を課すなんて教官は変態にもほどがある。

**デフォルトの名無しさん** · 2021/06/24(木) 23:17:10.64

>>104の例だとtail recursionになっていないから
内部でloop化できる仮言語で書いてもこのように分解するしかなくて
f(1)
fn f(a) {
　 f2(a, 1)
　 f(a+1) if a != 9
}
fn f2(a, b) {
　 print `${a}x${b}=${a*b}`
　 f2(a, b + 1) if b != 9
}
結局のところ関数分割→個別ループ化→関数統合で二重ループ化まで自動でしてくれる言語は無いから
再帰は使わずに自分でループ化すればいいよね、って結論
つまりアルゴリズムでは再帰で考えても実装はループにしてコメント残しておくのが正解

**はちみつ餃子** ◆8X2XSCHEME · 2021/06/25(金) 00:17:11.72

>>107
プログラミング言語 Scheme の仕様だと >>104 のようなパターンは末尾文脈の定義にあてはまるし
末尾呼出し最適化が適用されることが保証されるから、
現代的な言語処理系で最適化できないとは信じられないんだけど、
実際にRust コンパイラに >>104 を与えたときにループに最適化はしないの？
Rust のコンパイラの使い方に不慣れでアセンブリコードの出力のさせかたがよくわからん……。

ほぼそのまま C のコードに書き換えてみたら
GCC ではジャンプに置き換えたコードが生成されるみたいだし……。
(ちなみに GCC では末尾呼出しになっていなくても一部の状況では再帰をループに変形できることがある。)

Clang だとループを全部 unroll しやがった！

**デフォルトの名無しさん** · 2021/06/25(金) 11:49:33.37

c言語だと再帰が末尾呼び出し最適化されるかどうかがオプティマイズレベルで変わるからややこしい。
リリース版だと動くがデバッグ版だとスタックオーバーフローみたいな事になる。
単純な再帰ならループに書き直してもいいけど、相互再帰みたいなのは末尾呼び出し最適化してくれないと困る。

**デフォルトの名無しさん** · 2021/06/25(金) 11:58:36.77

あの、Rustの勉強のために逆引きサンプルwiki作ろうと思うんですけど
テンプレ殿堂入りを目指して作ってもいいですか？
もちろん広告は入れませんが、レンタルwikiが提供している広告は表示されるかもしれませんが。。。

**はちみつ餃子** ◆8X2XSCHEME · 2021/06/25(金) 12:05:43.49

>>110
目指すことは自由じゃないの。
皆がどう判断するかも自由だけど。

**デフォルトの名無しさん** · 2021/06/25(金) 12:18:21.65

先輩ありがとうございます！
受け入れてもらえるようなコンテンツを作ります！

**デフォルトの名無しさん** · 2021/06/25(金) 15:26:59.18

5chに閉じずに本家のコミュニティにも便利と思ってもらえるもの目指した方が良いのでは

**デフォルトの名無しさん** · 2021/06/26(土) 00:57:24.13

>>86
ただし石器時代のな

**デフォルトの名無しさん** · 2021/06/26(土) 02:18:19.63

>>114
ミンチメーカー、ではなくスパゲティメーカーとして恐れられてるかもな

**デフォルトの名無しさん** · 2021/06/26(土) 03:08:39.74

Rustと他の言語との違いについて興味深い観点で盛り上がってるスレ
特に後半

趣味でプログラミングの勉強するとしたら何言語がいい？
https://matsuri.5ch.net/test/read.cgi/morningcoffee/1623527901/

**デフォルトの名無しさん** · 2021/06/26(土) 12:15:14.01

斜め読みしかしてないから見逃してるかも知れないけどさんざん言い尽くされた話ばかりだった気が
そもそもRust自体はC++を置き換えることを目的にはしていない

**デフォルトの名無しさん** · 2021/06/26(土) 14:26:52.57

やたらC++と比較されるのはどっちもbetter Cの側面があるからだろうか
個人的にRustはCとScheme（Lisp）のハーフという印象
SchemeよりMLの方が近いらしいけどMLは使ったことないからよく分からない

手続き型で関数型を疑似表現したり関数型で手続き型を疑似表現する試みがあるけど
Rustはその中間を上手く埋めてる感じ

**デフォルトの名無しさん** · 2021/06/26(土) 14:33:02.82

> better Cの側面がある

はぁ？
お前がcもc++もrustもニワカなのは分かった
あと五年間は、カキコ無前にROMに徹してみてほしい

**デフォルトの名無しさん** · 2021/06/26(土) 15:07:09.40

>>119
急にどうしたんだ
better Cの意味が分からなかった感じ？

**デフォルトの名無しさん** · 2021/06/26(土) 15:16:37.21

実際にはRustはbetter D

**デフォルトの名無しさん** · 2021/06/26(土) 15:47:21.36

急に発狂する奴はどこの掲示板にもいる　気にするな

**デフォルトの名無しさん** · 2021/06/26(土) 16:24:43.50

わざわざ自演するようなことかね？

**デフォルトの名無しさん** · 2021/06/26(土) 16:34:36.83

mozillaのc++を安全に使う数多の取り組みに疲れ果てた結果出てきた新言語がrustなのでc++と比較されるのは当然

**デフォルトの名無しさん** · 2021/06/26(土) 18:03:00.84

この板全域に出没して何でもRubyと比較するガイジみたいなもんだろ
ここにはなぜかいないけど

**デフォルトの名無しさん** · 2021/06/26(土) 18:06:17.50

>>116
Rust布教スレになってんじゃん
不健全

**デフォルトの名無しさん** · 2021/06/26(土) 19:35:22.90

今から新規のプロジェクトをC++かRustで始めるとなったらRustの一択でしょう
つまりRustはbetter C++

**デフォルトの名無しさん** · 2021/06/26(土) 21:22:24.72

まったく何も資産がない新規であればそうかもしれんが

**デフォルトの名無しさん** · 2021/06/26(土) 21:36:19.59

>>118
どこらへんがschemeに近い？
よく知らんがschemeってカッコが一杯あって、再帰ばっかりしてるイメージなんだが

**デフォルトの名無しさん** · 2021/06/26(土) 21:43:00.01

つまり過去のしがらみのある案件は時間がかかり遅れるが
いずれも徐々にC++はRustへ置き換えられていく

**デフォルトの名無しさん** · 2021/06/26(土) 21:48:35.28

逆に枯れてる分野でしか実装されんわ

**デフォルトの名無しさん** · 2021/06/26(土) 21:51:34.18

emacsとあとなんだっけ？ SVGのライブラリ？が
オブジェクトファイル *.o 単位で少しずつCからRustに移植してたな

**デフォルトの名無しさん** · 2021/06/26(土) 22:01:32.26

librsvgだね

**デフォルトの名無しさん** · 2021/06/26(土) 23:01:02.22

>>129
ifとかmatchのブロックがそのまま値になるところが何となくS式っぽいんだよね
ブロックの最後の式が全体の値になるのも(begin ..)に近いし

**デフォルトの名無しさん** · 2021/06/27(日) 00:09:44.66

それは単に式指向という話なのでは

**デフォルトの名無しさん** · 2021/06/27(日) 00:12:27.99

MLの方が普通に近いな
パターンマッチとか束縛がletとかHMの型システムだとか

**デフォルトの名無しさん** · 2021/06/27(日) 01:36:30.56

一番近いのは Ocaml。なぜなら、かつてRustはOcamlで組まれていたから。
そして途中でコンパイラをRust自身に直したと聞いた。

**はちみつ餃子** ◆8X2XSCHEME · 2021/06/27(日) 03:28:07.65

Rust の Scheme っぽいところを探すとしたらマクロだろ。
伝統的な Lisp 系言語だと実行時の環境とマクロ展開時の環境を分けないが、
Scheme は分ける方針をとってる。
(実際には分けない実装をしている処理系もあるし、次の仕様の更新でどうなるか不透明だけど。)

**デフォルトの名無しさん** · 2021/06/27(日) 12:22:30.08

何に近いかでここまで盛り上がれるのだね
何も産まないのに

**デフォルトの名無しさん** · 2021/06/27(日) 12:24:39.60

Parkinson's Law of Triviality

**デフォルトの名無しさん** · 2021/06/27(日) 13:55:37.78

>>139
比較から何かを見出せる人もいるから何も産まないということはないよ

**デフォルトの名無しさん** · 2021/06/27(日) 14:24:31.82

そんなセンスのある人がここにいると思うのｗｗ？
センスないねｗ

**デフォルトの名無しさん** · 2021/06/28(月) 20:31:57.40

ちょっと見ないうちに色々変わる＋自分の理解が浅いせいで追いつけない

**デフォルトの名無しさん** · 2021/06/29(火) 16:25:09.28

RustのIDEでおすすめを教えて

**デフォルトの名無しさん** · 2021/06/29(火) 19:29:01.37

VSCode+rust-analyzerが定番

**デフォルトの名無しさん** · 2021/06/30(水) 01:32:52.11

bindgenって複雑なヘッダーだと全然駄目なんだなあ
殆どそれ目的でRustやってたのに

**デフォルトの名無しさん** · 2021/06/30(水) 09:59:01.57

>>146
実際に使ってみて初めて分かる問題点だね。

**デフォルトの名無しさん** · 2021/06/30(水) 22:36:50.05

>>146
CXXはどうですか？

**デフォルトの名無しさん** · 2021/07/03(土) 10:43:55.27

rust始めました！
ってゲームの方を始めてたネタをやろうと思ったけど
想像以上にクソゲー過ぎてダメだった
やっぱり言語の方がいい

**デフォルトの名無しさん** · 2021/07/03(土) 16:18:59.47

検索するとゲームの方と言語の方が出てきてややこしい
Rust(ゲーム)は名前変えてくれ...

**デフォルトの名無しさん** · 2021/07/03(土) 16:30:28.41

それな
go(一般動詞)も名前を変えてくれ

**デフォルトの名無しさん** · 2021/07/03(土) 16:48:51.41

GoはGolangって別名があるから問題ないけどRustに関してはRustLangとはあまり言わないのがなぁ

**デフォルトの名無しさん** · 2021/07/03(土) 17:18:42.64

まあそれはRustの問題ではないですが、クロス環境に問題を感じているなら、Haskellがお勧めですよ。
あわしろ氏がいつも言ってることですがね。

**デフォルトの名無しさん** · 2021/07/03(土) 18:23:28.50

rustlang言わない？

**デフォルトの名無しさん** · 2021/07/03(土) 19:07:06.86

そもそもオフィシャルのレポジトリ名がrust-lang/rustだし普通に言うのでは

**デフォルトの名無しさん** · 2021/07/03(土) 19:51:08.37

言わなくはないけどRustLangよりはRustと呼ばれることのが多い気がする
GoだったらGo(golang)とかGolangとか言われることが多いけど

**デフォルトの名無しさん** · 2021/07/03(土) 22:13:02.85

単にgoよりgooglabilityが高いことのあらわれじゃね
別にそんなに困ったこと無いけどな

**デフォルトの名無しさん** · 2021/07/03(土) 23:01:24.13

ていうかGoはもうgolangに改名したほうがいいと思う
Goではとにかく名前がクソすぎる
そもそもなんかダサいし

**デフォルトの名無しさん** · 2021/07/04(日) 00:56:25.25

goはogle（いやらしい目で見る）という名前のデバッガとセットで売り出す予定だったけど
ogleがこけたから残念な名前だけが残ってしまった

**デフォルトの名無しさん** · 2021/07/04(日) 01:51:19.90

Rustってゲームなかったっけ？

**デフォルトの名無しさん** · 2021/07/04(日) 05:17:25.91

あるからこまってる

**デフォルトの名無しさん** · 2021/07/04(日) 09:10:12.70

JuliaでAV女優ばっか出てくるのと一緒やな

**デフォルトの名無しさん** · 2021/07/04(日) 09:10:48.09

たいていは rust + 別の単語でググるけどゲームの情報が出てきて困ったことはあまりないかな

**デフォルトの名無しさん** · 2021/07/04(日) 09:12:10.94

pythonってそう考えるとなかなかいいネーミング

**デフォルトの名無しさん** · 2021/07/04(日) 09:13:21.27

そういやRustはツイッター検索だとかなり厄介だったな

**デフォルトの名無しさん** · 2021/07/04(日) 09:25:35.54

既存の名詞使うときは perl みたいにスペルに一ひねり加えるのが良いんだろうね
rust でやるのは難しいけど

**デフォルトの名無しさん** · 2021/07/04(日) 17:06:20.02

>>166
pearlとしなかったのは既存言語が存在した偶然みたいだけどね

phpは某雑誌がよく引っ掛かってたな

**デフォルトの名無しさん** · 2021/07/05(月) 22:26:57.75

Rust とかGoとか固有名詞やめてほしいよね。。。

**デフォルトの名無しさん** · 2021/07/06(火) 00:14:23.09

固有名詞でない言語名...
「名前を言ってはいけないあの言語」みたいな名付けかな

**デフォルトの名無しさん** · 2021/07/06(火) 00:37:05.95

既存の固有名詞じゃない方が珍しい気がする

**デフォルトの名無しさん** · 2021/07/06(火) 07:26:35.07

そう言う意味だとCとか最悪だな

**デフォルトの名無しさん** · 2021/07/06(火) 09:07:51.28

langを付けると意味が変わるしCは本当に検索ワードに迷う

**デフォルトの名無しさん** · 2021/07/06(火) 10:07:00.27

C++もtwitterでは検索できない。C#もだけど。
それは、わざとなんらかかの意図を持ってされていることかも知れない。
twitteの社長や技術者がC++が嫌いだとか。

**デフォルトの名無しさん** · 2021/07/06(火) 11:00:10.66

/ も無視されるし単純に記号が無視されるだけでしょ

**デフォルトの名無しさん** · 2021/07/06(火) 11:33:36.74

つまりまたもやlispが最強だと判明してしまったわけたな

**デフォルトの名無しさん** · 2021/07/06(火) 12:33:05.02

ガイジ度でRubyには勝てんだろ

**デフォルトの名無しさん** · 2021/07/06(火) 13:48:45.02

>>174
技術的には簡単に直せるのに直さないところに意図を感じる。

**デフォルトの名無しさん** · 2021/07/06(火) 15:47:25.27

技術的に簡単だと思うなら外部サービスとして提供してみたら？

**デフォルトの名無しさん** · 2021/07/06(火) 17:48:26.50

外部から伺い知れない部分について簡単に違いないと断言する人とは議論しとうない

**デフォルトの名無しさん** · 2021/07/06(火) 17:56:26.40

全文検索とか形態素解析を少しでもかじってたら簡単とは思えないはずなんだけどね。

**デフォルトの名無しさん** · 2021/07/06(火) 18:02:06.64

>>178
外部サービスとは？
内部の人がやるのは簡単でも、外部の人がやるのはとても大変。

>>180
俺は字句解析系はよくやっているので簡単に感じるが。

**デフォルトの名無しさん** · 2021/07/06(火) 18:08:31.76

人は陰謀論が大好きなんですよ

**デフォルトの名無しさん** · 2021/07/06(火) 18:15:25.48

字句解析と形態素解析や全文検索はまったくの別物だろう

**デフォルトの名無しさん** · 2021/07/06(火) 18:16:09.96

陰謀論とかじゃなくて、壊したい相手に不利なようにするのがアメリカ流なんだよ。
卑怯な手口だが、卑怯という概念にはあの国には無いのだろう。
あの国の連中は、ことごとくそういう手口で生き残っているから、そのうち
技術の進歩が遅れてある時、がさっと負けだすかも知れないな、GAFAMも含めて。

**デフォルトの名無しさん** · 2021/07/06(火) 18:17:03.75

>>183
形態素解析などに入る前に、例えば、C++をcppと同一視してしまえばいいんだ。

**デフォルトの名無しさん** · 2021/07/06(火) 18:20:48.86

簡単に直せる
(計算量が増えたり既存機能に影響を与えたりするかもしれないけど)

ってことでしょ

**デフォルトの名無しさん** · 2021/07/06(火) 19:17:37.60

>>186
それを簡単と呼ぶのは研究とかラボの人間よね。

**デフォルトの名無しさん** · 2021/07/06(火) 20:35:47.80

字句解析と形態素解析の違いもわからないのはちょっと…

**デフォルトの名無しさん** · 2021/07/06(火) 23:19:32.02

まーたrustと関係ない話してる

**デフォルトの名無しさん** · 2021/07/06(火) 23:35:07.67

「また」って言うけど「いつも」の間違いだろ？

**デフォルトの名無しさん** · 2021/07/07(水) 08:37:56.63

>>184
で、c++を壊してtwitterにどんなメリットが？アホなの？

**デフォルトの名無しさん** · 2021/07/07(水) 10:14:36.36

アホだと分かってるなら構うなよ

**デフォルトの名無しさん** · 2021/07/07(水) 10:38:37.05

https://lore.kernel.org/lkml/20210704202756.29107-1-ojeda@kernel.org/
panic問題は大部分解決されたみたい

**デフォルトの名無しさん** · 2021/07/08(木) 01:55:46.25

そういうのは形態素解析したあと、同義語辞書(シソーラス)で単語を正規化する作業になる。
形態素解析の段階で記号は除去しないとややこしくなるから記号入りの単語を使うのが悪いわな。

**デフォルトの名無しさん** · 2021/07/09(金) 19:08:10.80

ハッカーが使わない言語は流行らない。メモリ安全だけじゃ一部需要のみ

楽しい言語も流行らない。いつも趣味レベルの言語で終わる

**デフォルトの名無しさん** · 2021/07/09(金) 19:58:26.11

ハッカーって言葉久々に聞いた

**デフォルトの名無しさん** · 2021/07/09(金) 20:07:52.69

自分のこと賢いと思ってそう

**デフォルトの名無しさん** · 2021/07/09(金) 21:36:56.44

流行で選ぶってアフィチューバーやアフィブロガーかな？

**デフォルトの名無しさん** · 2021/07/10(土) 06:29:54.67

一通り学習したつもりになったから、WebAPIで情報取得するプログラムでもいざ書いてみようと思ったら・・・・
いきなりreqwestのクレートでasync/awaitの壁があったぜ
これThe Bookのキーワードの項目にはあるものの、本編で出てきたっけ？？？
https://doc.rust-lang.org/book/appendix-01-keywords.html
ちょっと適当に書いてみた感じ、他言語と違ってawaitしたところでアンラップされないのかな・・・・・？全然わからん
これって何を見たら学習できるの？

**デフォルトの名無しさん** · 2021/07/10(土) 07:10:52.64

これでいいんじゃない？
https://rust-lang.github.io/async-book/01_getting_started/01_chapter.html