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/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とか。

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

すべてのバグを仕様扱いにすればバグがなくなる

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

>>761
興味本位の質問だけど、どのC++言語仕様とコンパイラはどのバージョン使ってるの？
どれくらい古ければ枯れてると見なしてるのかが気になる

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

>>765
> どれくらい古ければ枯れてると見なしてるのかが気になる

枯れてなければ（リリース日が古くなければ）利用しないということではないよ
様々な状況を勘案して利用するものを決定する
ただし、いわゆる「メインストリーム」から外れているものについては、枯れているかどうかはかなり重要

ちなみに、うちではRHEL系のOSを使っていて、基本はそれに付属しているデフォルトバージョンを使う
今だと、gcc 8.5.0
ただし、Linuxだとサードパーティ製ライブラリ等をコードからビルドする必要がある場合があり、そのときは8よりも新しいものも使う
使えるのは、公式がリリースされているバージョン9系のパッケージと10系のパッケージ

また、プロジェクト毎にチームの合意があれば、はじめから9系あるいは10系を使うこともできる
（といっても、プロダクトコードをC++で記述するケースはかなり減ってはいる）

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

Firefoxはもちろん、LinuxやAndroid OSでもすでに採用されているのに、
いつになったらメインストリームといえるようになるの？

さすがにレガシープロジェクトの言語が置き換わるなんて無理だろうし

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

Rustのことね

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

ちなみに、Rustも全く使えないわけではなくて、許可されれば周辺ツール作成レベルなら使える場合もある
なお、RHEL 8系のRustのデフォルトパッケージのバージョンは、1.54.0まで来ている（インクリメンタルコンパイルがデフォルトで有効になったバージョン）

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

>>767
イメージでしか語れないが、Go言語レベルくらいになれば、メインとして使っても良いというところが増えると思う

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

なるほど
でも、そもそもこんな低レベル向けな言語は、ウェブ開発用の言語ほど使われないだろなあ
組み込みはそのうち使われるようになるだろうけど、
ゲーム開発とかでも使われるようになるのかな？

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

>>767
そうそう、
> Firefoxはもちろん、LinuxやAndroid OSでもすでに採用されている
ということができるのは、コンパイラのバグを見つけたら自分で修正してPR投げられるほどの優秀な人材が揃っていて、なおかつ工数を潤沢に取れるから
凡人チームがメインで採用できるようになるには、もう少し時間が必要だと思うよ

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

>>771
Goがウェブ開発用言語という認識？

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

ウェブ用言語とは思わないけど、一時期のRubyのようにウェブの用途でめっちゃ使われてると思ってる
Goが本当に得意なのは、並列処理の実装だろうけど

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

並列処理が得意なのはRustじゃないの？

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

>>774
並列処理が楽に書けるのは書けるんだけど
データ競合バグもカジュアルに入れ込んでしまう…
Rustみたいなコンパイル時のデータ競合検出はGoにこそ欲しかった

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

カジュアルなのは-raceで検知できるでしょ

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

おやおや？今度は Go vs Rustですか？

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

Goはコンパイル時にあれこれ頑張る言語ではないからこそ実現できてる使い心地もあるんじゃないかね

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

goとか例外ないゴミじゃん

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

総合すると、RustとRubyがお勧めって事かな。

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

>>780
panic/recoverが例外

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

C++は20年かかってやっと例外の実装が間違いだと認めて方向転換しようとしてる

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

>>783
何の話？
https://cpprefjp.github.io/lang/cpp17/remove_deprecated_exception_specifications.html
だとしたら、見当違い

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

>>767
"MAIN"streamなんだから、近くにデカい言語があるようじゃ無理だろ。
Perlに対してpythonくらいの関係にならないと。

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

>>777
Goの-raceは実行時の競合検出だからオーバーヘッドで重いし余分にメモリも喰うし
実際に競合する実行状況にならないとレアケースはいつまでも検出できない欠陥
つまりGoはC++と同じ状況

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

>>786
race付きでコンパイルしたものは本番で使わないよ

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

重くて本番で使わない結果
本番環境で運用中に生じる競合を検出できない

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

>>787
そりゃそうなんだけど実際検出したいバグは本番環境で長時間実行したらたまに出る、みたいなやつなので
手元でrace付けて簡単に再現するやつはそもそもそんなにデバッグにも苦労しないし、いまいち噛み合ってない感はあるなぁ

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

>>783
例外と例外指定の違いもつかないでC++批判か

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

>>776
自動でのチェックはできないかもしれないけどgoroutine間で変数を共有しないよう
注意するなら目視チェックでも十分だと思うがなぁ。

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

>>791
横からレスするけど、並列処理をガツガツ書く機会って少ないから
ちゃんとわからずに書く人多すぎんだよ・・・
やっぱRustみたいなコンパイル時に厳しくチェックしてくれる言語って重要だと思う

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

>>791
目視で99%見つけても1%残ったら落ちるからなぁ
多人数開発してて差分でレビューしてるときに全部発見できるかというと…できるか？

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

