Rust part10

1 名前：デフォルトの名無しさん mailto:sage [2021/04/02(金) 21:38:04.11 ID:L7IeSfpL.net] Mozilla発のRust言語のスレ 公式 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 part9 https://mevius.5ch.net/test/read.cgi/tech/1598112455/ 113 名前：はちみつ餃子 mailto:sage [2021/04/17(土) 02:30:05.79 ID:V2rXjiTW.net] Linux のカーネルはカーネルとは言ってもかなり巨大なので 現状の Rust でも採用可能な箇所もあるんでないの。 知らんけど。 114 名前：デフォルトの名無しさん mailto:sage [2021/04/17(土) 08:49:33.19 ID:r+Flv24K.net] >>112 だからその考えでドライバーならということで始めたら上記の問題が出てきたってところだよ。 何周遅れてんだよ。 115 名前：デフォルトの名無しさん mailto:sage [2021/04/17(土) 09:05:35.37 ID:dMPv+0ET.net] グーグル、Linuxカーネル開発における「Rust」採用の動きをサポートする考え https://japan.zdnet.com/article/35169455/ 利用が進めば問題点も見えてくるし何らかの対策は追加されるだろうな 116 名前：デフォルトの名無しさん mailto:sage [2021/04/17(土) 09:33:32.53 ID:tTsG+vVF.net] linusすごいな Rust関わってる人全員子供扱いかよ 117 名前：デフォルトの名無しさん mailto:sage [2021/04/17(土) 10:42:23.64 ID:r+Flv24K.net] いや、これrustでkernelに関わろうとした人たちが低レイヤーのこと、あまりにわかってなさすぎだろ。。 これ、ほぼ素人の俺でも気づくような内容だぞ 118 名前：デフォルトの名無しさん mailto:sage [2021/04/17(土) 10:53:16.85 ID:ttx9Ve6D.net] へぇ、すごいんですねぇー^^ 119 名前：デフォルトの名無しさん mailto:sage [2021/04/17(土) 10:55:23.76 ID:r+Flv24K.net] 冷笑系気取りのバカって本当に救いようがないよな。 120 名前：デフォルトの名無しさん mailto:sage [2021/04/17(土) 11:09:22.71 ID:h7zOlTtk.net] C++でもコンテナに値を追加しようとすると、メモリー不足で追加に失敗 する可能性があるが、それをいちいちチェックする人はまず居ないだろうな。 デスクトップマシンでそれに失敗する可能性はとても低いけども。 121 名前：デフォルトの名無しさん mailto:sage [2021/04/17(土) 11:14:10.31 ID:h7zOlTtk.net] 例えば、 std::vector<int> v; // 空の動的配列を生成 for ( unsigned int i = 0; i < 100000000; i++ ) { v.push_back(i + 100); // 末尾に i + 100 という値を追加 } とした場合、環境やマシンの状態によってはメモリー不足で失敗することは あるだろうが、これをいちいちエラーチェックする人は少ないだろう。 122 名前：デフォルトの名無しさん mailto:sage [2021/04/17(土) 11:22:45.09 ID:3/shspJz.net] >>116 https://rust-lang.github.io/rfcs/2116-alloc-me-maybe.html 歴史的背景はこことか見ると書いてあるけど、処理系の初期開発で想定されていたほとんどの開発者はallocation errorから回復する必要がないから、あえてそういうAPIデザインにしたと カーネルはその「ほとんど」から外れる用途だからlinusは当然今のAPIじゃダメだと釘を刺す だからallocator_apiその他の安定化が急がれる、それだけの話じゃないの？ 123 名前：デフォルトの名無しさん mailto:sage [2021/04/17(土) 11:25:00.56 ID:/69X/cno.net] linusへのレスポンス読んだ？ allocについては問題なのは認識してるけど 開発スピード上げるために今はliballoc使っていて そのうち独自の物に置き換えると言っている 124 名前：デフォルトの名無しさん mailto:sage [2021/04/17(土) 11:27:24.53 ID:t/1FzfAW.net] pure rustでカーネル作ってる人いるんだから 原理的に不可能ってわけでもないだろ 125 名前：デフォルトの名無しさん mailto:sage [2021/04/17(土) 11:29:13.13 ID:LJqBKM+D.net] allocまで全部作り切ってからパッチ投げてLinusに却下って言われたら目も当てられんしな。プロトタイプの段階でこまめに出すのはいいと思う。 126 名前：デフォルトの名無しさん mailto:sage [2021/04/17(土) 11:37:37.77 ID:h7zOlTtk.net] >>120 伝統的なCでは、 char *ptr; if ( (ptr = malloc(サイズ)) == NULL ) {　// (1) 　printf( "メモリ確保にしっぱいしたで〜\n" ); } それをC++で書くとすれば、 if ( (ptr = new char [サイズ]) == NULL ) {　// (2) 　printf( "メモリ確保にしっぱいしたで〜\n" ); } となるけれども、 v.push_back(i + 100);　// (3) でメモリーエラーのエラーチェックしないのに(2)でしても余り意味はないという 考え方もあるわけでなので(2)と書かずにエラーチェック無しで ptr = new char [サイズ];　// (4) と書く方針もあっていいと思う。 なお、よっぽど大きなデータを扱わない限り、デスクトップマシンでは (3)や(4)で失敗する可能性はとても低い。 127 名前：デフォルトの名無しさん mailto:sage [2021/04/17(土) 11:41:51.20 ID:h7zOlTtk.net] N88-BASICでは、読み込みモードでファイルを開く時、 open "ファイル名" for input as #1 と書いていたが、ファイルが存在しないとここでエラーになって アプリが終了していたことを思い出した。 Perl、Ruby、Pythonなんかは、全て基本的に同じ方針だと思う。 その流儀とRustでのメモリー不足時のpanicの方針も同じと考えていいだろうな。 128 名前：デフォルトの名無しさん mailto:sage [2021/04/17(土) 11:48:23.17 ID:r+Flv24K.net] >>121 そう、それだけの話。でもそれだけの話がここでは恐ろしく通じない。 129 名前：デフォルトの名無しさん mailto:sage [2021/04/17(土) 12:20:31.25 ID:3/shspJz.net] >>122 On allocation: this is just our usage of `alloc` in order to speed development up -- it will be replaced (or customized, we have to decide how we will approach it) with our own allocation and data structures. これのことか？ itってour usage of `alloc`のことじゃねーのと思ったけど、alloc自体のAPIデザインに問題があるみたいな話出てるの？ 130 名前：デフォルトの名無しさん mailto:sage [2021/04/17(土) 13:30:05.64 ID:5SUmF/jF.net] >>125 > if ( (ptr = new char [サイズ]) == NULL ) {　// (2) C++ は new も vector::push_back も bad_alloc が飛ぶ。ふつうの new は nullptr 返さない。 131 名前：デフォルトの名無しさん mailto:sage [2021/04/17(土) 13:35:37.75 ID:YGcs/48d.net] てかアロケータの動作がどうのってLinux Kernel関係あるの？ ベアメタル用途全般が該当すると思うけど 132 名前：デフォルトの名無しさん mailto:sage [2021/04/17(土) 14:08:16.83 ID:h7zOlTtk.net] >>129 そういえば、言葉は忘れたけど、関数宣言の行に、その関数の中でどういう 例外が起きる可能性があるかについてのthrows を書くかどうか、書くべきか、 省略しても良いか、などの違いが色々あって、どういう言語仕様にすべきかが 結構問題になっていると聞いた。 すべてを書くと多くなりすぎるし、全く書かないのも問題だとか、そんな話。 なんという言葉だったかな。 133 名前：デフォルトの名無しさん mailto:sage [2021/04/17(土) 14:30:50.99 ID:ahfNUrst.net] allocatorがエラーを返さずに例外を上げる挙動にRustの標準ライブラリ的なもの(コレクションとかスマートポインタとか？)が依存していて、 それはLinuxカーネル的には許容できないからそういうコードをそのまま持ち込むなよ？ということでしょ Linuxカーネル上のC言語はそもそも標準ライブラリとか使わないし メモリ確保もmallocじゃなくてkmallocというカーネル内独自関数使うし ここ見ると https://medium.com/nttlabs/linux-kernel-module-with-rust-d5363c2f9085 array: vec![0;32] で kmalloc が呼ばれるみたいだね でもこれLinuxのカーネルモジュールのコードとしてはそこでエラーチェックが必要になるのかね？ もしくはkmallocに失敗したらそのモジュール自体が自動でアンロードされるとか でもアンロードされるときに後処理とかしたいかなとかいろいろ考える必要はありそう 134 名前：はちみつ餃子 mailto:sage [2021/04/17(土) 14:48:08.80 ID:V2rXjiTW.net] >>131 動的例外仕様 (dynamic exception specification) のことか？ https://timsong-cpp.github.io/cppwp/n3337/except.spec 送出される可能性のある例外を記述する仕組みだったが、役に立ってなかったので C++17 で廃止された。 (例外を送出するかしないかだけを指定する方式が残された。) C++ の仕様では例外を送出しないという指定を付けたところを例外が通過しようとしたら std::terminate が呼ばれて異常終了扱いになるという、実質的な assert なんだわ。 静的な検査をカッチリやってくれるわけではないんで、 カーネル記述みたいな文脈では使い物にならんな。 135 名前：デフォルトの名無しさん mailto:sage [2021/04/17(土) 14:49:51.36 ID:ohP60UMx.net] linuxだろうとwindowsだろうと普通のカーネルはそうだろ。 よっぽど特殊用途のOSならどうかは知らんが。 136 名前：デフォルトの名無しさん mailto:sage [2021/04/17(土) 15:49:17.42 ID:h7zOlTtk.net] >>133 なんか、Javaにおいて、throwsに創出するすべての例外を書く仕様にしてみたら、 地獄のように沢山書かなくてはならなくなって困り、 関数プロトタイプ宣言の直後の throws()の中に 「書く必要のある例外」と「書かなくても良い例外」 の違いを設けることにした、この板で聞いた。 137 名前：デフォルトの名無しさん mailto:sage [2021/04/17(土) 15:56:30.53 ID:h7zOlTtk.net] >>135 「OutOfMemoryError」例外は、throws に明示しなくて良いことになった とWikipediaで見た記憶が有る。 138 名前：はちみつ餃子 mailto:sage [2021/04/17(土) 16:29:38.34 ID:V2rXjiTW.net] >>135 検査例外と非検査例外のことだな。 例外の便利なところは大域脱出が出来るところで、例外を捕捉する箇所と発生する箇所の間では例外のことを忘れられる点。 発生しうる例外の伝播を明示しないといけないのだと返却値で返す形にするのと差がない。 例外を使っていると異常系だということが見た目に分かり易いってくらいのもの。 Java が明示しなくてよい例外という分類を設けたのは明示しなくてよいというだけでなく捕捉もしなくてよいということでもあって、 どのように使い分けるのがよいかは諸説あるけども、非検査例外は ・ 捕捉したところで回復できないもの ・ そもそもその例外を発生させないようにすべきもの (実質的には assert) というのがおおよその共通認識になっている。 メモリ不足は回復不可能なので非検査例外に分類されているが、 「Java のレイヤでは」回復不可能という話であって、 Java では低レイヤを書かないという前提があるからこういう決め打ちが出来る。 低レイヤと高レイヤでは前提が違ってくるから同じようにはいかんのだ。 139 名前：デフォルトの名無しさん [2021/04/17(土) 16:34:30.24 ID:h7zOlTtk.net] >>136 https://www.w3resource.com/java-tutorial/types-of-exception.php 1. Checked exceptions 2. Unchecked exceptions が有り、2. には、 2-1. Errors 2-2. Runtime exceptions の2種類がある。 1はmethodシグネチャのthrowsの後に明示しなくてはならないが、 2は不要。1はプログラマが処理することが出来る場合が多いが、 2はとても難しいことが多い。 OutOfMemoryErrorは、2-1 に属し、throwsの後に明示する必要がないが 「2」なのでプログラマが対処することが難しい例外に分類される。 140 名前：はちみつ餃子 mailto:sage [2021/04/17(土) 16:46:23.23 ID:V2rXjiTW.net] 低レイヤでも高レイヤでも使うことを考えたらやっぱ例外という仕組みは使いにくいっつーことだな。 カーネルを書くにあたって Rust が (現状では) ベストというわけでもないだろうけど、 比較的可能性がある選択のひとつではあると思う。 どうせ標準ライブラリのフルセットを使えるわけではないのは C でも同じことだし。 141 名前：デフォルトの名無しさん mailto:sage [2021/04/17(土) 17:10:18.35 ID:h7zOlTtk.net] Rubyなんかでファイルオープンする時にはエラー発生チェックをしなくてもよくて エラーが発生するとpanicする。これは簡単なプログラムでは便利。 そしてbegin,rescue,endではさめば、panicせずにエラー処理することも 出来る様になっている。これはtry,catch構文と発想は同じ。 でも、読み書き用の2つのファイルをオープンして読んで加工して書き込む ような時、catch文でどっちのエラーか区別したりするのは面倒といえば面倒かな。 C風だと、fopen の行で処理できて分かり易かったのに。 142 名前：デフォルトの名無しさん [2021/04/17(土) 17:12:33.63 ID:h7zOlTtk.net] >>139 でも、リストに追加したときにメモリ不足になっても、例外機構でしか エラーを補足出来ないのは面倒だな。 143 名前：デフォルトの名無しさん mailto:sage [2021/04/18(日) 02:29:17.84 ID:xL1TJJG/.net] ttps://github.com/rust-lang/rust-bindgen/commit/0e25962c4e69aef647e7275fa7bc7545dbb8cd0b#diff-b1a35a68f14e696205874893c07fd24fdb88882b47c23cc0e0c80a30c7d53759 コロコロ変わってその度に置換するスクリプト書いてるんだけど、 二ヶ月くらい音沙汰ないからそろそろ名前くらい安定してほしい。 144 名前：デフォルトの名無しさん [2021/04/18(日) 09:49:21.11 ID:vWwiRD ] [ここ壊れてます] 145 名前：OG.net mailto: rustってそんなにいいか？ 任意の場所でfreeできるcとは違って ブロック抜けるタイミングでしかメモリ開放されないんだろ？ rustっていらなくなってもブロック抜けるまではヒープメモリ保持しないといけないってことなの？ [] [ここ壊れてます] 146 名前：デフォルトの名無しさん mailto:sage [2021/04/18(日) 10:08:02.12 ID:UN4umXE6.net] >>143 dropじゃだめなの？ 147 名前：デフォルトの名無しさん mailto:sage [2021/04/18(日) 10:09:10.01 ID:732wPalE.net] そんなに良くないからキミはもっとcを頑張ったほうがいい cを頑張ってc++にも手を出して頑張って 気が狂いそうになるのを覚えてからもう一度来たらいい 148 名前：デフォルトの名無しさん [2021/04/18(日) 10:34:02.72 ID:vWwiRDOG.net] >>144 lifetime内であれば手動で早期開放できるんですね お世話になりました 149 名前：デフォルトの名無しさん mailto:sage [2021/04/18(日) 12:33:31.22 ID:gA/cagL6.net] ワロタw 150 名前：デフォルトの名無しさん mailto:sage [2021/04/18(日) 12:57:11.20 ID:UN4umXE6.net] vectorにpushしながらその要素の可変参照を返すようなメソッドってあったりしますか？ 151 名前：デフォルトの名無しさん mailto:sage [2021/04/18(日) 13:12:40.26 ID:/yrt+WGh.net] お前らの用途だったらgoで十分だろと思うことが多いわ。 ファッションでやるってのも悪くはないが。 152 名前：デフォルトの名無しさん mailto:sage [2021/04/18(日) 13:30:23.57 ID:8MLIImZW.net] rustではunsafeを多用するのは良いことですか？ 153 名前：デフォルトの名無しさん mailto:sage [2021/04/18(日) 13:39:58.68 ID:a3mPgn8/.net] 必要なら使えばいい 154 名前：デフォルトの名無しさん mailto:sage [2021/04/18(日) 16:52:32.86 ID:dOXZMSKq.net] >>148 そういうメソッドはなさそう 特に理由がなければ分けて書いた方がいいけど、ブロック式を使って let y = { v.push(x); v.last_mut().unwrap() }; // 変数に入れる場合 f({ v.push(x); v.last_mut().unwrap() }); // 関数に渡す場合 みたいな詰め方はできるかな いっぱい使うならローカルなマクロ作ってもいい macro_rules! push_and_mut_ref { ($v:expr, $x:expr) => {{ $v.push($x); $v.last_mut().unwrap() }}; } let y = push_and_mut_ref!(v, x); 蛇足だけどyが生きてる間はvに触れないからご注意を 155 名前：デフォルトの名無しさん mailto:sage [2021/04/18(日) 17:30:23.89 ID:qHYw4Dd3.net] >>152 >蛇足だけどyが生きてる間はvに触れないからご注意を 蛇足ではない気がする push時にその要素のmut refを必要とするような書き方は避けたほうがいい 156 名前：デフォルトの名無しさん mailto:sage [2021/04/18(日) 17:38:05.52 ID:/DBGFH0C.net] entry APIみたいなことしたいのかな 157 名前：デフォルトの名無しさん mailto:sage [2021/04/19(月) 03:50:11.66 ID:cH3u5yp0.net] Rustに比べたC++の良さは雑に書けるところだって気付いた やっぱ雑が許されない巨大プロジェクトはRustで、小規模な自分用ツールの類はC++で書いてくことになりそうだ 158 名前：デフォルトの名無しさん mailto:sage [2021/04/19(月) 08:44:54.89 ID:4a/aZ6Q1.net] >>155 いいところに気付いたな Rustは一般プログラマーには無用の長物だ 159 名前：デフォルトの名無しさん mailto:sage [2021/04/19(月) 10:48:10.96 ID:7a+3hK+O.net] 段階的に直していく方法と最初から設計で硬くしておく方法があると思うが rustが念頭に置いてるのは明らかに後者。これがいいのか悪いのかは議論の余地がある。 160 名前：デフォルトの名無しさん mailto:sage [2021/04/19(月) 11:19:16.28 ID:QqvLWpkW.net] 型が強いからリファクタリングしやすいという意味では段々直していく方法に適しているとも言えると思うが 161 名前：デフォルトの名無しさん mailto:sage [2021/04/19(月) 11:21:50.23 ID:7a+3hK+O.net] >>158 型の強さがある意味で強すぎて、メモリ解放のタイミングまでキッチリあってないと無理なんだが。 ちょっとしたリファクタリングするにもかなり大域的変更になる。 162 名前：デフォルトの名無しさん mailto:sage [2021/04/19(月) 11:34:35.17 ID:VqBzpR75.net] >>155 雑に書いた脆弱性のあるバイナリを世に出さなきゃそれでもいいんじゃね 163 名前：デフォルトの名無しさん mailto:sage [2021/04/19(月) 13:02:55.04 ID:sZaag2LS.net] >>160 何言ってんだこの馬鹿 Rust謹製なら脆弱性が無いとでも思ってんのか？ 164 名前：デフォルトの名無しさん mailto:sage [2021/04/19(月) 13:06:52.92 ID:hAOdtYDs.net] つーかRust以前はどうしてたんだよって話ｗ 流行りのもんに飛びついてそれ以外見えなくなってる典型 165 名前：デフォルトの名無しさん [2021/04/19(月) 13:26:32.62 ID:I7sE/fYQ.net] どうしてたって脆弱性を秘めたまま出回ってただろ 166 名前：デフォルトの名無しさん mailto:sage [2021/04/19(月) 13:27:33.53 ID:k4Vsf7V5.net] いつものレイヤーとかスコープを ごちゃまぜにする思考が乱雑な人でしょ 167 名前：デフォルトの名無しさん mailto:sage [2021/04/19(月) 14:27:55.78 ID:7a+3hK+O.net] それお前だろ 168 名前：デフォルトの名無しさん [2021/04/19(月) 16:41:05.18 ID:OqiIdPZa.net] まあ、C/C++が危なかろうが、自分のやりたい計算をするだけみたいな用途には向いてるよな どうみても簡単で早いし・・・・ 169 名前：デフォルトの名無しさん mailto:sage [2021/04/19(月) 16:57:54.64 ID:QZprAv/b.net] >>155 C/C++は雑に書けるというより、Rustが想定してないでけで 本当は安全なプログラムも思った通りに書くことが出来る。 RustはRustが想定している範囲内でしか書けないので面倒なことになる。 170 名前：デフォルトの名無しさん mailto:sage [2021/04/19(月) 17:00:14.68 ID:QZprAv/b.net] >>167 職人さんはさまざまな危険な道具を、十分安全に使う。 Rustは、「危険だ危険だ」と言って、危ない道具を使わせず 予め「刃(やいば)を抜かれた」道具の使用を強制する。 171 名前：デフォルトの名無しさん mailto:sage [2021/04/19(月) 17:08:36.65 ID:QZprAv/b.net] AIの機械学習は計算が重いのに言語としては遅いところのPythonのAIは遅くはない。 なぜなら計算部分はC/C++で書かれたライブラリを呼び出して使ってるだけだから。 同様にRustがベンチマークで遅くないのは、実はunsafeモードで書かれたライブラリ を使ってるせいもある。だからそのベンチマークだけでC/C++と同程度の速さ であることの証明にはならない。 172 名前：デフォルトの名無しさん mailto:sage [2021/04/19(月) 17:33:10.17 ID:QqvLWpkW.net] >>169 具体的に何のベンチマークのことを言っているの？ 173 名前：デフォルトの名無しさん mailto:sage [2021/04/19(月) 17:37:07.25 ID:QqvLWpkW.net] unsafeがライブラリに隠蔽されていてかつ性能が出ることはRustのコンセプトが正しかったことの証明になるのでは？ 174 名前：デフォルトの名無しさん mailto:sage [2021/04/19(月) 17:58:35.97 ID:eG8AP0Ht.net] 今月のWEB+DB PRESSに載ってる簡易的なRDBMSをRustで実装する記事結構いいぞ RDBMSの仕組みを学ぶことが主眼でRustの解説は最低限なんだけど Rustでよく使うパターンが 175 名前：デフォルトの名無しさん mailto:sage [2021/04/19(月) 17:59:44.87 ID:cPEAzkUm.net] 「じゃあC++使えばいいよ」で済む質問を何度投下すれば気が済むのか 176 名前：デフォルトの名無しさん mailto:sage [2021/04/19(月) 18:02:01.96 ID:Nl1mmVW4.net] だって入れ食いなんだもん… 177 名前：デフォルトの名無しさん mailto:sage [2021/04/19(月) 18:15:13.40 ID:zaOVVmA+.net] >>173 リトマス試験紙なんよ C++で苦労した奴は文句は言わない。Rustが何をしてくれようとしてるのか分かるから。 C++ニワカは文句を言う。Rustが何をしてくれようとしてるのか分からないから。 178 名前：デフォルトの名無しさん mailto:sage [2021/04/19(月) 18:56:00.14 ID:7a+3hK+O.net] >>171 言ってる意味がまるでわからんのだが。 179 名前：デフォルトの名無しさん [2021/04/19(月) 19:29:57.41 ID:OqiIdPZa.net] 大半の人は、C/C++で苦労も何もしてないだろう 何が危ないのかも理解しないまま、危険なコードや穴の空きやすいコードを書いてるだけだ 180 名前：デフォルトの名無しさん mailto:sage [2021/04/19(月) 19:51:48.28 ID:iY2hw6vD.net] C/C++でメモリをぶっ壊して数日絶望するところまでがチュートリアル 181 名前：デフォルトの名無しさん mailto:sage [2021/04/19(月) 19:59:51.22 ID:sjEpEGTN.net] メモリぶっ壊すのは絶望ではない、C++の日常だ 182 名前：デフォルトの名無しさん mailto:sage [2021/04/19(月) 20:10:50.91 ID:hAOdtYDs.net] >>178-179 この人たち未だにC++でnewとかdelete多用してるかそれを通過儀礼のように捉えてる人たちだよね こえ〜 よくある職 183 名前：場の老害像そのものじゃん [] [ここ壊れてます] 184 名前：デフォルトの名無しさん mailto:sage [2021/04/19(月) 20:11:49.67 ID:sjEpEGTN.net] アマチュア君にはそう見えるんだね 185 名前：デフォルトの名無しさん mailto:sage [2021/04/19(月) 20:13:49.42 ID:cPEAzkUm.net] さすがに日常ではないかな…… 構造体の初期化にmemset使うようなC言語上がりのやつはどうだか知らんけど 186 名前：デフォルトの名無しさん mailto:sage [2021/04/19(月) 20:16:58.02 ID:swd16GZO.net] 毎日のようにRustスレで繰り返し同じ事をグチグチ言ってる自称C++使い達はよっぽど暇なんだなぁって思う 187 名前：デフォルトの名無しさん mailto:sage [2021/04/19(月) 20:21:28.79 ID:7a+3hK+O.net] c/c++でそんだけ壊れるならrustでもunsafe使ってぶっ壊れまくるだろ。。 エアプ丸出しすぎるわ 188 名前：デフォルトの名無しさん mailto:sage [2021/04/19(月) 20:21:54.23 ID:iY2hw6vD.net] 引数チェックのないライブラリ等で引数を誤ったりすると パッと見正しく見えるのでかなり面倒なことになる 189 名前：デフォルトの名無しさん mailto:sage [2021/04/19(月) 21:31:37.98 ID:LNECVJtJ.net] AddressSanitizerを使ったことのないものだけが石を投げよ 190 名前：デフォルトの名無しさん mailto:sage [2021/04/19(月) 22:14:40.51 ID:w0HdGBDs.net] 伸びてると思ったら。次からﾜｯﾁｮｲ付けろよ。 191 名前：デフォルトの名無しさん mailto:sage [2021/04/20(火) 00:56:58.25 ID:h4Yrn7zO.net] https://trends.google.com/trends/explore?date=today%205-y&geo=US&q=%2Fm%2F0dsbpg6,%2Fm%2F02p97,Python,Java,%2Fm%2F0jgqg Google Trends での Rustと他の言語とのトレンド比較。 これを見る限り、Rust言語は全く流行ってないようだ。 192 名前：デフォルトの名無しさん mailto:sage [2021/04/20(火) 00:59:14.52 ID:h4Yrn7zO.net] Python>Java>=JS>C++>>>>Rust 193 名前：デフォルトの名無しさん mailto:sage [2021/04/20(火) 01:00:58.56 ID:P7hWVPU6.net] そんな超メジャー言語と比較されるようになったのか 194 名前：デフォルトの名無しさん mailto:さげ [2021/04/20(火) 01:04:41.62 ID:h4Yrn7zO.net] >>190 逆にそんなマイナーな言語なのに書籍が出たりtwitterでRustとWasmが 対になって出たりしてたのか。 Rustを試してる人は書籍や雑誌記事を書いて食っていくかか、難しくて新しい言語 を知ることで自分の社会的評価(?)を上げようとしているのか。 195 名前：デフォルトの名無しさん mailto:sage [2021/04/20(火) 01:11:58.24 ID:P7hWVPU6.net] >>191 なんかかっこいい嫌味を言いたいみたいだけど 意味不明ですべってるぞ 196 名前：デフォルトの名無しさん mailto:sage [2021/04/20(火) 02:00:40.62 ID:1YS4Hj5E.net] >>161 雑に書いたコードだって自分で言ってんだろボケが 197 名前：デフォルトの名無しさん mailto:sage [2021/04/20(火) 08:34:25.33 ID:A+mNu4wy.net] https://m.slashdot.org/story/384324 198 名前：デフォルトの名無しさん mailto:sage [2021/04/20(火) 10:41:16.90 ID:MbK31k7w.net] なんか無駄なところに手を出しちゃったみたいになってる若い人が発狂してんのかね。 別にrustで学んだことは無駄にはならんよ。 現場でrust強要するのはクソだが。 199 名前：デフォルトの名無しさん mailto:sage [2021/04/20(火) 11:46:33.55 ID:UmXg6L/G.net] 5chに若い人なんかいないよ 200 名前：デフォルトの名無しさん mailto:sage [2021/04/20(火) 19:43:34.07 ID:jXnHABO7.net] なるほどそれで皆C++の話ばかりするのか 201 名前：デフォルトの名無しさん mailto:sage [2021/04/20(火) 21:08:17.70 ID:i+94ZV2W.net] C++もそれだけ枯れたか 202 名前：デフォルトの名無しさん [2021/04/21(水) 11:52:12.19 ID:/JxRHm/B.net] C++ニワカのLinusはpanicは認めないと言う話をしてるのにアロケーターだけの問題だ 「それだけでしょ、分かってるやつ居なすぎ」とまとめる 範囲外のインデックスアクセスでもpanicするし、Debugなら整数のオーバーフローでも panicする（なぜかReleaseだとpanicしない）とんでもないアホの勘違いはJavaを持って きて検査例外と非検査例外の話をし出す。せっかくResult/OptionがあるのにRustの文化と なっているpanicを通常は捕捉しないと言うものをKernelに持ち込むなと言う話。 範囲外アクセスで即座に既存のC/Kernelならレジスタを保存してダンプするような Segment fault例外トラップなどが働くのに、panicでスタック巻き戻し実行が起こるのは 絶対的に受け入れられない言うとる Cの悪名高きsetjmpや、C++のRTL/動的例外テーブルの議論を見てるようだ 検査例外と非検査例外の話をし出すアホはもう来るな 203 名前：デフォルトの名無しさん mailto:sage [2021/04/21(水) 12:24:14.02 ID:dj6DJThv.net] ++うんこ華麗にスルーして、やっぱリーナス見る目有るわ神だろ 204 名前：デフォルトの名無しさん mailto:sage [2021/04/21(水) 12:54:12.00 ID:KSNXGwT5.net] 別にそこまで褒めることでもないんだけどね。。 ttps://lkml.org/ の他の議論に比べて明らかに議論のレベルが低いわけで。。 205 名前：デフォルトの名無しさん [2021/04/21(水) 13:38:37.86 ID:T0Zi2n6U.net] >>199 なんか何言ってるのか分からない部分が有るな。 206 名前：デフォルトの名無しさん mailto:sage [2021/04/21(水) 17:38:16.65 ID:l2lL4TPp.net] js-sys見てたらJavaScript側の型の継承関係をDerefで表現しててびびった こういうの普通なん？ 207 名前：デフォルトの名無しさん mailto:sage [2021/04/21(水) 17:58:04.79 ID:tLndpRqR.net] >>201 歴史があってどう実装すべきかという指針ができあがっているCと 手探りで指針を作りつつあるRustで議論のレベルが同じにならないのは自然なのでは 208 名前：デフォルトの名無しさん mailto:sage [2021/04/21(水) 18:42:16.83 ID:KSNXGwT5.net] >>204 問題はそういう言語の問題まで行かず、カーネルが備えるべきところってな議論で止まってるって部分だけどね。 歴史という意味ではそもそもカーネルに対する歴史観が不足してる連中しかrustにはいないということになる。 209 名前：デフォルトの名無しさん mailto:sage [2021/04/21(水) 22:06:45.67 ID:2oKQsBoE.net] プロセスがスローし、誰も補足しなかった例外を 最終的に捕捉してそのプロセスを終了させるのはOS（ことによったらカーネル）の仕事である 一方、カーネルが仮に例外をスローしてしまったら誰が最終的な捕捉の任を負うのか について今今のOS論には目下定説が無い Linux（リーナス）は「カーネルは何があっても例外をスローすんなﾊｹﾞ、」という 古典的な立場 のやつ、 210 名前：デフォルトの名無しさん mailto:sage [2021/04/21(水) 23:10:54.58 ID:/dktUqXg.net] 機械語に例外なんてねーよ いい加減なこと言ってんじゃねーや 211 名前：デフォルトの名無しさん mailto:sage [2021/04/21(水) 23:43:21.15 ID:NQ0xHQya.net] >>206 CPUの例外と言語上の例外との区別が付いてないみたいね。 212 名前：デフォルトの名無しさん mailto:sage [2021/04/22(木) 00:18:18.68 ID:41g4gqqa.net] >>203 javascriptでメソッドとか探すときにプロトタイプを遡っていく動きがあるけど それをRustのドット演算子（.）がメソッド使える型になるまで自動で参照解決する仕様で 模倣したんだと思う 演算子の特殊な拡張は正規表現とか構文解析のライブラリでたまに見かけるけど どちらかと言えばトリッキーな手法 213 名前：デフォルトの名無しさん mailto:sage [2021/04/22(木) 02:40:36.34 ID:hZdbeIl+.net] panic上等のredox！ セキュリティホール開けるよりマシという理由だった。 >>203 アンチパターンだから通常のコードでは使うな。 トレイトメソッド呼べないからクソって所まではすでに githubのissuesやrust internalsで合意が有る。 js-sysはffi（バインダ）だから仕方ない。

---

---

[ 続きを読む ] / [ 携帯版 ]

read.cgi ver5.27 [feat.BBS2 +1.6] / e.0.2 (02/09/03) / eucaly.net products.
担当:undef