Rust part10 - 暇つぶし2ch

Rust part10 ..

112:デフォルトの名無しさん
21/04/17 00:54:40.80 r+Flv24K.net
知らんがな。どうしてもrustでkernel作りたいってやつに言えや。

113:はちみつ餃子
21/04/17 02:30:05.79 V2rXjiTW.net
Linux のカーネルはカーネルとは言ってもかなり巨大なので
現状の Rust でも採用可能な箇所もあるんでないの。
知らんけど。

114:デフォルトの名無しさん
21/04/17 08:49:33.19 r+Flv24K.net
>>112
だからその考えでドライバーならということで始めたら上記の問題が出てきたってところだよ。
何周遅れてんだよ。

115:デフォルトの名無しさん
21/04/17 09:05:35.37 dMPv+0ET.net
グーグル、Linuxカーネル開発における「Rust」採用の動きをサポートする考え
URLﾘﾝｸ(japan.zdnet.com)
利用が進めば問題点も見えてくるし何らかの対策は追加されるだろうな

116:デフォルトの名無しさん
21/04/17 09:33:32.53 tTsG+vVF.net
linusすごいな
Rust関わってる人全員子供扱いかよ

117:デフォルトの名無しさん
21/04/17 10:42:23.64 r+Flv24K.net
いや、これrustでkernelに関わろうとした人たちが低レイヤーのこと、あまりにわかってなさすぎだろ。。
これ、ほぼ素人の俺でも気づくような内容だぞ

118:デフォルトの名無しさん
21/04/17 10:53:16.85 ttx9Ve6D.net
へぇ、すごいんですねぇー^^

119:デフォルトの名無しさん
21/04/17 10:55:23.76 r+Flv24K.net
冷笑系気取りのバカって本当に救いようがないよな。

120:デフォルトの名無しさん
21/04/17 11:09:22.71 h7zOlTtk.net
C++でもコンテナに値を追加しようとすると、メモリー不足で追加に失敗
する可能性があるが、それをいちいちチェックする人はまず居ないだろうな。
デスクトップマシンでそれに失敗する可能性はとても低いけども。

121:デフォルトの名無しさん
21/04/17 11:14:10.31 h7zOlTtk.net
例えば、
std::vector<int> v; // 空の動的配列を生成
for ( unsigned int i = 0; i < 100000000; i++ ) {
v.push_back(i + 100); // 末尾に i + 100 という値を追加
}
とした場合、環境やマシンの状態によってはメモリー不足で失敗することは
あるだろうが、これをいちいちエラーチェックする人は少ないだろう。

122:デフォルトの名無しさん
21/04/17 11:22:45.09 3/shspJz.net
>>116
URLﾘﾝｸ(rust-lang.github.io)
歴史的背景はこことか見ると書いてあるけど、処理系の初期開発で想定されていたほとんどの開発者はallocation errorから回復する必要がないから、あえてそういうAPIデザインにしたと
カーネルはその「ほとんど」から外れる用途だからlinusは当然今のAPIじゃダメだと釘を刺す
だからallocator_apiその他の安定化が急がれる、それだけの話じゃないの？

123:デフォルトの名無しさん
21/04/17 11:25:00.56 /69X/cno.net
linusへのレスポンス読んだ？
allocについては問題なのは認識してるけど
開発スピード上げるために今はliballoc使っていて
そのうち独自の物に置き換えると言っている

124:デフォルトの名無しさん
21/04/17 11:27:24.53 t/1FzfAW.net
pure rustでカーネル作ってる人いるんだから
原理的に不可能ってわけでもないだろ

125:デフォルトの名無しさん
21/04/17 11:29:13.13 LJqBKM+D.net
allocまで全部作り切ってからパッチ投げてLinusに却下って言われたら目も当てられんしな。プロトタイプの段階でこまめに出すのはいいと思う。

126:デフォルトの名無しさん
21/04/17 11:37:37.77 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:デフォルトの名無しさん
21/04/17 11:41:51.20 h7zOlTtk.net
N88-BASICでは、読み込みモードでファイルを開く時、
open "ファイル名" for input as #1
と書いていたが、ファイルが存在しないとここでエラーになって
アプリが終了していたことを思い出した。
Perl、Ruby、Pythonなんかは、全て基本的に同じ方針だと思う。
その流儀とRustでのメモリー不足時のpanicの方針も同じと考えていいだろうな。

128:デフォルトの名無しさん
21/04/17 11:48:23.17 r+Flv24K.net
>>121
そう、それだけの話。でもそれだけの話がここでは恐ろしく通じない。