>>776のようにカジュアルに発生するってのは問題だが1%見逃すのは仕方ないんでないの？
並列処理のデータ競合バグを100%排除できる言語なんてある？

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

>>794
少なくともRustはコンパイラやunsafe絡みのバグを除けば原理的には100%なんだから、それと同じくらいまでは頑張って欲しい
せっかくgoroutineが使いやすいのに、目視レビュー頑張ってって言われるとちょっと…

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

>>784
これ読んできなよ
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p0709r4.pdf

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

例えばCでグローバル変数絡みのバグを防ぐためにグローバル変数使用禁止という規約はよくあるが
それを守るには目視チェックでも十分。そのくらいの感覚。

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

みんな理解していると思うが念のため
Rustコンパイラが100%保証するのは「データ競合(data races)」が起きないこと
だからその点ではC++やGoよりは遥かに優れている

一方でデータ競合を除く「競合状態(race conditions)」を100%検出する方法は存在しない
だからデッドロックなどはRustコンパイラでも当然ながら検出できない

もちろんデッドロックはロック順序決めで対応できるし
Rustならロック解除し忘れ防止も大丈夫といったように別の解決方法となる

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

>>796
例外じゃなくてエラーコードにしろよ派の人かと思ったよ
これね
https://cpplover.blogspot.com/2018/07/c.html

**デフォルトの名無しさん** · 2022/01/19(水) 00:23:42.92

>>796
Stroustrup の反論に遭って2年ほど塩漬け状態だねぇ。
https://github.com/cplusplus/papers/issues/310

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

>>788
テストしないのかな？
それともテストで検知できないような設計しちゃってるのかな？

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

>>799
C++の従来の例外の諸問題を解決するため
オーバーヘッドが無く決定的な例外(zero-overhead deteministic exceptions)が提案されていてそれを静的例外と呼ぶわけね
その静的例外はexpected<T,E>みたいな感じで関数の返り値として返すわけか
そのexpected<T,E>はRustのResult<T,E>とほぼ同じで別途P0323R10としてstd::expectedへ向けて進行中のようだ
従来の例外メカニズムよりも様々な面で優れているという点は共通認識なのね

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

>>802
完全移行しましょうという話ではないよ

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

>>791
いつもお前がチェックしてるの？
それともお前のチームのあいつもチェックするの？あいつに任せて大丈夫？

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

>>801
テストでカバレッジ100%とか目指しちゃってる？
テスト終わるのかな？
（真面目な話、長期運用中のレアなバグをテストで捕捉できるんなら誰も苦労しない）

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

>>805
まぁ、C0カバレッジはおろかC1カバレッジ100%にしても、競合のバグは発見できないことが多々あるんだけどね

**デフォルトの名無しさん** · 2022/01/19(水) 11:48:30.52

テストで競合のバグ網羅的に検出する方法教えてほしいわ...

**デフォルトの名無しさん** · 2022/01/19(水) 12:03:27.07

>>805
データ競合確認用のテストを書くんだぞ
カバレッジ上げて検出できるようお祈りしてるだけじゃそりゃ無理よ

**デフォルトの名無しさん** · 2022/01/19(水) 13:00:05.26

競合のバグってどんなバグ？

**デフォルトの名無しさん** · 2022/01/19(水) 13:29:00.39

>>808
え？データ競合を網羅的にチェックできるテスト手法があるの？
こんなとこに書いてる場合じゃなくて、学会発表とか特許出願したほうがいいんじゃない？

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

・複数人で開発している
・その中にど素人が紛れている
・誰でもアクセスできる場所にデータが置かれている

というときにど素人がデータ競合をやらかす可能性があるが、それ以外は設計で防げる気がするがどうか

**デフォルトの名無しさん** · 2022/01/19(水) 14:37:52.59

>>810
網羅的なんて書いてないだろ
お前は網羅的にできないから全くやらないのか？

**デフォルトの名無しさん** · 2022/01/19(水) 14:44:54.08

結局の所、高頻度・ロングランテストするくらいしか検出方法ないんですかね

**デフォルトの名無しさん** · 2022/01/19(水) 14:59:15.19

ロングランテストwww
何の関係があるんだよw
いつもの知ったかさんでしょコレ

**デフォルトの名無しさん** · 2022/01/19(水) 15:00:04.95

設計自体のバグもあり得るしねえ
形式手法を使うくらいか？

**デフォルトの名無しさん** · 2022/01/19(水) 15:26:10.86

>>814
通常のテストで検知が難しいバグを見つける手段として、高負荷・高頻度・長時間（の組み合わせ）のテストをするのは常識
もちろん、それで問題が発生しなかったからといって、バグがないことが証明されたわけではないけどね

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

>>792
意地悪なこと言ってスマンけど
「ガツガツ書く」「少ない」
「ちゃんとわからず」「多すぎ」
夢見がちで可愛い表現だなｗ
井戸の中のカエルが反り返って演説してる気迫を感じる

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

哲学知らぬ者、バグを知らず

**デフォルトの名無しさん** · 2022/01/19(水) 17:49:18.38

食事する哲学者問題？

**デフォルトの名無しさん** · 2022/01/19(水) 17:57:12.48

