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/14(金) 16:45:29.34

>>662
計算じゃなく、データベースにクエリー投げるとか普通にあるだろ。　そういう場合、
いちいち関数の引数にIPアドレスやホスト名を渡すのではなく、オブジェクトメンバ
として持たせて、計算メソッドを呼ぶって実装にするのでは？

んで、サーバー応答がない場合だけでなく、IPアドレスやホスト名をセットせずに、
計算メソッドを呼んだりしたら、例外を投げるよな？

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

>>658
> 途中で低位層の仕様が変わるとか有り得ない机上の空論に対して
> どこまで何を前提にしていいのか何もかも不明だから誰も何も答えられない

やっぱり例外のことわかってないね
自作関数hoge()がサードパーティ製ライブラリの関数foo()を呼び出しているとき、hoge()ではfoo()が送出する例外をどうするかを実装するだけでいい
その後、foo()が更新されfoo()が依存するライブラリが例えばIoErrorをthrowするようになってfoo()はそれに対して何もしないとしても、hoge()は変更する必要がないし知る必要もない

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

並行並列処理した時点で例外が破綻するのは事実だな
擬似的に例外を伝播させるにしても途中でエラー値渡しが必要
例外を使えば途中は何も考えなくていいはウソだな

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

そもそも、例えばJavaScriptでnpmパッケージを少しつかうと、数百個のnpmパッケージがインストールされて数千個のthrowが実装されてて、全貌を知るなんて無理んだんだよ
そんなこと知らなくても、JavaScriptでアプリコードは書ける

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

>>666
スレッド内では関数を多段に呼び出すことはないという主張なのかな？

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

やっぱこいつ例外のことなんもわかってねーわ

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

>>663 >>664
計算を与えるものと
サーバー情報を与えるものは
明らかに独立して扱うべきもの
内部で計算するなら前者だけで済む
なるべく依存関係を少なくモノリシックにならないように設計するのが常識

>>664
ホスト名がないとかサーバーが応答しないとか
そんな普通に起こりうることはエラーを返す

**デフォルトの名無しさん** · 2022/01/14(金) 17:02:36.16

>>665
知らなくていいメリットか知りようがないデメリットか

**デフォルトの名無しさん** · 2022/01/14(金) 17:02:40.51

>>668
並列計算スレッドの中で多段に呼ぶのはいいが何をしたいんだ？
ちゃんと頭の中が整理できていないだろw
コードを書いたことあるのかね？

**デフォルトの名無しさん** · 2022/01/14(金) 17:03:04.21

例外がわかってないっつーか
プログラミングど素人だったわw

**デフォルトの名無しさん** · 2022/01/14(金) 17:10:08.74

>>654
そうだよ
Tで返してたところをOption<T>で返すように変更が入るとかは普通にある

型で表現できることのメリットの裏返しで
型で表現してるからこそそれに依存してるところは全部変更が必要
誰か書いてたけど検査例外と同じデメリットがある

**デフォルトの名無しさん** · 2022/01/14(金) 17:13:19.40

>>665
これはRustでも同じ
hoge()ではfoo()が返すResult<T, E>のErrorだけ気にすればいいように作る
(正確にはfooを含むmod Fooが定義するErrorのうちfooが返すものだけ気にする)

**デフォルトの名無しさん** · 2022/01/14(金) 17:13:47.97

>>665
JavaScriptについてちゃんとわかっていないようだな
それらは大量にあっても自分のところに飛んで来ないthrowだ
自分のところに飛んでくるthrowはcatchしないとuncaughtExceptionで怒られる
だから下から例外が来るか否かは把握していないといけない
そもそも途中でライブラリの仕様が変わって例外を投げるようになること自体がナンセンスだが

**デフォルトの名無しさん** · 2022/01/14(金) 17:26:27.30

>>667
まずは例外の基本を理解しなさい
ライブラリ群のソースの中に何千個のthrowがあろうが各々のtry-catchで閉じ込められておりその外に対しては一切無関係
関係があるのは自分に向かって来る分のみ

**デフォルトの名無しさん** · 2022/01/14(金) 17:43:36.82

>>670
> 明らかに独立して扱うべきもの
機能が一緒なのに？
君のべき論ならそうなのかも知れないけど、それが一般的というわけではないよね

