C vs C++ vs Rust Part.2

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

競え
※前スレ
C++ vs Rust
https://mevius.5ch.net/test/read.cgi/tech/1619219089/

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

釣り針見えてますよ

**デフォルトの名無しさん** · 2022/01/05(水) 20:15:39.00

これが釣りに見えるのか。
驚きです。

**デフォルトの名無しさん** · 2022/01/05(水) 21:37:09.44

HaskellとRustのバグはバグじゃなくて仕様と呼ぶからなｗ

**デフォルトの名無しさん** · 2022/01/05(水) 22:15:33.82

どうせバカが使ってもRc、RefCellばっかのコードで全く所有権なんて活かせないコードにしかならんよ。

**デフォルトの名無しさん** · 2022/01/06(木) 14:37:54.75

>>447
rustのコンパイラって不等号の向き間違ってますよとか教えてくれるの？

**デフォルトの名無しさん** · 2022/01/06(木) 15:02:23.63

日付比較で不等号の向きで古いファイルが消されるか新しいファイルが消されるか決まることもあるしな
ふるい分けファイルの方が日にち稼いでいるからデカいはずだと錯覚するヤツが必ずでてきてデススパイラル撒き散らしたりな

**デフォルトの名無しさん** · 2022/01/06(木) 15:03:56.77

×ふるい分け
○古い

**デフォルトの名無しさん** · 2022/01/06(木) 16:49:55.21

仲介イテレータ君かな
「バグ」という言葉すら独自解釈

**デフォルトの名無しさん** · 2022/01/06(木) 16:54:48.74

釣りじゃなくてマジだったらアカンやつだ

**デフォルトの名無しさん** · 2022/01/06(木) 18:00:28.75

でかい釣り針は不都合なものから注意をそらせるために使うもの

**デフォルトの名無しさん** · 2022/01/06(木) 21:02:54.57

>>338
リーナスが例外（パニック含む）を受け入れないから

**デフォルトの名無しさん** · 2022/01/06(木) 23:56:10.56

Rustなら例外機構がそもそも無いし
パニックを引き起こさないチェック付きの代替も揃っているからな

**デフォルトの名無しさん** · 2022/01/07(金) 00:30:02.39

SanitizerなしでCやC++書ける人にはRust不要かもね
逆に必要な人はRust使った方が幸せになりそうです

**デフォルトの名無しさん** · 2022/01/07(金) 00:44:00.42

例外機構≠パニックという主張はGoでもあるが無理がある。チェックも近代的な言語ならほぼある

**デフォルトの名無しさん** · 2022/01/07(金) 01:15:29.54

Rustは標準ライブラリの条件付きコンパイルをサポートしてるしそのうちpanic-freeな標準ライブラリも作れるようになるんじゃね。知らんけど

**デフォルトの名無しさん** · 2022/01/07(金) 01:18:46.69

Rustで特別に安全っていうのはあくまでメモリらへんの事なんだよね
ダングリングポインタ、データ競合、未初期化の変数を読んでしまう、とかみたいなのは起きない
こういうのはC/C++だと巨大プロジェクトではどうしても抜け漏れが出るし、よく脆弱性になるからこれが保証されるだけでもめちゃくちゃ心強い

そんで例外っていう危うい仕組みはなくても、他にも気をつけなきゃいけない事はいくらでもある
例えば内部部割り込み、デッドロック、競合状態、メモリリークとかはunsafe使ってなくても普通に起こるので、
プログラマがちゃんと理解して考えて制御しなければいけない

**デフォルトの名無しさん** · 2022/01/07(金) 08:07:46.87

>>445が明らかに嘘八百なのに、そのことを無視して>>447とか>>453とか言うのはさすがに無能すぎない？

**デフォルトの名無しさん** · 2022/01/07(金) 11:19:37.80

>>462
445 = 447だし、何いってるかわかんない

**デフォルトの名無しさん** · 2022/01/07(金) 11:31:20.72

>>463
「HaskellとRustはコンパイル出来た時点でバグが無いことを保証される。」
が大嘘ということ。
こんなことを言うのは無能か詐欺師。