結局のところ未熟者が書いたコードは当てにならないと言うのがすべて

**デフォルトの名無しさん** · 2022/01/19(水) 17:58:56.29

未熟者に限らず自分自身含む人が書いたコードはまず疑った方が良い

**デフォルトの名無しさん** · 2022/01/19(水) 18:28:03.14

ロングランテストの所有権を複製して仲介イテレータで処理すれば算数は100点！！

**デフォルトの名無しさん** · 2022/01/19(水) 18:33:19.44

最近Rustが楽しくなってきた

**デフォルトの名無しさん** · 2022/01/19(水) 18:45:27.74

RustはFirefoxがまともに動くようになってからでイイわ。
本家すら使いこなせてないのに俺ら雑魚にはまだ無理だわ。

**デフォルトの名無しさん** · 2022/01/19(水) 18:54:05.02

GoとRustはやっといた方が良い予感がする

**デフォルトの名無しさん** · 2022/01/19(水) 21:11:11.24

>>824
ブラウザがこのスレにどういう関係が？？

**デフォルトの名無しさん** · 2022/01/19(水) 21:51:11.75

>>811
並行性テストすら知らないど素人さんが言うと説得力あるね～

**デフォルトの名無しさん** · 2022/01/19(水) 22:55:16.29

今はRustで書けばコンパイラがデータ競合も指摘してくれるので大丈夫
C++は既存システムのメンテ用

**デフォルトの名無しさん** · 2022/01/19(水) 23:24:32.20

データ競合起こすようなコードしか書けない奴はプログラマに向いてないわ

**デフォルトの名無しさん** · 2022/01/19(水) 23:52:50.70

ベテランでもデータ競合やメモリ安全のうっかりミスがあることは何度も示されている
それらをコンパイラでチェックできる高機能なプログラミング言語が登場したのだから
高機能な新しいものに付いて来れないプログラマこそ向いていない

**デフォルトの名無しさん** · 2022/01/20(木) 00:39:05.76

必死で宣伝するほどのものでもないのでは？

**デフォルトの名無しさん** · 2022/01/20(木) 00:48:04.28

Cで書かれているLinux OSが
あれほどC++は無意味な言語と採用を拒否し続けてきたにも関わらず
Rustを一部採用し始めたのが典型的ですね

**デフォルトの名無しさん** · 2022/01/20(木) 00:48:26.56

以前のHaskellのような勢いがあるけど、まったく使われないのもHaskellと同じでは？

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

うっかりミスで競合バグやメモリ破壊が起きるとは思えんな
データ構造やテーブルの設計ができない、メモリ安全な書き方知らないってスキルや知識、経験の問題だろうよ

マルチスレッドの使いどころを知らないやつ、知ったか、コミュ障あたりがプロジェクトに混じると起きる
そういった猿を炙り出せるrustはパラドックスを抱えてる気もするが俺は好意的

**デフォルトの名無しさん** · 2022/01/20(木) 01:25:44.62

>>830
お前あんの？
俺一回もないけど
どんだけひどいコードかいてんだよw

**デフォルトの名無しさん** · 2022/01/20(木) 01:26:44.10

あとメモリ安全の話してないしw

**デフォルトの名無しさん** · 2022/01/20(木) 01:27:16.51

俺もそうだったが、初めてマルチタスクOSでプログラミングし始めた頃に
興味を持ちやすいのが、マルチスレッドや、メッセージパッシング、
同期、非同期、排他処理など。
そして、実際にプログラム経験を積むにつれ、そういったものは、そんなに
使用しなくてもほとんどのプログラムには関係無いことが分かってくる。
というのは、シングルスレッドでも処理速度が足りる場合が多いからだ。
また、ブラウザ以外では async, awaitなどを使う理由は皆無である
ことも分かってくる。複雑になるだけで速度も上がらないから。
ほぼブラウザ上アプリ専用だと考えて良いだろう。

**デフォルトの名無しさん** · 2022/01/20(木) 01:29:39.27

>>837
なぜブラウザだけ？

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

>>837
ウェブ周りは間違った設計が堂々としてて凄い貫禄と思う。
無印ペンティアム辺りの時代を未だに引きずっているのかも。

**デフォルトの名無しさん** · 2022/01/20(木) 01:31:27.85

>>838
貫禄が在りすぎて我々にはどうしようもない。

**デフォルトの名無しさん** · 2022/01/20(木) 01:52:40.04

>>837
色々とおかしいぜ
まずシングルスレッドでも可能な並行処理とマルチスレッドとなる並列処理の違いがわかっていない？
さらに非同期処理と並行並列処理の違いも分かっていない？

まずシングルスレッド内でもマルチタスクで並行処理はするしasync/awaitは用いる
ブラウザ上での各ページのJavaScriptもシングルスレッドで動いていてasync/awaitが使われる
非同期であればasync/awaitは使われるのだからマルチスレッドである必要はない

さらにasync/awaitを使おうと使わまいと非同期処理は必須
ネット通信にしてもI/O読み書きにしても同期かつ並行並列もなく待ちぼうけプログラミングでもしているのかね？