**デフォルトの名無しさん** · 2022/01/14(金) 17:45:12.30

>>672
整理できてないのはお・ま・え w

**デフォルトの名無しさん** · 2022/01/14(金) 17:48:13.03

>>674
そこは了解
まあ単純に上位に渡すだけならIDEで自動で修正とかできそう

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

>>679
じゃあ並列計算スレッドの中で多段に呼ぶ関数があるとして
どういう仕様変更をせざるをえなくなるのか具体的に答えてみよ
無いと思うけどな

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

そもそもrustで言うと Result<T, E> の E を変更するのは破壊的変更だから普通は依存crateのエラー型をそのまま外部に見せるようなことはしない

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

>>681
スレッド内ではシングルスレッドと同じだろ
スレ読み直してこい

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

>>683
で、並列計算スレッドの中で多段に呼ぶ関数があるとして
具体的にどういう仕様変更をせざるをえなくなるのか早く答えて欲しい
無いと思うけどな

**デフォルトの名無しさん** · 2022/01/14(金) 20:30:51.27

コードの修正が必要になるって話な

> 逆にRustだとなんかの理由で奥底の関数がエラーを返すように変更されたらその上の関数全てを変更するってこと？

**デフォルトの名無しさん** · 2022/01/14(金) 20:46:13.89

>>685
エラーに限らず一般的によくあることだね
返すべき値が増えたり
返すべき型が変わったり
あるいは逆に
引き渡す値が増えたり
引き渡す型が変わったり
それらは機能追加変更でも起きるけど
リファクタリングでも起きたりしてる
Rustでも他の言語でもその状況は変わらない

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

話の流れ見えてる？

> 例外なら発生と受けるところの変更だけで済むけど、Rustだと間の関数も全て変更が必要じゃね？

> 面倒というより本質的に途中の関数には関係ないはずなのに修正が必要になると言うのがちょっと嫌かな

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

>>686
それがコールツリーを遡って何層にも伝播していくのは普通にある事ではない
あるなら設計が悪い

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

どこでどういう例外が発生するか全部把握している人にとっては造作もないこと

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

>>687
Rustでも下位でエラー(例外)の種類が増えたとしたら
同じように上位の関数でそれらのエラーを処理する場合
?オペレーターで飛ばす途中の関数はそのまま変更ないよ

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

>>690
少し上のレスくらいは読んでくれ…

> 逆にRustだとなんかの理由で奥底の関数がエラーを返すように変更されたらその上の関数全てを変更するってこと？

**デフォルトの名無しさん** · 2022/01/14(金) 22:00:42.61

>?オペレーターで飛ばす途中の関数はそのまま変更ないよ

?オペレーターかどうかは関係ないやろ
いつもいつもホントいい加減な事言うよなぁ

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

>>691
その関数の元の戻り型と変更後の戻り型次第じゃないかな
元々がそのエラーと別の他のエラーを返しているか何らかの理由でResultならば
既にその関数呼び出しに?オペレーターを付けてあるので変更なし
その関数の元の戻り型が新たにResultになったのならば
その関数呼び出しに?オペレーターを付ける
それに応じて自分自身に対しても以下同様

>>692
間違ったことは言っていないつもりだが
もし何かミスがあれば指摘くれるとうれしい
もうそろそろ寝室へ移動するが

**デフォルトの名無しさん** · 2022/01/14(金) 22:28:31.33

検査例外の不便さを軽減しつつ例外が送出されることのみ型で明記する方式をとったのがSwift
RustのResultを返す方式と基本思想は同じだがエラーの型を明記しなくていいので使いやすい

**デフォルトの名無しさん** · 2022/01/14(金) 22:32:28.06

エラーの種類を型で区別するというのがそもそも無理があったんだろうな。

**デフォルトの名無しさん** · 2022/01/14(金) 22:35:46.65

>>694
エラーの型の明記自体は必要なことだから問題ないんじゃないかな
>>695
もちろんRustではdyn Errorで何でも楽する形から個別に用意して堅牢にする方法まで様々な形態を取ることができる

**デフォルトの名無しさん** · 2022/01/14(金) 22:45:19.38

>>693
> その関数呼び出しに?オペレーターを付ける
> それに応じて自分自身に対しても以下同様
だからそれが必要だろって話
てか、話がループしてるからはよ寝ろ