**デフォルトの名無しさん** · 2022/01/07(金) 11:36:10.44

誰でも知ってる常識を鬼の首を取ったように言うなよ
見てるほうが恥ずかしくなる

**デフォルトの名無しさん** · 2022/01/07(金) 11:38:11.47

>例外っていう危うい仕組み
この捉え方のほうが危うい

**デフォルトの名無しさん** · 2022/01/07(金) 11:46:55.77

>>466
ここで言う例外はプログラミング言語の機能としての例外(大域脱出)のことで一般的な例外処理のことではないのでは

**デフォルトの名無しさん** · 2022/01/07(金) 12:40:14.57

>>435
組み込みでRustを使う流れがきてるのに期待してる

同意

**デフォルトの名無しさん** · 2022/01/07(金) 13:12:58.77

>>467
「一般的な例外処理」の定義をしないで語られても

**デフォルトの名無しさん** · 2022/01/07(金) 13:46:09.88

>>464
お前一人だけこのスレで浮いてるわw
黙っとけ

**デフォルトの名無しさん** · 2022/01/07(金) 13:54:43.45

再帰から一気にジャンプ出来る例外案件

**デフォルトの名無しさん** · 2022/01/07(金) 14:57:02.30

Rustの勉強も始めたが
驚き感動することが多くてはまりそうだ
try/throw/catchがないのに同じことが出来てる仕組みに感動した
?一文字でエラーを上位へ委ねることができたり
単なるenumに過ぎないはずのResult型が巧妙に使えるヤツだったり

**デフォルトの名無しさん** · 2022/01/07(金) 15:04:16.53

>>472
おまえいい加減にしろよ

**デフォルトの名無しさん** · 2022/01/07(金) 15:07:55.28

>>467
一般的な例外処理で大域脱出でないのがあればそう言えるけど、そんなのあったっけ。

**デフォルトの名無しさん** · 2022/01/07(金) 15:48:22.19

>>472
enumといっても値付きenumだからな
値付きenumとマッチング機構のせいでRustにC++が敗北したとみている

**デフォルトの名無しさん** · 2022/01/07(金) 16:14:22.26

>>469
>>474
https://ja.m.wikipedia.org/wiki/%E4%BE%8B%E5%A4%96%E5%87%A6%E7%90%86
この意味での例外
確かに言語でサポートするなら大域脱出になるか

**デフォルトの名無しさん** · 2022/01/07(金) 17:12:07.47

>>476
そのwikiの定義はめちゃくちゃ曖昧だな
回復不能なエラーのことだったり、業務エラーに対するシステムエラーのことだったり
さらには設計で想定されてない問題と言いつつ
ユーザーの入力間違いや他システムと疎通が取れない場合が含まれてたり

**デフォルトの名無しさん** · 2022/01/07(金) 17:20:41.93

>>477
なら例外（処理）の明確な定義ってなんだ？

**デフォルトの名無しさん** · 2022/01/07(金) 17:49:08.57

>>478
話の意図や文脈によっていろんな定義がありえる言葉なんだから
自分の定義を話せばいいじゃん

**デフォルトの名無しさん** · 2022/01/07(金) 17:57:58.23

>>478
まぁ、ここはプログラミング言語を取り扱っているので、各言語ごとの例外機構のことなんじゃないかな

**デフォルトの名無しさん** · 2022/01/07(金) 17:58:11.94

GoやRustなどの言語には例外処理がないと一般的に言われているけど
これはtry/throw/catchといった特別な枠組みが存在しないことを意味してる

**デフォルトの名無しさん** · 2022/01/07(金) 18:14:31.53

いやまず>>477が定義を示すべきだろｗ

> そのwikiの定義はめちゃくちゃ曖昧だな

じゃあはっきりしたやつよろしく

**デフォルトの名無しさん** · 2022/01/07(金) 18:40:25.34

結局いつもの気持ち悪い自演コース

**デフォルトの名無しさん** · 2022/01/07(金) 18:51:47.76

例外が発生しないので安全です。

**デフォルトの名無しさん** · 2022/01/07(金) 18:53:45.04

