Rust part10

**デフォルトの名無しさん** · 2021/04/02(金) 21:38:04.11

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/

**デフォルトの名無しさん** · 2021/05/02(日) 14:35:17.11

>>392
Javaの知識があれば
　trait object： interfaceとして渡されたオブジェクト
という感じで説明できるけど何か使い慣れた言語はあるかね

**デフォルトの名無しさん** · 2021/05/02(日) 15:05:16.82

>>393
もしかしてExistential Container(和訳不明)が独立のオブジェクトとして括り出さている感じですか？
なおC#が一番使い慣れているのですが、この範囲ではJavaと大きく違わなさそうでしょうか・・・・

**デフォルトの名無しさん** · 2021/05/02(日) 15:36:14.52

>>392
The Bookの該当箇所を読むのを勧める
Java/C#のインターフェースと基本的には同じだけど違う部分もある
https://doc.rust-lang.org/book/ch17-02-trait-objects.html

その少し後に出てくるBoxのコードに出てくる
`animals: Vec<Box<dyn NoiseMaker>>`の
Box<dyn NoiseMaker>がTrait Object

Trait Objectは動的サイズの型なので&NoiseMakerやBox<dyn NoiseMaker>のようにポインタの形になる
そのチュートリアルは前後のページとどう関係があるのかについて説明がほぼないのでわかりにくいかもね

**はちみつ餃子** ◆8X2XSCHEME · 2021/05/02(日) 15:50:22.98

他の言語の概念と対応付けるよりはそれ自体として理解したほうがいいのは確かだと思う。
(理解できずに行き詰まるくらいなら雑な理解でも一旦前に進んだほうがいいかもしれんけど。)

言語機能ってひとつだけを取り出して使えるものじゃなくて、他の言語機能との連携の中で活きてくるものだから
個別の言語機能を他言語の言語機能と対応付けて理解しても綺麗に繋がらない感じがする。

**デフォルトの名無しさん** · 2021/05/02(日) 15:58:09.22

https://doc.rust-lang.org/reference/types/trait-object.html

こっちじゃ`dyn Trait`のことをtrait objectと呼んでいるようだけど
というか俺はこれだと思ってた
Traitを実装する具体型の値のアドレスと、その型に対するTrait実装のvtableの組

**デフォルトの名無しさん** · 2021/05/02(日) 16:04:49.31

>>394
C#はあまり詳しくないけど、例えばListのAddRange関数の引数の(IEnumerable collection)が近いかな
AddRangeにはIEnumerableを実装してればどんな型でも渡せるはず（ArrayList、HashSet, etc）

これをAddRangeの視点で見ると、渡されたcollectionが実際に何の型かは分からないけど
IEnumerable（interface≒trait）を実装してることは分かってるから
そのGetEnumeratorを呼んでIEnumeratorを受け取ってそこから取り出せる要素を全部追加すれば
目的の動作は果たせることになる

このAddRangeの引数のcollectionがIEnumerableトレイトを実装したtrait objectって感じ

**デフォルトの名無しさん** · 2021/05/02(日) 17:25:27.83

>>397
正確に言うとリファレンスに書いてる通りdyn Trait型のオブジェクトがTrait Object
&dyn TraitやBox<dyn Trait>はTrait Objectを指してるfat pointer

でも実用上は&dyn TraitやBox<dyn Trait>のfat pointerのこと自体を
Trait Objectというものとして理解したほうがわかりやすいので
The Bookや他の解説書でも区別してないのが多い

**デフォルトの名無しさん** · 2021/05/03(月) 09:09:00.34

>>76
Visual Rust#やろ

**デフォルトの名無しさん** · 2021/05/03(月) 11:04:52.91

https://marketplace.visualstudio.com/items?itemName=vosen.VisualRust

**デフォルトの名無しさん** · 2021/05/03(月) 15:28:19.67

囲い込んでブラックボックス強要するあたりはMSと相性いいかもな

**デフォルトの名無しさん** · 2021/05/04(火) 15:41:01.40

facebookも財団に参加したのか
appleも時間の問題かな

intelとかのCPUメーカーにも参加して欲しい所だが

**デフォルトの名無しさん** · 2021/05/04(火) 17:15:37.01