**デフォルトの名無しさん** · 2022/01/14(金) 22:53:53.91

>>697
型が変わるケースのみ最小限の限定した対応が必要となるのは当たり前
そんな常識を「必要だろ」とわざわざ言われても…
おやすみ

**デフォルトの名無しさん** · 2022/01/15(土) 00:46:19.46

言語が違うんだからやり方や考え方が違うというのはべつにどうでもよくて
どちらの方がバグを生みにくいのかが気になる
エラーハンドリングにまつわるバグもいろいろあるけど、例えばリカバリ可能なエラーを取り逃してプログラムがクラッシュする可能性が低いのはどっちなの？

**デフォルトの名無しさん** · 2022/01/15(土) 02:37:29.52

メモリがないとパニックしてabortってなんなの？
動作変えられないの？

**デフォルトの名無しさん** · 2022/01/15(土) 02:40:42.88

>>699
それならばRustが安全
Rustのenum Result型から正常値を取り出すには
matchやif letもしくはResult型のメソッドunwrap_*()などの
エラー値ではない時のみ正常値を取り出し使える手段を必ず経る必要がある
つまり正常値を使って処理していくコードはエラー値ではない時だけしか動作しないことが保証される

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

>>698
常識と言いながら話をループさせるのはもしかして認知症… w

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

>>701エラーケースのリカバリの話をしているんだが

**デフォルトの名無しさん** · 2022/01/15(土) 09:29:13.90

>>701
例外でも保証されるじゃん
何言ってんの

**デフォルトの名無しさん** · 2022/01/15(土) 09:44:44.45

ここはrustをよく知らない人に
rust初心者がrustをゴリ押しするスレです。

**デフォルトの名無しさん** · 2022/01/15(土) 09:46:20.74

>>699
強いて言えばRustかな

**デフォルトの名無しさん** · 2022/01/15(土) 10:05:00.72

できるだけコンパイル時にチェックしてくれるほうが良い。

**デフォルトの名無しさん** · 2022/01/15(土) 10:09:23.43

>>699
JavaやSwiftみたいに検査例外があるやつはRustと大差ないだろうね
非検査例外しかないやつだとcatch忘れるのを防げないが
あとはfinallyやdeferによるエラー時の後始末は忘れる可能性があるが、RustならRAIIに任せられる範囲内でなら忘れない

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

日本語初心者でもありそう

**デフォルトの名無しさん** · 2022/01/15(土) 10:12:01.91

>>708
C++との比較だとRAIIは同等だが検査例外がない分Rustの方が有利ということか

**デフォルトの名無しさん** · 2022/01/15(土) 11:12:22.12

>>710
そういうことやね
あとはそのメリットと
> その関数呼び出しに?オペレーターを付ける
> それに応じて自分自身に対しても以下同様
をしないといけない面倒さのトレードオフかと

**デフォルトの名無しさん** · 2022/01/15(土) 11:19:39.12

そういや、Rustの?演算子の性能コストはどうなの？

プログラマの負担を増やしても行儀正しいコードを強制しようとするRustが?演算子による明記を選んだのはなんとなくわかるけど、性能コストがどうなるかは気になるところ。
性能調査結果とかある？

**デフォルトの名無しさん** · 2022/01/15(土) 11:32:51.20

>>708
エラーハンドリング方式の違いによる有意な差なんてないよ
それ以外の要因のほうが大きすぎるから

**デフォルトの名無しさん** · 2022/01/15(土) 11:38:21.03

>>712
単に戻り値を返すだけだから
戻り値方式と例外方式の性能比較を参考にすればいい

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

setjmp/longjmp系と違ってSwiftみたいにResultに展開されるのもあるから
コードの見た目と性能は必ずしもリンクしない

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

>>712
Rustの?演算子による即returnと
C++の例外によるスタック巻き戻しの性能は同じ
どちらもRAIIだから通過する各関数の各ローカル変数に対するデストラクタが全て呼ばれる

>>715
C++の例外は上述のようにデストラクタ処理があるため単なるlongjmpとは異なる
あとヒープがメモリ解放されるためにはunique_ptrとshared_ptrを用いることが必須