129:デフォルトの名無しさん
21/04/17 12:20:31.25 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:デフォルトの名無しさん
21/04/17 13:30:05.64 5SUmF/jF.net
>>125
> if ( (ptr = new char [サイズ]) == NULL ) {　// (2)
C++ は new も vector::push_back も bad_alloc が飛ぶ。ふつうの new は nullptr 返さない。

131:デフォルトの名無しさん
21/04/17 13:35:37.75 YGcs/48d.net
てかアロケータの動作がどうのってLinux Kernel関係あるの？
ベアメタル用途全般が該当すると思うけど

132:デフォルトの名無しさん
21/04/17 14:08:16.83 h7zOlTtk.net
>>129
そういえば、言葉は忘れたけど、関数宣言の行に、その関数の中でどういう
例外が起きる可能性があるかについてのthrows を書くかどうか、書くべきか、
省略しても良いか、などの違いが色々あって、どういう言語仕様にすべきかが
結構問題になっていると聞いた。
すべてを書くと多くなりすぎるし、全く書かないのも問題だとか、そんな話。
なんという言葉だったかな。

133:デフォルトの名無しさん
21/04/17 14:30:50.99 ahfNUrst.net
allocatorがエラーを返さずに例外を上げる挙動にRustの標準ライブラリ的なもの(コレクションとかスマートポインタとか？)が依存していて、
それはLinuxカーネル的には許容できないからそういうコードをそのまま持ち込むなよ？ということでしょ
Linuxカーネル上のC言語はそもそも標準ライブラリとか使わないし
メモリ確保もmallocじゃなくてkmallocというカーネル内独自関数使うし
ここ見ると
URLﾘﾝｸ(medium.com)
array: vec![0;32] で kmalloc が呼ばれるみたいだね
でもこれLinuxのカーネルモジュールのコードとしてはそこでエラーチェックが必要になるのかね？
もしくはkmallocに失敗したらそのモジュール自体が自動でアンロードされるとか
でもアンロードされるときに後処理とかしたいかなとかいろいろ考える必要はありそう

134:はちみつ餃子
21/04/17 14:48:08.80 V2rXjiTW.net
>>131
動的例外仕様 (dynamic exception specification) のことか？
URLﾘﾝｸ(timsong-cpp.github.io)
送出される可能性のある例外を記述する仕組みだったが、役に立ってなかったので C++17 で廃止された。
(例外を送出するかしないかだけを指定する方式が残された。)
C++ の仕様では例外を送出しないという指定を付けたところを例外が通過しようとしたら
std::terminate が呼ばれて異常終了扱いになるという、実質的な assert なんだわ。
静的な検査をカッチリやってくれるわけではないんで、
カーネル記述みたいな文脈では使い物にならんな。

135:デフォルトの名無しさん
21/04/17 14:49:51.36 ohP60UMx.net
linuxだろうとwindowsだろうと普通のカーネルはそうだろ。
よっぽど特殊用途のOSならどうかは知らんが。

136:デフォルトの名無しさん
21/04/17 15:49:17.42 h7zOlTtk.net
>>133
なんか、Javaにおいて、throwsに創出するすべての例外を書く仕様にしてみたら、
地獄のように沢山書かなくてはならなくなって困り、
関数プロトタイプ宣言の直後の throws()の中に
「書く必要のある例外」と「書かなくても良い例外」
の違いを設けることにした、この板で聞いた。

137:デフォルトの名無しさん
21/04/17 15:56:30.53 h7zOlTtk.net
>>135
「OutOfMemoryError」例外は、throws に明示しなくて良いことになった
とWikipediaで見た記憶が有る。

138:はちみつ餃子
21/04/17 16:29:38.34 V2rXjiTW.net
>>135
検査例外と非検査例外のことだな。
例外の便利なところは大域脱出が出来るところで、例外を捕捉する箇所と発生する箇所の間では例外のことを忘れられる点。
発生しうる例外の伝播を明示しないといけないのだと返却値で返す形にするのと差がない。
例外を使っていると異常系だということが見た目に分かり易いってくらいのもの。
Java が明示しなくてよい例外という分類を設けたのは明示しなくてよいというだけでなく捕捉もしなくてよいということでもあって、
どのように使い分けるのがよいかは諸説あるけども、非検査例外は
・捕捉したところで回復できないもの
・そもそもその例外を発生させないようにすべきもの (実質的には assert)
というのがおおよその共通認識になっている。
メモリ不足は回復不可能なので非検査例外に分類されているが、
「Java のレイヤでは」回復不可能という話であって、
Java では低レイヤを書かないという前提があるからこういう決め打ちが出来る。
低レイヤと高レイヤでは前提が違ってくるから同じようにはいかんのだ。

139:デフォルトの名無しさん
21/04/17 16:34:30.24 h7zOlTtk.net
>>136
URLﾘﾝｸ(www.w3resource.com)
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:はちみつ餃子
21/04/17 16:46:23.23 V2rXjiTW.net
低レイヤでも高レイヤでも使うことを考えたらやっぱ例外という仕組みは使いにくいっつーことだな。
カーネルを書くにあたって Rust が (現状では) ベストというわけでもないだろうけど、
比較的可能性がある選択のひとつではあると思う。
どうせ標準ライブラリのフルセットを使えるわけではないのは C でも同じことだし。

141:デフォルトの名無しさん
21/04/17 17:10:18.35 h7zOlTtk.net
Rubyなんかでファイルオープンする時にはエラー発生チェックをしなくてもよくて
エラーが発生するとpanicする。これは簡単なプログラムでは便利。
そしてbegin,rescue,endではさめば、panicせずにエラー処理することも
出来る様になっている。これはtry,catch構文と発想は同じ。
でも、読み書き用の2つのファイルをオープンして読んで加工して書き込む
ような時、catch文でどっちのエラーか区別したりするのは面倒といえば面倒かな。
C風だと、fopen の行で処理できて分かり易かったのに。

142:デフォルトの名無しさん
21/04/17 17:12:33.63 h7zOlTtk.net
>>139
でも、リストに追加したときにメモリ不足になっても、例外機構でしか
エラーを補足出来ないのは面倒だな。

143:デフォルトの名無しさん
21/04/18 02:29:17.84 xL1TJJG/.net
URLﾘﾝｸ(github.com)
コロコロ変わってその度に置換するスクリプト書いてるんだけど、
二ヶ月くらい音沙汰ないからそろそろ名前くらい安定してほしい。

144:デフォルトの名無しさん
21/04/18 09:49:21.11 vWwiRD

145:OG.net

146:デフォルトの名無しさん
21/04/18 10:08:02.12 UN4umXE6.net
>>143
dropじゃだめなの？

147:デフォルトの名無しさん
21/04/18 10:09:10.01 732wPalE.net
そんなに良くないからキミはもっとcを頑張ったほうがいい
cを頑張ってc++にも手を出して頑張って
気が狂いそうになるのを覚えてからもう一度来たらいい

148:デフォルトの名無しさん
21/04/18 10:34:02.72 vWwiRDOG.net
>>144
lifetime内であれば手動で早期開放できるんですね
お世話になりました

149:デフォルトの名無しさん
21/04/18 12:33:31.22 gA/cagL6.net
ワロタw

150:デフォルトの名無しさん
21/04/18 12:57:11.20 UN4umXE6.net
vectorにpushしながらその要素の可変参照を返すようなメソッドってあったりしますか？

151:デフォルトの名無しさん
21/04/18 13:12:40.26 /yrt+WGh.net
お前らの用途だったらgoで十分だろと思うことが多いわ。
ファッションでやるってのも悪くはないが。

152:デフォルトの名無しさん
21/04/18 13:30:23.57 8MLIImZW.net
rustではunsafeを多用するのは良いことですか？

153:デフォルトの名無しさん
21/04/18 13:39:58.68 a3mPgn8/.net
必要なら使えばいい

154:デフォルトの名無しさん
21/04/18 16:52:32.86 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:デフォルトの名無しさん
21/04/18 17:30:23.89 qHYw4Dd3.net
>>152
>蛇足だけどyが生きてる間はvに触れないからご注意を
蛇足ではない気がする
push時にその要素のmut refを必要とするような書き方は避けたほうがいい

156:デフォルトの名無しさん
21/04/18 17:38:05.52 /DBGFH0C.net
entry APIみたいなことしたいのかな

157:デフォルトの名無しさん
21/04/19 03:50:11.66 cH3u5yp0.net
Rustに比べたC++の良さは雑に書けるところだって気付いた
やっぱ雑が許されない巨大プロジェクトはRustで、小規模な自分用ツールの類はC++で書いてくことになりそうだ

158:デフォルトの名無しさん
21/04/19 08:44:54.89 4a/aZ6Q1.net
>>155
いいところに気付いたな
Rustは一般プログラマーには無用の長物だ

159:デフォルトの名無しさん
21/04/19 10:48:10.96 7a+3hK+O.net
段階的に直していく方法と最初から設計で硬くしておく方法があると思うが
rustが念頭に置いてるのは明らかに後者。これがいいのか悪いのかは議論の余地がある。

160:デフォルトの名無しさん
21/04/19 11:19:16.28 QqvLWpkW.net
型が強いからリファクタリングしやすいという意味では段々直していく方法に適しているとも言えると思うが

161:デフォルトの名無しさん
21/04/19 11:21:50.23 7a+3hK+O.net
>>158
型の強さがある意味で強すぎて、メモリ解放のタイミングまでキッチリあってないと無理なんだが。
ちょっとしたリファクタリングするにもかなり大域的変更になる。

162:デフォルトの名無しさん
21/04/19 11:34:35.17 VqBzpR75.net
>>155
雑に書いた脆弱性のあるバイナリを世に出さなきゃそれでもいいんじゃね

163:デフォルトの名無しさん
21/04/19 13:02:55.04 sZaag2LS.net
>>160
何言ってんだこの馬鹿
Rust謹製なら脆弱性が無いとでも思ってんのか？

164:デフォルトの名無しさん
21/04/19 13:06:52.92 hAOdtYDs.net
つーかRust以前はどうしてたんだよって話ｗ
流行りのもんに飛びついてそれ以外見えなくなってる典型

165:デフォルトの名無しさん
21/04/19 13:26:32.62 I7sE/fYQ.net
どうしてたって脆弱性を秘めたまま出回ってただろ

166:デフォルトの名無しさん
21/04/19 13:27:33.53 k4Vsf7V5.net
いつものレイヤーとかスコープを
ごちゃまぜにする思考が乱雑な人でしょ

167:デフォルトの名無しさん
21/04/19 14:27:55.78 7a+3hK+O.net
それお前だろ

168:デフォルトの名無しさん
21/04/19 16:41:05.18 OqiIdPZa.net
まあ、C/C++が危なかろうが、自分のやりたい計算をするだけみたいな用途には向いてるよな
どうみても簡単で早いし・・・・

169:デフォルトの名無しさん
21/04/19 16:57:54.64 QZprAv/b.net
>>155
C/C++は雑に書けるというより、Rustが想定してないでけで
本当は安全なプログラムも思った通りに書くことが出来る。
RustはRustが想定している範囲内でしか書けないので面倒なことになる。

170:デフォルトの名無しさん
21/04/19 17:00:14.68 QZprAv/b.net
>>167
職人さんはさまざまな危険な道具を、十分安全に使う。
Rustは、「危険だ危険だ」と言って、危ない道具を使わせず
予め「刃(やいば)を抜かれた」道具の使用を強制する。

171:デフォルトの名無しさん
21/04/19 17:08:36.65 QZprAv/b.net
AIの機械学習は計算が重いのに言語としては遅いところのPythonのAIは遅くはない。
なぜなら計算部分はC/C++で書かれたライブラリを呼び出して使ってるだけだから。
同様にRustがベンチマークで遅くないのは、実はunsafeモードで書かれたライブラリ
を使ってるせいもある。だからそのベンチマークだけでC/C++と同程度の速さ
であることの証明にはならない。

172:デフォルトの名無しさん
21/04/19 17:33:10.17 QqvLWpkW.net
>>169
具体的に何のベンチマークのことを言っているの？

173:デフォルトの名無しさん
21/04/19 17:37:07.25 QqvLWpkW.net
unsafeがライブラリに隠蔽されていてかつ性能が出ることはRustのコンセプトが正しかったことの証明になるのでは？

174:デフォルトの名無しさん
21/04/19 17:58:35.97 eG8AP0Ht.net
今月のWEB+DB PRESSに載ってる簡易的なRDBMSをRustで実装する記事結構いいぞ
RDBMSの仕組みを学ぶことが主眼でRustの解説は最低限なんだけど
Rustでよく使うパターンが

175:デフォルトの名無しさん
21/04/19 17:59:44.87 cPEAzkUm.net
「じゃあC++使えばいいよ」で済む質問を何度投下すれば気が済むのか

176:デフォルトの名無しさん
21/04/19 18:02:01.96 Nl1mmVW4.net
だって入れ食いなんだもん…

177:デフォルトの名無しさん
21/04/19 18:15:13.40 zaOVVmA+.net
>>173
リトマス試験紙なんよ
C++で苦労した奴は文句は言わない。Rustが何をしてくれようとしてるのか分かるから。
C++ニワカは文句を言う。Rustが何をしてくれようとしてるのか分からないから。

178:デフォルトの名無しさん
21/04/19 18:56:00.14 7a+3hK+O.net
>>171
言ってる意味がまるでわからんのだが。

179:デフォルトの名無しさん
21/04/19 19:29:57.41 OqiIdPZa.net
大半の人は、C/C++で苦労も何もしてないだろう
何が危ないのかも理解しないまま、危険なコードや穴の空きやすいコードを書いてるだけだ

180:デフォルトの名無しさん
21/04/19 19:51:48.28 iY2hw6vD.net
C/C++でメモリをぶっ壊して数日絶望するところまでがチュートリアル

181:デフォルトの名無しさん
21/04/19 19:59:51.22 sjEpEGTN.net
メモリぶっ壊すのは絶望ではない、C++の日常だ

182:デフォルトの名無しさん
21/04/19 20:10:50.91 hAOdtYDs.net
>>178-179
この人たち未だにC++でnewとかdelete多用してるかそれを通過儀礼のように捉えてる人たちだよね
こえ～
よくある職

183:場の老害像そのものじゃん

184:デフォルトの名無しさん
21/04/19 20:11:49.67 sjEpEGTN.net
アマチュア君にはそう見えるんだね

185:デフォルトの名無しさん
21/04/19 20:13:49.42 cPEAzkUm.net
さすがに日常ではないかな……
構造体の初期化にmemset使うようなC言語上がりのやつはどうだか知らんけど

186:デフォルトの名無しさん
21/04/19 20:16:58.02 swd16GZO.net
毎日のようにRustスレで繰り返し同じ事をグチグチ言ってる自称C++使い達はよっぽど暇なんだなぁって思う

187:デフォルトの名無しさん
21/04/19 20:21:28.79 7a+3hK+O.net
c/c++でそんだけ壊れるならrustでもunsafe使ってぶっ壊れまくるだろ。。
エアプ丸出しすぎるわ

188:デフォルトの名無しさん
21/04/19 20:21:54.23 iY2hw6vD.net
引数チェックのないライブラリ等で引数を誤ったりすると
パッと見正しく見えるのでかなり面倒なことになる

189:デフォルトの名無しさん
21/04/19 21:31:37.98 LNECVJtJ.net
AddressSanitizerを使ったことのないものだけが石を投げよ

190:デフォルトの名無しさん
21/04/19 22:14:40.51 w0HdGBDs.net
伸びてると思ったら。次からﾜｯﾁｮｲ付けろよ。

191:デフォルトの名無しさん
21/04/20 00:56:58.25 h4Yrn7zO.net
URLﾘﾝｸ(trends.google.com)
Google Trends での Rustと他の言語とのトレンド比較。
これを見る限り、Rust言語は全く流行ってないようだ。

192:デフォルトの名無しさん
21/04/20 00:59:14.52 h4Yrn7zO.net
Python>Java>=JS>C++>>>>Rust

193:デフォルトの名無しさん
21/04/20 01:00:58.56 P7hWVPU6.net
そんな超メジャー言語と比較されるようになったのか

194:デフォルトの名無しさん
21/04/20 01:04:41.62 h4Yrn7zO.net
>>190
逆にそんなマイナーな言語なのに書籍が出たりtwitterでRustとWasmが
対になって出たりしてたのか。
Rustを試してる人は書籍や雑誌記事を書いて食っていくかか、難しくて新しい言語
を知ることで自分の社会的評価(?)を上げようとしているのか。

195:デフォルトの名無しさん
21/04/20 01:11:58.24 P7hWVPU6.net
>>191
なんかかっこいい嫌味を言いたいみたいだけど
意味不明ですべってるぞ

196:デフォルトの名無しさん
21/04/20 02:00:40.62 1YS4Hj5E.net
>>161
雑に書いたコードだって自分で言ってんだろボケが

197:デフォルトの名無しさん
21/04/20 08:34:25.33 A+mNu4wy.net
URLﾘﾝｸ(m.slashdot.org)

198:デフォルトの名無しさん
21/04/20 10:41:16.90 MbK31k7w.net
なんか無駄なところに手を出しちゃったみたいになってる若い人が発狂してんのかね。
別にrustで学んだことは無駄にはならんよ。
現場でrust強要するのはクソだが。

199:デフォルトの名無しさん
21/04/20 11:46:33.55 UmXg6L/G.net
5chに若い人なんかいないよ

200:デフォルトの名無しさん
21/04/20 19:43:34.07 jXnHABO7.net
なるほどそれで皆C++の話ばかりするのか

201:デフォルトの名無しさん
21/04/20 21:08:17.70 i+94ZV2W.net
C++もそれだけ枯れたか

202:デフォルトの名無しさん
21/04/21 11:52:12.19 /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:デフォルトの名無しさん
21/04/21 12:24:14.02 dj6DJThv.net
++うんこ華麗にスルーして、やっぱリーナス見る目有るわ神だろ

204:デフォルトの名無しさん
21/04/21 12:54:12.00 KSNXGwT5.net
別にそこまで褒めることでもないんだけどね。。
URLﾘﾝｸ(lkml.org)
の他の議論に比べて明らかに議論のレベルが低いわけで。。

205:デフォルトの名無しさん
21/04/21 13:38:37.86 T0Zi2n6U.net
>>199
なんか何言ってるのか分からない部分が有るな。

206:デフォルトの名無しさん
21/04/21 17:38:16.65 l2lL4TPp.net
js-sys見てたらJavaScript側の型の継承関係をDerefで表現しててびびった
こういうの普通なん？

207:デフォルトの名無しさん
21/04/21 17:58:04.79 tLndpRqR.net
>>201
歴史があってどう実装すべきかという指針ができあがっているCと
手探りで指針を作りつつあるRustで議論のレベルが同じにならないのは自然なのでは

208:デフォルトの名無しさん
21/04/21 18:42:16.83 KSNXGwT5.net
>>204
問題はそういう言語の問題まで行かず、カーネルが備えるべきところってな議論で止まってるって部分だけどね。
歴史という意味ではそもそもカーネルに対する歴史観が不足してる連中しかrustにはいないということになる。

209:デフォルトの名無しさん
21/04/21 22:06:45.67 2oKQsBoE.net
プロセスがスローし、誰も補足しなかった例外を
最終的に捕捉してそのプロセスを終了させるのはOS（ことによったらカーネル）の仕事である
一方、カーネルが仮に例外をスローしてしまったら誰が最終的な捕捉の任を負うのか
について今今のOS論には目下定説が無い
Linux（リーナス）は「カーネルは何があっても例外をスローすんなﾊｹﾞ、」という
古典的な立場
のやつ、

210:デフォルトの名無しさん
21/04/21 23:10:54.58 /dktUqXg.net
機械語に例外なんてねーよ
いい加減なこと言ってんじゃねーや

211:デフォルトの名無しさん
21/04/21 23:43:21.15 NQ0xHQya.net
>>206 CPUの例外と言語上の例外との区別が付いてないみたいね。

212:デフォルトの名無しさん
21/04/22 00:18:18.68 41g4gqqa.net
>>203
javascriptでメソッドとか探すときにプロトタイプを遡っていく動きがあるけど
それをRustのドット演算子（.）がメソッド使える型になるまで自動で参照解決する仕様で
模倣したんだと思う
演算子の特殊な拡張は正規表現とか構文解析のライブラリでたまに見かけるけど
どちらかと言えばトリッキーな手法

213:デフォルトの名無しさん
21/04/22 02:40:36.34 hZdbeIl+.net
panic上等のredox！
セキュリティホール開けるよりマシという理由だった。
>>203
アンチパターンだから通常のコードでは使うな。
トレイトメソッド呼べないからクソって所まではすでに
githubのissuesやrust internalsで合意が有る。
js-sysはffi（バインダ）だから仕方ない。

214:はちみつ餃子
21/04/22 02:53:02.19 3zTCC3Br.net
>>203
ガイドライン的には Deref はスマートポインタだけにしとけってことになってる。
URLﾘﾝｸ(rust-lang.github.io)

215:デフォルトの名無しさん
21/04/22 05:58:54.39 WQGVMWvQ.net
例外の最終的な捕捉をOSの仕事、と書いたのは語弊があったｽﾏﾝｶｯﾀ、
正確に言えば言語のランタイムが最終的に捕捉してプロセスを自発的に終了する
（スタックのアンワインドは言語依存性が強いのでそうなっている
しかしプロセスが自発的にexit()したら誰がそれを処理するのかというとOSやんけ；；；
カーネルの中で例外を生じられたら誰が終了を担保するのかについて
OS論的に定説が無いのは真
 >>208
いじょ

216:デフォルトの名無しさん
21/04/22 06:34:32.34 WQGVMWvQ.net
で、別の観点の話をする、
OSがpanic上等というのはそれはそれでも良いが、
とにかくスタックのアンワインド処理は言語依存性が強いので
例外が通過する関数（ゼロコストの奴も含む）の巻き戻しのためには
関数のアドレスとスタックのアンワインド方法の対応表をランタイムが把握せねばならない
というわけでカーネル内の例外を認めると、その例外を最終的に捕捉する奴より
上の関数を全部同一言語・同一コンパイラで書かねばならないという縛りが生じる
現実にはそれで問題など生じないかしらんが、とにかくレイヤー分けに縛りが生じる
Redoxの一部をC++（等）で書くことは事実上不可能に、

217:デフォルトの名無しさん
21/04/22 13:01:11.46 hZdbeIl+.net
>>212,213
なんでカーネルの話してるのに言語ランタイムとプラットフォーム依存の話してるんだ？
>>213
Linusがカーネル書くのに信用してないだけで
C++でもフリースタンディング書けるだろ。
C++のフリースタンディングは最低限の標準ライブラリは持つからrustのcoreクレートと同じ。
C++ならexception、abort,exitがある。
>>213がホストとベアメタルの区別がついてないだけじゃないか？
あと、redoxのpanicはスタックトレース吐いてx86のhltループするだけだから。
そもそもカーネルで標準のexitなんか呼ぶか。

218:デフォルトの名無しさん
21/04/22 13:21:02.53 EDkBlaoV.net
Linux界隈といえばちょうど｢マージしたパッチが研究目的にわざと脆弱性を含んだものだったことが発覚して激おこで送ってきた奴らの大学出禁にする｣みたいな面白いことが起こってる模様

219:デフォルトの名無しさん
21/04/22 13:49:41.54 I9diyMZ1.net
どうせお前らはOS書かないんだからどっちでもいいじゃん

220:デフォルトの名無しさん
21/04/22 15:39:04.46 VwSZJGdV.net
linuxの騒動の話はさすがにスレチ

221:デフォルトの名無しさん
21/04/22 21:04:10.86 ndVhN6HU.net
Cコンパイラゼミ消失問題を思い出した
URLﾘﾝｸ(twitter.com)
(deleted an unsolicited ad)

222:デフォルトの名無しさん
21/04/22 23:08:37.40 y/lG5X/l.net
研究目的だろうがそうでなかろうがわざと脆弱性を含むパッチを簡単にマージできている、という状況が問題なんであって
腹たつから大学出禁にしたった、とやったところで根本的な問題は何も解決しないんだけどlinuxのメンテナンスしてる連中とか
linusを筆頭にとか老害頭ばっかりだから自分がスッとすれはそれでいいんだろうな

223:デフォルトの名無しさん
21/04/22 23:21:38.67 5b2Tg2Qr.net
1) 善意でやってくれてる連中にケチつけんな
2) じゃあお前が根本的な解決とやらをやれ
3) もしくはその根本的な解決方法を彼らに教えてやれ