CPUメーカーが参加するとどういうことが嬉しいの？
LLVMなら分かるんだけど

**デフォルトの名無しさん** · 2021/05/04(火) 20:03:06.80

まあ元intelのエンジニアも開発に参加しとるけどね

**デフォルトの名無しさん** · 2021/05/04(火) 20:33:44.63

え？脆弱で有名なあのインテル？
ヤバいじゃないですかぁ

**デフォルトの名無しさん** · 2021/05/04(火) 21:04:23.81

rustが低レイヤーの開発言語としては覇権取りそうね
今から勉強しとくのが良さそう

**デフォルトの名無しさん** · 2021/05/04(火) 22:09:05.61

低レイヤーの仕事をしたことないってのがよくわかるわ。

**デフォルトの名無しさん** · 2021/05/05(水) 00:03:56.29

>>405
エンジニア個々人が参加するのは普通にあると思うんだけど
企業として支援することにどんなうまみがあるのかなと思って

ただ改めて思うとintelもソフトウェアたくさん出しててrust使う旨みはあるから支援する意味はありそうだね

**デフォルトの名無しさん** · 2021/05/05(水) 01:46:02.42

SHやArmのRustコンパイラをメーカーが出たらｶﾞﾁ

**はちみつ餃子** ◆8X2XSCHEME · 2021/05/05(水) 03:09:13.31

うまみっていうか、それが上手くいくかどうかなんて事前にはわからん。
ほどほどに有用そうなものに支援してたらどれかひとつくらいはいい感じって程度の話だろ。

**デフォルトの名無しさん** · 2021/05/05(水) 05:31:11.89

協力し合うと同時にあまり勝手しないように牽制するのも目的なので

**デフォルトの名無しさん** · 2021/05/05(水) 12:35:13.44

どうも頭の悪い輩が多いなと思ってたけど、
この言語、ある程度まではスクリプト的に書けるからなんだな。。
なんとなくおかしなこと言ってる奴の感覚がわかってきたわ。

**デフォルトの名無しさん** · 2021/05/05(水) 13:37:38.31

>>413
> この言語、ある程度まではスクリプト的に書けるからなんだな。。
短く簡単に書けるようにするのはRustの課題の一つだと思ってるので、どういう観点から「スクリプト的に書ける」とおっしゃるのか伺いたいです
よく比較に上がるC++よりはよっぽど記述量多くなるよね？

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

そりゃautoなんかを使いまくった最近のスクリプト厨のc++ならそうだろうけれど、
普通に仕事で読むc++コードはそういう感じではないからね。
てかc++と一口に言っても年代で全く別言語だわ。
そういうスクリプト的な書き方をした場合、rustのがc++より快適に感じるのはまあわかるよ。
問題もrustのが少なく感じる。そういう書き方だけしてる場合はね。

**デフォルトの名無しさん** · 2021/05/05(水) 14:59:14.54

炎上学習法かってくらい何も理解してない感じでワロス

**デフォルトの名無しさん** · 2021/05/05(水) 15:13:12.13

autoと動的型付けの区別が付いていない...?

**デフォルトの名無しさん** · 2021/05/05(水) 15:19:43.76

型再構築なんてむしろ厳格に型付けされた言語から生まれたんだが

**デフォルトの名無しさん** · 2021/05/05(水) 15:21:51.15

C#でvarキーワードが導入された時も
基本型の変数にvar使うのやめましょうみたいな規約を
意味不明な根拠で良い規約と信じて導入しようとする
おかしな人達がそこら中に居た
後にEffective C#かそこらの書籍で
ローカル変数はvar使えと明確に書かれるようになって
老害ザマァと思ったものだ

**デフォルトの名無しさん** · 2021/05/05(水) 15:46:10.02

正義が世俗の愚劣さに屈した

**はちみつ餃子** ◆8X2XSCHEME · 2021/05/05(水) 15:47:19.58

ローカル変数の場合は型がすぐ隣に書いてあるような状況だろうからな。

**デフォルトの名無しさん** · 2021/05/05(水) 16:17:27.41

ほらね。
好き勝手な自分流でコード書いてるだけで人のコードを読んでないのが丸わかりなコメントしてても
全く気づかないバカしかいない。