いやいや、まず>>467が示すべきだろう
示されたWikipediaは曖昧と言うより色々な例外が記載されてるから、この意味での例外と言われてもどれよ？
ってなってるんだから

**デフォルトの名無しさん** · 2022/01/07(金) 18:58:51.33

古典的言語はどれも例外が発生するので危険です。

**デフォルトの名無しさん** · 2022/01/07(金) 19:07:57.34

panicよりマシだろ。

**デフォルトの名無しさん** · 2022/01/07(金) 19:15:54.57

例外が発生しない安全な言語を使うべきです。

**デフォルトの名無しさん** · 2022/01/07(金) 19:16:41.68

例外が発生すると大変危険です。

**デフォルトの名無しさん** · 2022/01/07(金) 19:28:13.38

正確には、例外が発生する「ような」状況、な。

例外すら出さずにpanicするような言語は論外。

**デフォルトの名無しさん** · 2022/01/07(金) 19:44:23.16

元々 >>461 の言う例外とはなんのことかという話で
言語機能としての例外のことを >>461 は指しているのではないかと推測したのが >>467

461 は panic による大域脱出の発生を防げたとしても他にも気にすることがある、と言い換えても良いのかと思う

で >>466 は業務エラーに対するシステムエラーなど他の意味での "例外" (例えばカーネルにおけるメモリ獲得失敗とか) はきちんと取り扱うべきという主張だと思ったので 467 を書いた

変な理解してたらスマン

**デフォルトの名無しさん** · 2022/01/07(金) 21:01:46.84

例外安全性を静的に保証できる言語なんて無かったよな

**デフォルトの名無しさん** · 2022/01/08(土) 07:16:32.27

lowlevel、ハードウェアに近い開発者は例外を嫌う傾向にある

**デフォルトの名無しさん** · 2022/01/08(土) 08:43:00.56

スタック深階層から天元突破する不思議なマホウ
エクスセプションナムパトローナ！

**デフォルトの名無しさん** · 2022/01/08(土) 09:24:36.18

>>493
signalはよく使うがな

**デフォルトの名無しさん** · 2022/01/08(土) 12:05:39.79

try/catchの仕組みはなくても、割り込みの対応はまあどうしても必要だよな？

**デフォルトの名無しさん** · 2022/01/08(土) 13:29:15.68

組み込み用にexception handlerあるみたいよ

**デフォルトの名無しさん** · 2022/01/08(土) 13:56:43.16

言語側に求められる割り込みの対応って何
割り込みの呼び出し規約に従った関数を定義できれば良い？

**デフォルトの名無しさん** · 2022/01/08(土) 14:36:14.89

低レベルの割込み処理に言語側で出来ることはあまり無い
コンパイラ側の対応次第
組込みだとマイコンの割込みベクタテーブルに関数(いわゆる割込みハンドラ)のアドレスを設定するだけ
ハンドラ内のレジスタバンク切替えやコンテキストスイッチングなどは言語の範疇を超えるのでインラインアセンブラで記述する場合もある

**デフォルトの名無しさん** · 2022/01/08(土) 14:41:47.33

>>494
各関数呼び出し毎にRAIIによるデストラクタ処理が入る
だから例外で一気にスタックを巻き上げるだけにはならない
結局try-catch / throwという特殊な枠組みはRustのように無くしてしまえばいいのかもしれない

**デフォルトの名無しさん** · 2022/01/08(土) 15:35:19.92

>>500
>各関数呼び出し毎にRAIIによるデストラクタ処理が入る
Rustのように戻り値で返す場合も同じでは？
それにスタック巻き戻しを伴わないtry-catch/throwもあるよ

**デフォルトの名無しさん** · 2022/01/08(土) 16:01:51.30

>>500
panic&catch_unwindがあるからrustにtry-catch的な機構はあるんだけど
両者を区別する理由があるからRustにはtry-catchがないと言っている？
それとも try-catch という構文がないことだけを言っている？

>>501
try-catchでも関数からの復帰のようにデストラクタが呼ばれるという話だよ
スタック巻き戻しを伴わない try-catch って panic=abort のこと？

**デフォルトの名無しさん** · 2022/01/08(土) 17:09:19.03