**デフォルトの名無しさん** · 2022/01/15(土) 20:23:33.12

>>716
> あとヒープがメモリ解放されるためにはunique_ptrとshared_ptrを用いることが必須
必須じゃないだろ
デストラクタで解放すればいいだけ
まあちゃんとやるには色々面倒ではあるが

**デフォルトの名無しさん** · 2022/01/15(土) 20:53:33.23

>>717
もちろん自分で毎回漏れなく面倒を忘れず頑張るならばその通り
そのコストは見合わないから
単なるポインタ使用ではダメという意味でunique_ptrとshared_ptrを用いることが必須と書いた

**デフォルトの名無しさん** · 2022/01/15(土) 22:12:38.76

>>716
>Rustの?演算子による即returnと
>C++の例外によるスタック巻き戻しの性能は同じ
全然違うよ
コンパイル時の設定にもよるが
一般的には例外が投げられないケースに最適化するから
例外が投げられた時は桁違いに遅い

**デフォルトの名無しさん** · 2022/01/15(土) 22:14:04.01

>>719
桁違いは言い過ぎでは
数割とかじゃないの

**デフォルトの名無しさん** · 2022/01/15(土) 22:19:26.94

>>718
必須の意味わかる？w

**デフォルトの名無しさん** · 2022/01/15(土) 22:26:24.89

例外が投げられなくても
try/catchの記述をしただけでコストが余分にかかる

**デフォルトの名無しさん** · 2022/01/15(土) 22:41:23.56

>>719
どっちかって言うと例外にならないケースのオーバーヘッドの方が知りたい

**デフォルトの名無しさん** · 2022/01/15(土) 22:53:35.49

>>723
例外が発生するしないに関わらず
例外が発生した時のために必ず準備をしておくのでその分のオーバーヘッドがある

**デフォルトの名無しさん** · 2022/01/15(土) 23:42:43.37

>>724
あるのはわかってるよ
rustとC++のどっちがでかいかって話で

**デフォルトの名無しさん** · 2022/01/15(土) 23:50:30.00

議論を見てるとC++に落ちこぼれたヤツがRust派に立って復讐劇を繰り広げてるかのようだな

**デフォルトの名無しさん** · 2022/01/16(日) 00:12:49.41

>>722,724
そのタイプの実装は廃れて、今はコンパイル時にテーブル用意して「準備」を済ませる実装が主流だと
思ってるんだけど、その「コスト」「オーバーヘッド」って何見て言ってるの？昔の記憶？

**デフォルトの名無しさん** · 2022/01/16(日) 00:29:49.74

c++も言語仕様マウント馬鹿でクソ化した言語の一つだが、rustは確実にその跡を継いでる。

**デフォルトの名無しさん** · 2022/01/16(日) 02:06:36.28

まあRustは、ほぼC++の真似で一部を独自仕様にしてるから。
糞な部分を受け継いでる事もあるだろう。

**デフォルトの名無しさん** · 2022/01/16(日) 07:12:19.25

Firefoxの評判を見れば、Rust製アプリがどういうモノかわかる。
Google Playでコメントを見れば良い。

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

所詮LLVM言語、FirefoxのエンジンがWebkitに勝てない時点でUnixのコマンドでも書いてなさいってこった

**デフォルトの名無しさん** · 2022/01/16(日) 19:06:11.93

バグの多さでは勝っている。
ハイ論破。

**デフォルトの名無しさん** · 2022/01/16(日) 19:34:05.93

コンパイル出来た時点でバグが無いことを保証される。
したがって、落ちるのはバグでなく仕様。
いまどき落ちるブラウザなんてありえないし。

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

>>725
Rustのエラー返しのコストは
C++のエラー返しのコストと同じ
C++の例外が最もコストが高い

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

>>734 正常フローの効率を考えるとそうとも言い切れんだろう。

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

>>734
だ・か・ら
> どっちかって言うと例外にならないケースのオーバーヘッドの方が知りたい
に答えなよ

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

C++もRustやSwiftを真似する方向性なんじゃないの？
https://youtu.be/ARYP83yNAWk?t=1870

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

これは例外のほうがコストがかかる。
だからC++においても何でも例外を使うということはなく、
普通にエラーを関数の返り値として返している。

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