**デフォルトの名無しさん** · 2021/05/05(水) 16:25:26.72

>>421
ようするに型情報を二重に書いてるようなものだよな
情報の多重化であり
小さなDRY原則違反
こんな簡単な理屈を理解出来ない奴が不思議

**デフォルトの名無しさん** · 2021/05/05(水) 16:30:24.49

書かれておらずメソッドで戻り値を取得するような場合
C#もJavaも型で呼び出し先が変わる仕組みなので
意図せずに処理の流れまで変わってしまう

**デフォルトの名無しさん** · 2021/05/05(水) 16:44:03.35

>>424
お前は日本語勉強しろよ
普通に読解不能なんだよ

必要な所には型を書く
当たり前
不要な所に書いてると
「何故書いてるのだろうか？
何か理由を見落としてるだろうか？」
と注意深いプログラマを考えさせるのでエネルギーの無駄

◆QZaw55cn4c · 2021/05/05(水) 16:50:12.99

>>416
＞炎上学習法

懐かしい言葉ですね‥‥

**デフォルトの名無しさん** · 2021/05/05(水) 16:59:13.24

>>425
varにするようになったら全部varにするだろ？

**デフォルトの名無しさん** · 2021/05/05(水) 17:40:56.63

>>416
相手してるお前も同罪やぞ
すぐ見分けつくだろ

**デフォルトの名無しさん** · 2021/05/05(水) 18:09:53.05

VSCode + rust-analyzer だとletやメソッドチェーンのところに型が表示されるし
今時の開発環境使っていればローカル変数の型がぱっと見で分からなくて苦労することは少ないのでは

**デフォルトの名無しさん** · 2021/05/05(水) 18:14:24.50

>>427
何を言っとるんだお前は？
右辺値と同じ型で「困る」時は型を書くに決まってるだろ
下手するとvarの仕様も理解せずに混乱した事を書いてんじゃないだろうな

**デフォルトの名無しさん** · 2021/05/05(水) 18:51:20.46

ゲェーQZ居着いてんのかよこのスレ
バカなくせに出しゃばりでウザいからC++スレから出てくんなよ

**デフォルトの名無しさん** · 2021/05/05(水) 19:01:51.22

>>430
後から右辺値の型が変わったら気が付かないうちに影響が波及するじゃん

**デフォルトの名無しさん** · 2021/05/05(水) 19:41:05.57

var xの型が何であるかはxの初期化のときただ一度きりの右辺の型で決まるんｼﾞｬﾈｰﾉ
だとしたら後から右辺値の型が変わることに関して
varの導入で傷口が広がったことにはならない

**デフォルトの名無しさん** · 2021/05/05(水) 19:44:32.97

二回目以降の右辺値はxに対する代入でしかありえない
それらはxに対して（暗黙の型変換等を経て）代入可能ならコンパイルが通るし、
代入不可能ならエラーになる。
xの初期化時にvarを使おうが使うまいが（明示的に型を書こうが）変わらない話

**デフォルトの名無しさん** · 2021/05/05(水) 20:38:12.35

せめてletの話をしろよ

**デフォルトの名無しさん** · 2021/05/05(水) 20:48:36.67

RustのletはJS由来？　それともHaskell？

**デフォルトの名無しさん** · 2021/05/05(水) 21:09:59.09

JavaScriptにもletあるけど語源調べたら普通に英単語のletで短縮形ってわけじゃないらしい

**デフォルトの名無しさん** · 2021/05/05(水) 21:24:20.68

BASICの時代からletはあったけどな

**デフォルトの名無しさん** · 2021/05/05(水) 21:31:43.51

letはlisp系から始まったイメージ。

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

RustのletはML系由来だろ

**デフォルトの名無しさん** · 2021/05/05(水) 22:44:48.04

最初のrustcはocamlで書かれてたくらいだしML系の影響は色濃そう

◆QZaw55cn4c · 2021/05/05(水) 22:49:49.94

>>431
https://mevius.5ch.net/test/read.cgi/tech/1610096040/839

**デフォルトの名無しさん** · 2021/05/06(木) 01:02:12.67

let mut にするか var にするかの決定で、
目立たないけどRustに貢献した人という記事が最近書かれたので貼っとく
https://brson.github.io/2021/05/02/rusts-most-unrecognized-contributor

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