224:デフォルトの名無しさん
21/04/22 23:33:32.83 Bg0clzlT.net
しーぷらぷらあきらめてどろっぷあうとした
ちんちんぶらぶらまるはだかなひとたちが
らすとすぱぁとをきめるスレ

225:デフォルトの名無しさん
21/04/22 23:52:38.76 KHhdvM96.net
rust厨八つ当たりw

226:デフォルトの名無しさん
21/04/23 08:31:32.27 yuX3+THA.net
その脆弱性もUAFとかぬるぽデリファレンスとか未初期化領域の使用とか2重開放とか最近の言語じゃ明らかに

227:意図してやらなきゃ起きないようなもんばっかだもんなぁそりゃC/C++にしがみついてる大先輩方にとっちゃ逆鱗だわな

228:デフォルトの名無しさん
21/04/23 08:34:12.76 Lj3XxxY0.net
そんなもんunsafeしまくれば同じだろ。。
そういう問題じゃないことくらいわかるだろうに、本当の馬鹿だな。

229:デフォルトの名無しさん
21/04/23 08:36:52.46 +YpcBxgU.net
C++とlinuxの話禁止な

230:デフォルトの名無しさん
21/04/23 08:52:11.81 Lj3XxxY0.net
rustでOSかける->linus、panicある限り載せねーよ->rust信者発狂