従来の例外は皆がwikipediaの定義を批判しているように何でもかんでも曖昧に整理されずに詰め込みすぎている
そして各言語でのtry/catchの使われ方も同様

だからRustでは分離したのではないか？
例えば相手の状態や相手からのデータや入出力次第で起こりうる各種エラーは
こちらのプログラムに関係なく起き得ることだから普通に関数の返り値によるエラー処理でよい
一方でそれらとは全く別にプログラムが原因で起きるあってはならない論理的な間違いや
もしくはリソース不足などでの続行不可能などの事象はエラー処理ではないためパニック処理として分離した
したがって曖昧な存在である例外というものは消え去った

**デフォルトの名無しさん** · 2022/01/08(土) 18:42:49.44

なるほど
Goのpanic/recoverは例外機構なのか、っていうとそうじゃない感じするしややこしいなあ

**デフォルトの名無しさん** · 2022/01/08(土) 18:50:40.59

461 == 467 == 503

**デフォルトの名無しさん** · 2022/01/08(土) 18:52:09.09

>>503
Rustのpanic って、無かったことにできるようになったの？
Linusがpanic厳禁って言ってたよね？

**デフォルトの名無しさん** · 2022/01/08(土) 19:06:30.46

>>503
カーネルコードではallocできなくても継続不可能とはみなさないように
何を続行不可能な事象とするかはアプリケーションによって変わる
つまりその分け方は業務エラー/システムエラーや回復可能エラー/回復不能エラーなど従来の分け方と同じ

**デフォルトの名無しさん** · 2022/01/08(土) 19:52:28.22

>>505
ちがうよ

**デフォルトの名無しさん** · 2022/01/08(土) 21:04:20.72

>>506 >>507
そういうカーネルではアロケーション自体も自作だからそこでパニックを発生させずに
例えばシステムコール要求元にENOMEMなどを返すため>>503の分離ではエラー処理側に分類される

**デフォルトの名無しさん** · 2022/01/08(土) 21:50:04.90

例外が発生しなければ安全です。
したがって例外をサポートしない言語が安全です。

**デフォルトの名無しさん** · 2022/01/08(土) 21:54:31.05

>>510
なあ、例外がなければ安全だなんて言ってる無能な働き者はお前ぐらいだけど、大丈夫？

**デフォルトの名無しさん** · 2022/01/08(土) 23:09:37.91

>>509
>もしくはリソース不足などでの続行不可能などの事象はエラー処理ではないためパニック処理として分離した
>したがって曖昧な存在である例外というものは消え去った
ここで言ってるパニック処理が例外処理そのもの
例外処理用のハンドリング方法を別途用意しただけであって例外というものが消え去ったわけではない

**デフォルトの名無しさん** · 2022/01/08(土) 23:12:31.28

>>509
カーネルコードでアロケーションエラーを例外としてではなく通常のエラーとして処理するのは
アロケーション自体が自作だからではないよ

**デフォルトの名無しさん** · 2022/01/09(日) 00:21:57.46

Rust坊の植民地になった。ここまでC/C++に対する優位性の証明ゼロ、分裂したRust坊を収容するスレ
あんたらが本当に必要なのはRust初心者スレだ。親の仇のようにC/C++に攻撃性を向けるのはもうやめたら？

**デフォルトの名無しさん** · 2022/01/09(日) 03:40:09.35

トリオンが足りないのでは？

**デフォルトの名無しさん** · 2022/01/09(日) 04:14:04.91

誰もC++攻撃してないよね

**デフォルトの名無しさん** · 2022/01/09(日) 09:21:12.75

元々はRustスレに定期的に出没する「俺は天才だからC++でも安全なコードを書ける、Rustの制約はパフォーマンスの足枷」ってうるさい奴を隔離するスレだったんだよな
あいつがフェードアウトしたのに逆の意味でスレが機能し続けるのは皮肉なもんだ

**デフォルトの名無しさん** · 2022/01/09(日) 09:37:17.07

>>503
英語版wikiの定義を読むといい

例外の定義や理解1つとっても日本がIT後進国なのを痛感する