>>443
3行でまとめて

**デフォルトの名無しさん** · 2021/05/06(木) 01:35:02.38

デイブ・ハーマン（Dave Herman）というECMAScript委員会のMozillaの代表者の人がいました。
リポジトリ上のコミットログでは目立ちませんが、彼の好みがRustチームの好みを作り、チームの組織と維持に重要な役割を果たしていました。
彼はチームの決定をほとんど穏やかに受け入れていましたが、let mut と var のどちらにするかについては var を使うというチームの決定に同意しませんでした。

**デフォルトの名無しさん** · 2021/05/06(木) 01:36:11.91

>>421
でも、
BYTE c = 'a';
と
let c = 'a';
では間違い易さが違う。後者は、int か BYTE か SBYTE か分からない。

**デフォルトの名無しさん** · 2021/05/06(木) 01:37:37.69

Rustだと、明示するには、
let c:i8 = 'a';
とキータイプが多くなってしまうな。

**デフォルトの名無しさん** · 2021/05/06(木) 01:40:47.77

例えばの話、演算子も優先順位が決まっているので、
if ( (a >= 5 && a <= 10) || (b>=10 && b <=20) ) {・・・}
見たいな条件も、優先順位の括弧を省略できるかも知れないが、勘違いや
記憶違いを防ぐために書いた方がいいと言われている。
int c = 'a';
char c ='a';
auto c = 'a';
ではやはり、autoはバグの原因になりそう。

**デフォルトの名無しさん** · 2021/05/06(木) 01:47:50.96

それと、型を明示した方が後から見たときにプログラマの脳内の想定もわかり易い。
float a = 1.0f;
float b = a + 5.0f;
みたいなものも、もし、
auto a = 1.0f;
auto b = a + 5.0f;
と書くと b は、double 型になってしまうかもしれないが、テストしても
間違いに気づかず、僅かに速度低下やメモリーを多く食ってしまう
かもしれない。また、思想にもよるが、1.0f などと書かずに
float a = 1;
float b = 5;
と書きたい人も居ると思う。これの方が、後から double 型に変えたときに
右辺を訂正する必要がないメリットもある。

**デフォルトの名無しさん** · 2021/05/06(木) 03:19:29.71

>>446
rustの文字リテラルはu8でもi8でもなくてcharな

それはそれとして型やら括弧やらを明示的に書くことは禁じられてないんだから書けばよいのでは
言語の問題というよりはコーディング規約でなんとかすべき領域かと

タイプ数が多くなるとかはデフォルトをどちらに倒すかの問題で世間の嗜好とずれてるなら多少手間がかかるのは諦めるしかない

**デフォルトの名無しさん** · 2021/05/06(木) 03:21:51.36

誤解を招きそうだから補足しておくとrustのcharはユニコードのコードポイントが格納される32bit符号なし整数型な

**デフォルトの名無しさん** · 2021/05/06(木) 06:46:11.97

>>443
こういうのいいな

**デフォルトの名無しさん** · 2021/05/06(木) 10:08:34.61

>>445
var使おうとしてたってマジかー
let (mut a, b) = get_foo_tuple();
みたいなやつとかvarじゃ困るから必然だと思ってたのに

**デフォルトの名無しさん** · 2021/05/06(木) 10:15:22.90

>>445の要約の最後たぶん間違ってる
デイブ氏はキーワードを重ねるとmutableな変数の使用を躊躇させる効果が生じて
プログラマのコーディング方式の選択を咎めることになるから反対だったらしい
チームの決定は初めからlet mutで彼は（珍しく）反対したけど最終的には受け入れた

**デフォルトの名無しさん** · 2021/05/06(木) 11:35:13.23

つまり暗黙の型変換は癌

**デフォルトの名無しさん** · 2021/05/06(木) 11:48:56.26

varでいいじゃん
あとはideが勝手に型直してくれるよ

**デフォルトの名無しさん** · 2021/05/06(木) 11:52:26.38

いないいない

**デフォルトの名無しさん** · 2021/05/06(木) 14:35:25.59

>>454
すまん、指示代名詞の指してる先を読み違えた
デイブ氏はvar押しだったんだな