231:デフォルトの名無しさん
21/04/23 09:00:00.40 5QBVXmI/.net
発狂？むしろ歓迎
個人で使うようなアプリは好きなだけパニくれ
使われるアプリはパニくんなカス、これ常識だろ

232:デフォルトの名無しさん
21/04/23 10:42:10.47 Lj3XxxY0.net
言語実装的にもそうなってないよねって話なんだけど、なんだか通じてなさげ。

233:デフォルトの名無しさん
21/04/23 11:59:33.30 bX8BaI1F.net
rustにもgoのマスコットキャラみたいなのいないんですか？

234:あめ
21/04/23 12:13:46.74 hS4CVJbd.net
かにさん

235:デフォルトの名無しさん
21/04/23 12:17:43.73 E6ocica9.net
>>214
>なんでカーネルの話してるのに言語ランタイムとプラットフォーム依存の話してるんだ？
カーネル内での例外を許すみたいな立場で話す人が居るから
例外メカニズムが言語ランタイムと不可分な理由は
>スタックのアンワインドは言語依存性が強いのでそうなっている (>>212
C言語みたいにそもそも例外メカニズムを持たない言語を使った場合のみ
言語ランタイムと切り離したカーネル設計ができてｽｷｰﾘ

236:デフォルトの名無しさん
21/04/23 12:23:39.46 Xbep6LJc.net
>>219
だから、脆弱性を簡単に盛り込めないように危険な団体を排除しただけだろ。
普通の対応だと思うけど？

237:デフォルトの名無しさん
21/04/23 12:31:21.77 +YpcBxgU.net
>>231
> >なんでカーネルの話してるのに言語ランタイムとプラットフォーム依存の話してるんだ？
> カーネル内での例外を許すみたいな立場で話す人が居るから
いません
この話はおわり

238:デフォルトの名無しさん
21/04/23 12:56:09.67 1/JMNo8Q.net
「注意すればC/C++でも問題ない」って意見は日本的だよな
人間はミスしないことが前提になっている
Rust Foundationのメンバーに言わせればそういう問題ではない
人間はミスするものだってなるんだろうけど

239:デフォルトの名無しさん
21/04/23 13:00:34.48 Lj3XxxY0.net
そのミスの取り除き方のアプローチの違いだっていうことにさえ気づかない馬鹿。

240:デフォルトの名無しさん
21/04/23 13:33:15.21 AZKiGQoD.net
c++でミスするような無能はrustでも使ってろと怒鳴り散らす
これが正しいアプローチ

241:デフォルトの名無しさん
21/04/23 13:43:27.45 M88Kc634.net
>>229-230
なんで蟹なんだろうな。
PythonユーザーのことPythonistaって言うみたいに
RustユーザーのことRustaceanって言うけど、
これCrustacean（甲殻類）からCを取り除いたものなんだな。

242:デフォルトの名無しさん
21/04/23 14:28:40.04 9+zMAQDa.net
エビにしろよな
カニだとRealtekと被るじゃん

243:デフォルトの名無しさん
21/04/23 14:58:40.99 ntrIv3TW.net
大半の人は、C/C++の文法がわかる程度でプログラムを書いているのが現状だろう
何がミスなのかそもそもわかっておらず、Rustを勉強している人と話も噛み合わない

244:デフォルトの名無しさん
21/04/23 15:01:12.26 Lj3XxxY0.net
c++とrustの部分入れ替えてもなんの違和感もない文章だね

245:デフォルトの名無しさん
21/04/23 15:03:21.83 ntrIv3TW.net
君にはそう見えるだろうね

246:デフォルトの名無しさん
21/04/23 15:05:01.62 Lj3XxxY0.net
君にはそう見えないんだろうね

247:デフォルトの名無しさん
21/04/23 15:05:59.83 ntrIv3TW.net
とりあえず、話が噛み合わないのはわかったでしょ

248:デフォルトの名無しさん
21/04/23 15:07:53.22 9+zMAQDa.net
C++ドロップアウターが希望を求めてやって来るスレ

249:デフォルトの名無しさん
21/04/23 15:13:29.93 ECpnCXVF.net
スレでグチグチ言うよりプログラム書いた方がよっぽど理解できるよ

250:デフォルトの名無しさん
21/04/23 15:20:14.54 ntrIv3TW.net
C/C++で穴のあるコードを書いてもしょうがないし、それも難しいんじゃないのかな
逆にC/C++の人らがRustコンパイラをすり抜けるヤバいコードを提示してくれたら、一発で口だけじゃなく出来る人だったと示せるだろうが

251:デフォルトの名無しさん
21/04/23 15:28:23.22 mq69qBnk.net
>>155
> Rustに比べたC++の良さは雑に書けるところだって気付いた
> やっぱ雑が許されない巨大プロジェクトはRustで、小規模な自分用ツールの類はC++で書いてくことになりそうだ

これが何気に的を得てるでしょ
コンパイラが安全な方に導いてくれるのはもちろん良いとして、それよりも雑に (あるいは短く親しんだ方法で) 書きたい思惑が優先されるときは C/C++ でやれば良い話で

252:デフォルトの名無しさん
21/04/23 15:38:53.83 CjhKTAAP.net
いや、Rustでラクに書けない時点で勉強が不足してる
そのことに自分で気付けるような人だけRust使えばいい
「当を得る」か「的を射る」ことが出来るような人になってほしい

253:デフォルトの名無しさん
21/04/23 15:56:22.07 mq69qBnk.net
いや、単にコード長が C/C++ の方が短く書ける可能性高いでしょ
どんなイディオムを駆使しても

254:デフォルトの名無しさん
21/04/23 15:59:55.49 mq69qBnk.net
あと近年では「的を得る」は必ずしも誤用じゃないという見方が主流でしょ

255:デフォルトの名無しさん
21/04/23 19:45:46.49 ECpnCXVF.net
Rustの方が雑に書ける局面多いと思うけどなぁ

256:デフォルトの名無しさん
21/04/23 20:51:53.23 +YpcBxgU.net
C++ vs Rustスレでも作ってそっちでやってくれマジで
不毛すぎる

257:デフォルトの名無しさん
21/04/23 21:04:58.31 g6tU54WL.net
>>249
そうだね、記述量の多い言語だと思う

258:デフォルトの名無しさん
21/04/23 22:37:03.61 E6ocica9.net
Rustのコンパイラと戦って勝ったコードは
シンプルでエレガントで簡潔なことが多い
らしい
mjk、

259:デフォルトの名無しさん
21/04/23 23:34:43.49 KS/Kkucz.net
linusはやっぱすげーな
洞察力が違うわ
もちろんその道の神的な存在とはいえ
たいして知らない言語の弱点を一瞬にして暴いて
論破できるのは凄い

260:デフォルトの名無しさん
21/04/24 01:08:35.83 h5KFlu4v.net
>>251
例えばどんなとき？

261:デフォルトの名無しさん
21/04/24 01:20:53.45 vtdgUVMq.net
どんなときもどんなときもRustがRustらしくある～ために～

262:デフォルトの名無しさん
21/04/24 08:06:24.96 nPKzA798.net
C++ vs Rust
ｽﾚﾘﾝｸ(tech板)
立てましたので以降そういうのはこっちでお願いします

263:デフォルトの名無しさん
21/04/24 08:33:43.03 AUtfiExa.net
>>258
お前ずっと一人で「他所でやれ」連呼してる奴だろ
C++との対立構造はRustにとって無視できないテーマでしょ
正直C++とどう住み分けたら良いのかわかってない奴がほとんどなんだから

264:デフォルトの名無しさん
21/04/24 08:39:09.80 /opj2hnT.net
C++とRustは対立なんてしてない
Rustが怖いC++お爺ちゃんがRustに噛みつているだけでしょ

265:デフォルトの名無しさん
21/04/24 08:48:20.99 MAG7Rri7.net
カーネルの件で完全に拗らせとるな

266:デフォルトの名無しさん
21/04/24 08:54:35.43 8O98k7om.net
> C++との対立構造はRustにとって無視できないテーマでしょ
お前のテーマなんてどうでもいいんだよ
よそでやってくれ

267:デフォルトの名無しさん
21/04/24 08:59:24.96 MAG7Rri7.net
一般的なテーマだってこともわからんのか。馬鹿だな。

268:デフォルトの名無しさん
21/04/24 09:02:59.11 CqGuC/ho.net
リナス「やっぱCが至高、C++もRustもクソ！」

269:デフォルトの名無しさん
21/04/24 09:13:04.98 IM8zU0Pj.net
rustもpanicをコアから外せればいけると思うのだが
もろ言語のコアなんだよな
痛いところ突かれた

270:デフォルトの名無しさん
21/04/24 10:06:12.73 yJd/gJxx.net
言語の問題じゃなくてライブラリの問題では

271:デフォルトの名無しさん
21/04/24 10:11:32.69 vtdgUVMq.net
へーpanicってライブラリなんだ

272:デフォルトの名無しさん
21/04/24 10:29:13.61 nPKzA798.net
>>259
仮にその対立構造を認めるにしても
「雑に書くならC++のほうが楽」なんて、曖昧で基準も何も示されない話に真面目に付き合う奴はいないよ
そういう奴らのための隔離スレとして用意したから好き放題書き散らせばいい

273:デフォルトの名無しさん
21/04/24 10:42:59.04 2MdujosH.net
コード長の話でしょ？
どー考えてもC++の方が短いよ
んなとこで張り合ってもしゃーない

274:デフォルトの名無しさん
21/04/24 11:44:33.91 8fCyRscb.net
3割ぐらいは長いな
URLﾘﾝｸ(benchmarksgame-team.pages.debian.net)
median source code gzip (July 2018)
Ruby 568
Python 672
C++ 1044
C 1115
Rust 1319

275:デフォルトの名無しさん
21/04/24 12:07:10.57 RPGHdVOi.net
>>258
乙。次からテンプレ入りで
 >>980
スレ立てよろ
==========
公式
URLﾘﾝｸ(www.rust-lang.org)
URLﾘﾝｸ(blog.rust-lang.org)
URLﾘﾝｸ(github.com)
Web上の実行環境
URLﾘﾝｸ(play.rust-lang.org)<)
※Rustを学びたい人はまず最初に公式のThe Bookを読むこと
URLﾘﾝｸ(doc.rust-lang.org)
※C++との比較は専用スレへ
C++ vs Rust
ｽﾚﾘﾝｸ(tech板)
前スレ
Rust part10
ｽﾚﾘﾝｸ(tech板)
==========