そういえばRustってメモリ不足補足出来なかったけど、あの時のFirefoxってメモリ不足したらどうしてたんだろ

**デフォルトの名無しさん** · 2022/01/17(月) 00:35:40.34

>>739
何を言いたいのか意味不明だが
補足が捕捉ならばメモリ確保(reserve)はエラーを返すので捕捉できる
fn main() {
let len = 1_000_000_000_000;
let mut v = Vec::<usize>::new();
if let Err(e) = v.try_reserve(len) {
println!("ERROR: {}", e);
return;
}
(0..len).for_each(|i| v.push(i));
}

**デフォルトの名無しさん** · 2022/01/17(月) 00:44:45.54

linux限定の話かもしれないけど他の言語ってcopy on writeとかoom killerとかあってもメモリ不足捕捉できる？

**デフォルトの名無しさん** · 2022/01/17(月) 01:06:34.70

>>740
これ最近出来た機能じゃない？
これがなかった頃はどうすんだろって

**デフォルトの名無しさん** · 2022/01/17(月) 01:22:04.37

>>741
oom killerはSIGKILL送られてくるから言語関係なくプロセス側でできることは何もない

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

Firefoxの惨状を見る限り、Rustは危険。

**デフォルトの名無しさん** · 2022/01/17(月) 02:12:46.28

linuxだとデフォルトでオーバーコミットされるからユーザー空間のプロセスでメモリ不足時になんかするのは難しいんじゃないの

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

>>744
なにかあったん？

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

>>744
どうしたん？
話聞くよ？

**デフォルトの名無しさん** · 2022/01/17(月) 15:45:19.32

バリバリのプログラマーとか元より
マウス操作の超上手い（自称）理系とか別に嫌いじゃないけどね

**デフォルトの名無しさん** · 2022/01/17(月) 16:14:38.28

コンパイルできた時点でバグがないことが保証されるのに、rust 本体がbugfixされるのはなぜでしょう

**デフォルトの名無しさん** · 2022/01/17(月) 17:55:53.78

>>749
キチガイアンチが「コンパイルできた時点でバグがないことが保証される」と誰もがガセとわかることを連呼する理由は
「コンパイルできた時点で様々な安全性が保証される」という現実が羨ましくて逆恨みでその事実から目を背けたいから？

**デフォルトの名無しさん** · 2022/01/17(月) 18:09:16.17

>>749
ちょっといってる意味がわかりませんねぇ
落ち着いて書込みしましょう

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

>>751
あ、俺もアンカー消す方ﾏﾁｶﾞｴﾃ、意味不明になったわw

**デフォルトの名無しさん** · 2022/01/17(月) 18:27:39.21

>>744
先週ニュースになったFirefoxの件は
QUIC利用のHTTP/3実装の問題がクラウドプロバイダー側での設定変更で発動して接続障害が起きただけ
当然プログラミング言語とは全く関係なく既に修正された

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

>>749
なぜ「コンパイルできた時点でバグがないことが保証される」と思ったのですか？

**デフォルトの名無しさん** · 2022/01/18(火) 00:02:30.21

まだまだ枯れてないので致命的バグがあるようですね
仕事じゃ使いたくない

**デフォルトの名無しさん** · 2022/01/18(火) 00:25:05.38

>>755
致命的バグとは何ですか？
C++にもRustにもそんな話は聞いたことがないのですが

**デフォルトの名無しさん** · 2022/01/18(火) 00:52:32.38

>>756
聞いたことないって、聞こうとしてないの間違いでしょ
1.52.1でも致命的バグがfixされたし

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

C++は今後も仕様拡張を続けるから枯れることはない
GCCも毎回大量のバグリストを抱えている

**デフォルトの名無しさん** · 2022/01/18(火) 02:54:11.55

Firefoxはサイトによって落ちるから見れないサイトがある。
アマゾンもどうしても見れないページがある。
不便。

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

C++とRustのプログラミング言語のスレで
なぜブラウザやサイトのページの話をする人がいるんですか？

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

>>758
君の所では仕事にRust を使えるかもしれないが、うちじゃ使えない、それだけの話
なぜなら枯れてないから

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

処理系にバグのない言語って実際あるの？

**デフォルトの名無しさん** · 2022/01/18(火) 08:20:43.00

>>762
brainf*ckとか。