**デフォルトの名無しさん** · 2021/05/06(木) 16:00:35.75

タイプ数で優劣を決めようとするアホとは次元が違うな

**デフォルトの名無しさん** · 2021/05/06(木) 16:31:20.99

タイプ数は少ない方が問答無用で良い

**デフォルトの名無しさん** · 2021/05/06(木) 17:13:47.97

fn, ret, cont, break の時代に回帰するか

**デフォルトの名無しさん** · 2021/05/06(木) 17:27:07.40

タイプ数は少ない
って基本型が少ない言語が好みなのかと思った

**デフォルトの名無しさん** · 2021/05/06(木) 19:28:16.24

<?rust
println!("hello rust!!");
?>

**デフォルトの名無しさん** · 2021/05/06(木) 21:17:13.93

>>448
型を明示したってバグるくせによく言うのぜ

**デフォルトの名無しさん** · 2021/05/06(木) 22:42:35.79

タイプ数が少ないようが絶対良いんなら
むかしGAMEとかいうすべてのキーワードが1文字の言語があったからそれでも使え

**デフォルトの名無しさん** · 2021/05/06(木) 23:22:18.38

Rust ～地図にない場所～

**デフォルトの名無しさん** · 2021/05/07(金) 03:50:05.38

>>464
型明示はバグの軽減に繋がる。
>>465
絶対的に良いわけではないが、let a:i32 = 5; と int a = 5; だと後者の方が楽。

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

>>467
intが32bitだといつから錯覚していた？

**デフォルトの名無しさん** · 2021/05/07(金) 08:21:08.42

Announcing Rust for Windows v0.9
https://blogs.windows.com/windowsdeveloper/2021/05/06/announcing-rust-for-windows-v0-9/

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

言ってる側から落とし穴に嵌っててワロタ

**デフォルトの名無しさん** · 2021/05/07(金) 10:35:21.40

let a = 5_i32;

型は右側だけで決めるのじゃ
両側で合わせるのは無駄、変更するときも面倒じゃろ

・・なに？
aがi32だと明示してバグを軽減したいじゃと？

それなら行を分けるのじゃ
１行にまとめるとせっかくの明示が埋もれてしまうからの

let a: i32; // この行の存在は大きいぞい
a = 5_i32;

**デフォルトの名無しさん** · 2021/05/07(金) 12:08:53.04

>>468
そこまでいうなら、int32 a = 5; や i32 a = 5; と書けばいい。
なお、Rustではこの書き方が出来ない。

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

>>468
ちなみに、組み込み以外のほとんどのC/C++コンパイラでは、intは32BIT型。
デスクトップマシン用のC/C++では、32BIT/64BIT のどちらでも、intは、
32BIT型のはずで、少なくとも VC++では必ず int は 32BIT。

**デフォルトの名無しさん** · 2021/05/07(金) 12:24:00.34

>>472
int32_tな

**デフォルトの名無しさん** · 2021/05/07(金) 12:51:05.27

>>474
typedef int int32;
typedef int i32;
とすればよいだけ。

**デフォルトの名無しさん** · 2021/05/07(金) 12:57:04.52

>>475
それintが32bitじゃない環境でアホみたいにミスリーディングになるけど？
いい加減スレチだし「int32_t 標準ライブラリ」でググって理解したらこの話終わりにして？

**デフォルトの名無しさん** · 2021/05/07(金) 13:31:50.44

>>476
そんな基本的なことは当たり前で、そのような環境では、
typedef __int32 int32;
typedef __int32 i32;
とする。

**デフォルトの名無しさん** · 2021/05/07(金) 13:40:18.27

どういうバグを作る可能性があるかという点が共有されてないから議論空回りしている感

**デフォルトの名無しさん** · 2021/05/07(金) 13:42:32.36

というか、int32_t という型名を考えた人が馬鹿すぎるので、長くて困るという話
だと思ったんだ。もし、int32_t が使える環境で賢く使いたい人は、
typedef int32_t int32;
typedef int32_t i32;
typedef int32_t Int32;
などとすればいいという話。
前提とする知識が低すぎる人がいるから困る。

**デフォルトの名無しさん** · 2021/05/07(金) 13:45:35.27

何を議論してるのか全然分からん