**デフォルトの名無しさん** · 2022/01/09(日) 10:02:26.10

>>518
> 日本がIT後進国なのを痛感する
例外の話だけじゃなくてこれはいろんなとこににじみ出てるよな
いろんなwikipediaの記事も日本語版って何かあいまいだったり
説明が簡潔じゃなかったりして驚く

まぁこれに関しては国のIT進歩度というよりは
あっちの人のほうが単に理論的で
理論的に書くのが好きで
理論的に書いてないのを許さない文化がるんだと思う

**デフォルトの名無しさん** · 2022/01/09(日) 10:37:31.41

>>518-519
そういう具体性の欠片もないレスでドヤ顔されても… w

**デフォルトの名無しさん** · 2022/01/09(日) 10:38:49.37

>>519
それが逆に数学分野や工業化学分野だと、日本の方がはるかに端正で正確な記述だと思っているのです…

**デフォルトの名無しさん** · 2022/01/09(日) 11:07:34.53

>>521
まぁ個人の感想なんで気にしないでねｗ
あとプログラミング言語の本も日本人が書いたものより
海外のものを翻訳したやつのほうがスッキリしてると感じる
説明も体系的というか

**デフォルトの名無しさん** · 2022/01/09(日) 11:28:40.59

www 503 == 520 == 521 www

**デフォルトの名無しさん** · 2022/01/09(日) 16:55:21.90

>海外のものを翻訳
ここは笑うところか？

**デフォルトの名無しさん** · 2022/01/09(日) 18:55:06.30

wikipediaで知識を語る超初心者がマウント取るための厨房すれ

**デフォルトの名無しさん** · 2022/01/09(日) 20:11:12.28

例外をサポートしない言語は例外が発生しないので例外安全です。

**デフォルトの名無しさん** · 2022/01/09(日) 21:06:21.23

型安全性を保証しない言語は型検査エラーを起こさないので型安全ですって言ってるようなもんやん

**デフォルトの名無しさん** · 2022/01/09(日) 22:16:01.73

例外安全てのは例外によって引き起こされる問題に対して安全かどうかなんだからその喩えは不適切

**デフォルトの名無しさん** · 2022/01/09(日) 22:29:15.26

何かを言っているようで実質内容がないw

**デフォルトの名無しさん** · 2022/01/09(日) 22:32:02.28

全てのエラーは例外が原因です。
例外サポートを無くしましょう。

**デフォルトの名無しさん** · 2022/01/09(日) 22:52:05.52

>>526
https://en.wikipedia.org/wiki/Exception_safety
> The guarantees presented here originated out of work on C++, but apply equally to other languages and error-handling mechanisms.

**デフォルトの名無しさん** · 2022/01/09(日) 23:01:24.93

Rustがtry-catchの例外機構を持たない理由は非常に単純で
(A) 本質的にリカバリできることは通常のエラー処理だけで十分に対処可
(B) 本質的にリカバリできないことはpanic
前者の(A)では関数がResult<T,E>で返しそれがエラー時Err(E)の時に
処理をスルーして上位へ移譲したいならfunc()?と?を1文字付加だけで済む仕組み

一方で(B)の「本質的にリカバリできない」panicとは具体的に次のどちらかとなる
(1) プログラムに論理的な間違いがある場合
(2) 何らかのリソース不足になった場合

この(1)は具体的に以下のようなケースがある
- ありえない状況に陥ってプログラマー自らpanicさせる場合
- 一部の標準ライブラリに対してありえない値を渡した場合
- 配列などで範囲外のインデックスで操作しようとした場合
- ResultやOptionで正常値でない時にunwrap()した場合
- RefCellやRwLockで実行時借用ルールを犯した場合
これらはプログラムに論理的な間違いがある場合のみ生じるためエラー処理とは本質的に異なる

一方で(2)の「何らかのリソース不足になった場合」は
プログラム自体には論理的なミスはないが何らかが溢れた以下のケース
- 数値型が溢れて計算を続行できない場合
- ヒープが溢れて新たにアロケーションできない場合
- スタックが溢れて新たに関数呼び出しができない場合
このうち数値溢れ演算はpanicを起さないチェック付き演算で置き換えて回避可能
アロケーションもpanicを生じさせないアロケーターを作ることで回避可能