276:デフォルトの名無しさん
21/04/24 12:17:31.75 HBFF7y2e.net
Rustしかまじめに勉強したことないけどいい言語だと思うよ

277:デフォルトの名無しさん
21/04/24 12:21:15.48 8fCyRscb.net
>>272
C/C++で一度ひどい目にあわないとRustの良さは分からんよ
今はまだ分かった気になってるだけ

278:デフォルトの名無しさん
21/04/24 12:39:27.31 aNHhbYgZ.net
Rustはコンパイルでひどい目にあうから問題無い
同じことだ

279:デフォルトの名無しさん
21/04/24 12:56:02.52 1Wwd5OE1.net
Rustのコンパイラに怒られまくる奴は三流プログラマ

280:デフォルトの名無しさん
21/04/24 12:59:06.14 hc4SaSPr.net
Rustの文字列変数って、
str1 = str2;
のように書いた時、copyではなくmoveでしたっけ？

281:デフォルトの名無しさん
21/04/24 13:03:33.00 kYV5ExS+.net
String型ならmove、&str型ならcopy
文字列リテラルなら後者

282:デフォルトの名無しさん
21/04/24 13:09:43.73 hc4SaSPr.net
>>276
調べてみたら、やっぱり、
let s1 = String::from("hello");
let s2 = s1;
とすると、以後、s1は使用できなくなり、使用しようとするとコンパイルエラー
になるんだね。こうなるのは珍しいと言えば珍しい言語。
1. Javaだと、参照を入れるだけで同じ実体を指しているため、s2経由で変更してもs1が
　指しているものも変更される。
2. JS の文字列は primitive 型なので「コピー動作」となり、s2とs1は別の実体を
　指すことになり、一方を変更しても他方には変更の影響は及ばない。
3. MFCのCStringも意味的にはコピー動作なのでJSと似ているが、高速化のため、
　代入後に一度も書き換えなければ、文字列を入れているメモリブロックは複製
　されないし、コピーもされない。
4. STL(C++) の std::striingもMFCと意味的には似た動作。
5. BASIC言語でも、文字列はコピー動作。
6. Rubyの場合、Javaと同じで同じ実体を参照しているだけなので、一方を書き換えると
　他方も全く同じように書き換わる。コピーするためには、s2 = s1.dup; と書く。
つまり、
a. BASIC、JS、MFC、STL(C++)は似た動作。
b. JavaとRubyも似た動作。
c. Rustは、b の系統に似ているが、s1 が使えなくなるのでちょっと違う。

283:デフォルトの名無しさん
21/04/24 13:13:27.35 vtdgUVMq.net
>>278
無駄なことに時間使ってないでthe bookくらい読みなよ

284:デフォルトの名無しさん
21/04/24 13:20:12.76 hc4SaSPr.net
>>
C# は、「b.」の系統で、JavaとRubyと似た動作だね。

285:デフォルトの名無しさん
21/04/24 13:23:38.54 hc4SaSPr.net
>>279
いろんな言語をかじってしまうと、どれがどれだか分からなくなってしまうんだよ。
文字列の s2 = s1 の動作は：
a. BASIC、JS、MFC、STL(C++)は似た動作。中身をコピーする。
b. Java、Ruby、C# が似た動作。参照を代入するだけ。コピーしたければ明示する。
c. Rustは、b の系統に似ているが、s1 が使えなくなる。

次ページ