**デフォルトの名無しさん** · 2021/05/07(金) 14:02:25.02

1レス目で即NG
相手してるやつも同じカテゴリなので即NG

**はちみつ餃子** ◆8X2XSCHEME · 2021/05/07(金) 14:03:01.68

議論なんかするつもりがないんだろう。

**デフォルトの名無しさん** · 2021/05/07(金) 14:40:46.39

>>479
>というか、int32_t という型名を考えた人が馬鹿すぎるので、長くて困るという話
>だと思ったんだ。

誰がどこでそんな話をしたのか
ログ辿っても全然分からない件

ついでに言えば
グローバル名前空間の中に標準ライブラリがブチ込む型名として
_tサフィックス以外あり得んので
何も馬鹿なことなんか無い
つーか本当に誰もそんな話してないな

これ突っ込んだら
どんなガイジレスを返すのか興味津々

>>480
論点不明のドッジボールだからな
今はどこでも似たようなやり取りが見られて
5ch終わってる感がハンパない
俺は句点付きが特に頭おかしいと思うけど
レスバ相手はEQがヤバイ感じだが
句点付きはIQがヤバイ

**デフォルトの名無しさん** · 2021/05/07(金) 14:57:30.94

メジャーなGUIアプリで使われているrust製GUIライブラリってなにがありますか？
GUI使いたいんですが長いものにまかれたいので

**はちみつ餃子** ◆8X2XSCHEME · 2021/05/07(金) 15:02:55.52

>>484
プラットフォーム (OS) によって違うんじゃない？
その中ではある程度に淘汰されてると思うけど、
あらゆる環境で万能な決定版は無いと思う。

**デフォルトの名無しさん** · 2021/05/07(金) 15:53:14.60

>>483
>句点付きはIQがヤバイ
実際にIQ150越えてるので、ノーマル一般人が理解できないだけではないか。

**デフォルトの名無しさん** · 2021/05/07(金) 16:08:00.06

>>486
証拠うpしてくれ
ID付き画像とかなら最高だ
IQ150超えでもこんなガイジレスするのか
マジで興味あるわ

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

メモリ不足でカーネルパニックが起きることの問題がわからない
普通のパソコン用途に使われてたらユーザーランドのソフトがOOM Killerに殺されようがOS丸ごとクラッシュしようが作業内容が失われるのは変わらん
サーバー用途でも一部のプロセスが殺されて中途半端の状態で動き続けるよりいっその事OSまるごとクラッシュしたほうがいいと思う

**デフォルトの名無しさん** · 2021/05/07(金) 17:16:13.01

>>488
rustでLinuxのドライバー書く話？
メモリ不足時にどうハンドリングされるべきかは使い方によって違うので一律パニックするのは良くない
例えば例に挙げてるOOM Killerだってカーネルがパニックしたら実行されないわけで

**デフォルトの名無しさん** · 2021/05/07(金) 17:22:12.18

>>488
何かあった時止まればいいシステムばかりじゃないだろ
ペースメーカーとか原子炉とか
細かいことは知らんけど
昔、組み込み屋のおっさんが最初から1Mぐらい確保して
何かあったらそれを解放してどうにかするみたいなこと言ってた
知らんけど

**はちみつ餃子** ◆8X2XSCHEME · 2021/05/07(金) 18:25:34.58

>>488
システムは単独で動いているわけではない。
カーネルがパニックすることがあって良いという前提で設計して、パニックしうる前提で運用できるならそれでも構わんのだが、
Linux のカーネルでパニックを許すなら今 Linux を基礎にしているあらゆるシステムの運用体制を見直さざるを得ない。

カーネルパニックが絶対に駄目というわけじゃないんだ。
(もちろん発生しないに越したことは無いが。)
Linux では起こさないという前提に皆が従っているので変えられないという話なんだよ。

**デフォルトの名無しさん** · 2021/05/07(金) 18:53:57.67

割り込みが飛んでくる環境で例外なんか扱おうとしたら普通に死ぬだろ

**デフォルトの名無しさん** · 2021/05/07(金) 19:12:04.63

>>488
失われる作業内容の範囲があるだろ。
クライアントOSのWindowsですらBSODで切れる奴が多かったんだから、サーバーOSでそんな考えが許されるはずがない。