Rust part11
レス数が1000を超えています。これ以上書き込みはできません。
勉強中でいまいちよくわかってないんだけどさ
よくRsutでメモリの扱いが安全になるとか言われてるけど、これって解放忘れを防いでくれるだけであって、オーバーフローを防いでくれるものではないわけ？
それとも登場する全ての型がオーバーフローしないような仕組み(スタックプロテクター以上の何か)があるの？ スタックプロテクターの話題を出すってことは
バッファオーバーフロー (バッファオーバーラン) のことじゃないかな。
配列は大きさの情報を持っているし、
配列の一部の範囲を受け渡すときはポインタでなくスライスで扱うのが Rust の基本的な設計になってる。
ポインタと違ってスライスは範囲の情報を持っているのでチェック可能で、チェックする仕様になってるよ。
溢れたら panic する。
(もちろん unsafe な操作をしたらいくらでも危険な操作は出来る。)
絶対に溢れないことがコンパイル時に見抜ける場合であれば
チェックしないように最適化したりすることもあるし、
チェックする場合でも現代的な CPU ではほぼ確実に分岐予測が成功するから
処理速度が遅くなる分は十分に小さいとかいう話があったはず。 バッファオーバーフローのことなのか
Safe Rustでは基本的に発生しないが仕組みというより
unsafeなコードを書く人が要求された安全性を保証するという約束の上に成り立ってる
Rustの要求するメモリ安全性を保証するためには
unsafeなコードでポインタをdereferenceする前にout-of-boundsかどうかのチェックが必要 境界チェックなんて他の言語でもあるし、別にそこが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 解放忘れ（メモリーリーク）はRustは
保証してないのでは？ Box::leakして返された参照を捨てるとメモリリーク起こせる 最近勉強始めたんだが、正直ムズイ
特にwinapiのポインタ引数が(構造体のポインタではなく)DWORDで定義されてたりするので、
キャストするのが超絶面倒臭い
microsoftはcrate修正してほしい
まあ、rustというよりwinapiの問題なんだが…… わかる。
DWORD とポインタをカジュアルに同一視する API はまだマシなほうで、
Rust は文字列をスライスで扱うから単純にポインタに変換してもヌル終端されてないのがクソめんどい。
文字列を渡すとかすごく普通にあることなんで、それがこんなに面倒くさいの勘弁して欲しい。 普通に書いててwinapiとか使う機会ないと思うけどOS機能を直接触る必要のあるライブラリでも書いてるのかな? OS層に近いAPI全く使わないならrustやc++とかデメリットの方が多いような。 俺も最近Rust勉強してるんだけど、GC無しでのメモリ管理が最高に気持ちいい
何もかもRustで書きたくなる ワイは基本moveってところが気に入ってる
参照をもって回るんじゃなくて
実態をmoveで渡してmoveで返されるとき清々しいのを感じる システムコールや低レベルなライブラリをいい感じに安全にラップしてくれるcrateが提供されてるのはrustの良いところ moveって最適化ビルドだと消えたりしてるのかな？ moveが消えるとは？
moveがコンパイルされた結果のmemcpyなどが消えることはある >>13
Rustのスライスは、ほぼPascal文字列だから、Cよりも古くから作法や
概念は存在している。
しかし、なぜCがPascal文字列ではなく0終端文字列にしたのかには
理由があって、文字列の途中(部分文字列)を扱わない場合においては効率が良いから。
0終端文字列の欠点は、部分文字列を扱おうとするととたんに面倒なことになること。
ただ、strcmpみたいなものを書いたり、字句解析を書いたりするときには、効率は良い。
字句解析では決定性オートマトンの理論がグラフ的(状態遷移図的)になっており、
Cの0終端文字列とはとても相性が良い。
そして、コンパイラの実行時間の大部分は、実測してみると、意外にも字句解析が占めている。
字句解析は単純ではあるが、量が多いので1クロックの差がものをいう世界である。
ただ、Pascal文字列(スライス)が字句解析でも有利に働く場面はあるにはあるが。
どちらの方式が一方的に優れているとはいえない。 >>21
すまん。今調べたら、Pascal文字列は、配列の先頭に文字数が
入っている特殊な形式で、スライスとはまた違うものだった。
今まで誤解していたわ。
Pascal文字列はダメだわ、全く意味無し。
ただ、俺が言いたかったのは、Rustのスライス方式も古くから概念自体は存在し、
Win32APIでもGetTextExtentPoint32()なんかが、ポインタと、その後に続く
文字数の両方を指定する方式を取っている。
このやり方は、文字列の中に 0x00 を埋め込まなくても部分文字列を扱えて
便利は便利。もしこれを部分文字列の場所を少しずつ変えていくようなの場合に、
0終端文字列でやろうとすると、効率が悪くなる。
ただ、いつでもスライスの方が0終端文字列より効率が良いという訳ではない。
それが>>21で言いたかったこと。決定性や非決定性オートマトンの考え方で字句解析を
する際には、Cの0終端文字列はスライスより効率が良い。 読む価値無い文章をダラダラ書いちゃうのって
なんらかの障害なんやろな >>22
そのせいでPascal文字列は長さ255文字までに制限されてたのよな。 結論は、Rustがそんなにすばらしい言語とは到底思えないということだ。 >>25 まぁ用途によるやろ
発展途上なところもあるし､そもそもRustが向いてないような用途もある >>13
様々な文字列処理をしたことがある人になら自明ですが
文字列を扱う場合は￥0終端よりもスライスのほうが圧倒的に有利です
例えば何段か深いディレクトリの絶対パスが与えられた時に各ディレクトリのリストを返す（つまりsprit）時
￥0終端方式だと元の文字列を書き換え破壊しない限りコピーが発生してしまいます
スライス方式だと書き換えもコピーも発生しません
これは正規表現によるパターンマッチングでも同じで￥0終端方式だと結果である部分文字列をコピーしなければ返せません
またHTMLやJSONなどの様々な構造データの解析結果でもそうです
JSON文字列を解析して内部構造化表現にする時もスライス方式ならば文字列のコピーが発生せずに済むわけです >>28
>文字列を扱う場合は￥0終端よりもスライスのほうが圧倒的に有利です
有利だろうが何だろうが、APIや過去の資産を活用するのに面倒という事実は何も変わらないが そういやRustの std::ffi::OsString って￥0終端なんだっけ？ >>30
違う
null terminatedはCString >>29 FFIのことを考えつつスライスの恩恵(境界チェックなど)も受けるなら今のRustの文字列に最後に\0を入れるようにしたらいいと思ったけどなんでしないんやろ
\0分の1バイトぐらい今のPCじゃ問題にならないはず >>32
従来の &str (部分文字列) とnul終端文字列を区別しないといけないけど
型で区別しようとすると結局今のCStr/CStringと同じになるのでは
文字列は部分文字列含め全部Stringみたいにヒープアロケーションするなら良いけどさすがに効率が悪すぎる Rust違いです
ってかゲームのほうのRustって個別スレ無いんだね 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'足す方が簡単かもしれない >>28
気持ちは分かるし、実際、その例に挙がっているケースではそうなんだけど、
字句解析は、コンパイラ理論の状態遷移図に基いて行うと効率が良いが、
それは 0 終端文字列の方が効率が良い。 何度も言うが、全面的にスライスが良いなら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++; の部分が追加されて効率が落ちる。 Linuxカーネル開発における「Rust」採用の動き、グーグルとISRGがさらなる後押し
https://japan.zdnet.com/article/35172646/
> Googleは、ウェブサーバーソフトウェアの「Apache HTTP Server」向けのモジュールをRustによるモジュールで置き換えるというISRGのプロジェクトも支援している。 windows apiを使ってメッセージダイアログボックスを表示するサンプルが載ってるサイト教えてください >>38
今のcpuとコンパイラの最適化で両者にどれくらいの性能差があるか示したベンチマークなどある？
rustでも文字列末尾に0を差し込めば同じことはできるので、本当に速くなるなら最適化の手法として採用しても良いかもしれない >>41
試しに手元の環境で1GB分やってみたが1割くらい差があるね
コンパイラはgcc9
でもRustの文字列ってnull文字含むことができるんじゃなかったっけ？試したことないけど >>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);
}
} 設計判断ってのは常にトードオフの選択だからな
ヌル終端にすることで得られるものと失うものを天秤にかける必要がある
得られるものしか見ないやつは設計からは手を引け >>38
ptrとlenが分かってるなら別途カウントアップしていかなくても
どの位置のptrまで読めばいいか最初に分かるんじゃない？ Rustってなんでprintlnの後にビックリマークあるの？ >>47
確かに。end_ptrとの比較で終了判定した場合は(1)と差はなかった
比較一個分くらいなら今どきのプロセッサの並列実行で
十分吸収できるということかな >>48
printlnは関数じゃなくマクロだから
ちなみにマクロにしてる理由は引数の型と個数が不定だから そういや、可変長引数を直接書けないからRustはクソって言う人はまだ見た事ないな
あんまり使わないからかな？ >>42
文字列中にNULが含まれないことを前提とした最適化だから
NUL含む場合は使えないという制約はあるね
Cの文字列と同じ制約だから実用上あまり困らないんじゃないのかな知らんけど >>52
Cで可変長引数使いたくなるのってprintf系関数以外なんかある？ >>54
ない
標準関数ではprintfとscanfだけ >>47
なるほど、こういうことかな：
(2)' (ptr, len)でスライス文字列を表現している場合 :
int btm = ptr + len;
while ( ptr < btm && *ptr >= 'A' && *ptr <= 'Z' ) {ptr++;}
>>49
差は少なくはなるが、無くなるわけではない。
ptr < btm という部分が残るから。整数比較命令と 条件jmp命令の
合計2命令はまだ(1)より多い。 >>56
そりゃ命令数に差があるのは当然だけど
現代的なプロセッサの並列発行や分岐予測を考慮して
なおパフォーマンス差があるかを見たかっただけなので
そちらは実際測定して差を確認できた？ 議論するのそこ？
むしろセキュリティ(バッファオーバーランの危険性)とパフォーマンスを秤にかけて
rustはセキュリティの方を採用したってだけじゃない？
パスカル文字列なんて昔からあったわけだし >>52
どうしてもやりたければビルダーパターンでまとめてから渡すイディオムが確立してるから
そんなに不満にもならないんじゃない？ >>58
いや安全な方を選んだってのはそのとおりだと思うけど
理論上遅いはずってのを実際測るとそうでもなかったってのはよくある話で
そこが気になっただけ >>60
rustが組み込みも視野に入れている以上、現代的なプロセッサは当てにできないと思う
8bitマイコンとかでrustが動くのかどうかはわからないけど >>61
別にRustはあらゆるアーキテクチャでのパフォーマンスを保証するつもりはないと思うけどね
実際測定してるのはTier1環境だけだろうし winapiクレートを使うことってもうなくね？
Microsoft公式のwindiwsクレートの方がよっぽど使いやすいよ >>38
＞(1) ptrが0終端文字列を挿している場合:
＞while ( *ptr >= 'A' && *ptr <= 'Z' ) ptr++;
その場合でも、まず与えられたデータが0終端しているかどうかを確認する必要がありますよね。
データがどこから来るのかは、
ネット上の通信相手か
ディスク上のファイルか
メモリ上の他言語等APIかになりますが、
いずれも盲目的に信頼せずに処理する必要があります。
そして小さいデータならばどんな処理方法でも誤差になるのでしょうが、
大きなデータの場合は>>28のように元はJSONとかHTMLのように構造をもっており、
その解析結果である各一部分が対象文字列になります。
すると0終端させた方がわずかに速く扱える可能性があるからといって、元の大きなデータから毎回コピーして0終端文字列を作る場合と、
コピーをせずにスライスのまま部分文字列を扱う場合との、比較になるのでははいでしょうか？ >>64
>元の大きなデータから毎回コピーして0終端文字列を作る場合
どこからコピーの話が出た？ >>65
変更したくない文字列"あいうえおかきくけこ"から部分文字列"かき"を取り出す場合、
スライス式だと元の文字列の[5:7]の範囲という形で表現できるからコピー不要だけど
ナル終端式だと"く"が邪魔で"かき\0"にできないからどこかに"かき"のコピーが必要になる
って話が>>28に出てる その比較は部分文字列をコピーするかスライスで表現するかの違いであって
0終端文字列のメリット・デメリットとは少し違うんじゃない？
0終端でも同じようにスライスを(ptr, len)で作ればコピーは不要 >>68
> 0終端でも同じようにスライスを(ptr, len)で作ればコピーは不要
それをやってしまうとその部分文字列に対して0終端のメリットが効かなくなるわけで
コピーしないとメリットを得られないというのがデメリットになってる つまり部分文字列を扱う場合は、コピーが発生する0終端方式が不利になりますね。
具体的にファイルパスからディレクトリ部分を得るとか、URLからホスト名を得るとか、元データを破壊したくない時は0終端方式だとコピーするしかないです。
つまり一貫してRustのように始点＆長さ方式の方が、有利かつメモリ安全ではないでしょうか？
さらに文字列比較の場合も長さ方式よりも0終端方式が不利です。
これはCのmemcmpとstrcmpの比較に還元されますが、
memcmpは64bit比較やSIMD利用ができるからです。 &strって3つの意味があると思うんだよね
1: 文字列リテラル
2: Stringの参照
3: 部分文字列
文字列リテラルとStringは終端にNULLを付けるようにして(今まで通りlenやcapは残す)､部分文字列は部分文字列を意味する別の型を作ればいいと思った
こうすることでRust側ではlenやcapを使い､C側ではNULL終端を利用できるという状態になる(Stringや&strをRustで使ってもCで使ってもゼロコスト)
もしNULL終端ではない部分文字列をCで使いたければStringに変換すれば使えるようになる(これはコストがかかるけどCの文字列も同じ問題を抱えてるので問題なし) >>70
それやるには文字列がimmutableでなければならないから、それによって生じるスペースコストとどっちをとるかって話だな。
それにimmutableな文字列って、部分変更に相当する処理をする場合に逆にコピーが必要になるし。
どっちにしても一概に、コピー不要だからこっちが有利、みたいな話にはならんかと。 rustで初心者がハマるポイントを初心者が紹介します
・所有権の概念が難しい
・何をするにしても外部ライブラリが必要（乱数生成など）
・ポインタが難しい >>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終端されている。 >>76
ファイルから読んだデータをpszHogeに格納するときにゼロ終端の要件満たしてるか確認する必要あるよねって話だぞ >>74がマジで深刻すぎる
ついでに加藤純一っていうゲーム実況者とかとじゅんっていうRust/Scala使いがいるのも紛らわしい >>76
>というのは、必ず0終端されている文字列の事なので確認は不要。
という考えで脆弱性を量産してきたC言語の負の歴史を顧みて
Rustを始めとした新しい言語は異なる文字列表現を採用してるわけだ >>77
コンピュータの世界で「確認」とは、データの中を検査するという意味で
使われるが、そういうことは不要。
自分で末尾に 0 を書き込む必要があるだけ。 そこで確認不要とか言ってるからユーザにヌル文字含んだ文字列渡されて死ぬのでは セキュアプログラムは面倒だからなー
数値のオーバーフローチェックとかみんなやらないでしょ？
アップキャストして値に結果を放り込んでチェックした後、
ダウンキャストするとか面倒すぎる >>81
そういう外部からの入力に対するエラーチェックはするのは当然だが、
0終端文字列でやる場合には、ファイルのバイト数だけ読み込んで、
一番最後に 0 を書き込んでおくとそれ以上まで進むことはない。
途中の 0 に関しては スライス方式でも同じ問題が残る。
途中に 0 が有っても大丈夫な様に作るだけ。 >>84
ちなみに、リアルワールドでは俺は名プログラマだと評価されているぞ。 良いプログラムを作るための基本ポリシー：
・外部データと内部データは明確に分ける。
・外部データを内部データに入れる場合は、エラーチェックを徹底的にする。
・内部データに関しては、原則的には完全に正しいことを前提にしてプログラム
して良い。ただし、プログラムのミスのための念のためのチェックはしても良い。 >>87
３番目のチェックはアサーション（assert）だと思うけどあれはコードを読む人に背景の条件を明示する意味もあるね
逆にアサーション以外の余計なチェックはコードを読む人を混乱させる可能性がある ヌル終端はパンチカードが現役だった時代に数バイトケチった名残
互換性のためにサポートしなきゃいけないのは理解できるが
今の時代にヌル終端が優れてるとかそれをデフォルトにしろってのは控えめに言って頭おかしい >>90
外部でーたとしては、他にも有ると思うが、一例としては、
1. 他人が自由に書けるファイルから読み取ったばかりのデータ。
(アプリケーション内部にリソースデータとして内蔵し、安全性が
テスト済みであるようなファイルは内部データとみなしても良い場合も有る。)
2. 安全対策を徹底したいライブラリの場合は、ライブラリを使う側が関数に
渡してきたテキストデータや引数の値。
ただし、このようなものまで徹底的にチェックするとなれば遅くなるので、
設計思想によっては、NO-CHECK、または、軽いチェックだけで済ましても良い。
3. OSの場合は、同様なものとして、APIを呼び出した側が渡してきたデータ。
これは、安全性チェックは徹底して行う必要がある。
4. データベースソフトなどの場合も、2や3に準ずる。どこまで安全チェックするかは、
使用目的や用途、設計思想による。 一般に、アプリの外に置いてあるファイルはチェックした方が良いが、
その中でも、テキストファイルは、信頼置け無い事が多いのでチェックは必要。
アプリの外に置いてあっても、バイナリデータだと人が手書きすることはないため、
設計思想にもよるが、安全チェックはある程度省略しても良いと考える流儀もありえる。 結局アプリケーションがどう使われるか次第でしょ
アプリケーション作成時の前提が利用シーンの増加により後から覆されるなんてことは良くあることだから
性能要件がない限り最初から安全側に倒しておくのが合理的 constデフォルトあたりの話ってgoto禁止論みたいになっている気がする
理由を理解していないがとりあえずそうしておけみたいな人を少なからず見かけるような
>>94
パーサーがガバガバで細工したセーブデータで乗っ取られるゲームのことか >>95
MS製のリンカ(link.exe)の入力するlibraryファイル(*.lib)には、
ヘッダ部分にシンボルがアルファベット順にソートされたシンボルテーブル
が入っている。ソートされていることを前提にバイナリサーチが出来るので
シンボルを検索するのが高速になるとされる。バイナリサーチは、ソート
されているデータに対してのみ正しく検索できて、もしソートされていなければ
間違った結果になる。
しかし、link.exeが*.libを入力する時、ちゃんとシンボルテーブルのシンボル
がソートされたかどうかチェックしているかと言うと、定かではない。
だから、もし、サードパーティー製のツールが*.lib を作成した時、
ソートにミスがあったりすると、link.exeはundefined symbolエラーを出すか、
リンクには成功するが、実行段階でアプリが起動できなかったり途中でダウン
してしまうかも知れない。その様な場合、何が原因かは分からないであろうが、
多分、実際、検査はされてない。 >>97
実際は、サードパーティー製ツールも、ちゃんと*.libのヘッダのシンボルテーブルの
シンボルはソートしており、その部分にはバグはないので、それがソートされてない
*.libは基本的には存在しない。
ただし、*.libをバイナリエディタで開いて手作業で間違って変更したりすると
ソートされていないものが出来上がる。
それをlink.exeに入力しても、link.exeは、そのことに関してのエラーは出さない
だろう。 小学生が大人に九九暗唱してみせれば微笑ましいが
大人が大人に九九暗唱してみせるなら不気味で滑稽である 意図通りに動かないバグにつながるという話と
バッファオーバーフローみたいな脆弱性につながるという話は別だよね 再帰を使って1x1=1から9x9=81までの答えだけを書く場合
どうやって書けますか？ >>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),
}
} 実践的な話をするとRustは末尾再帰最適化が出来ないからなるべく再帰は使わないほうがいいと思う 宿題かなんかだろう。
Rustで宿題を課すなんて教官は変態にもほどがある。 >>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
}
結局のところ関数分割→個別ループ化→関数統合で二重ループ化まで自動でしてくれる言語は無いから
再帰は使わずに自分でループ化すればいいよね、って結論
つまりアルゴリズムでは再帰で考えても実装はループにしてコメント残しておくのが正解 >>107
プログラミング言語 Scheme の仕様だと >>104 のようなパターンは末尾文脈の定義にあてはまるし
末尾呼出し最適化が適用されることが保証されるから、
現代的な言語処理系で最適化できないとは信じられないんだけど、
実際にRust コンパイラに >>104 を与えたときにループに最適化はしないの？
Rust のコンパイラの使い方に不慣れでアセンブリコードの出力のさせかたがよくわからん……。
ほぼそのまま C のコードに書き換えてみたら
GCC ではジャンプに置き換えたコードが生成されるみたいだし……。
(ちなみに GCC では末尾呼出しになっていなくても一部の状況では再帰をループに変形できることがある。)
Clang だとループを全部 unroll しやがった！ c言語だと再帰が末尾呼び出し最適化されるかどうかがオプティマイズレベルで変わるからややこしい。
リリース版だと動くがデバッグ版だとスタックオーバーフローみたいな事になる。
単純な再帰ならループに書き直してもいいけど、相互再帰みたいなのは末尾呼び出し最適化してくれないと困る。 あの、Rustの勉強のために逆引きサンプルwiki作ろうと思うんですけど
テンプレ殿堂入りを目指して作ってもいいですか？
もちろん広告は入れませんが、レンタルwikiが提供している広告は表示されるかもしれませんが。。。 >>110
目指すことは自由じゃないの。
皆がどう判断するかも自由だけど。 先輩ありがとうございます！
受け入れてもらえるようなコンテンツを作ります！ 5chに閉じずに本家のコミュニティにも便利と思ってもらえるもの目指した方が良いのでは >>114
ミンチメーカー、ではなくスパゲティメーカーとして恐れられてるかもな Rustと他の言語との違いについて興味深い観点で盛り上がってるスレ
特に後半
趣味でプログラミングの勉強するとしたら何言語がいい？
https://matsuri.5ch.net/test/read.cgi/morningcoffee/1623527901/ 斜め読みしかしてないから見逃してるかも知れないけどさんざん言い尽くされた話ばかりだった気が
そもそもRust自体はC++を置き換えることを目的にはしていない やたらC++と比較されるのはどっちもbetter Cの側面があるからだろうか
個人的にRustはCとScheme（Lisp）のハーフという印象
SchemeよりMLの方が近いらしいけどMLは使ったことないからよく分からない
手続き型で関数型を疑似表現したり関数型で手続き型を疑似表現する試みがあるけど
Rustはその中間を上手く埋めてる感じ > better Cの側面がある
はぁ？
お前がcもc++もrustもニワカなのは分かった
あと五年間は、カキコ無前にROMに徹してみてほしい >>119
急にどうしたんだ
better Cの意味が分からなかった感じ？ mozillaのc++を安全に使う数多の取り組みに疲れ果てた結果出てきた新言語がrustなのでc++と比較されるのは当然 この板全域に出没して何でもRubyと比較するガイジみたいなもんだろ
ここにはなぜかいないけど >>116
Rust布教スレになってんじゃん
不健全 今から新規のプロジェクトをC++かRustで始めるとなったらRustの一択でしょう
つまりRustはbetter C++ まったく何も資産がない新規であればそうかもしれんが >>118
どこらへんがschemeに近い？
よく知らんがschemeってカッコが一杯あって、再帰ばっかりしてるイメージなんだが つまり過去のしがらみのある案件は時間がかかり遅れるが
いずれも徐々にC++はRustへ置き換えられていく emacsとあとなんだっけ？ SVGのライブラリ？が
オブジェクトファイル *.o 単位で少しずつCからRustに移植してたな >>129
ifとかmatchのブロックがそのまま値になるところが何となくS式っぽいんだよね
ブロックの最後の式が全体の値になるのも(begin ..)に近いし MLの方が普通に近いな
パターンマッチとか束縛がletとかHMの型システムだとか 一番近いのは Ocaml。なぜなら、かつてRustはOcamlで組まれていたから。
そして途中でコンパイラをRust自身に直したと聞いた。 Rust の Scheme っぽいところを探すとしたらマクロだろ。
伝統的な Lisp 系言語だと実行時の環境とマクロ展開時の環境を分けないが、
Scheme は分ける方針をとってる。
(実際には分けない実装をしている処理系もあるし、次の仕様の更新でどうなるか不透明だけど。) 何に近いかでここまで盛り上がれるのだね
何も産まないのに Parkinson's Law of Triviality >>139
比較から何かを見出せる人もいるから何も産まないということはないよ そんなセンスのある人がここにいると思うのｗｗ？
センスないねｗ ちょっと見ないうちに色々変わる＋自分の理解が浅いせいで追いつけない bindgenって複雑なヘッダーだと全然駄目なんだなあ
殆どそれ目的でRustやってたのに >>146
実際に使ってみて初めて分かる問題点だね。 rust始めました！
ってゲームの方を始めてたネタをやろうと思ったけど
想像以上にクソゲー過ぎてダメだった
やっぱり言語の方がいい 検索するとゲームの方と言語の方が出てきてややこしい
Rust(ゲーム)は名前変えてくれ... GoはGolangって別名があるから問題ないけどRustに関してはRustLangとはあまり言わないのがなぁ まあそれはRustの問題ではないですが、クロス環境に問題を感じているなら、Haskellがお勧めですよ。
あわしろ氏がいつも言ってることですがね。 そもそもオフィシャルのレポジトリ名がrust-lang/rustだし普通に言うのでは 言わなくはないけどRustLangよりはRustと呼ばれることのが多い気がする
GoだったらGo(golang)とかGolangとか言われることが多いけど 単にgoよりgooglabilityが高いことのあらわれじゃね
別にそんなに困ったこと無いけどな ていうかGoはもうgolangに改名したほうがいいと思う
Goではとにかく名前がクソすぎる
そもそもなんかダサいし goはogle（いやらしい目で見る）という名前のデバッガとセットで売り出す予定だったけど
ogleがこけたから残念な名前だけが残ってしまった たいていは rust + 別の単語 でググるけどゲームの情報が出てきて困ったことはあまりないかな pythonってそう考えるとなかなかいいネーミング そういやRustはツイッター検索だとかなり厄介だったな 既存の名詞使うときは perl みたいにスペルに一ひねり加えるのが良いんだろうね
rust でやるのは難しいけど >>166
pearlとしなかったのは既存言語が存在した偶然みたいだけどね
phpは某雑誌がよく引っ掛かってたな Rust とかGoとか固有名詞やめてほしいよね。。。 固有名詞でない言語名...
「名前を言ってはいけないあの言語」みたいな名付けかな langを付けると意味が変わるしCは本当に検索ワードに迷う C++もtwitterでは検索できない。C#もだけど。
それは、わざとなんらかかの意図を持ってされていることかも知れない。
twitteの社長や技術者がC++が嫌いだとか。 / も無視されるし単純に記号が無視されるだけでしょ つまりまたもやlispが最強だと判明してしまったわけたな >>174
技術的には簡単に直せるのに直さないところに意図を感じる。 技術的に簡単だと思うなら外部サービスとして提供してみたら？ 外部から伺い知れない部分について簡単に違いないと断言する人とは議論しとうない 全文検索とか形態素解析を少しでもかじってたら簡単とは思えないはずなんだけどね。 >>178
外部サービスとは？
内部の人がやるのは簡単でも、外部の人がやるのはとても大変。
>>180
俺は字句解析系はよくやっているので簡単に感じるが。 字句解析と形態素解析や全文検索はまったくの別物だろう 陰謀論とかじゃなくて、壊したい相手に不利なようにするのがアメリカ流なんだよ。
卑怯な手口だが、卑怯という概念にはあの国には無いのだろう。
あの国の連中は、ことごとくそういう手口で生き残っているから、そのうち
技術の進歩が遅れてある時、がさっと負けだすかも知れないな、GAFAMも含めて。 >>183
形態素解析などに入る前に、例えば、C++をcppと同一視してしまえばいいんだ。 簡単に直せる
(計算量が増えたり既存機能に影響を与えたりするかもしれないけど)
ってことでしょ >>186
それを簡単と呼ぶのは研究とかラボの人間よね。 字句解析と形態素解析の違いもわからないのはちょっと… >>184
で、c++を壊してtwitterにどんなメリットが？アホなの？ そういうのは形態素解析したあと、同義語辞書(シソーラス)で単語を正規化する作業になる。
形態素解析の段階で記号は除去しないとややこしくなるから記号入りの単語を使うのが悪いわな。 ハッカーが使わない言語は流行らない。メモリ安全だけじゃ一部需要のみ
楽しい言語も流行らない。いつも趣味レベルの言語で終わる 流行で選ぶってアフィチューバーやアフィブロガーかな？ 一通り学習したつもりになったから、WebAPIで情報取得するプログラムでもいざ書いてみようと思ったら・・・・
いきなりreqwestのクレートでasync/awaitの壁があったぜ
これThe Bookのキーワードの項目にはあるものの、本編で出てきたっけ？？？
https://doc.rust-lang.org/book/appendix-01-keywords.html
ちょっと適当に書いてみた感じ、他言語と違ってawaitしたところでアンラップされないのかな・・・・・？全然わからん
これって何を見たら学習できるの？ x.py build したあと、x.py install したら、
また意味不明にボコボコビルドし始めたんだけど、
知恵遅れなの? >>195
面白い観点だな。
楽しい言語も流行らないか・・・、なんか考えさせられる。 いつまで miri のトラブルを放置しておくの?
ゴミ言語 unsafeモードが使えても、safeモードでのコード生成結果が予測できないのであれば
使うのは難しい。 無駄な通信と監視と役立たずのゴミでツリーを汚すゴミ ハッカーは書くスピードと実行時間が重要だからnimとかが向いてそう
少なくともRustは絶対にハッカーの第一言語にならない ハッカーとか呼んでねえからキーボードでもしゃぶってろ ハッカー != 犯罪者 がモダンな解釈だと思うんだが。
○にかけのお爺さんかな？ ロシア人ハッカーグループって言ったら
犯罪者っぽくね？ イスラエル人ハッカーグループって言うと
なにか巨大な国際政治がらみの陰謀っぽい 日本は、一人当りのGDPだと先進30カ国中最下位レベルだけど、純粋な頭脳線だと、
三位以内に入ることが良くある。 >>199
Rustはasync/awaitを言語レベルでゼロコストでサポートする代わりに非同期ランタイムを別途用意する必要がある
これによりRustでは様々な非同期ランタイムを言語と独立に自由に作ることができる
例えば非同期ランタイムを自作することも当然できてfuturesクレイトをその部品として使うことができる
もちろん非同期ランタイムを自作せずとも既に様々なコミュニティから提供されているのでそれを使うこともできる
具体的には例えば最も使われているtokioなどのチュートリアルを見るのが良いかな
https://tokio.rs/tokio/tutorial >>219-220
その考え方が古い。(というか最初から？)間違ってる。
ハッカー == 凄い奴 的な意図でしかないので
ロシアだろうがイスラエルだろうが某大陸だろうが
超エリートなんだろうなとしか思わない(事になってる)。
犯罪者はクラッカーと言って区別される(事になってる)。
区別しようと言い出したのは…(ry でも発端の>>195の「ハッカー」はホワイトかブラックかは知らんがセキュリティ関連の話ちゃうんか？ >>225
モダンな解釈だと良いハッカー=ホワイトハッカー 悪いハッカー=ハッカーですね
あと老人ホームから抜け出してまで5chなんてしたら家族に迷惑かかりますよ
迷惑かけない内に尊厳死をおすすめします そんな高度な話だったんだ
小学生がうんこちんちんって罵倒してるようなものだと理解していた >>227
> 悪いハッカー=ハッカー
では無いよ、と書いてる事が理解できないかな？
>>227 がどう思おうがどうでも良いけど
話が通じないことがある事くらいは理解しといた方が
身のためだぞ。
ttps://ja.m.wikipedia.org/wiki/ハッカー
迷惑かけない内に勉強し直す事お勧めておきます。 正しい定義がどうだろうと>>195の意図なんかわからんのでどうでもいいうんこちんちん 仕様や実装のマイナーな機能を使って人を驚かせるのがハッカーだ、と思ってるのでは
Cのポインタ祭りとかLISPのマクロ生成マクロとかを好むのだ、と ハッカーの定義はどうでも良いからせめてrustの何がダメかを語れよ rustは文字列の扱いに難があるなあ
sjisのコンテンツとかマルチバイトのファイル名(WinだとUTF16?)の扱い方がよくわからん Non-Lexical Lifetimes が制御フローレベルなので実装をデバッグできるやつがほとんどいない。
c++と同じレベルの複雑さを有するようになってきている。
cargoのビルドシステムがあまりに強制的すぎる。
メモリを直接いじる必要のある効率的なアルゴリズムでは結局unsafeになる。
メモリ最適化の許す範囲があまりに非自明でcから呼ぶのは不安定すぎる。 コンテナ類が実際にどのように格納されているかが分からないと言うのは、
それをunsafeで扱うのが難しくなってる。
どこでコピーが生じて、どこがmoveなのかも分かりにくいことがあるし。 ライフタイムもちゃんと仕様が書いてないから、手探り状態で試さないといけないし
プログラムするのに時間が掛かる。
色々やっても結局、C/C++のような効率のよい方法を取ることは不可能な場合もあるし。 ときどき、Javaの検査例外みたいなやらかし感を感じる
厳密にしすぎると却って使いづらいみたいな Box<dyn Error>やanyhowやeyreを使えば良いのでは >>235
Windows 系以外のすべての言語は、UTF-8
だから、MSYS/MinGW でも、UTF-8以外でバグるので、
UTF-8以外を使っちゃいけない！
唯一バグらないのは、WSL。
Windows Terminal, VSCode のRemote WSL などで、
ls /mnt/c/Users/Owner/Documents/
と入力すると、日本語のフォルダ名も、正しく表示される
出力
あ
い
たぶん、Windowsが変換しているのだろう WSL は一種のチート
ハイパーバイザーでLinux を起動して、
Linux側から、Windows側のドライブを見た時に、
UTF-8 以外の言語をUTF-8に変換する
まあ、漏れの推測だけど >>242
そこに文句言われてもねー
要件に文句を付けるのはフェアじゃない
現実にUTF16でネーミングされたファイルがあって、
それにどう対応するかって話なんだけど だから、プログラマーの基本は、Windows 系など、UTF-8 以外を使わない事！
この大原則を守っていない人は、システムを作れない
システムには、ascii しか使えない！
これが大原則 >>244
WinならOsStringのエンコーディングは普通にUTF-16だから何の問題もないと思うが
sjis扱いたいならencoding-rsとか
結局何に困ってるのかわからないと何とも言いようがない じつはわしはRustはやったことなかったのだが、
これまでの経験上おそらく >>236 みたいな感じだろうなと想像してたら
ほんとうにそのとおりでワロタw
アホみたいに「安全ドグマ」に縛られるとたいがいそうなる >>245
プログラマーの基本！ とか システムを作れない(ｷﾘｯ とか言われても
既存のシステムがそうなってるんだという話
「システムには、ascii しか使えない！」とか言ったら、客に帰れと言われるだけ
>>246
sjisファイルを読み込みたい
でもチュートリアルにあるようにBufReaderは使えない
そりゃ読み込んだ後、変換処理したら何でもありでしょ
でも、ネイティブに処理できん？と思う
むしろ安全性にこだわる割に文字に対するこの雑さは何なの？と 論理的な問題点以前に、言語として見た目的な美しさも無いし、記述が
簡潔でもなければ直感的でもなく、無駄に長くなる。 システムには、ascii しか使わないのは、Linux の基本
AWS でも、そう。
半角空白もバグるから、使わない
必ず、客から注意される。
日本語のファイル名・半角空白を使わないでと。
バグるから
例えば、5ch は、sjis だからバグだらけ。
; を書いていないのに、文字列の後ろに、; が付いてるとか
sjisとか、Windows以外では、どうしようもない >>249
バイト列としてVec<u8>に読んじゃえば後はCと一緒じゃん
それともlocaleとwchar_tフル活用したいという話？ >>253
それでcrlfでsplitしろって？
なんて原始的な… UTF-8(とchar用のUTF-32)以外滅んでほしいが､過去の遺産がそれに対応してないという現実的な問題...
まぁencoding_rsってクレート使って変換してやればヨシ >>242
に書いたみたいに、
sjis, UTF-16 などのWindows 用言語で、
唯一バグらないのは、WSL だけ
WSL でLinux側から、Windows側のドライブを見た時だけ、
日本語のファイル名を正常に変換できる
Windows Terminal, VSCode のRemote WSL などで使える
ひょっとして、Windows用言語を扱っていて、WSLを使っていないの？ >>249
変換せずに扱いたいのか？いまいちよくわからんが、既存の言語で理想的なやつってどれ？
Rustは文字列に関しては最もちゃんとしてる方だと思うけど あ、あとascii/WSLおじさんは気にしなくていいと思うよ
少なくともRustにそんな制限はない
Cとかだとasciiに限定したい気持ちもわからなくはないけど ・ファイルシステム上のエンコーディング
・OSのAPIのエンコーディング
・言語のAPIのエンコーディング
・言語の文字列のエンコーディング
それぞれ独立だし変換しあってることをおじさんは理解していないと見える >>255
でもUTF8は「ひらがな」ですら3バイトになるので困る。 >>256
へー WSL って言語だったんだωωω >>257
どれが理想的というか、rustは特にめんどい気がした
fgetsが出来ればそれでいいんだが >>249
sjisを変換せずそのまま内部表現として標準的に扱うプログラミング言語って具体的に何？
もちろん全ての言語でバイト配列としては扱えるけどsjisにとってそれは無意味であり
先頭から全読みしないとsjisの1バイト目か2バイト目かすらわからない欠陥sjis仕様のためsjisそのまま使うことはないよね
仮に入力も出力もsjisなら内部表現もsjisのままにしてsjis処理関数いっぱい
書くのも見合うケースがあるかもしれないけど
入出力の片方がsjisでないならば他との変換必ず必要だから内部表現をsjisにこだわる意味はないよね
一方で内部表現として処理を無条件に簡単にしようとするとUTF32で1文字32bitにするしかないけど常にUTF32強制ではメモリが無駄すぎる
そこでメモリ上だけでなくファイルもネット通信も無駄を避けるためにUTF8を用いる
という当たり前の帰結になりRustもそうだけどこれの何が不満なの？ >>266
いや、内部表現なんてどうだっていいんだって
utf8以外のテキストを使うとResult<Error>でぶっ飛ばされるのが面倒なの >>267
それはUTF8文字列として扱う関数を使うからそうなる
普通に生バイト列として扱う関数を呼べばよい
このへんは多くのプログラミング言語で同じ話 >>264
fgetsで良いって言うなら単にVec<u8>で読むだけだと思うけど
エラー処理が面倒というならとりあえずunwrapしてればいいし
そういうので文字数がかさむのが嫌だというなら、Rustは合ってないんじゃないかな
Rustは基本的にソースコード上にいろいろ明記したい言語なので >>269
それって行の切り出し(改行までのsplit)って自分で書かなきゃだめ？ >>270
それは書かないといけないね
たぶんRustが好きな人は「fgetsだと何が改行コードとして想定されてるのか分からなくて不安」
って人が多いんじゃないかな
実際Linux環境でCR改行のファイルをfgetsするとどうなるのかよく分からんし
そういうふうに処理系がうまくやってくれることを期待するならGoとかもほうが合っているかも うーん、Windowsでsjisファイル読み込むのってそんなにニッチなのか……
>>271
>たぶんRustが好きな人は「fgetsだと何が改行コードとして想定されてるのか分からなくて不安」
>って人が多いんじゃないかな
BufReaderがあるので、それはないかと >>273
read_lineはLF区切りって決まってるからそんなに気にならないけどな
fgetsはプラットフォーム依存じゃなかったっけ？
もう忘れてしまったけど これはRustの問題ではない
例えばスクリプト言語であるJavaScriptでもsjisファイルを読み込むにはNodeでも標準サポートはない
だから生バッファに読み込んで次にそのsjisを内部へ変換するという手順となる
いずれにせよ文字コード変換の一行が余分に入るだけでありどの言語でも大した問題ではない >>272
うん、それはそうなんだ>splitすればいい
でも、なんでこんなにしつこく聞いたかっていうと
最近の言語にこんな基本的な機能ないわけないだろ？と思ったからなんだ
確かに自分で書いたって大した処理じゃない
でも、一人ひとりがそんな原始的なコード書いてるの？
ありえない 標準で用意しとけやって >>275
文字コード変換だけなら文句は言わない
昔からMulitbyteToWideCharを噛ませるぐらいのことはやってたからね 最近の言語としては標準ライブラリが小さいというのはあるね
代わりに外部ライブラリをたくさん使うという方針
今のケースならこれかな
https://crates.io/crates/bytelines >>278
おおっ！ これ良さそうだね！
試してみる！ サンキュー 要はバイナリのsplitがあればいいんだろ
まあニッチだし標準には入りにくいだろうな >>265
ログ的なものや、テキストファイルが大きくなる。
開発中にはソースやバイナリを高頻度に単純コピーでバックアップしたいが、
そのとき、毎回毎回大きくなるのでディスクの無駄使いになる。 >>281
それはもうutf8の問題じゃないんじゃないか？ >>281
今さら何を言ってるんだ？
UTF-8が長いとか短いとか論争してたのは20世紀の過去の話であり今は2021年だ
UTF-9のエイプリルフールRFCが出たのですら16年前の2005年だ
既に20世紀に今後は世界中全てUTF-8で行くと方向が決まった >>242
No.
Linux やら BSD やらでファイル名を UTF-8 と保証しているものはたぶん少数派だ。
ロケール設定で UTF-8 を選ぶのが多数派になっているのは疑いがないが、
システムとして保証しない分だけ Windows よりつらい。 >>282
日本人そっちのけで勝手にアメリカ人が作った文字コード。
日本(と中国)だけが不利になった。 最近でもJSは日本語の文字イベントがサポートされてない。
アメリカ中心。 UTF-8の規格制定の時にはアジア圏も割と口出しだんではなかった？ >>287
日本語の文字イベントという意味不明なものは何だ？
日本語じゃない文字イベントというのも聞いたことないぞ sjisのfgets()相当の件だけど
標準のBufReaderのlines()で回すのは何が不満なんだっけ？
use std::error::Error;
use std::fs::File;
use std::io::{BufReader, BufRead};
use encoding_rs::SHIFT_JIS;
use encoding_rs_io::DecodeReaderBytesBuilder;
fn main() -> Result<(), Box<dyn Error>> {
let file = File::open("sjis.txt")?;
let reader = BufReader::new(DecodeReaderBytesBuilder::new().encoding(Some(SHIFT_JIS)).build(file));
for line in reader.lines() {
println!("utf8: {}", line?);
}
return Ok(());
} >>290
nativeのWin32やMFCだと、IMEで日本語入力した時、WM_CHARで
SJISやUnicodeの文字コードを取得できるが、ブラウザ上のJSだと、
英字の範囲でしかそれに該当するイベント、つまり、IMEで
漢字やひらがなを打った結果を取得する文字イベントが無い。 >>291
いいね！
取得した文字列をOsStringに変換しなくても
なぜかファイルパスとして正常に動作するし(UTF16じゃなくていいのか……)
encoding_rs標準になればいいのに encoding_rsが標準になって欲しい(stdに入って欲しい？)のはなぜ？ >>295
・基本機能だから
・ロジックを標準化するため
・Cargo.tomlのdependancyに記述するのが面倒だから
特にバージョン指定 >>296
stdに取り込む提案のRFC書いてみたら？ UTF8（とASCII）以外の文字コードを扱うのが基本機能とは思えんが >>296
> 基本機能だから
UTF-8さえ標準で扱えれば問題ない､UTF-8は世界標準だから
よって基本機能ではない
なので標準化する必要もないし､cargo.tomlに依存ライブラリを書くのが面倒ならapt-getでライブラリをインストールして使うC言語でも使えばいい >>301
「utf8以外を使う場合のやり方を標準化してほしい」って要望に対して
「utf8を使え」ってのは答えになってない 今は多少議論の余地があっても、数年したら
「なんでstdにSJIS扱うライブラリ入ってるの？ めったに使わないのにバカじゃねーの」
って言われるのが目に見えてる エンコーディング関連のコードは量が多いだろうから
あらゆるプログラムのコンパイル時間を増やしたりバイナリサイズを大きくしたりするだけの価値があるかという議論にはなりそう encoding_rsはSJISのためのライブラリじゃないでしょ Cとかだと依存ライブラリの導入が面倒すぎるから標準化してほしいというのもわかるが
Cargo.tomlに一行書くのが面倒と言われてもあまり共感は得られないんじゃないかな >>285
その通り。だから、
>>251
に書いたように、ユーザー名・ファイル名などのシステムには、ascii しか使えない
システム内部で、UTF-8/16 のどちらを使っているか不明だから、
共通項のasciiしか使えない
ただ、Windows で日本語のファイル名を使っている人も多いから、その場合は、
>>242
に書いたように、WSL で、Linux, UTF-8 に変換できると言うだけ
Windows言語だけは特殊。
Windows言語以外のすべての言語は、Linux, UTF-8 が基本 >>302 UTF-8を使えというより､今の標準はUTF-8だから標準化する必要がないということを言いたかった
そんなものを標準化したところで使うのは英語圏以外だけだし､その英語圏以外でも滅多に使うことはないから必要に応じてcargo.tomlに書き加える今の方式で良い >>311
多数決で言えば漢字文化圏の方が人口が多い。
しかも母国語が漢字を使う。英語を母国語とする人口は三億人くらい。
漢字を母国語で使うのは15億人くらい。
漢字以外の多バイト文字を使う国まで入れたら70億人、つまり地球の95%異常
となる。英語の方が少数派。 >>311
多数決で言えば漢字文化圏の方が人口が多い。
しかも母国語が漢字を使う。英語を母国語とする人口は三億人くらい。
漢字を母国語で使うのは15億人くらい。
漢字以外の多バイト文字を使う国まで入れたら70億人、つまり地球の95%異常
となる。英語の方が少数派。 漢字とかもあるけど、例えばMIME64のデコードとか
エンコード・デコード処理の標準化と考えれば英語圏でもありかも 日本語をユーザー名・ファイル名など、システムに使うのは、Windows の香具師だけ
Linux を使うプロは絶対に、ascii しか使わない。
せいぜい、ハイフン・アンダーバーぐらい
もし、半角空白でも使えば、あちこちから怒りの声が届く。
システムがバグるから使うな！ >>315
ここにいる人間はそんなことわかってるから、まあ落ち着け Linux のテレビの録画システムで、
日本語のテレビ番組名を、そのままファイル名にしていた香具師がいたけど、
バグって使えない Rubyボットの活動範囲がさらに広がってきたな
よほど暇なんだろう >>307
そこは実は本質的な要件ではないらしく
>>249
> sjisファイルを読み込みたい
> でもチュートリアルにあるようにBufReaderは使えない
が本質的な要件だから
utf8と全く同様にFile::openとBufReaderしてreader.lines()を使えれば良いと見て
>>291のコードを提案した
そして「いいね！」とレスしてるからこれでOKのようだ >>316
だよな
そして >>315 がいつものあいつだということもみんなしってる Windows ではプログラムをインストールするフォルダが Program Files となっているのは
パスが空白を含むくらいでおかしくなるようなカスなソフトを早めに発見するためなんよな。
パスが空白も漢字も含みうる仕様なのに対応してないソフトがあるならそのソフトがカスなだけじゃん。
今の時点で現実にそういうソフトがあるから仕方ないという論法だと
SJIS のデータがあるから仕方ないというのと言ってることは同じなわけで、
データが大事かソフトが大事かという点で軸が違うに過ぎない。 Windows 11は64-bitのみになるみたいだけど
Rustじゃ i686-pc-windows-gnu, i686-pc-windows-msvc はいつまでTier 1なんだろう？ >>325
32bit macがtier3落ちしたときはxcodeでコンパイルもできないし実行環境もないからって理由だったはず
同様にmsvcはMSがサポート切ってくればなくなるかもね
32bitアプリ自体が動かなくなるわけじゃなさそうだしgnuは大丈夫なんじゃないかな Win11はOSが32bitCPUでは動かないってだけで32ビットアプリはまだ動くのでは Win11は、16bitが公式では完全に動かなくなる >>329
え？今までも64ビット版Windowsでは 16 bit は NE フォーマットを含めて動かないと思っていました‥‥
だから emu を使っていましたが、今なら動くんですか？ Win11は u16, i16 が使えなくなるのか
ま、使ったことないけど Rustの文法を教えて欲しいんだけどさあ
https://github.com/seanmonstar/reqwest
ここのExampleの中にある
＞.json::<HashMap<String, String>>()
の行って、渡されたデータをHashMapに変換してるようだけど・・・・()があるから関数を呼び出しているんだろうけど、なのに関数名が無いってどういう文法なの？ >>335
関数名はjsonで::の後はjsonの型パラメーター >>335
turbofishで検索してみると幸せになれるかもよ そういうことだったのか
チュートリアルやったつもりが全然身についてなくて、まるで初見の文法に見えたよ
ありがとう！ async/awaitよく理解できないので質問です。
async fnを.awaitすることは、
thread::spawn(fn)で得られたJoinHandleをjoinすることと何が異なるのでしょうか >>339
どのプログラミング言語でも同じ概念の話として
非同期プログラミングとスレッドプログラミングの違いをまず学ぶと良いでしょう
非同期プログラミングはスレッド使わないシングルスレッドでも成立するしよく使われます
スレッドは無駄にリソースを喰って重いのでスレッドを使わないシングルスレッドでプログラミング出来る事ならばそれが最も軽くて速いです
まずはシングルスレッドでの非同期プログラミングを経験しておきましょう
もちろん最初はasync/awaitを使わずに非同期プログラミングを体験したほうが良いでしょう
そうすることで初めてasync/awaitの意義と利便性を理解することができます
以上が通常のasync/awaitの初心者がたどるべき入門コースです 初級プログラマーは非同期プログラミングをしたことない人もいるけど
中級プログラマーになるには必須の技術だからね 初級なら知らなくても仕方ない、中級なら必須という区分けはなんか違和感あるかな。対象の業務次第で知っとけよって範囲は違うからなぁ。 その辺は分野にもよるでしょ
組み込みと可だと初級でもマルチスレッドシラネはかなり問題だぞ 昔ながらの言語だとスレッドはできてもコルーチンはできなかったりするので分野次第かな >>346
今回はマルチスレッドしか知らなくて
(シングルスレッドでも動く)非同期プログラミングを知らないという話だから プリエンプティブじゃないマルチタスクωですねわかります await後にどのスレッドが戻ってくるかは運なの？ >>350
async/awaitとスレッドは直接は関係がない
async/awaitの対象はタスク
例えば1つのスレッドに10000のタスクを動作可能
8つのスレッドそれぞれでそれを行なえば計80000のタスクになるけども
スレッド1つにタスク1つしか使わなければ8つのスレッドで計8つのタスクになるといった具合い
これらはランタイムによってサポートが様々
したがって正確な質問は「await後にどのタスクが戻ってくるかは運なの？」となるけど
これはランタイムのスケジューリング次第
ランタイムはRustの言語仕様範囲外なので自分で決めた方針でスケジューリングするランタイムを作ることが可能
つまり運ではなく自分の思い通りに実行させることも可能 JSのasync awaitってややこしい
goroutineのほうが簡単 promise使うのに比べてそこまで楽か？って言われるとそうでもないわな >>352
え？
そもそもタスクとはどう定義するのですか？
あなたの①プロセス②スレッド、そして③タスクの定義を教えてください、多分①②③の違いが明確でないので話が混乱しているかと JSのawait/asyncとかめちゃくちゃ簡単やろ
シングルスレッドなのと背後にイベントループが存在することを抑えておけば余裕よ
すまんスレチだな >>355
ここはRustのスレ。
スレッドとはstd::threadであり、いわゆるOSスレッド。
つまり1つのOSプロセスの中で、1つまたは複数のOSスレッドが動く。
一方で、async/.awaitが対象としているのは、スレッドよりさらに小さいタスク。
つまり1つのOSスレッドの上で、1つまたは複数のタスクが動く。
例えばシングルスレッドマルチタスクランタイムでは、1つのOSスレッドの上で無数のタスクを動かすことができる。
async/.awaitはこの非同期に実行されるタスクを扱う。 asyncは途中I/Oウェイトで待たされるような処理じゃないと意味がない スレッド、プロセス、タスクなどの定義は分野やプラットフォーム等によって異なる VSCode+Rust Analyzerの環境で、ミュータブル変数にアンダーラインが付されるのをやめたいのですがどうすればよいですか？ awaitの前後でスレッドは変わる可能性があるものの、タスクは変わらないんだと思ってたわ >>357の言う「タスク」って1つのasync関数のように読めるんだが、そういう理解で合ってるのか？ >>362
tokio::spawnなどの引数に渡すものがタスク
async関数やブロックの場合もあるし、それらをコンビネーターでしたものの場合もある だとすると「スレッドよりさらに小さい」ってのは変だな。大きい小さいあるいは包含関係が決められるものじゃない。 そもそも直交する概念だし用途によって使い分けるものでもあるし Elixirのプロセスは、軽量プロセスと言われていて、
OSのプロセスやスレッドではなく、Greenスレッドです
カーネルではなく、VMでスケジューリングされるので軽量、
コンテキストスイッチが発生しない
1軽量プロセスで約300ワードです いつものRubyキチガイだろう
何言っても無駄だからスルーするしかない >>366
スレッドで動くんだから「スレッドより軽量」ってことはない。 >>367
軽量プロセスでもコンテキストスイッチは発生するよ >>370
タスクと同じことをスレッドでやろうとした場合の比較ね
タスクと同じ数のスレッドを作った場合スタックだけで結構な量のメモリが必要になったりする
あとコンテキストスイッチのコストは少なく済んだりするんじゃないかな >>372
「タスク」の定義が>>363のようなものならそれはスレッドと直交する概念だと思うが？ >>370
async/awaitでのタスクはスレッドよりリソースを喰わず軽量
例えば1つのスレッドの上に1万個のタスクでも動作可能でいわゆるC10K問題も対応できる軽量さ
>>373
直交する概念ではなく重量順に
OSプロセス≧OSスレッド≧タスク
（それぞれ＝となるのは1プロセス1スレッドおよび1スレッド1タスクで用いる時） タスクって名前が良くないな
一般的にはタスクってプロセスのことじゃない？ タスクってのは内部実装的には非同期I/Oを使ったシングルスレッドでしょ。 >>375
OSプロセスは複数のスレッドを持つ場合があるから≧でいいが、>>363の言うタスクなら
1スレッドで同時に実行できるのは1タスクしかないと思うが？ Rustのasyncについて知りたければ「async-book」は必読なので
次からテンプレに入れよう
https://rust-lang.github.io/async-book/
>>980
よろしこ >>379
1スレッドで同時に実行されるタスクが1つというのは正しい
従来のスレッドでの並列化(1スレッド1タスク)の場合、IO処理を呼び出すと処理完了するまでの間はスレッドはsleep状態になってしまっていた
sleepしている間に他のタスクを実行させるためには、実行するタスクと同じ数だけのスレッドを生成する必要があるが
スレッド生成で消費するリソースが多いため数万タスクを同時に捌くことは難しかった
async-awaitではIO処理完了までの間スレッドをsleep状態にするのではなく別のタスクを実行する
これによりスレッドあたりの処理可能タスク数が増えるため、アプリケーション全体で同時に捌けるタスク数も増える
従来の手法でもスレッドをsleepさせないようなプログラミングは可能だけどプログラムの構造を大きく書き換えないといけなかった
普通のスレッド並列のプログラムと同じ書き味でより多くのタスクを捌けるプログラムが書けるというのがasync-awaitの一番のメリット
ただし常にasync-awaitが望ましいわけでもない
async-awaitで効率的に実行できるのはIO待ちが発生するタスクの場合で、CPUをぶんまわす処理には向いていない
適材適所で従来のスレッドによる並列化手法と組み合わせて使うことになる >>379
いいえ
1つのスレッド上で同時に複数のタスクを並行(concurrent)に実行できるのがasync/awaitのタスクです。
C10Kと言われるように1つのスレッド上で10000のタスクでも並行に実行できます。
ちなみに1つのスレッド上で並列(parallel)に実行されるのは1つのタスクのみなのは当たり前なので、わざわざ言うことはないです。
今回はasync/awaitの話なので、
『1つのスレッド上で同時に複数のタスクを並行(concurrent)に実行できる』が正解です。 >>381
その1スレッドが時分割で複数タスクを実行できるということのちょうど裏返しで、1タスクは複数スレッドから実行され得る。
つまりそこに大小関係、包含関係などは無い直交した概念。
軽量云々てのはOSスレッドとグリーンスレッドの話とごっちゃになってんじゃないかねぇ。 >>382
>C10Kと言われるように1つのスレッド上で10000のタスクでも並行に実行できます。
本当に並行に実行される？
キューイングされたコールバックを順に呼んでるだけじゃなくて？ ねえこの引っ込みがつかなくなったゴミクズ共のメンチの切り合いっていつまで続くの？ 包丁刺し合って死んで終わらないからネットのマウント取り合いって性質が悪いんだよね >>384
あなたは初心者のようだから
まずは基礎知識である並行(concurrent)と並列(parallel)の違いを理解してから
あらためて>>382を読み直して理解しましょう で、実際のところランタイムってlongjmpみたいなことしてるの？ >>391
しない
Futureを実装したオブジェクトのメンバとして持ち回る
クロージャがFnMut/FnOnceを実装したオブジェクトのメンバとして状態を持ち回るのと同じ Elixir, Go の軽量プロセスと同じでしょ？
OS は関係ない。
言語(VM)内で切り替えているだけだから タスクの厳密な定義が気になるのってFutureを必要とする動機が無いんじゃないかね
別に新しいことができるわけじゃないし、必要無ければ知らなくていいよ C10k問題がまずあって、それをselect/epollで解決するってシナリオをまず理解しておかないと
何でめんどくさい事わざわざやってんの？としかならんでしょ
モチベーションが大事 オライリーのrustの本ってどう？
これから勉強するんだけど、これ使っても時代に遅れない？ >>383
マルチスレッドなランタイムを使えばスレッドとタスクはm:nだけど
シングルスレッドなランタイムを使えばスレッドとタスクは1:n
いずれの場合でもタスクはスレッドより軽量な存在であり直交する概念ではない >>397
原著の第2版がオススメ
といってもasyncの章が追加されたのを除くとコアなところは第1版と同じ
今のところオライリー本が圧倒的に良いので他の本で学ぶくらいなら第1版の訳書のほうがいい
古くなってるところはEdition Guideやasync-book、Rust Blogで補完 俺もそう思う。古かろうがオライリー本が圧倒的に良い。 >>397
言語仕様的なのが延々と書いてあっても辛くないタイプの人ならオススメ
自分はそういうのが好きだが、「サンプルアプリを作りながら学びましょう」ってタイプではないので合わない人はいると思う Rust はサンプルコードを見ながら真似ていれば雰囲気で書けるようになる……
なんていう言語ではないので基礎的な理屈を体系的に (それでいてわかりやすく)
説明してくれるオライリー本はとても良いよ。
確かに理屈っぽいが、 Rust がそういう言語なのでオライリーの本がつらいと思う人は
そもそも Rust がつらいタイプの人なんだと思う。 Rustlingsのこれやっててよくわかんなかったんだけどさあ
https://github.com/rust-lang/rustlings/blob/main/exercises/if/if1.rs
自分の解答は
pub fn bigger(a: i32, b: i32) -> i32 {
if a > b{
return a;
}
b
}
これなんだけど、「return a;」のところってなんで「a」だけじゃダメなの？ ブロック式が値を持つなら式文も値を持たせればよかったと思うんだけど、それだと何か都合が悪いのかな。 セミコロンあるなしで意味が変わるのって、バグを産む原因になりそう どちらかというと;の有無で()を返すかどうか制御できる方がいい気がするけどな
式文も値を持つならわざわざ();って書かないといけない
（まぁわざわざ書かせるのもRustらしい気もするが）
>>413
間違えたら型エラーになるからバグにはならんと思うよ () を返す場合は関数省略だからreturn必須でよかったな if-elseとかmatchとかでひたすら();書くのさすがにやばくない？ どうしても () を返さなきゃならない場面ってそんなに多いんだっけ？ 最初アホみたいにReturn合った方が…とか思ってたけど慣れると全く要らん境地になるから不思議 >>418
少なくともletは値を返すわけにはいかないので()だね
まぁCopyなら返せなくもないけど、Copyかどうかで挙動が変わるのはさすがに…
();を明示する、みたいにするとletだけ特別扱いになるし、結局今のルールでいいんじゃないかと >>417
書き方が悪かった
returnは値を返す時は必須だけどreturnがない場合は省略する。 関数の返り値と同じ法則で でも、関数の最後じゃなくてもさあ
文があったら、そこでリターンしてくれたらいいのにな
まあ、ミスってても気づき辛くなるからダメなんかな？ >>422
特別扱いってのがよくわからないなぁ。
let x が () なら let x; も () でいいし (); を明示する必要もないと思うんだけど。 XXXがstatementだとか、XXXはexpressionだとか
そういう議論が出る時点でダメ言語のオーラが
言語オタクには楽しいかもしれないけど だから式文じゃない文は () でいいんじゃね？特に特別扱いとは思わんが。 文は()という単純なルールを崩してまで式文から値を得たいモチベーションがよくわからん
単に;を取って式にすればいいだけなのに Rust書いてて式と文を意識して区別しないといけないことなんて無いよ
CやPythonならあるけど 関数末尾だけセミコロン外すのが気に入らないなら、C/C++でやってたようにreturn x;とすればいい
それで不都合を生むことはない #![allow(clippy::foo)] を書けばいいじゃん なるほど
＞Rustのセミコロンは意味と構文からそれぞれ説明できる。
＞意味論的には、以下の原則を覚えておけば十分である。
＞
＞・セミコロンで終端された文は強制的に () 型となる。
＞・ブロックの途中の文は () 型でなければならない。
＞・ブロックの型はブロックの最後の文の型と等しい。(文がひとつもない場合は ()) ＞・ブロックの途中の文は () 型でなければならない。
これがあるから1行目の仕様なんだろうけど、これの理由ってなんなのかな。 文って値を返さないのかと思ってたけれど、
()を返してるって事？ ブロックの型はブロックの最後の「式」の型と等しい。(「ブロックの最後に式がない」場合は())
ここの間違いが他のすべての説明によく分からない辻褄合わせを持ち込んでいるだけだと思う >>437
＞・ブロックの途中の文は () 型でなければならない。
そもそもブロックの途中の文を()以外にすることってできるの？
{ foo; bar } みたいなブロックを{ foo bar }とは書けないし >>442
それは型の問題以前に文法の問題
型だけの問題だというなら、{ let foo = (); foo bar }と書けばコンパイルできるはずだが、
もちろんそんなことはない >>443
文法の問題を解決しつつブロックの途中の文を（）以外にする方法がわからんってことよ 「文を()にする/()以外にする」の正確な意味を言語化してほしい
「文が評価されて結果として()/()以外が得られる」という意味で言っているのなら、文は評価されて結果を返すものではない
評価されて結果を返すものは式と呼ばれる
文は式ではない >>447
俺もそのへんはよくわからんが、
式文は「文が評価されて結果として()が得られる」って認識で使ってた
これが誤りならまあすまん
ここにこだわるつもりは全然なくて、
ようするに>>437の「ブロックの途中の文は () 型でなければならない。」ってのがどういうこっちゃってこと
この表現だと() 型じゃなくする方法があるように読めるからさ >>448
自分は>>441で書いた通りその部分は辻褄合わせだと思ってるよ
まあでも、自分もRust入門したころは似たようなことでこんがらがってたような気はする
ブロックが式だなんて思ってなかったからかな セミコロン省略できる式文(?)の型が()ではない場合は型エラーになるね
https://play.rust-lang.org/?version=stable&;mode=debug&edition=2018&gist=85e09ac464b7f9fb07b6aa1e2d08e8c9
セミコロンをつけたり、型を()にしたりするとエラーにならない
https://play.rust-lang.org/?version=stable&;mode=debug&edition=2018&gist=4e4152ae35e8fd2821060f44ed9a2fda
https://play.rust-lang.org/?version=stable&;mode=debug&edition=2018&gist=86429babc54c38b515dfe1f9de85f127 最も単純化してこれはコンパイル通るけど
fn main() {
if true {
1
} else {
0
};
()
}
しかし上記のifの尻のセミコロン無しだとコンパイルエラー【値が()ではない】となる
セミコロン無しでも数字1と0を()へ変えればコンパイルが通る
つまり
>>437
＞・ブロックの途中の文は () 型でなければならない。
ifをセミコロン無しで値が数字だと上記の条項を満たせないためエラー
ifをセミコロン無しで値が()だと上記の条項を満たせる
あるいは
＞・セミコロンで終端された文は強制的に () 型となる。
値が数字でもifをセミコロン終端させれば上記の条項を満たせる >>454
そのリファレンスの説明だけだと
以下はコンパイル通るけど、関数内の3つの()のうち任意の1つでも数値に変えるとコンパイルエラーとなる説明はどの部分になる？
fn main() {
if true {
()
} else {
()
}
()
} >>455
Note: As a control flow expression, if a block expression is the outer expression of an expression statement, the expected type is () unless it is followed immediately by a semicolon.
https://doc.rust-lang.org/reference/expressions/block-expr.html
An expression that consists of only a block expression or control flow expression, if used in a context where a statement is permitted, can omit the trailing semicolon. This can cause an ambiguity between it being parsed as a standalone statement and as a part of another expression; in this case, it is parsed as a statement. The type of ExpressionWithBlock expressions when used as statements must be the unit type.
When the trailing semicolon is omitted, the result must be type ().
https://doc.rust-lang.org/reference/statements.html#expression-statements
あとif式はifのブロックとelseのブロックで型が揃ってないとだめだよ >>440
「値を返さない」と「()を返す」は同義だと思う。 >>458
値を返さないことはnever typeとして別途定義されてるから()を返すこととは違うよ never は値どころか制御も返さないから別物では？
()を返す(値は返さない)ことはできるけど、neverは返すことも不可能だと思う。 >>455
2つのエラー要因がある
ifは式(rustでは式文と呼ぶのか)なので、then節とelse節が同じ型でないといけない
mainはTerminationトレイトを実装していないといけないので最後の()は数値にできない >>458
値を返さない、という言葉が今この場では曖昧に見える
本当にrustが値を返すものじゃない、と定義しているのは文法レベルで定義しているのはletや関数定義などの文
これは型チェック入る前にエラーになる
文法的に正しい、けど「値を返さない型」としか呼べないような式も存在して、それはrustだとnever type (!) と呼んでいる
loop {} とかif true { return 10} else { return 0 }とか、こいつらは式だけど決して値にならない >>461
じゃあどうしてこれがコンパイルエラーとなるの？
fn main() {
if true {
1
} else {
0
}
()
} The syntax for a block is {, then any inner attributes, then any number of statements, then an optional expression, called the final operand, and finally a }.
The type of a block is the type of the final operand, or () if the final operand is omitted.
https://doc.rust-lang.org/reference/expressions/block-expr.html
let foo = { fn_call(); }; // final operandがないのでブロックの型は()
let bar = { fn_call() }; // final operandがあるのブロックの型はfn_call()の型
式文が()を返すわけじゃない >>464
fn main() {
if true { 1 } else { 0 } // <- 式。文法的にfinal operand以外は文じゃないとダメ。if式の型が()の場合のみセミコロンを省略可。
() // <- final operand
} >>466
なぜ『if式の型が()の場合のみセミコロンを省略可。』という謎ルールがあるの？？ >>467
使い勝手がいいから
fn main() {
if true { 1 } else { 0 }
()
}
↑この`if true { 1 } else { 0 }`に意味ないでしょ？
意味持たせるには`let foo = if true { 1 } else { 0 };`みたいに評価結果の値を何かしら使う形にする必要がある
意味がないけどセミコロンで式文にして「値を無視します」と表明すればエラーにはしない
表明がなければ「お前意味ないことやってるぞ」とエラーにしてくれる
`if condition { println!(“1”) } else { println!(“0”) }`みたいに()に評価されるif式は
副作用を起こしたいケースなので評価結果の値を何かしら使う形じゃなくても意味がある
この使い方の時にセミコロンを必須にすると他言語習得者にとってはめちゃくちゃ使い勝手が悪い
知ってれば役に立つことはあっても普段コードを書く時に意識する必要のないルール >>467 他の言語での一般的な書き方も出来るようにだと思う >>467
if式から値が返ってきた場合、次の行まで式が継続するのか;省略なのかが曖昧になるから
()ならそれに対してなにか操作はできないから、式が継続する可能性は消えて、;省略が確定する >>468
>`let foo = if true { 1 } else { 0 };`
一応補足しておくと↑この場合のセミコロンは文法的にはlet statementのセミコロン >>470
こういうことかな
if true { () } else { () } - 2 【値-2】
if true { 1 } else { 0 } - 2 【エラー】
if true { 1 } else { 0 }; - 2 【値-2】
(if true { 1 } else { 0 }) - 2 【値-1】 Cは、明確にポインタをつかって書くことで手作業で最適化できるが、
Rustのsafeモードは、見た目は参照もポインタも使わず実体コピーのような
書き方をする。例えば、
let a = Box::new(オブジェクト名:{・・・});
や、
let b = Box::new(オブジェクトを返す関数(・・・));
のように。
これはちゃんとコピーが生じないように最適化されているのだろうか？
C++は、同様の書き方をする場合は、無駄をなくすために例えば、
vector::emplace_back()
なるものがあり、最適化に任さずに明確にコピーを省略するマクロの様な
働きをするらしい。 >>476
あと、C++の場合、
CPerson person = CPerson(・・・);
と書いた場合は、代入にならずに必ず、
CPerson person(・・・);
と書いた場合と全く同様にコンストラクタが呼び出されることが決まっている。
Rustの場合、そういうことが全くドキュメント化されてない。
C++プログラマはそのことを理解しているから高速なコードが書けるが、
Rustは書いてないのでテキトーに書くしかない。
結果、あまり速くないコードになって、しかもどこが原因かも分からなく
なりそう。 Rustでは、CPersonのメンバ関数 new()の中で Heapにオブジェクトを作る時、
fn new(yyy) {
return Box::new( CPerson {
age: xxxx,
name: xxxx
} );
}
みたいに書くしかないらしい。しかし、C++だと、コンストラクタの中で、
GetSystemModuleName(&name, zzz);
のような書き方も出来る。
何が言いたいかと言えば、Rustだと代入形式でしか書けないので柔軟性に
欠けるということ。 bindings_after_at stableになったのうれしい >>480
メモリ安全性を保つのが困難になっていくからそれを避ける方法がベストだよ >>476
コピーが生じないように最適化される。
つまり、スタック上の一時オブジェクトをヒープにコピーするのではなく、ヒープ上に直接オブジェクトを作成する。 >>480
具体的にこのように書きたいけどエラーになるというRustのコードを示してください。（他の言語のコードは不要）
それによりようやく初めて、何を問題としているのか、何が問題なのか、がはっきりします。 VeqDequeに二分探索実装されてるけどそもそもソートできなくない？？？ >>488
make_contiguousかas_mut_slicesで中身の可変スライスを受け取って
そのスライスのsortかsort_byを使えばソートできそう（試してない）
make_contiguousが本線っぽいからリファレンス読んでくれ make_contiguousするならそのあとのas_mut_slicesに対して二分探索でよくない？？？？ contiguousじゃないがsortされてることが保証されてるケースで使いたいのかね sort順を壊さない位置に要素を挿入するのにbinary_searchを使う >>486
オブジェクトを返す関数を Box::new()のパラメータの位置に書いてもそうなるの？ std::ops::Index を実装すればええんちゃう？ >>498
おお、こんなのあるのか。知らなかった。 Tokio @tokio_rs
Announcing Axum - An ergonomic and modular web framework that takes full advantage of the Tokio, Hyper, and Tower ecosystem.
https://tokio.rs/blog/2021-07-announcing-axum axumはシンプルかつ洗練されており柔軟性もあって、よりRustっぽい
それでいてtokio直轄だから今後の主流になりそう tokio、名前がダサすぎて無理w
async-std勢にもっと頑張ってほしい Tokioの名前の由来って普通に東京の可能性があるのか
＞I enjoyed visiting Tokio (Tokyo) the city and I liked the "io" suffix and how it plays w/ Mio as well. I don't know... naming is hard so I didn't spend too much time thinking about it.
https://www.reddit.com/r/rust/comments/d3ld9z/how_tokio_crate_got_its_name_like_that/ axumのimpl IntoResponseとかはaxcixより命名規則とかディレクトリ構造とかよかったけどappの組み立て方が微妙だなー
n-texとかがかなりいいよね ランタイムはasync-std, tokio, actixの3系統という認識であっていますか？
今回は組み込みとか除外で、ウェブ使う前提での根幹の非同期ランタイムに限る話として。
それぞれの系統のデメリットは何ですか？ actixは内部でtokio使ってるから実質tokio ここ反tokio派が多いようなので
見習ってasync-std派になろうと思います
デメリットなどあれば教えてください 遊びコードなら非同期なんか要らないだろ
同期処理のフレームワークにしとけ tokioは巨大な一枚岩になっていて方針がおかしくね？ >>520
smolはasync-ioやasync-fsやasync-netやasync-executorなどの親分だね
それらsmolのサブクレートであるasync-*シリーズはsmol以外のところでも使われてる RustではじめるWebAssembly入門～JavaScriptを超える高速なWebアプリ開発を実践しよう
https://codezine.jp/article/detail/14567 昔はtokioも同じように多数のtokio-xxxから成り立っていた
しかしどんどん合併していき巨大な一枚岩tokioになってしまった 最終的に各機能は連携するので整合性を維持したまま保守し続けることを考えたら
全体でひとつのパッケージにしてしまうのが楽というのはわかる。 featureで機能on/offするtokio方式の方が使う側も楽では >>520
smolもasync-stdもStjepan Glavinaが立ち上げた
だからasync-ioなど両者共にベースとしている オライリーの本で勉強始めたんだが、説明なしにいきなりSomeとか出てきてもやもやしながら読み進んでいる。
索引にも見つからないし。この本のどこかにSomeの説明があるなら誰かページ数教えて。 Somewhere
言いたかっただけだから叩かないで蹴らないで わいの持ってるオライリーの『プログラミング Rust』だと27ページ（§2.6.1）でOptionの説明してる 同じ本です。そこで使っているSome(T)の説明がなかったので。
文脈からするとT型の値を持っている何かなんだろうけど、正体がわからないのがもやもやして。 列挙型（enum）なら10章で取り上げてるね
Optionは出てこないかもしれないけど あ、なるほど。Some(T)とい型があるのかと思ってしまったけど、Some<T>じゃないですね。
Option<T>の値の一つとしてSomeがあって、それがTの値を持っていると。 Rustの特徴のうち今回の件だと以下の3つの側面を理解するまでが初心者あるあるですもんね
・Rustのenumは値付きenumすなわちタグ付きunionである
・enumのうちResultとOptionの時だけmatch/return構造のsyntax sugarとして? operatorがある
・そのためRustにはtry/catchの大域脱出機構が無いけども同様の利便性を途中の関数呼び出しに?の1文字付けるだけでスルー出来る >>534
原著の新しい版持ってるけど26~27ページにあるOption<T>の説明は特に変わりないよ
サンプルコードのOption<u32>がOption<usize>になってるくらい
>>535
>そのためRustにはtry/catchの大域脱出機構が無いけども同様の利便性を途中の関数呼び出しに?の1文字付けるだけでスルー出来る
実際に書いてれば分かると思うけど受け渡しするための型を常に意識する必要があるからスルーとはちょっと違う
Javaの検査例外前提なら同様の利便性と言えるかもしれないけど >>536
エラー返す関数はResult<T,Error>で統一されているから、呼び出す自分もそれを見習うだけでしょ。
そしてエラーをcatchしたいところではmatchして、エラーをスルーしたいところでは『?』 >>537
Result<T, Error>のErrorの部分の型が違うと?演算子は使えない
struct MyError; // 独自エラー型
fn task() -> Result<(), MyError> {
let file = std::fs::File::open("foo.txt")?; // std::io::Error ≠ MyError だから駄目
// ...
Ok(())
}
ただ型が違ってもFromを実装することで?演算子を使えるようになるのは知っておくと便利
// ↓があると↑はコンパイルできる
impl From<std::io::Error> for MyError {
fn from(error: std::io::Error)-> MyError {
MyError
}
} ?はintoを呼び出してるから
まで知っているとモテる 不要なuse削除してくれる便利な機能ってもしかしてあったりしますか？ Optionすら知らない人が、いきなりオライリー読んでも分からんのでは…
無料で読めるBookから読んだ方が良くない？ Rustlingsの構造体のところやってるんだけどさあ
↓この構造体があった場合に、なんで後に出てくるダメって方のじゃ動かないの？？？
struct ColorClassicStruct {
name :String,
hex :String,
}
//ダメ
//テキスト領域に"green"や"#00FF00"が書き込まれて、それに対する参照が渡されるからダメってこと！？
let green = ColorClassicStruct{
name: "green",
hex: "#00FF00",
};
//OK
let green = ColorClassicStruct{
name: "green".to_string(),
hex: "#00FF00".to_string(),
}; "green"の型は&'static strで"green".to_string()の型はString
ただそれだけの話 >>545
型が異なる
どちらも文字列実体はUTF8の[u8]配列だが
String
・Vec<u8>を利用
・つまり文字列実体は[u8]配列をヒープに領域確保(この場所は伸長により自動的に移動あり)
・そこへのポインタと確保メモリの長さと文字列の長さの『3つ組』を持つ
・文字列の長さは可変で確保メモリの長さを超えるとヒープ再割り当てが自動的に起きる
&str
・スライス&[u8]を利用
・つまり文字列実体の[u8]は既にどこかに確保されている
・そこへのポインタと文字列の長さの『2つ組』を持つ
・文字列の長さを変えるという概念はない 現状LLVM上でしか動かないらしいけど
将来的にC/C++並みにターゲットプラットホーム増やすって動きはないの？ >>550
そのプラットホームって何を指して言ってる？ >>550
gccバックエンドとかのプロジェクトは進んでいる gccrsはやってること考えたらすごい勢いで進んでるとは思うけどね
実用になるのはこっちが早いかと
https://github.com/antoyo/rustc_codegen_gcc JVMバックエンドで動くJRustも欲しい
あ、Rust.NETもいるな ランタイムを変える必要はなくて、FFIでいいんじゃないだろうか 純粋に興味だけで言えば面白そうだけど
C++/CLIの二の舞になりそう JVM上で動かすなんて、既存資産扱うところでGC避けられなくなる訳だから嬉しさが皆無では。
JVM上で現代的なプログラミングしたいだけならScalaやKotlinのほうがよっぽどいい。 >>546
>>547
どっちも参照っぽいのに何が違うのか全然わ買ってなかったよ
ありがとう！ >>561
二の舞って、MSがサポートを投げだした以外は別に悪いところは無かったと思うが。 C++/CLIのCLIってマイクロソフト.NETのでしょ LLVMのバックエンドがgcc並みになれば万事解決 >>564
それが全てだろ。
開発コミュニティが長期的に維持されない (維持される見込みがない) なら
他の何が良くても産業的に使い難い。 はぁ。
>>561はGCを持った仮想マシン環境に移植することがC++/CLIと似た状況だと言っていたのかと思ったが、
そこは全然これっぽっちも関係ない話なわけね。
開発コミュニティが途中で投げ出す恐れなんて言っていたらあらゆるものが当てはまりそうだが。 競プロでRustを使ってみようと思って勉強してたんだけど、
再帰関数がめっちゃ面倒なのね
関数の外のスコープの変数の読み取りができないから、
全部引数に記述しなくちゃいけなくて凄い面倒
処理速度が速かったので期待してたんだけどな(´･ω･`) >>545
ダメの方で通るでしょ
宣言でStringを&'static strにする
"green"とだけ書けばプログラムコードのread onlyエリアに確保されて&'static strのライフタイムになる
Stringを使うとheapエリアを余分に使ってしまうので損
もちろん文字列が伸びたり一部書き換わったりなど対応したい時ならばStringを使う >>570
全部引数渡しは当然だろう
問題なのは末尾再帰が出来ない事 >>570
グローバル変数使いたいなら static mut 使えば良いのでは
unaafe 必要だけど別に安全性欲してないでしょ？ >>573
マジかそんなんあんのか！！！！
static mut test: i32 = 0;
fn main() {
unsafe {
test = 1;
unsafe fn calc() {
if test == 1 { println!("yes") }
}
calc();
}
}
yes表示ｷﾀ━━━━(ﾟ∀ﾟ)━━━━!!
ありがとうありがとうヽ(´ー｀)ノ 純粋なグローバル変数は仕方ないけど、thread_localは
もっと簡単な使い方にしてほしかったなー
コールバック関数みたいに引数で渡せないパターンが面倒 競プロに向いてるかって言われるとそうでもない気はする >>570
グローバル変数の代わりに関数の引数を増やすと毎回連れ回す形で見にくくなるけれど
再帰関数ではなく再帰メソッドにしてしまえば引数を増やさずにいくらでもパラメータを使えます
例えば「再帰で1からnまでの和や積」を求める例で「差分diff」が可変パラメータとした場合
struct Arith { diff: i32 }
impl Arith {
fn sum(&self, n: i32) -> i32 { if n <= 0 { 0 } else { n + self.sum(n - self.diff) } }
fn mul(&self, n: i32) -> i32 { if n <= 1 { 1 } else { n * self.mul(n - self.diff) } }
}
fn main() {
let diff1 = Arith { diff: 1 };
assert_eq!(diff1.sum(10), 55); // 1+2+3+4+5+6+7+8+9+10
assert_eq!(diff1.mul(7), 5040); // 1*2*3*4*5*6*7
let diff2 = Arith { diff: 2 };
assert_eq!(diff2.sum(10), 30); // 2+4+6+8+10
assert_eq!(diff2.mul(7), 105); // 1*3*5*7
}
今回はdiffの部分が1個だけですが複数のパラメータにもできます
こうすることで「グローバル変数を使わず」＆「引数を毎回連れ回さず」に書けます >>574
キャプチャしたいだけならクロージャ使えばいいけど
let test = 1;
let calc = || {
if test == 1 { println!("yes") }
};
calc();
再帰ならaccumulator的なものを連れ回すほうがいいと思う struct使ってimplで&mut selfを持ち回せばいい気が >>576
全部自分で作れるんならね
既存のライブラリとかOSのAPIとかの制限は自分じゃどうにもならん >>577
.with使うのが面倒 .borrow_mutもね
そのまま読み書きしたい
そもそもstaticな時点で生存期間のチェックなんていらないんじゃないかと >>585
可変参照が複数同時に存在すると即UBだから safe なコンテキストでは with や borrow は必須にせざるを得ないだろうね
RefCell とかと同じ みんなありがとう、なんとなく再帰できたよ。やり方あってるかわからんけども
以下お試しプログラム
ttps://paiza.jp/works/mondai/dp_primer/dp_primer_stairs_boss
use std::*;
fn main() {
let mut str = String::new();
io::stdin().read_line(&mut str).unwrap();
let mut nums0: Vec<i32> = str.trim().split(" ").map(|it| it.parse().unwrap()).collect();
let mut test = Test { nums: nums0 };
println!("{}", test.calc(0));
}
pub struct Test {
nums: Vec<i32>,
}
impl Test {
pub fn calc(&mut self, id: i32) -> i32 {
if id == self.nums[0] { return 1; }
let mut res0: i32 = 0;
for i in 1..=3 {
if id + self.nums[i] <= self.nums[0] {
res0 += self.calc(id + self.nums[i as usize]);
}
}
return res0;
}
} ちな、同じプログラムをkotlinで
fun main() {
var numList = readLine()!!.split(" ").map { it.toInt() }.toIntArray();
fun calc(id: Int): Int {
if (id == numList[0]) return 1
var res: Int = 0
for (i in 1..3) {
if (id + numList[i] <= numList[0])
res += calc(id + numList[i])
}
return res;
}
println(calc(0))
} >>587
このケースだとmutの必要もないし
単に`fn calc(id:i32, nums:Vec<i32>) -> i32`にすればよくない？ とりあえずできるかどうか適当に書いたものだからｗ
あと、これはindexだけを順繰りに送っていけばいいので引数1個でいいけど、
複雑な問題だとindexに、3次元配列の添え字として3つ、その配列本体、比較する配列の文字列とか、
さらにメモ化するためには、メモする配列もとか、めっちゃ引数がもの凄くなることがあるのね
だから、なんとかグローバル変数にアクセスできないかと思って
逆に構造体に全部の参照したい変数をまとめて、それだけを持ち回るとかもいいかもｗ 再帰使うならもっと再帰っぽく書いてくれ
numsの初項とそれ以降の数値の意味が全く違うなら同じ変数に入れないでくれ
書き捨てや試行錯誤の途中ですらやらないぞこんなの >numsの初項とそれ以降の数値の意味が全く違うなら同じ変数に入れないでくれ
確かにそうなんだが、一度配列にいれちゃったからいいと思ってｗ
そして十分に再帰っぽいと思うけどなあ
↓スキルがありそうな人のご意見なので、もし良ければ再帰での美しい実装を披露して欲しい
↓参考にしたいのでよろしくお願いします
ttps://paiza.jp/works/mondai/dp_primer/dp_primer_stairs_boss スマン競プロなの失念してた。ならしょうがないゴメンよ >>592
競技プログラミングが何の実用的な実力に結びつかず、全く役に立たない遊びに過ぎない、と言われているのはそこですね 再帰でメモ化したバージョンとループでボトムアップにしたバージョン
https://play.rust-lang.org/?version=stable&;mode=release&edition=2018&gist=d1b9bd1a085e334225a253ed9360c2e7
テストはしてない メモ化するならグローバル変数(もしくは引数で渡す)にした方が良いんじゃないの？ >>596
競プロは戦闘機でいうところのアクロバット技術と同じようなものだな
アクロバット飛行はときに見るものを魅了するし部分的には実戦に通じるような高度な技術も必要だが
それ自体は実戦では役にたたず実戦でアクロバット飛行のような飛び方をしようものなら撃墜される >>593
やってみた
入出力例のassertも通ったけどこれでいい？
fn main() {
assert_eq!(17, count(10, &vec![2, 3, 4]));
}
fn count(n: i32, abc: &[i32]) -> i32 {
if n < 0 { 0 } else if n == 0 { 1 } else { abc.iter().map(|a| count(n - a, abc)).sum() }
} >>598
そだね
少し数が増えるとめちゃ効率悪かったわ >>600
おお 与えられた数値をmapのなかでラムダ式で計算して、リストのsumするところが素晴らしいｗ
この場合はカウントだからsumだけど、最小値のminとか最大値のmaxとかでも利用できそうだ >>600
いま試しにやってみたけど、メモ化は必須だから、その美しさは保つことができなかった(´･ω･`) メモを連れ回す方式に修正した
borrowだと面倒なのでmoveにしたがRefCell使うともう少し速くなったりするのかもしれない
https://play.rust-lang.org/?version=stable&;mode=release&edition=2018&gist=a0cd25619216cbe4dcdab6c51b7301ad 競プロって計算量を落とせるアルゴリズムを考えることがポイントだと思うんだけど
実装言語の差異はどれくらい影響してくるの？ >>605
あくまで参考だけど、こういうのがあるよ
ttps://twitter.com/chokudai/status/1325981178730438657
ただ3次元配列になると途端に速度が落ちるとか、そういうのもあるので鵜呑みにはできないけど傾向ってことで
あと、各言語の時間制限をしているサイトもある
ttps://paiza.jp/guide/language.html
この各言語の時間制限をみると、運営が考えている言語ごとの速度の違いが大まかにわかる
https://twitter.com/5chan_nel (5ch newer account) 競プロやっても日本の情報処理産業の国際的地位向上に結びつく気がしない そら趣味だもの。仕事とは関係ない
ただ、言ってる論理構成が、某小学生youtuberが義務教育なんか
必要ないって言ってる理屈と同じだなと感じる >>603
メモ化するならこう
fn main() {
let mut input_line = String::new();
std::io::stdin().read_line(&mut input_line).unwrap();
let input_numbers: Vec<i32> = input_line.split_whitespace().filter_map(|s| s.parse().ok()).collect();
let n = input_numbers[0];
let abc = &input_numbers[1..];
let mut memo: Vec<i32> = vec!(1);
memo.resize((n + 1) as usize, -1);
println!("{}", count(n, abc, &mut memo));
}
fn count(n: i32, abc: &[i32], memo: &mut [i32]) -> i32 {
abc.iter().map(|a| { let m = n - a; if m < 0 { 0 } else { if memo[m as usize] == -1 { memo[m as usize] = count(m, abc, memo); }; memo[m as usize] }}).sum()
} >>608
むしろ義務教育でyoutube撮影方法教えるべきだとか主張するアホと一緒だろ >>608
資格主義や学歴主義もだけど戦略不在でそれ自体が目的化しているように感じる
手段が目的化して迷走している事例は腐るほどあるような 競プロはある種のパズル
パズルを解いたり競ったりを楽しむのもの
パズルをたくさん解くことで仕事のプログラミングに活きる部分がなくも無いが
その二つを同一視してる人は有害 同一視してるというか
同一視された方が有利になれる人が同一視するように仕向けている
それ誰よっていうと、サロン屋や人材屋 Rustlingsの問題なんだけど、これの37行目のmutってなんで必要なの？？？
https://ideone.com/41tBgy
参照するアドレスが変わるわけでもないのに・・・・どう理解すればいいものなんだろう・・・・
それと、ある構造体を構成するメンバーって、全部がmutか否かの二択になっちゃうわけ？混ぜれないの？？？ >>616
え？どこに参照が出てきているの？構造体そのものでしょ
そして直後に構造体の中を書き換えているからmutが必要
そして構造体のメンバーはバラバラに生死貸借が起きることはないからメンバー個別の指定の必要性はない 38,39でその構造体のメンバーに代入するのに必要 >>616
1. let mut x = create_order();
2. let mut x = &create_order();
3. let y = &mut create_order();
4. let mut y = &mut create_order();
それぞれ何がmutableなのか違う
「参照するアドレスが変わるわけでもないのに」ってのは3番目をイメージしてると思われる let mut your_name = Some(String::from("変更前"));
match robot_name {
Some(ref mut name) => *name = String::from("変更後"),
None => (),
}
println!("君の名は。: {:?}", your_name); 初歩的な申し訳ないんだが
let x = "hello".to_string(); // convart text to a string テキストを文字列に変換
let y = String::from("hello"); // get text directly テキストを直接取得
これの違いがわかりません
やってること同じですよね？
出力の違いが出る例とかあれば教えてもらえないでしょうか？ to_stringはinlineでString::fromしてるから全く同じ
impl ToString for str {
#[inline]
fn to_string(&self) -> String {
String::from(self)
}
} >>622
早朝からレス感謝
もやもやがとれて勉強に集中できそうです
ありがとうございました loop式はbreakで指定した値を返せるのに
なぜwhile式やfor式は値を返せないの？
Option型にしてbreakで値を指定した時だけSome(値)としてそれ以外はNoneとすれば便利なのに (while true のような実質無条件ループを除き)条件付きループをbreakで抜けるのは可読性を下げる要因になるから一般的にはRustに限らずできるだけ避けるだろ
悪い作法を推奨するような機能は付けるべきではない ほぉたしかにそうゆうのあれば便利な時もありそう
macroで似たような物は作れそうな気がする
たしかにlispとかでもwhileはnil returnだな(´・ω・｀) >>626
forでお目当てのものが見つかったらその時の値を欲しい時
当然そこで打ち切りたいから普通にbreakすると思うが君は回り続けるのかね？ >>628
打ち切りたいなら、take_whileの結果を対して回せばよくね？ つまりforやwhileではなくiterを使うかloopを使えってことか awaitとか ? が絡むとループ使いたい場合はあるかもね >>632
それらメソッドチェーン部分ではもちろん使えるけど
iter系で指定するクロージャの中でも使えるんだっけ？ >>633
Item が Option や Result なら ? は使えるけど
await は async fn か async block の中でしか使えないからほぼ使えないと思ってよさそう >>634
?の方だけど、NoneやErrを除外してSomeやOkの皮を外すのはfilter_map使わないとメンドイね
例えばこんな感じで「?」はクロージャ内で使えた
println!("{}", std::env::args().filter_map(|x| std::char::from_u32(x.parse::<u32>().ok()?+110)).collect::<String>());
実行結果
$ cargo run 4 test 7 5 987654321 6
rust >>636
これは filter_map よりも map().collect::<Result<String, _>>() の方がよさそう 全く関係ないけど、
for x in v
には、
for x in &v
for x in &mut v
for x in v.iter()
のようなバリエーションもあるようだけど、
for &x in v
のような書き方も出来るの？
あと、v と書いても v.iter() の省略なの？
この辺の話はどこに書いてる？ >>638
ついでに、
let x = &y;
は、
let &x = &y;
let &x = y;
みたいに書くことも出来るの？？？ >>638-639
左辺と右辺はパターンマッチで対応するメカニズムになっている。 この言語の敷居の高さの上げ方は異常すぎる。誰も全容分かってない それだと最初のエラーを拾ってしまうけど今回はエラーになる引数を与えてそれらを無視して拾い集めるコード
もしエラーにならない引数だけを与えて成功するコードならばその方針もいいかも
あとfrom_u32はOptionを返すのでResultでなく全体をOptionにするとして
最後にunwrapも必要なのでmap().collect()のコードは以下になると思いますが
元の>>636より長くなってしまいますね
println!("{}", std::env::args().skip(1).map(|x| std::char::from_u32(x.parse::<u32>().ok()?+110)).collect::<Option<String>>().unwrap());
実行結果
$ cargo run 4 7 5 6
rust 参照型の変数xをlet文で新しい変数yの初期値にした場合、
let a = 123;
let x:&i32 = &a;
let y = x;
y は参照型になるんだっけ？
そもそも、最初の文は
let x = &a;
と書いても全く同じ意味だっけ？ さらに、
let x:&i32 = a;
と書いても同じ？ >>647
試してみるといいよ
yの型を知りたければtype_of(&y)で
fn type_of<T>(_: &T) -> &str {
std::any::type_name::<T>()
}
let a = 123;
let x = &a;
let y = x;
println!("{}:{}, {}:{}", x, type_of(&x), y, type_of(&y)); 答えを知ってる人に書いて欲しい。
この言語、試してみないと型すら分からないんだったら困るな。 >>647
> y は参照型になるんだっけ？
なる
> そもそも、最初の文は
> let x = &a;
> と書いても全く同じ意味だっけ？
ほぼ同じ
下だとaの型がi32に固定されない点だけ違う
> さらに、
> let x:&i32 = a;
> と書いても同じ？
これは全然違う
そもそも型エラーでコンパイルできない >>647
めちゃ基本的なことなので入門書を読もう 本を読んだけど、明確には書いてなかったと思う。
let文に置いて参照型が右辺の場合、左辺も参照型になるということなのか。
ということは、letを書かない代入文で左辺に参照型で無い型を
書いて、右辺に参照型がある場合にはエラーになるのか？？？
わけが分からん。 C++出身だ。
Rustにおける参照型の変数の規則性が分からない。 >>654
Rustの参照はC++の参照じゃなくてポインタのほうが近いよ Rustから入る人や
色々な言語をやってきた人は理解が早い
しかしC++だけやJavaだけしか経験ない人は
自己中な思い込みが激しくて素直に学習しようとせずに間違った解釈したりして無駄な質問ばかりしがち Rustは例はあるが、ちゃんとした論理的な言葉や数式の様なもので、規則性が
書いてないのではない？
C++だともっと厳密に書いてある。 >>656
そうではなくて、規則性を言葉で書いてくれ、ということだよ。
試してみてなんとなくの経験法則とかじゃなく。 >>658
bookの印刷版も読んだが、途中読み飛ばしたページもあるが
読んだところにはちゃんと書いてなかったと思う。
数学的な規則が欲しいんだ。
文学的な言葉や例ではなく。 >>657
そういう位置付けのドキュメントはこれだね
ただし冒頭にもある通り完全ではない
The Rust Reference
https://doc.rust-lang.org/stable/reference/ >>656
まずはC++を忘れろ
思い込みは習得の邪魔になる
あるいは様々な言語をやってきていれば各言語で概念や書式や用語などが少しずつ異なることが理解できるはずだ >>662
めんどくさいので試してないんだよ。
試さなくても数学の用に読んで理解できる規則が欲しい。
Cのポインタは難しいとされるが、俺は数学が得意なので本を読んだだけで
完璧に理解できた。
C++探せばちゃんと書いてある本がある。 >>661
BNFで書いてあるようだが、具体的にどこに書いてあるか示してくれ。
ちなみにBNFだと意味論までは語れ無い事があるので無理かも知れない。 「俺は数学が得意なんだ！」
ワロタ
いつものBoxおじいさんじゃん 目次を見てもReferenceの文字が見当たらないが。
C++だとちゃんとあるぞ。
どうしてReferenceも型のはずなのに、目次すらないんだよ。 >>660
そこまで言うならば十数種類あるRustドキュメントのうち、
editionとapiとstdとreferenceとtheとcookとexampleあたりにあとはcliとasyncくらいまでが基礎かな。
あと外部たがcargoとrustcにrustdocなどのbookも。
unstableやnomiconは後でいい。
wasmやembedded系bookも必要なら。 >>668
なんで、この言語に置いて最も重要な型の一つの規則性がそんな何千ページもの
本を読まないと解説されてないんだよ。 >>667
数学得意ならRustも深く理解しやすい
強い静的な型システムの元にある
そして生死貸借も明確で数学的にメモリ安全性を保証
利便性のための参照＆外し自動適用を除いて型キャストが暗黙に自動で行われることともない >>672
さっきから聞いているのに、ちゃんとした論理的規則を語った人は誰も居ない。
つまり、今このスレに居る人達は誰も理解してない証拠だろう。
つまりこれは、Rustが試してみないと分からない言語だからではないか。 >>673
5chじゃなくて users.rust-lang.org あたりで聞いてみたら
専門家がいっぱいいるよ >>674
参照型はRustにとって最重要の型。
それがそんなところに質問しなければ分からないというのは困ったことだぞ。 ポインタを理解するのにもRustを理解するのにも数学の得意不得意は関係なくね？
ポインタを理解できない人をあまり多く見たことがないから実際のところどうなのかよく分からないんだが >>670
どこにも記述されていないことを君が自己中心的な思い込みで間違いなく判断や間違った推測をしているから>>647や>>652の書き込みになっている
let文や呼び出し引数はirrefutable pattern matchingであり各種destruturingはあっても個々の型は対応する
Tと&Tがmatchingすることはない >>677
どから、それがどこに書いているのかリンクを張ってくれ。
あなたの独自説ではなく、公式のな。 >>672
>利便性のための参照＆外し自動適用を除いて型キャストが暗黙に自動で行われることともない
rustではcoercionと呼んでるものが暗黙の型変換だぞ 公式の言葉が欲しいってならreferenceのlet statement, reference patternsあたりでもみりゃいいんじゃないっすかね知らんけど rustは思ったより流行りそうにないなぁ。
使用者爆発的に増えてくるハズがC++知らん人は
そもそも使う層じゃないし、
C++知ってる人は、逆にめんどくさいから様子見、流行らなければスルー
ぐらいかね。 ぶっちゃけ1言語のみしか使えないようなプログラマが有能だとはとても思えないが
実際にそういう人はいるけど融通効かないし生産性が高いとも思えない
所詮ドカタじゃないの >>682
C++ で疲弊した人が Rust に移ってるってのはあるぞ。 >>675
だからそう主張してくればよいじゃん
ここにいる人じゃ話にならないんでしょ？ >>647
上３つの式は正しいのに、なんで下２つの式はそうなるのか 実際はc++わからんけどrustわかればマウント取れそうじゃね？って馬鹿しか手を出してないという現実。 Rustは、GoogleTrendsでは他の言語に比べて低空飛行だけど(Kotlinと同じくらい
ではあるが)、他の言語が下がる傾向があるのに対してRustだけは少しずつ上がってる。
Stackoverflowでは既にC++の30%～40%位まで質問の量が迫ってきているとか。
なので良く分からない。
GoogleTrendsが実際と合ってないという説も見かけた。 crates.ioでcrateをダウンロードされた回数が20億回を越えていたり、
投稿されたcrateの数が3万種類を超えたりとか。
20億回というのはとんでもない大きな数字。
全世界のプログラマの数は2,500万人くらいだそうだから相当な数だ。
良く分からないくらい異常に大きな数値。 iocrateはきっと誰かがwhile true do; cargo build; cargo clean;doneみたいの流し続けたんだろ
c++よりマシなのは確かだがredosだかみたいの全然進まんしc++,cな代替物にはなれなさそう
tech giantsみたいな連中が根幹部分rustに変えるみたいな事言ってるけど流行ってる感じ全然しないよね(´・ω・｀) リポジトリの分散化考えないとマジ負荷が半端無さそう rustで作ったライブラリは他の言語から使いやすいんかい？
c\c++置き換えるなら、むしろそここそ一番重要かもしれん。 >>696
Rustのライブラリは他言語からは使いにくいのが問題になっていると聞いたが。
多分、C/C++のライブラリのようにはいかないと思う。 >>692
前半、なるほど。
githubで最高人気であるところのvue.jsも、いいねは2万くらいだったと思うし。
なんか数値に異常さを感じる。 vue.jsのgithubでのStar数は、18万7,000だった。
crate.ioのダウンロード回数はこの1万倍を越えている。
普通に使っているだけでは辻褄が合いそうに無いな。
全世界の全てのプログラマが100回くらいcrateをダウンロードしたことになる。 crates.ioのDL数と比較すべきはnpmのDL数では？
https://www.npmtrends.com/vue crates.ioのダウンロード数は依存crateのCIが走る度に増えるようなものだからそりゃ多くなるでしょ
GitHubのstarと比較したのはなぜ？ 別にプログラマが手動でダウンロードするわけではないんだが…
1回コンパイルすると100個以上落としてくるのも普通だから
2千万回コンパイルが実行された、という程度の話
ざっくり5年で均せば1日1万回ってとこか CIだろうね。人がcargoを直に打ってるとは思えん 強力にキャッシュが効くはずのCIでツールが未整備なために効かず
異常にDL数が伸びてしまっただけだろう CIのライブラリインストールが動画の次に無駄な帯域を食ってると言われているだけある >>639
難しく考えすぎ
&と*の関係は単純明白
let a = 123; // a: i32
let b = a; // b: i32
let p = &b; // p: &i32
let q = p; // q: &i32
let &r = &p; // r: &i32
let x = &q; // x: &&i32
let s = *x; // s: &i32
let c = *r; // c: i32
let y = &&c // y: &&i32
let z = y; // z: &&i32
let d = **z; // d: i32 ライブラリが他言語から使いにくいってのも謎だな
他言語からならC ABI一択なわけで、どの言語でライブラリ書こうが使い勝手は同じだと思うが >>697
例えばPyO3でPythonからRust呼び出せるよ >>672
自動的な参照外し(*を記載してないのに*適用)って、値を使うところで&Tや&&Tなどが使われたときにTの値になる、というルールだからそれも数学的でしょ。
あと&Tではない各種スマートポインタや自作の型を、*記載で参照外しする時も、Derefトレイト実装通りに行われるからこれも数学的。 >>647氏が混乱したのもそこかもね
例えば
let a = 99;
let b = &a;
assert_eq!(100, b + 1);
assert_eq!(100, *b + 1);
つまり値を使う所では参照のままではなく安全に*が自動適用
構造体のフィールドアクセスも
struct Point {x: i32, y: i32}
let p = Point {x: 19, y: 31};
let q = &p;
assert_eq!(p.x, q.x);
assert_eq!(p.y, (*q).y);
つまりフィールドアクセスする所では参照のままではなく安全に*が自動適用
だからC言語などにある「q->y」という記法がRustには不要なので存在しない こじつけの自己レス自演が気持ち悪い
これでバレないとおもってるんだからww
お前も頑張って勉強中なの丸出しなのになぜそんなに上から目線で書きたがる？ >>710
assert_eq!(100, b + 1); は通るけど
assert_eq!(99, b); はコンパイルエラーになるところがミソかな 演算子も含めてメソッド呼出しのときの self の参照が調整されるのは言語コアの機能だけど
演算子の右辺で参照が剥がされるのは参照を受け取るバージョンのメソッドも用意されてるから
という理解でいいんだよね？ >>710
>assert_eq!(100, b + 1);
`b + 1`のbは*が自動適用されてるわけじゃない そこはstd::ops::Addトレイトのimplがあるかどうか
ただしi32と&i32に対してはあるけど&&i32に対してはない
そのためさきほどの例だと
let a = 99;
let c = &&a;
assert_eq!(100, **c + 1); // i32はそのままOK
assert_eq!(100, *c + 1); // &i32は参照外してi32でOK
assert_eq!(100, c + 1); // &&i32のAddトレイト定義はないからコンパイルエラー 質問したようなのと近い流れになってて助かった
(0..7).filter(|&x| x == 0);
↑これ通るから ↓こうしたら駄目だった。なんでなん？
let mut vec0 = vec![1, 2, 3, 4, 5, 6];
vec0.iter().filter(|&x| x == 1);
そこで、様々テストしたら、↓の方法でコンパイルが通ることがわかった
どのやり方が一般的なん？個人的には1か4かと思うんだけど。あと、2は+0することで型推論が働いてるのん？
vec0.iter().filter(|&x| *x == 1); //1
vec0.iter().filter(|&x| x + 0 == 1); //2
vec0.iter().filter(|&x| x == &1); //3
vec0.iter().filter(|&x| x.clone() == 1); //4
vec0.iter().filter(|x| **x == 1); //5
vec0.iter().filter(|x| *x == &1); //6 ベクタの内容を↓にして
let mut vec0 = vec![1, 2, 1, 4, 1, 6];
1の数をcountするようにして表示させてみたけど、>>720の1～6のやり方でどれもcountの数は同じだね いいぞ！いいぞ！これも通るぞ！！
let mut test6 = vec0.iter().filter(|&&x| x == 1).count();
let mut test7 = vec0.iter().filter(|x| x == &&1).count();
let mut test8 = vec0.iter().filter(|x| *x + 0 == 1).count();
ヽ(ﾟ∀ﾟ)メ(ﾟ∀ﾟ)メ(ﾟ∀ﾟ)ノ Bible終えるのにどれぐらい時間かかりましたか？ >>720
(0..7).filter(|&x| x == 0);と同等なのは
let v = vec![1,2,3,4,5,6];
v.into_iter().filter(|&x| x==0); >>725
うおー、まじか！
わかったありがとう。だからforループはちょっと違う挙動になるんだな 違いをわかりやすく示すと
let vec0 = vec![1, 2, 3, 4, 5, 6];
assert_eq!(Some(&1), vec0.iter().next());
assert_eq!(Some(1), vec0.into_iter().next()); ありがとうありがとう
&TのイテレータとTのイテレータが別々になっているとはおもわなんだ まだ慣れてないからideに言われるがままに直してるな、、 >>728
そう考えるよりもムーブor借用と捉えるほうがいいかな
vec0.into_iter()だとムーブになるから値そのものが次々と来る。しかしその後にvec0は使えない。
vec0.iter()だと借用になるから値への参照が次々と来る。その後もvec0は使える。
(&vec0).into_iter()でも借用になるから値への参照が次々と来る。その後もvec0は使える。 >>732
これは例がよくないな。
もう一段ほど関数呼出しを挟む構造になっていればより分かり易くなる気がする。
? 演算子はエラーだったときにそのエラー値を返り値として return する。
つまりその例の場合は do_something_that_might_fail が
エラー値を返したときは main から抜ける。
関数がエラーを出したときに上位にもエラーとして伝播させる機能。
unwrap は Result を剥がすが、エラー値だったときにはその場で panic する。
unwrap を書くというのは「エラー値が返されることはないことをプログラマとして保証する」
または「そのエラーに対して対処する方法はない、対処する気はない」という表明で、
assert 的な意味合いを含む。
エラーの対処を書くのが面倒だけど Result を剥がして型は合わせないといけない
というときに雑に unwrap することはあるんだけど、
多少なりとも汎用的なライブラリにするなら (事前条件が正しい限り) panic が
起こるのは好ましくはないので使い方は慎重に。 >>732
?演算子はほぼtry!マクロのsyntax sugar
言語自体に組み込んだ時にその適用範囲を広げた
try!マクロとは見やすく省略して書くと
Result型rに対してはtry!(r)がほぼmatch r { Ok(n) => n, Err(e) => return Err(e) }となる
つまり?演算子はOption型やResult型の尻につけてNoneやErrの時にreturnする
一方でunwrapはpanicして死ぬ ほぉ、なるへそ
noneとかへの振る舞いの遅延行為としての?op
ある関数を呼んだ関数自体でerrへの振る舞い決定すべきだと考えた場合は?opにする
とすると?op含んだ関数のcallerはmatchとかのタイプ別振る舞い定義をちょっとやかましめ書く必要ありだな
いまいちpanicの振る舞いが分からん
spawned threadが内部でパニくった場合その娘、息子スレッド（スレッドの下層スレッド）とそのスレッド自体にのみunwindが適用されるんだよな？(´・ω・｀) vec0.iter().filter(|&x| x == &1);
これの数字に&つけて型同じにしたら通るってのが納得できないな～
比較がプリミティブ型の変数同士だったら自動的に数値として扱って欲しい >>737
それは強い静的型付けのメリット
異なる型同士の==が通るのは困る
といいたいところだけど
PartialEqトレイト次第で異なる型でも==してくれる場合もある
文字列など
でも整数は厳密でi32とi16ですら不許可 >>738
でも、上の例で
vec0.iter().filter(|&x| x + 0 == 1);
が通るのは+0したときに中身がプリミティブ型だから数値だけ取り出してくれてるんでそ？ >>739
それはまた別で>>715
つまり足し算の実装 &i32 + i32 の計算ができるようAddトレイトで実装されていて、結果をi32で返すようになってるからエラーにならないってことでしょ？ >>741
ご丁寧にi32+i32 i32+&i32 &i32+i32 &i32+&i32の4種類をカバーしてくれてるね
&&i32はサポートしていないため
vec0.iter().filter(|x| x+1==2)はコンパイルエラー まず>>715の間違いを反省しようね
>let a = 99;
>let c = &&a;
>assert_eq!(100, *c + 1); // &i32は参照外してi32でOK >>744
それであってるぜ
&i32+i32は左だけ参照を外してi32にして足し算する >>733
>>734
丁寧に教えてくれて、ほんとありがとう >>743
なるほど、なんかすべての挙動を把握しないとならないんだね
でも、やっぱり「&1」が通用するのは納得いかない(´･ω･`) >>748
基本的には正しく型を用いれば済む
&i32は数値ではなく数値への参照にすぎない
*付けなくても済む便宜の恩恵を受けるのはよいけどそれを理解したうえでしているかどうかの違い String と &str が == で比較できるなら i32 と &i32 も比較できて良い気はする
単に impl がないだけだから pull req 送ったら取り込んで貰えるのでは もう純粋に&1て、1の参照じゃんね
その意味がわからんし、存在意義がわからん
変数同士ならわかるけど、定数的に書いてるんだったらもうプリミティブ型だったら
中身で判断してくれよヽ(`Д´)ﾉｳﾜｧｧｧﾝ >>750
今もi32と&i32の組み合わせ4通り定義
そこへ&&i32が加わると9通り定義
そこまでする意義は？
>>751
だからx==&1ではなくて素直に*x==1と書こう >>751
プリミティブのwrapper crateを作って自分の好きなように定義すれば万事解決 推奨する方法をやりやすく、推奨しない方法をやりにくく
Rustは他の言語に比べると特に後者についてよく考えられてる >>754
postgresクレートのquery()でparamsに数字を書きたいときとか
pub fn query<T>(&mut self, query: &T, params: &[&(dyn ToSql + Sync)]) -> Result<Vec<Row>, Error>
where
T: ?Sized + ToStatement >>752
*x == 1 と書けというのは分かるんだけど
impl PartialEq<String> for &str や impl Add<&i32> for i32 があるのに
impl PartialEq<&i32> for i32がないのは一貫性がないように思う
なんで実装されていないのだろうか >>757
自己解決
RFC1332で議論されていた rubyもpythonも見よう見まねで書けるんだけどなー
javaなんてC++とほとんど同じだから半日もあればマスターできる
でもrustだけは勉強しないと無理っぽい
難しいよ >>757
実は整数と文字列ではそこの逆転現象が起きていて
Stringと&strの等号比較はOK
assert!("xyz".to_string() == "xyz")
しかしStringをmatch文でアームに&strだとコンパイル型エラーでNG
// assert!(match "xyz".to_string() { "xyz" => true, _ => false, });
&i32とi32の等号比較はコンパイル型エラーでNG
// assert!(&123 == 123);
しかし&i32をmatch文でアームにi32だと比較OK
assert!(match &123 { 123 => true, _ => false, }); オブジェクトの同一性 (メモリ上の同一の場所に配置されている) を判定したいときって
参照を == で比較しても駄目ですよね？
ポインタを取り出すのも恰好が悪いように思うんですが、
なんか定番の方法ってあります？ >>754
消費(ムーブ)せずに参照で済ませるためにiter()を使うと当然 &1 が出てくる
let vec0 = vec![1, 2, 3, 4, 5, 6];
assert_eq!(Some(&1), vec0.iter().next());
assert_eq!(Some(1), vec0.into_iter().next());
これはVecだから消費するinto_iter()が使えば 1 に出来るけど
スライスだと消費という概念がないから必ず &1 が出てきてしまう >>761
Rustは所有権があるから同一メモリを指すのは所有権を持つものへの参照同士かな
つまりコード上明白であり比較する必要性がないことに？ こういうことかな
複数の参照もmut参照も生ポインタも当然すべて同じアドレスを指している
let mut i = 123;
let pi1 = &i;
let pi2 = &i;
println!("{:p}", pi1); // 0x7fffebf915a4
println!("{:p}", pi2); // 0x7fffebf915a4
let pi3 = &mut i;
println!("{:p}", pi3); // 0x7fffebf915a4
let rpi3r = pi3 as *mut i32; // 生ポインタ
println!("{:p}", rpi3); // 0x7fffebf915a4
生ポインタを使って書き換えると元の変数が書き換わるので確かにこれは変数の格納アドレス
unsafe {
println!("{}", *rpi3); // 123
*rpi3 = 456;
}
println!("{}", i); // 456 >>766
それは逆
メンテナンス性は最も優れているプログラミング言語の一つ ポインタ関連の問題が所有権と参照で絶対に発生しないってのはデカイよね 将来の苦痛を先に解消できるのが良いのにな、不具合も絞り込みやすい
メンテナンス性悪いってどの辺言ってんのか聞いてみたい 一年ぶりに触るソースを大規模改修しても、コンパイル通せばほぼ動く安心感ある
他言語（特に動的型言語）だと相当テストを作り込まない限り、このメンテナンス性は得られない印象 データ設計を少し考えさせられることによって
メモリ安全性を得ただけでなく見通しも良くなったｗ 潜在的にバグの原因となる変数の扱いすると
コンパイラが怒るのは安心できる 繰り返しでiter()を使ったりinto_iter()を使ったり、ループを使ったり、高階を使ったり。。
そして文字列が複数あったり、更にそれをマクロにされると、それで書き直しが必要だったり
多くの言語でも初心者と上級者で当然、コードの美麗さに違いが出るが余りにも差があり過ぎ
たった「一年ぶり」でコンパイルが通らない言語なんてあるだろうけど、そんな話じゃない イテレータなんてどの言語にもあるし困るようなことか？
無理やり導入で汚い言語よりもRustは綺麗に洗練されていて書きやすい 同じようなことなのに人によって書き方が全然違うからクソって言いたいんじゃないの？ 何が何故問題なのか説明できないイチャモンなんかほっとけ 文字列が複数種類あることが嬉しい人のための言語
嬉しくない人は別の言語を使うべき >>778
例えばいわゆるスクリプト言語などはいずれもRustのString型相当のものしかないため非効率でメモリ食い散らかす状態になっていますね
Rustはそれに加えて部分を指し示すだけの文字列スライス&str型を持っているので無駄なアロケーションを防いで効率の良いコードを書けるようになっていますね >>774
> 繰り返しでiter()を使ったりinto_iter()を使ったり、ループを使ったり、高階を使ったり。
あなたはちょっと無知すぎます。
まず高階関数とも言われるmap()やfilter()等を用いるにはイテレータが必須ですから同じことを指しています。
どちらかを選ぶようなものではありません。
次にRustのforループもイテレータ必須で内部でイテレータを作ってforループを回していますから同じことです。
forループ方式と高階関数方式の2種類で書けてしまうじゃないか！と言いたいのでしょうが、これは他のプログラミング言語でも同じで2種類あります。 繰り返しでiter()を使ったりinto_iter()を使ったりと複数のやり方があるのはおかしいとの御指摘だが
into_iter()は値のイテレータ
iter()は参照のイテレータ
同じものに対して適用しても別のイテレータが得られる 少し前までは荒らし以外は結構いいスレだったが
近頃はC++スレでダベってた暇人たちが引っ越して来ちゃってゴミスレ化しつつあるね >>782
これ、同じメソッドにするのではなくて、イテレータにするのはiter()で共通にして、
参照する場合には、別のメソッドにしたほうがいいんじゃないのかなと思う
例えば
iter() ← 値
iter().ref() ← 参照
とか なんで配列にイテレータないんや！
配列を使うな！ vecを使えということなのか
そういえばC++でもvector使えとか言われてたな
もっと配列にも愛を！
ところでvecより配列の方がうれしいことってある？
実は配列いらない子なんじゃないかと思い始めた >>784
それはiterのシグネチャがメソッドチェーンするかどうかで変わってしまうから
今のRustの型システムでは表現不能だと思う
プログラマ視点でも、後続する関数呼び出しがその手前に影響するってのはかなりわかりにくいのでは？ >>785
スタックとかヒープとかアロケーションとか気にならない用途ならRust使わなくてもいいと思うの >>786
moveをデフォルトにするのは無理だけど
iter()は参照でiter().into()で値ならCow的なのでなんとかなる気がする >>785
> Rust 1.53からは配列型に対して直接IntoIteratorトレイトが実装されるようになり、配列をそのままループに使うことが出来るようになりました。
https://tech-blog.optim.co.jp/entry/2021/06/18/080000 >>787
いやいや、もちろん配列との比較なんだから、アロケーションの発生しない処理の話だよ
スタックを気にするなら、むしろヒープに置いた方がいいし
(キャッシュミスヒットの話じゃなくて、スタックオーバーフローの話ね) >>788
それだとinto_iterとは意味変わっちゃってるのでは
intoで元のコレクションのコピーが作られて、それをイテレートするってことでしょ？
コピーを作らず所有権を奪って値をイテレートする方法がなくなってしまう >>789
おお！ 知らなかった。
ってかめっちゃ最近じゃん！
追いかけるの大変だな >>784
iter().cloned() とか使えば良いのでは hoge.iter()だと参照でhoge.iter().fuga()だとhogeの所有権ぶんどる、みたいなのは無理な気がする >>790
Vecは可変長なので必ずヒープからアロケーションが発生します
一方で配列は必ず固定長でスタックに置かれます
>>784
(&vec0).into_iter()はvec0.iter()となるので
into_iter()だけにすることも出来なくはないと思いますが
書き方が面倒なので簡潔なiter()と共存してるのだと思います >>791
Cow使えばできるという話じゃないよ
lazyに所有権を取得するような機能を持った型を追加すれば
今の型システムでも表現できないってことはないんじゃないかって話
そういう型を追加することを型システムの変更と言うのであれば
今の型システムでは表現できないてのに同意するよ >>795
アロケーションが発生するのは伸長するときだけでしょ
伸長するような用途だったら、そもそも配列使えないし
>一方で配列は必ず固定長でスタックに置かれます
だめじゃん。スタックオーバーフロー考慮するならvecの方がいいじゃん
まあ、自分も組み込み以外でスタックフレームのサイズなんて考慮したことないけど >>795
ちなみにスタックにあることによってL2キャッシュに載りやすいだろ！
という意見ならそれは同意する。サイズが小さければね。 >>797
> アロケーションが発生するのは伸長するときだけでしょ
いいえ。
Vecの実体は必ずヒープにアロケーションされます。
Vec自体は(指定しなければ)スタック上で、ヒープへのポインタや長さなどで構成されて固定長です。
Stringも内部はVec<u8>なので同様です。 >>799
ああ、アロケーションじゃなくてヒープにってところを問題視してる？
ガベージコレクションの発生を懸念してる？ >>800
Rustではガベージコレクションは起きない
しかしスタック上かヒープ上かの区別は重要
スタック上のデータはその関数を終える時に消滅する >>801
>Rustではガベージコレクションは起きない
ヒープを使ってるんだから起きないわけないだろ
＞スタック上のデータはその関数を終える時に消滅する
Vecの中身だって関数を終えるときに解放されるでしょ
されないんだっけ？
そもそもの話は配列を使ってるところをVecにしても問題なくね？ってことなんだけど
どこが問題になるかの例を示してもらえたら、わかりやすい rustにはガベージコレクションがないんだぜ・・・ デストラクタ的な機構で後始末するのはガベージコレクションとは普通言わない Cでもひーぷをつかうとがべーじこれくしょんがおきるの？ ヒープへのメモリアロケーションはコストが高いから避けたいんでしょ >>802
RustにGCはない
Vecの中身(配列相当部分)はスタック上ではなくヒープ上なので関数を終えるときに解放されない
Vec自体が消える時に解放される
Vec自体(ポインタと長さなど)はスタック上にあれば関数を終える時に消える
もちろんVec自体を関数の返り値として返すことは出来る
受け取った上位の関数でVecの中身を使える
例えば
fn main() {
let mut v: Vec<i32> = make_i32_vec_from_args();
v.push(999);
println!("{:?}", v);
}
fn make_i32_vec_from_args() -> Vec<i32> {
let mut v = Vec::new();
std::env::args().skip(1).map(|s| s.parse::<i32>().unwrap()).for_each(|n| v.push(n));
v
}
$ cargo run 111 222 333
[111, 222, 333, 999] >>795
Box<[T; N]> のように配列がヒープに置かれる場合もある >>809
それはBoxだからであって、そんなこと言い出したら整数だってヒープに置かれうる
しかし普通に「整数型はスタックに置かれる」と言われる時は、Boxを使わない場合を意味している
Boxを使えばヒープに置かれるのは自明だからだ
したがって、整数や配列やVecの管理データ部分はそのままだとスタックに置かれるがVecのデータ実体は常にヒープに置かれる、で良い うーん、なんだかなー
みんなヒープのことを無限にバイトを吐き出す魔法の箱かなんかだと思ってない？
>>805
>Cでもひーぷをつかうとがべーじこれくしょんがおきるの？
当然
Cのmalloc/freeやC++のnew/deleteでもガベージコレクションは発生する
wikipediaの「ヒープ領域」がよくまとってるよ
いくつかの理由からfree/deleteのガベージコレクションはJavaやC#のガベージコレクションよりも超高速だ
それでも、組み込みの世界ではガベージコレクションのせいでリアルタイム性が失われることを嫌がって、
ヒープを使わなかったりする
じゃあ、組み込みでは動的なメモリをどうするかっていうと、リンクドリストのノードをメモリブロックに
見立てて、メモリ管理システムにしたりする
これだと取得も解放も定数時間のコストだからね
>>807
すまん、例をみてますます配列なくても困らない気がしてきた
配列でできて、Vecにできないことはないの？ >>811
Rustにはガベージコレクションはありません
おっしゃる通りヒープからの取得も解放も定数時間のコストで行なわれ更にガベージが溜まることはありません
Rustでは生存期間や所有権に貸し借りが明白になっているため、使用中のものが解放されたり、解放済みが使われたり、使用済みが解放されなかったりは起きません >>812
>ヒープからの取得も解放も定数時間のコストで行なわれ
これってどういう原理？ 本当に定数ならそれもうヒープじゃないんじゃ
ヒープツリーを辿る処理も未使用ノードを結合する処理も定数時間って
ありえないと思うんだけど もしかしてmalloc/freeのヒープメモリ管理のことをこの人はガベージコレクションと呼んでいるのかも
そのためRustにガベージコレクションがないことを理解できていないような感じ？ 調べた
・rustのヒープはフリーリストアロケータじゃない
（サイズごとのメモリスラブをさらに分割して使う）
・取得・解放は定数時間じゃない
(メモリスラブ全体が未使用になったときに、デフラグして別サイズのスラブとして利用可能になる)
→これ実質ガベージコレクション処理じゃん
・当然デフラグは発生するが、大して問題にならない
→そうだろうね。C++でさえアロケータ書いたことない
・問題になるならアロケータを自作することも可能(デフォルトはjemalloc)
だそうだ。
ヒープはヒープ構造じゃないのか…… >>814
>もしかしてmalloc/freeのヒープメモリ管理のことをこの人はガベージコレクションと呼んでいるのかも
freeの中にもガベージコレクション処理があるんだよという話
javaと違ってマーク＆スイープ処理いらないから早いけどね
>そのためRustにガベージコレクションがないことを理解できていないような感じ？
そんなことはわかってる
今は処理コストの話をしてる
サイズが変わらないVecと配列(配列なのでもちろん固定長)でそこまで優位の差があるのかと訊いた
そこでVecはヒープを使う(からダメだ)という答えが返ってきたので、
ヒープを使うとなぜダメなんだ？ ガベージコレクションのオーバーヘッドを気にしてるのか？と
そうするとrustはガベージコレクションありませんと言われた
じゃあ、結局のところヒープを使うとなぜダメなんだ？ 勝手に定義した「ガベージコレクション」なんか議論するだけ時間の無駄 >>816
あなたが完全に間違っている
それを世間ではガベージコレクションとは呼ばない >>818
辞書が絶対とは言いたくないがwikipediaの「ヒープ領域」見て 自分でfreeしたものをGCと呼ぶとは強者が現れたな それこそwikipediaの「ガベージコレクション」見てもらった方がいいのでは。 そういやこんな記事があったよ
実装言語を「Go」から「Rust」に変更、ゲーマー向けチャットアプリ「Discord」の課題とは
ttps://atmarkit.itmedia.co.jp/ait/articles/2002/10/news038.html
> 平均すれば高速に動作していたものの、数分ごとに平均応答時間が急に大きくなり、
> ユーザーエクスペリエンスを損なっていた。調査したところ、
> これはGoの中核機能であるメモリモデルとガベージコレクタ（GC）に起因することが分かった。
> Rustではガベージコレクションが不要だ。
> 同社がRead StatesサービスをRustで実装しようと考えたのはこれが理由だ。
> Rustを使えば、Goで実装した場合に生じた平均応答時間の急増は見られないだろう。 >>820
だから、ここではコストの話をしてるんだって言ってんのに
>>821
見た。もちろん知ってる。
本題からずれてる。自動解放とかデフラグの定義の話がしたいんじゃない
配列とVecのことが知りたいんだって
なんだってこう話を逸らすんだ？ >>824
まずはプログラミング言語におけるガベージコレクションとは何かを理解して
次にRustではそのガベージコレクションがないことを理解して
その上で何を質問したいのかを整理してはいかがでしょうか？
それを終えてからでないとあなただけ用語の定義が異なったままでは話が進みません ガベコレは普通javaとかpyのコンパイラやらインタプリタがreference counterをオブジェクトに勝手に付随させる事を想定するけどな
Vec arr処理コストの違いに関してはbuffer使わないんだからarrayの方が基本的には糞みたいに早いと思うがな
そこらosとかによって最適化図られるからオブジェクト生成のとき以外は決定的な違いあんまなさそうだが
要素数をコンパイルタイムに決定(これのアルゴにもよるが)出来るなら普通はシンプル配列の方が速いよね
goはparallel threadingみたいな部分で変なgc実装してて大量に独立の計算量ハード問題導入するからねそこらへんがドイヒーなんだろうな
俺は好きだけど(´・ω・｀) >>824
何度も説明されている通り
配列は固定長なのでデータ管理部分はなく配列は通常スタック上
Vecは可変長なのでデータ管理部分がありそれは通常スタック上そして配列相当部分は常にヒープ上 コンパクションとガベージコレクションの区別がついてない
世の中のガベージコレクターがコンパクションもやってるからといって
コンパクションのみを指してガベージコレクションとは呼ばない >>828
それの何が問題？
stringの実装はヒープだけど問題ないよね？
こういう使い方をすると配列より100倍くらい遅いとか、メモリリークするからVec止めて配列使えとか
そういう注意点ある？
もちろんループの中でVec::newするとオーバーヘッドでかいとか、
そういうわざとらしいのはなしにして
あえていうなら初期化の記述量がちょっと増える、とか？ >>831
誰も何も問題にしていませんよ
あなたが勘違いをして勝手な何かを問題にしているだけ
StringはVecにstructの皮を被せただけなので状況は同じ >>829
HDDの頃はよく使ってたHDD最適化と容量を増やすみたいなソフトを思い出した
HDDのデフラグ → メモリコンパクション
HDDにある不要なキャッシュの削除 → ガベージコレクション
こんな感じに似てるな ヒープがヒープ構造じゃないのかとか言ってるから本当に何も知らなかったのだろう
オレオレ用語使われると混乱するからとりあえずmalloc動画くらいみて勉強してきてほしい >>834
そこ話の本筋じゃないんだよなー
Vecはヒープ使ってるからダメって言われて、何がダメか説明してくれって言ってるだけなんだけどなー >>835
ヒープ使ってるからダメ、なんて誰も言っていない
全ては君の勘違い >>836
そうなの？ じゃあ結論として配列はVecに置き換えても問題ないってこと？ Vecは固定長配列(型[u8; 32]とかで表されるやつ)を置き換える用途としては使えないが, 逆に言えばそれだけ むしろ配列なんてクレート使わないとコンパイル時点で数値が決まってないと使えないから
ほとんど出番がないんだから、どこに悩む必要があるというのか >>835
＞Vecはヒープ使ってるからダメって言われて、何がダメか説明してくれって言ってるだけなんだけどなー
あなたの妄想ではないですか？
スレを読みましたが、
Vecはヒープ使ってるからダメと言われた書き込みが見当たりません。 Linux のデフォルトではスタックの大きさは 8 メガが上限じゃなかったっけ？
(Windows だともっと小さかったはず)
大きさが固定 (コンパイル時に確定する) でかつ十分に小さく寿命が短いなら配列をスタックにおく
のは性能的に有利 (確保と解放のコストが小さい) だが、大きさを見積もれないときにスタックに置くと
スタックが足りないときにどうにもできないで即死するしかない。
大きさのわからない配列はスタックに置くべきではないというのが世の常識というもの。
少なくとも高レイヤのアプリケーションでは。 仮想メモリなんだからスタック8GBに設定すればいいんじゃないの？ Rustのメモリ安全性はボローチェッカーによって担保されているが、
Nimと比較してRustはタイプ量が多い事により限りなく低い生産性と
C++のような高い難読性、超巨大なバイナリ生成性能を兼ね備えています
Nimはバージョン1.5.1でRustのボローチェッカーに似た「View types」が実装されれば、
GC無しでView types参照の有効性を検証することによってメモリ安全性を保証しつつ
限りなく抑え込まれたタイプ量で高速化したCのソースコードを吐き出せます
Nimソースコード ==nimコンパイラ==> Cソースコード ==Cコンパイラ==> バイナリ
なので、nimコンパイラが通った時点でメモリ安全性が担保されませんか？
Nimの実験的特徴
著者： アンドレアス・ルンプ
バージョン： 1.5.1
http://nim-lang.github.io/Nim/manual_experimental.html
Nimは限りなく抑え込まれたタイプ量で高い生産性とPythonのような高い可読性を実現し
ているにもかかわらず、Cのソースコードを吐き出せるのでC言語でリモートワークされ
ている方は割り振られた仕事が早く終わっても終わってないふりをして怠けることができる
「怠け者とはこうあるべきだ！」と言うとても大事な事を Nim は我々に教えてくれます pythonが特別読みやすいとは思わんが、pythonで読みづらいコード書くやつが
何で実装しても読みやすいものを書くことはないだろう。 >>844
Pythonはたまたま外部ライブラリ充実などで普及していますが、あまりよろしくない言語です。
そのためPythonで開発したいという人はいないです。
なので「Pythonのような高い可読性を実現している」と宣伝されても逆効果。 >>844の人は関係ないスレに迷惑かけて、nimユーザーのイメージダウンが目的なんだろうか。 積極的にPython使おうとは思わんなぁ。インタプリタ系はRuby使っているわ
Luaも結構良い感じだと思う うん。 プログラマは Python をそんなに気に入ってない場合は多いと思う。
ただ現代ではプログラミングするのはプログラマとは限らない。
Python は元々はコンポーネントを組み合わせる、いわゆるグルー言語として設計されていて、
エンドユーザ向けの性質を持っている。 BASIC 系と似た立場かな。
このくらいに制限されていたほうがかえって使いやすいという場合は確かにある。
必要なコンポーネントが出そろっている状況で上位のロジックを組み立てる分には
Python も便利なこともあるにせよ、言語としての出来はそんなに良くない。 >>845
>Nimは知らんがパイソンが読みやすいなんて
Pythonは構文にインデントを組み込むことによってざっと眺めた時に人間が読みやすい
一般的には上記の事をPythonは高い可読性があると表現されています
この事は「Pythonは可読性の高い言語」ググれば約 265,000 件出てきます
他の言語と可読性は同じだろって意見の人もいますが少数派ですね 元の文脈的に
nimも構文にインデントを組み込んでるからpythonが出てきただけでそういう議論がしたいんじゃないと思う >>852
>「javascriptは可読性の高い言語」で検索すると約 334,000 件
単に検索件数が多いだけで、上位10件の表示内容を読んでも
「javascriptは可読性の高い言語」と言う内容のページは1つも見つかりません
対して「Pythonは可読性の高い言語」は上位10件の内5件見つかりました ただのコピペ荒らし
まったくRustもNimも関係ないスレでも見るし Rust Tourだけやっていても作業の流れが身につかなさそうなので、写経を始めました
そこでまず出くわしたのがTokioのバージョンの壁で、バージョンによって動いたり動かなかったり差がありました
クレートの無難なバージョンがどれか、クレート同士の無難な食い合わせはどれか、など、どうやって知れば良いのですか？ 写経なら写し元と同じバージョンにそろえるのがよいのでは >>859
>写経なら写し元と同じバージョンにそろえるのがよいのでは
Nimのバージョン 1.5.1を写経しましょう
Nimの実験的特徴
著者： アンドレアス・ルンプ
バージョン： 1.5.1
http://nim-lang.github.io/Nim/manual_experimental.html 組み込み系ではMicroPythonが流行っているらしいが全く魅力を感じないｗ Nimを調べてみたのだが
Rustよりも高機能な点を見つけられなかった
もし有るならば書いてください
無ければ去ってください >>862
>Nimを調べてみたのだがRustよりも高機能な点を見つけられなかった
>もし有るならば書いてください
>無ければ去ってください
そんな寂しい事言わないでかまってよ～(´;︵;`)
行末のセミコロンが必要ない
タイプ数がもりもり減ります。
Rust にはもちろん必要です。
main が要らない
スクリプト言語感覚でいきなりコードを書けます。
Rust は main が必要です。
>Nimキチガイ
いつもみんなによく言われます
いや～照れますね～ｖ（=＾0＾=）ｖ >>863
あなたは知恵遅れか何か？
Rustより高機能な点を問われているのに、セミコロンが必要ないとかどうでもいい話しかできないの？
答えられないならここから出ていきなさい。 >>863
>nimのスレ立ててそっちでやってよ
そんな寂しい事言わないでかまってよ～(´;︵;`)
Nim は標準出力への文字列出力が楽
Nim では echo で改行付きの出力ができます。shell と同じですね。通常は改行付きで出力することの方が多いでしょ。
Nim はしょっちゅうやることは簡単にできるようになっています。
そんな Nim の echo は可変引数で値を受け取り型が何なんだろうとお構いなしに出力できます。
let n = 10
let str = "HOGE"
echo "Number: ", n, " String: ", str
一方 Rust は
let n = 10;
let str = "HOGE";
println!("Number: {} String: {}", n, str);
なんかよく判らんマクロでいちいちびっくりさせなきゃいけないです。よく使うものが冗長だとゲンナリします。
変数を直接ぶち込むことも出来ませんしね。
let n = 10
echo n
普通出来るでしょこんなもん・・・。ところが Rust は出来ない。
let n = 10;
println!(n); <- エラー
println!("{}", n); <- 毎度これを書かされる
うざいっす。 >>865
そんな寂しい事言わないでかまってよ～(´;︵;`)
NimはC の関数を気軽に持ってくる
たった一行足すだけで C の関数を使うことが出来るようになります。
proc printf*(format: cstring) {.header: "<stdio.h>", importc: "printf", varargs.}
let n = 10
let str = "HOGE"
printf "Number: %d String: %s\n", n, str
どうですこれ？C の資産を気軽に使うことができるんです。SWIG 等の鬱陶しいラッパーを使うこと無くです。
Rust の場合はご多分にもれずラッパー行きで超絶面倒くさいです。比較用に書きたいんですが結構な文章量になるのでやめます。 >>866
そんな寂しい事言わないでかまってよ～(´;︵;`)
Nimはmut mut しなくて良い
Rust はまともな変数を使おうとすると mut mut しないといけません。デフォルトだと再代入できませんから。
普通再代入しまくりますよね？定数ライクに使いたい機会なんて殆どないですよね？なのに mut を毎度書かされます。
let n:int = 10
let mut m: int = 10
Nim ならこうですよ。
let n = 10 # immutable
var m = 10 # mutable
素敵。 >>862
Nim所有者・借用なんてもんでイライラしない
Rust には C のポインタが可愛く見えるレベルで高くそびえ立つ鉄壁の初心者ガード、悪夢の"所有者・借用"の概念が存在します。
プログラムに慣れた人間ですら混乱に陥れ、書いている最中に精神力と人生の貴重な時間をガンガン削ってくれる究極の嫌がらせです。
Rust は変数のコピーしちゃうと元のやつが使えなくなるクソ仕様なのです。書き手にメリットなんて一切無い。C++の悪しきメモリ管理の呪いを持ち込んで来てその中でもさらに悪い部分をデフォルトにした感じです。
struct Point {
x: i32,
y: i32,
}
fn Print(p: Point) {
println!("x = {}, y = {}", p.x, p.y);
}
fn main() {
let mut a: Point = Point{ x: 10, y: 15 };
Print(a);
// エラー！
println!("x = {}, y = {}", a.x, a.y);
}
Print(a) で1回コピーされているのでその後使うと死にます。ウソでしょ？と思うでしょ？ホントです。
そしてプリミティブ型ならOKと言う Java に似たダブスタの呪いもオマケで付いてます。
おかげさまで関数はほぼ全て明示的に参照渡しをするハメになります。
「だったらデフォルトそうしとけよ！ & をイチイチ書かせんなやワレ！」と思わないのってある種の才能だと思います >>862
struct Point {
x: i32,
y: i32,
}
fn Print(p: &Point) {
println!("x = {}, y = {}", p.x, p.y);
}
fn main() {
let mut a: Point = Point{ x: 10, y: 15 };
Print(&a);
println!("x = {}, y = {}", a.x, a.y);
}
これだとまぁエラーにはなりません。が、参照だからといってこんなことやったら死にます。
fn Print(p: &Point) {
println!("x = {}, y = {}", p.x, p.y);
p.x = 10; <- die
}
イミュータブルだからですって。はぁ・・・。 >>862
だからこう書けですって。
fn Print(p: &mut Point) {
println!("x = {}, y = {}", p.x, p.y);
p.x = 100;
}
fn main() {
let mut a: Point = Point{ x: 10, y: 15 };
Print(&mut a);
println!("x = {}, y = {}", a.x, a.y);
}
はい来た。mut mut mut mut mut mut mut mut mut ああぁぁああぁ～～～！！！
なんでよく使う方を面倒臭くしたがるんですか、この言語を作っている方々は。
その他又貸しの呪いやらなにやら超盛り沢山ですし。もうね私とはセンスが全く合わないです。
ぬぅぅうぅうぉぉおぉおぁぁあぁあああ！！！！！Rustよ！もうお前には頼まん！malloc と free を俺によこせうぉるぅぁあ！！こんな訳のわからんものに付き合わされるんだったら自分でメモリ管理した方がマシだわ！！！
とよくみんな発狂しませんよね。我慢強いですね。馬鹿じゃないの。
とっても良い子である Nim にはこんな呪いある"ワケ"がないです。 >>862
type Point = object
x: int
y: int
proc print(this: Point) =
echo "x = ", this.x, ", y = ", this.y
var p = Point(x: 10, y: 15)
p.print()
echo "x = ", p.x, ", y = ", p.y
まぁ普通はこうですよね・・・。Rust がぶっ飛んで異常なだけです。ありえないです。
ちなみに Nim の場合 print(p) と p.print() は書き方が違うだけで意味は同じです。 >>862
参照で渡す場合はこうなります。
type Point = object
x: int
y: int
proc print(this: ref Point) =
echo "x = ", this.x, ", y = ", this.y
this.x = 100
var p = Point.new
p.x = 10
p.y = 15
p.print()
echo "x = ", p.x, ", y = ", p.y
new で Point object を作成すると参照のオブジェクトが出来ます。これを渡すために print 側の引数には ref をつけてあげます。new 関数でメンバに値を割り当てることは出来ないので後から渡してやります。
つっても上のやつはあくまで Rust と似せて書いたらこうなるよって話でこんな書き方しません。 >>862
普通オブジェクトなんて参照だろ、って事で Nim では以下のように書くのが慣例化しています。
type
Point = ref PointObj
PointObj = object
x: int
y: int
proc print(this: Point) =
echo "x = ", this.x, ", y = ", this.y
this.x = 100
var p = Point(x: 10, y: 15)
p.print()
echo "x = ", p.x, ", y = ", p.y
オブジェクトとそのリファレンスを同時に定義して、通常使わない方のオブジェクト側にサフィックスをつけておくと、まぁ素のオブジェクトも作りたきゃ作れるし、って話です。
自分は正直リファレンスだけで良いので更に手を抜いてこう書きますけどね。
type
Point = ref object
x: int
y: int >>862
パターンマッチ？case でしょ？
Nim も case でそれっぽく書けます。
複式パターン
fn main() {
let x = 1;
match x {
1 | 2 => println!("1 | 2"),
3 => println!("3"),
_ => println!("other"),
}
}
let x = 1
case x
of 1, 2: echo "1 | 2"
of 3: echo "3"
else: echo "other" >>862
範囲
fn main() {
let x = 1;
match x {
1...5 => println!("1...5"),
_ => println!("other"),
};
}
let x = 1
case x
of 1..5: echo "1..5"
else: echo "other" >>862
case の返りを受け取る
fn main() {
let x = 1;
let s = match x {
1 => "one",
2 => "two",
_ => "other",
};
println!("{}", s)
}
let x = 1
let s = case x
of 1: "one"
of 2: "two"
else: "other"
echo s >>862
仕様バグがない
Rust の以下の挙動は全く理解ができません。
fn main() {
let x = 'x';
let c = 'c';
match c {
// x: c c: c
x => println!("x: {} c: {}", x, c),
}
// x: x
println!("x: {}", x)
}
普通 x にマッチすると思わないでしょこれ。
さらにその直後 x が 'c' に変わってるとか予想だにしませんよ。
まぁ普通はこんな書き方しないと思いますがこんな調子ではどこでどうハマるか予測不可能です恐ろしすぎます。
Nim はこんな書き方そもそも出来ません。 >>862
コンパイラがケチくさくない
nim c -r hoge
これで hoge.nim をコンパイルします。
拡張子なんて指定する必要ありません。
-r で実行もします。
Rust の場合
rustc hoge <- ダメ
コンパイルと同時に実行しようと思ったら
rustc hoge.rs && ./hoge
うーん・・・ >>862
実行速度・メモリ使用量・ファイルサイズが小さい
Rust と比べて Nim の実効速度はどっこいかむしろ速いです。
Rust はこんだけイライラする書き方を強制されるにも関わらずたいして速くないとかもう哀れすぎます。
コンパイル後のファイルサイズは話にならないレベルで比べ物になりません。
fizzbuzz の例(FizzBuzz を無駄にベンチマークしてみた By Nim、golang、Rust、Crystal、その他 - 強まっていこう)で言うと
項目 Nim Rust
実行速度 0.37s 0.44s
ファイルサイズ 82K 3.4M
メモリ 356K 900K
こんな感じです。 >>883
>無知がやるとそうなるわな
バカ丸出し
Nimは標準実装されたnimコンパイラが強力なマクロで
最適化されたCのソースコードを吐き出して、Cコンパイラ
で極小バイナリまで生成するから、コンパイルするだけで
後はプログラマがする仕事が無いので怠けててもいい
Rustは標準実装されたコンパイラでコンパイルするだけでは
超巨大なバイナリを生成するので、最適化せれたチューニング
を施して小さなバイナリを生成しなければならないから
プログラマの仕事が増えて怠けられない >>880
それはブロックスコープといって多くの言語が備えておりプログラミングの基礎です
まさかNimには存在しないのですか？ >>862
マクロのシンタックスを別で覚える必要がない
Rust のマクロは構文が全く変わってしまいます。
そしてそれは脳が全力で受付を拒否する素敵な仕上がりとなっております。
公式で自ら「マクロベースのコードの欠点は、組み込みルールの少なさに
由来するそのコードの理解のしづらさです。」と言いのけちゃう代物で
「なんじゃそりゃ」と言う言葉しか出ません。
Nim は構文がそのまま使えます。なので強力なマクロを使いこなすための
障壁の低さは比べ物になりません。 実際rustって色々リンクするから、最小バイナリでかいよな
でも、それで困ったことってあるか？
俺はない >>891
それはリンクする状況にするからであってRustのせいではない
例えばRustを使って組み込みやWASM等でもバイナリでかいと思ってないよね Rustは他に比べれば最小のバイナリでしょ、コンパイラ/リンカーが長い年数を掛けて最適化されたCより大きいが。
一番不満なのが公式はビルドが速いというがそんなに早くない事だけ。それ以外は従来のC/C++（C++17/20/23
なんかを除く)より圧倒的に安全だし、明示的であるからこそタイプ量が多い。
Nimに比べて大きいというのはRustのコンパイラがまだCを吐き出してた頃から最適化されていないから、Nimと
いうかGCCやClangに比べ、ほんの少し大きくなる。リンクするものが大きければバイナリが大きくなるのは
当然でGoなんかはまさにそれでしょ、goroutineを共有ライブラリに押し込めることは出来ないから >>892
まあ、ユーザコード自体のサイズがでかいわけじゃないのは同意 もう１つ不満がある事は、Rustならメモリーリークしないと言う奴がいる事、公式も明言してる通り
グローバルの循環参照を作成してしまえば簡単にリークするのに、意識高い系のコード書かないやつが
メモリーリークしないんだと他の言語も触ったことの無い初心者に力説する事。盛大にリークしてて
正常に動いてるプログラムを直すのは大変・・・
ま、これは言語のせいじゃないけどね、他は凄い良く出来てる、Linuxカーネルに採用されるような
他の言語（第３の言語）は当分出てこないだろうと思うほど Rustのメモリ安全性は、メモリリークしない、ではないからな。 >>895
Rustは弱参照があるから強参照の循環参照を作らずに済みます
よってまとまなプログラミングをしていればメモリーリークは起きません >>895
javaでも同じことを言う奴がいる
「GCが頻発する。GC壊れてる」
壊れてるのはお前のコードだ >>867
構ってあげるから別スレ建ててください
C へのトランスレータであることは魅力的ですよね >>895は分かってる人だろう
ちゃんと読んでるか？ ビット全探索する関数作ったヽ(´ー｀)ノ
fn bit_search<T: Copy>(vec: &Vec<T>) -> Vec<Vec<T>> {
let mut tmp_vec: Vec<Vec<T>> = Vec::new();
for i in 0..(1 << vec.len()) {
let mut slist = (0..vec.len())
.filter(|it| i & (1 << it) != 0)
.map(|it| vec[it]).collect();
tmp_vec.push(slist);
}
return tmp_vec;
}
使い方
let vec0 = bit_search(&(0..5).collect());
など >>862
Rust の良いところ
さすがに Rust を批判ばかりしていては公平性に欠ける報道となり官邸から怒られます。
Rust にも良いところはあります。
fn <- 短い！
proc <- 長い！
これはメリットですよ。タイプが2回ずつ減るのは素敵なことです。
しっかしこれだけ馬鹿げた冗長さを押し付けてくる言語のくせして、
何故ここだけすっきりしているのやらさっぱり意味がわからないです。
あ、結局ディスってもうた・・・。 >>902
どうでもいいだろ
それが0文字の言語も8文字の言語も併用しているが長さで困ったことはない
タイプ数を気にするのは愚か者だけだ この仕組みを教えて下さい
もしかして2bit＋1byte＝2bytesってこと？
> > Option<Option<T>> has layout [0..1][0..1]<u8> , i.e., be of size 3
>
> False. Thanks to @eddyb’s work, the compiler will collapse the discriminant of the first option into the second. Thus, mem::size_of::<Option<Option<u8>>>() == 2. >>895
他の言語に比べれば循環参照を作るハードルはかなり高いでしょ
現実的な用途でborrow checkerに引っかからないような循環参照を作って
リーク以外は機能的に問題ないコードを書くのは初心者には難しいと思う >>904
the compiler will collapse the discriminant of the first option into the second.
って言ってるから
Option<Option<u8>>はOption<u8>に変換されるってことじゃない？ >>554-555
あたりが物になるのはいつかなぁ
組み込みだとLLVM縛りは結構きつい >>904
Optionで9回包んでもsizeは2のままだったのでそういうわけではなさそう
None, Some(_), Some(Some(_)) の3バリアントがあるのと同じようなレイアウトになる模様
↓はOption<Option<Option<u8>>>の例
https://play.rust-lang.org/?version=stable&;mode=debug&edition=2018&gist=31c195fa7390041e3a2d7ce9ff1417f2 909のコードを借りて確かめてみたら
<Option<Option<Option<u8>>>>(&Some(Some(None)));
と<Option<u8>>(&Some(None))が
<Option<Option<Option<u8>>>>(&Some(Some(Some(0))));
と<Option<u8>>(&Some(0))が同じ結果になったよ
1byte目が00の場合None、00以外の場合Some
<Option<Option<Option<u8>>>>(&Some(None))みたいに
OptionとSomeのレイヤの数が違うと1byte目の結果が違うみたい
1byte目でどのレイヤのSome/Noneか区別してるのかな [0..=3]<u8>になってるね
nightlyで#[rustc_layout(…)]を使うと確認できる
#![feature(rustc_attrs)]
#[rustc_layout(abi, size, debug)]
type Foo = Option<Option<Option<u8>>>; Itertoolsが便利すぎて今までの自分が可愛そうすぎる(´･ω･`) >>862
技術書典に出会っていなかったら俺はNimをさわってないと思う
背景
俺たち「そろそろ技術書典に参戦するか」
俺たち「何書く？」
俺たち「マイナー言語を触ってみよう。言語選択は早い者勝ちね」
ワイ「(マイナーの定義はさておき)Nimでオナシャス」
ワイ「(アドカレあるし、記事まとめておくかぁ...)」
Nimとは？
Nim は アンドレアス・ランプフ氏によって設計・開発された命令型、マルチパラダイム、
コンパイル言語という特徴を持つプログラミング言語です。
アンドレアス・ランプフ氏は3DICC社に所属するエンジニアです。彼はNim開発以前に様々
な言語を触っていたようです。が、どの言語も満足せず、自身で作成することにしたようです。
それがNimプロジェクトの始まりで、2005年頃のようでした。
当初NiｍはNimrod(旧約聖書の登場人物)という名前でしたが、マーケティング上の理由から
2014年12月29日にリリースされたバージョン 0.10.2 からNimに変更されました。 こんだけ型がっちがちに固められた言語触っちゃったら他の言語に戻れない
PythonとかPythonとか 実行時にバグるよりコンパイルエラーでコンパイル出来ない方が遥かに優れていると思ってるけど, そう思わないと型が辛くなるだろうなぁ JavaScriptで組んでたときに、文字の数字を数値型に変換したくて、
"10" + 0
みたいにしてたことを思い出した >>919
JSようしらんけどこれって"100"にならないんだ？ >>862
Nimの特徴
直感的でわかりやすいシンタックス
公式サイトの記載からNimの特徴を見てみましょう。
以下は公式サイトに掲載されているNimのコード例です。
Nimの最初の特徴して挙げられているのが、そのシンタックスで、曰く「直感的でわかりやすい」とのことです。
Python(のインデントを含めた多くの特徴)やPascalを参考にしているらしいので似ていると思いますが、シンプルですね。
import strformat
type
Person = object
name*: string # Field is exported using `*`.
age: Natural # Natural type ensures the age is positive.
var people = [
Person(name: "John", age: 45),
Person(name: "Kate", age: 30)
]
for person in people:
# Type-safe string interpolation.
echo(fmt"{person.name} is {person.age} years old") >>862
Nimの特徴
直感的でわかりやすいシンタックス
公式サイトの記載からNimの特徴を見てみましょう。
以下は公式サイトに掲載されているNimのコード例です。
Nimの最初の特徴して挙げられているのが、そのシンタックスで、曰く「直感的でわかりやすい」とのことです。
Python(のインデントを含めた多くの特徴)やPascalを参考にしているらしいので似ていると思いますが、シンプルですね。
import strformat
type
Person = object
name*: string # Field is exported using `*`.
age: Natural # Natural type ensures the age is positive.
var people = [
Person(name: "John", age: 45),
Person(name: "Kate", age: 30)
]
for person in people:
# Type-safe string interpolation.
echo(fmt"{person.name} is {person.age} years old") RustにはGCないから云々言われるけどメモリ以外のリソースもRAIIとムーブセマンティクスの力でいい感じに扱えるのは良いよね
他の言語だと with 式などでスコープ抜けたら解放は出来るけど
クロージャにキャプチャされる場合など長時間生き残るようなケースをちゃんと扱えたりするのだろうか >>898
JavaはグローバルのGCがあるから意味が違うよ。リークしているように見えるがプログラムが正常に
終了をすればGCが起こる（だからJavaは停止時にフリーズしたようになるプログラムが多数）
>>905
ハードルは高くないよ。循環参照をWeak<T>でなくRc<T>で書いてしまえば普通にリークする
リファレンスカウントになっているのだから当たり前だけどね
https://doc.rust-jp.rs/book-ja/ch15-06-reference-cycles.html GC言語にも弱参照はあるのでまともなプログラマーならば強循環参照は作らない
RustはGCが無しでメモリ安全性を保証できる言語であるとともにメモリリークも避けることができる言語 >>928
GCは方式の異なる段階があって
弱参照を使う循環参照なら強参照カウンタだけで回収できる
強参照のみの循環参照までも回収する方式は様々あるけどいずれも重い
だからGC言語にも弱参照があって賢い配慮あるプログラマーが使えるようになっている >>926
その日本語訳に書いてる通り
「循環参照は簡単にできることではありませんが、不可能というわけでもありません。 Rc<T>値を含むRefCell<T>値があるなどの内部可変性と参照カウントのある型がネストして組み合わさっていたら、 循環していないことを保証しなければなりません;」
RefCell<Rc<T>>を使いこなせるのに循環参照で盛大にリークさせる人も
Rc<T>をWeak<T>に直すのが大変っていう人も
かなりの激レアさんだと思う(個人の感想) >>929
誤り
GC言語の弱参照は強循環参照対策ではなく、キャッシュなどで長寿命のオブジェクトがGCを妨げることを避ける目的で使用される
だから例えば、ウインドウはボタンを管理しボタンは自身がクリックされたことをウインドウに通知する、ただしボタンが動的に追加削除されることはない、
といったような互いに寿命が一致する循環参照が生じるケースでは弱参照は普通使用しない
マークアンドスイープは十分に高速なので、参照カウンタをGCと併用するのはあまり一般的ではない ネストしたstructの奥深いところにひっそりRcが隠れてたら
知らない間に循環参照になってることもあるかもしれない 念のため補足しておくが、寿命が一致しない循環参照の場合は弱参照を使わなければならないというわけではない
ウインドウとボタンの例でいうと、普通に考えてボタンが動的に削除されようとしていることをウインドウが知らないわけないから、そのタイミングでウインドウが持つボタンへの参照を削除すればいいだけだ
GC言語で弱参照が必要とされるのは極めて特殊なケースに限られており、ほとんど使用されることはない >>933
特殊なケースではないと思う
GC言語でも何らかのツリー構造をあつかうことはよくあって
その時に親から子へは普通に強参照でも子から親へは弱参照の方が有利だよね
弱参照を使っていれば一部のサブツリーを捨てた時に循環参照ではなくなる
これはGC言語だけではなくRustでも同様で、サブツリーを捨てたらそのトップへの強参照が消えて連鎖的にサブツリーが回収されますよね？ >>934
別に有利じゃないから普通にどっちも強参照使うのが普通だよ
マークアンドスイープは循環参照で遅くなったりしないから >>935
マークアンドスイープ方式のみでGCする言語ばかりではない
GCは奥が深い
弱参照の使用はそこで有利 ちなみにGC言語は常に強参照を使うことを前提に最適化されているので、必要もないのに弱参照を多用すると確実に遅くなるよ
Javaだと弱参照それ自体がヒープアロケーションされるオブジェクトだったりするので、とんでもなく非効率だ >>937
Rustでは弱参照を使うデメリットありますか？ >>938
生存期間を意識した非対称なコーディングをしなければならないこと、だね
親子関係の循環参照でどちらを弱参照にすべきかはケースバイケースであり、>>934が思っているほど単純な話ではない
別にRustを批判してるわけじゃないが、GC言語から見ればそれ自体がデメリットなんだよ これまでRust書いている時にトレーシングGCが欲しくなったことはありますか？
それはどのようなプログラムを書いている時ですか？ >>934
その通り。
ツリーでなくてもある地点から一方向のみの有向グラフになるような強参照の時
そのある地点が解放されれば残りも解放される PythonやSwiftの自動参照カウント方式はGCとは呼ばない派がいるんだね
Rustの場合は弱参照を使うかどうかに関わらず
生存期間を常に意識してコーディングする必要がある
どちらを弱参照にすべきかは所有権を考えれば明白 C++ スレでスマートポインタが GC かどうかという話題が出たことあるわ。
そこで現れた GC の定義としては大まかに
① 十分に信頼してメモリ管理をまかせることが出来る能力がある
② メモリ管理を意識することなく利用できる
のいずれか (または両方) が上げられていて、
その上で信頼性の程度、意識するというのがどの程度のことを言うのかで
様々な線引きがある感じだった。
たとえば①については参照カウンタだと循環を解決できないが、
それはエッジケースでしかなくてたいした問題じゃないと考えるか
そうでないかは人によるが、いずれにしてもまかせるに足る能力で
考えるという考え方。
②についてはメモリ管理を自動化する能力ではなく見せ方の問題だとする派閥。
スマートポインタは管理方法も管理内容も決まっていて
プログラマがそれを利用するという明示が含まれるので GC ではないという考え方もあるし、
管理の開始こそ明示的な宣言ではあるものの
直接的な管理は隠されているので GC だという主張もある。
どちらに線を引くかは異論があるにせよ、プログラマの側からどう「見えるか」という
抽象度の問題とする考え方。 >>943
違うよ
GCの定義は明白で
「ガベージが生じて溜まっていってそれらをまとめてコレクションすること」
だからRustで例えばノードツリーのトップが何らか任意の方法でドロップとなった時
連鎖的にツリー全体が次々とRcの強参照カウント0となりツリー全体が解放されるのはGCではない
即座に消えてガベージは溜まって行ってないため >>944
明白か？
そんな定義は無いと思うが。
GCの起源はLISP由来だと思うけど、その時の実装は参照カウントでは？ あ、すまん。LISPはマークアンドスイープで、その後に参照カウントが発明されてるわ。 >>945
参照カウント方式か否かは焦点ではなくて、ゴミがたまっていってまとめて処理することをgarbage collectionと呼ぶ。
RustのRc利用はゴミがたまっていかないのでGCと呼ばれていない。 >>944
「溜まっていってそれらをまとめて」というのは間違いだな。
wikipediaの記載にある
「不要になった（メモリ）領域を自動的に解放する機能」
というのが正しい。
ポイントは「不要と判断」して「解放」というところ。溜まる必要もまとめて解放する必要も無い。 個人的には GC であるかそうでないかという議論はそれほど意味が感じられない。
GC という切り口からメモリ管理を見ることが出来るという切り口だと考えてる。
極論すれば C の自動変数も「スコープを抜けたら不要 (ということにする) と判断」して「解放」してるので
GC の一種と言えば一種とも見れるし、しかし参照 (ポインタ) が残ってるかもしれないし
それを経由してアクセスしたらワヤになるので (GC としては) 出来が良くねぇなぁってだけのこと。 >>948
Garbage Collectionなのだからゴミ集め
ゴミが溜まったら拾い集めること
RustのRc利用だとゴミは溜まらないので「RustにはGCはない」と世間でも言われている通り 即時解放はGCじゃないと思うわ
スマポも即時解放なのでGCじゃない派 逆に言うと解放のタイミングが基本的に制御できない、つまりIDisposableみたいなのが必要になるならGCという認識 ほとんどの場合に参照が 0 になるより前にゴミになっているが
ゴミであることがわかるのがカウントが 0 になったときなんだ。
カウントが 0 になったときをゴミになったときだと定義づけるのは因果が逆転している。 >>953
参照0より前にゴミになった状態を把握する一貫した方法を示せれば貴方が勝てる可能性がある。
示せなければあなたの負け。 >>955
小学生かｗｗｗ 勝負してるわけじゃないだろ。
俺は GC とそうでないものを分ける意味があまりないという立場だ。
「即時」とそうでないものが GC かどうかを分ける境界だという主張に対して
実際には即時に近いものもあればそうでないものも中間もあってそのどこに
線を引けるのかは自明ではなく程度問題だと考えている。 >>948 その基準だとCの自動変数解放もGCになるね。 >>957
さすがにスタックフレームの移動は含まないんじゃないか >>959
関数を終える時点でゴミとなるので解放
だからRcと同じ即時解放タイプとなる
私は即時解放するならばGCでないと考える
だからRcやスタック変数はGCではない
つまりRustにはGCはないとの定説通り >>957
システムが不要と判断して開放しているならそうだが、実際には違う。
まだ必要（ポインタとかで参照されている）としている領域でもスコープから抜ければ削除されるから、「不要になった領域を削除する機能」とは言えない。 >>947
まとめて処理しなくてもcollectionだろ。
お前がフィギュアを集めてるとして、欲しいものを溜めて一気に買ってるのか？
定期的に収拾する事自体がcollectionじゃん。 まとめて処理しないとGCではないというのなら
GCのパラメーター変更して毎命令処理の度にGCが走るようにしたらGCではなくなるということ？ 与太話はさておきただ単にGCと言うだけでは伝わりにくいから
トレーシングGCとかリファレンスカウント(GC)とか言った方がよいのでは >>964
そこは論点ではない
リファレンスカウントでも即時解放していればGCではない
ガベージが貯まってから解放処理をしていればGC 所有権を設定して、ブロックスコープを抜けた所有権のある変数はすべて開放とかよく考えたよね リファレンスカウントは、c++のスマートポインタみたいな循環参照でリークするのと、pythonみたいに循環参照してるゴミを後から回収するのがあるから、後者はリファレンスカウント(GC)と呼ぶべきということでしょ？
前者はGCではない 全く関係ない話するけど、
Rustは、可変参照型の変数を右辺に書いて、moveのソース側にすることは
可能？
それとも、moveのソース側は、普通の所有権がある可変変数でないとダメ？ >>968
moveのソース側って？
ownedの引数にmutable borrowは渡せない
fn foo(mut i: i32){…}
let x = 42;
foo(&mut x); // error >>969
let x = 構造体名{初期化メンバの列};
let y = x;
と書いた場合、x の内容がy に moveされるけど、
let mut x = 構造体名{初期化メンバの列};
let z = &mut x;
let y = *z;
とすることは可能？ >>970
なるほどそういうことか
構造体がCopyなら可、Copyじゃなければ不可 GCという言葉がそこまで細かく使わなきゃいけない言葉になってることに意味がない気がする >>971
Copyって、Cloneじゃなくて POD 的な場合に単純コピーされるというやつの事？ >>973
便乗質問
ムーブで関数に渡してもコピーできない型はcall by valueではなくポインタが渡るのですか？ >>973
Copy はトレイトだがそれ自体はただのマーカーでしかなく特に実装しなければならないメソッドはない。
Copy が実装された型はムーブの文脈でコピーになる (所有権を奪わない)。
https://doc.rust-lang.org/std/marker/trait.Copy.html
clone を (必要な文脈では) 自動で呼ぶってだけ。
複製の仕方は Clone の実装のほうに従う。 >>974
ムーブの実態はビット単位のコピー。
ムーブ元は「今後絶対に使われない」という静的な強力な保証があるから
有効なオブジェクトはひとつだけなんだ。
ビットパターンの複製は作られるよ。
コピー (クローン) という用語は Rust 的にはあくまでも静的な所有権管理と紐付いていて
機械語レベルでデータが複製されるかどうかとは関係がない。 >>930
お互い個人の感想なので強くは言いませんが、公式に上がっている例を見ていただければ、たった数十行で
リーク構造を作れることは分かってもらえると思います。
あなたが言う通りにRc<T>の特性を知って使いこなしているのであれば別ですが、初心者が全て知っている事は
稀、レアというよりあり得ません。またRc<T>をWeak<T>に直すのが大変という話ではありませんよ。
データ構造上のリング構造や、ツリー上に出来てしまった循環参照を前提に（リークはするが）動いている依存
コードが多量にあるプログラムを影響を与えないように直すのが難しいという話です。これはRustではなくても
他の循環参照を明示的に破棄しないプログラムを書いてしまえば同じ事ですが。
Rustは大変に高パフォーマンスで、明示的な制御が効きますが>>895で言っているのは技術レベルが違う二者で
苦労する人が一定数発生する事でしょう。言語とはほぼ何の関係ありませんが まあ将来的にはコンパイラーがより賢く・早くなれば循環参照で増え続けるリークに対してコンパイルエラーにも
出来ると思うので、今は未だ、リークする可能性があろうとRustが良い言語だという認識は変わらない。
他の言語でも当然リークチェックは出来るが、GCを前提とするならコンパイルエラーが出ても、なぜエラーなのか
理解しずらいかもしれない。 行数の問題ではなく、Rcを使って独自のデータ構造を作るスキルがあるのに循環参照だけ知らない初心者、というのはレアということでは
まぁそれはそれとして直すのが難しいケースがあるのは同意 ・Rustで循環参照が起きるにはRc利用が必須
・Rc利用者は循環参照の存在もそれを避けるWeakの存在も知っている
・したがってRustでメモリリークを生じさせる者はレアケース
・Weak(弱参照)を適切に上手く用いて循環参照を避けるのが大変な場合もあるが全ての言語で共通の問題でありRustの問題点ではない >>971
なるほど。Rustのオブジェクト型であるところの struct はデフォルトでは
Copy trait は実装されないので、>>970 の後半のように借用を介して
moveのsource側にすることは禁止されているということなのね。 rustってどうやって二重開放のリスク防いでるの？全然ピンとこない ownershipが１つしかない状態を維持しつつownershipが0になったら（確実に）解放する感じ
ownershipはどこかの変数が直接的or間接的に保有してて
同じリソースに複数のownershipが発生しないように
代入とか関数の受け渡しでmoveしたりborrowしたりする
少し逸れるけど解放処理を必要としないデータはCopy可能な場合が多い
ownershipは「所有権」て訳されるけど意味的には「解放権」とか「解放責任」に近いかも >>977
公式の見解を個人の感想と一緒にするなよ Rustで循環参照作るの簡単とか言ってるやつは100%エアプだからほっといてやれ
他言語での経験をあたかもRustで経験したかのように語りたかったんだろう >>985
メモリリークの原因になるかどうかを別にすれば、循環参照自体は普通に簡単に生じるだろう unsafeでポインタ使えば簡単だろうけどライフタイムのある参照の循環は大変そう
'a > 'bと 'b > 'aを両立は不可能に見えるけど何か抜け道あるのかな >>983
なるほどサンクス
リージョン理論に線形論理を上手く組み合わせて、cycloneとかの欠点を克服したrustってすげーなあ
とはいってもそもそも二重開放してエラーになるというのがピンとこない
free(a);
free(a);
は二重解放しているように見えて合法だろ？
一度目のfreeでaにNULLが代入されて、二度目のfreeでは引数がNULLの場合はそのままreturnって処理されるんだから、理論上は何度free使ってもエラーにならないじゃないか >>980
>Rustで循環参照が起きるにはRc利用が必須
RcだけじゃなくRcとInterior Mutabilityが必須
(どちらか片方はmutableじゃないと循環させられないので)
>Weak(弱参照)を適切に上手く用いて循環参照を避けるのが大変な場合もあるが
Rustの場合は循環参照で意図通り動くコードを書くのに比べれば
弱参照に変更するのはすごく簡単
循環参照を修正してる例
https://github.com/DataDog/glommio/commit/677fe1dfbaf911245fbc5c3eef75532d08d784bf
https://github.com/KWARC/rust-libxml/commit/bd4b120b90b2568ca6d5bfaa368a200573b87d09 すまんが、複数のファイルにソースを分割する練習教材みたいなものがあったら教えてくれんか？ >>992
「book」にもモジュールの章がある。 循環によって現れるメモリリークは Rust が提供する「メモリ安全」を損なわないと定義されている。
Rust は循環参照を防がないし、メモリリークに対処するのはプログラマの責任。 このスレッドは１０００を超えました。
新しいスレッドを立ててください。
life time: 69日 1時間 5分 21秒 5ちゃんねるの運営はプレミアム会員の皆さまに支えられています。
運営にご協力お願いいたします。
───────────────────
《プレミアム会員の主な特典》
★ 5ちゃんねる専用ブラウザからの広告除去
★ 5ちゃんねるの過去ログを取得
★ 書き込み規制の緩和
───────────────────
会員登録には個人情報は一切必要ありません。
月300円から匿名でご購入いただけます。
▼ プレミアム会員登録はこちら ▼
https://premium.5ch.net/
▼ 浪人ログインはこちら ▼
https://login.5ch.net/login.php レス数が1000を超えています。これ以上書き込みはできません。