＃ちなみに「リカバリできないことはpanic」の考えはクロージャ単位にまで拡張されていて
＃ panic::catch_unwind(クロージャ)を使うとResult<T,E>を返しpanic時にErr(E)を得られるため
＃そのクロージャ自体は内部でリカバリできないがpanic発生を捕捉すること自体は可能

このようにRustでは曖昧な存在である『例外』を廃して
通常のエラー処理と真の異常時であるpanicの二種類に分けて扱っている

**デフォルトの名無しさん** · 2022/01/09(日) 23:16:25.98

昔のテレビにはホワイトノイズあったけど、そんな感じです

**デフォルトの名無しさん** · 2022/01/09(日) 23:43:54.04

プログラムには二種類ある。
例外か例外でないか。
例外は悪。
それ以外は善。

**デフォルトの名無しさん** · 2022/01/09(日) 23:45:42.71

じゃあ配列の範囲例外が発生するプログラムは全部悪ですね、範囲外を示して書き換えられるようにしないと！
なるほどです！ためになります！

**デフォルトの名無しさん** · 2022/01/09(日) 23:50:45.64

>>535
それはプログラムがバグってるから当然悪
正しいプログラムで範囲外アクセスが生じることはない

**デフォルトの名無しさん** · 2022/01/10(月) 00:23:41.85

>>532
数値の溢れをリソース不足に分類するのは違和感あるなあ
論理的間違いに分類するのが適切では

**デフォルトの名無しさん** · 2022/01/10(月) 00:56:16.67

>>537
例えば以下のフィボナッチ数列を表示するプログラム
fn main() {
let mut m: i32 = 1;
let mut n: i32 = 1;
loop {
println!("{}", m);
let next = m + n;
m = n;
n = next;
}
}
これは45回まで正しく表示した後に46回目に数値が溢れてpanicとなる
プログラム自体に論理的な間違いがあるわけではない
ただ数値の溢れというリソース不足を起こしただけにすぎない

**デフォルトの名無しさん** · 2022/01/10(月) 01:07:09.56

配列の範囲外(Index bounds)と言っているのに、数値の溢れ(overflow)をリソース不足と言い出す
「論理的間違い」とか何を言ってるのかサッパリ分からんな、こんすれの隔離Rust超初心者たち…

**デフォルトの名無しさん** · 2022/01/10(月) 01:19:02.91

>>539
その違いは明白
配列の範囲外アクセスはプログラムが論理的にバグっている時のみ生じる
数値の溢れはプログラム自体が論理的に正しくても生じる

**デフォルトの名無しさん** · 2022/01/10(月) 01:56:06.89

数値型の範囲も論理的に考慮してくださいよ

**デフォルトの名無しさん** · 2022/01/10(月) 02:26:23.03

>>541
それは単なるリソース不足による数値の溢れだから無意味
例えば>>538のプログラムはi32型をi64型やi128型やu128型にすれば少しは延命する
例えばu128型(unsigned 128bit整数)にすれば185個の正しいフィボナッチ数列を出力できる
しかしそこまでに過ぎずこれはリソース不足の問題である
それより上はBigIntなどの数値上の上限がない型を用いることになる
するとこれもいずれ途中でメモリ不足でアロケーションできず同様にpanicするだろう
したがってこれは「プログラムの論理的な間違い」ではなく「数値の溢れというリソース不足の問題」である

**デフォルトの名無しさん** · 2022/01/10(月) 02:32:35.04

>>541
論理的に返答できる相手がどうかも論理的に考慮してくださいよ

**デフォルトの名無しさん** · 2022/01/10(月) 03:15:13.62

例外は危険なりよ。

**デフォルトの名無しさん** · 2022/01/10(月) 08:11:22.08

有限回のイテレーションしか回せないことが分かっているのに無限ループで書くのはプログラムの論理的な誤りじゃないんだ？
メモリだのファイルディスクリプタだのPIDだのの枯渇、いわゆる通常の「リソース不足」と違って、事前に発生が完全に予見できるのに？