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/03(月) 17:50:43.83

必須じゃないけど他の言語も知らないRust初心者が異常に増えてきているからトンチンカンな推しをするだけで
コミュニティの増加は良いことだが、初心者が書いた意味不明なコードを直すのはあんたら
Null安全系の推しをしてるのはド素人

**デフォルトの名無しさん** · 2022/01/03(月) 18:13:06.37

メモリ安全が守れればすべてが安全と謳ってる連中は原発は止めれば安心安全とほざいてた奴等と瓜二つ

**デフォルトの名無しさん** · 2022/01/03(月) 20:13:37.59

>>386
そもそもRustはメモリリークが起きないことは保証してくれない
参照カウントが循環参照にならないようにしたり、不要になった参照が残り続けたりしないようにするのはプログラマの責任
なのでプラグラム側になんらかのバグがあったのではないかと

メモリ管理周りを標準ライブラリやOSに全部任せられる普通のアプリケーションとは違って
全部自分でやらなきゃいけない自作OSだからバグなく作るのは難しいというのはあるかと思う

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

COBOLならメモリーリーク起こらないよ

**デフォルトの名無しさん** · 2022/01/03(月) 21:31:36.31

>>389
結局C++と同じで習熟甘いやつが作れば問題起きまくりなの？

**デフォルトの名無しさん** · 2022/01/03(月) 21:51:41.06

>>387
Rustを含めていまどきの言語がnull安全なのは常識
むしろC++やJavaが古すぎて様々な点で時代遅れにすぎない
もちろんRustはもっとその先へダングリングポインタ排除とGC排除を両立した点にある

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

このように攻撃性と倒錯を丸出しを両立してしまうと初心者っぽさが出てとても引っ掛かりやすい
どこで覚えたのかNull安全からダングリングポインタという関連性がない事を言い出す。
ゴミくずが降り積もっていく・・・

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

>>391
一般的にメモリ関係諸問題のうちメモリリークのみはGC利用でしか解消と判明している
しかし一方でRustではメモリリークを起こすのも意図的にしか起こせない
Rustには所有権の概念があるため特別に複数の所有権を認める特別な参照を
自分で明示的に使用した上でさらに循環参照を生じさせた時のみメモリリークが生じうる
もちろんそのような場面でも通常は弱参照を併用するためメモリリークは起きない

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

>>386
自分で独自OSのランタイムやGCを作って
その上で稼働させるアプリがリークを起こすかどうかは
アプリだけじゃなく作ったランタイムやGCのロジックに依存するよね

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

nullで落としてるようなバカがnull安全な言語使っても同じく死亡するコード作るだけにしか思えんがな。
あれで救えるコードなんてほとんどないと思うが。

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

もっとその先へ！草
上のOS記事の作者はリークというかフラグメンテーションの発生だと推測してるが絶対読んでないね。
「意図的にしか起こせない」はい嘘

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

nullで落としてるようなバカって例えばGoogleのChromeチームとかかな？
まぁ全人類バカなのでしょうがないね

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

ポインタ(参照)になぜかnull値を許してしまう欠陥言語でのみnull問題が起きる
そうでない普通の言語にとってnull安全は当たり前でありそれを意識することすらない
欠陥言語の存在に対してのみnull安全なる言葉の存在意義がある

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

>>395
そりゃランタイムやライブラリがバグってたらしゃーないわ

>>396
いや、コンパイルエラーになるからそこでちゃんと直せばいい
まあバカがコンパイルエラーを回避することが目的になって余計ひどいことになる未来もあるけどw

**デフォルトの名無しさん** · 2022/01/03(月) 23:21:21.46

null安全はマジで当たり前すぎてメリットでもなんでもないから
nullの話なんてしたくないわ

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

そもそもnullのある言語でもnull参照で死ぬなんてのは
よっぽどのクソコードでテストもしてないときだけだろ

**デフォルトの名無しさん** · 2022/01/03(月) 23:26:20.57

関数の定義からnullableが否かが分かるのがOption<T> のうれしいところと思う
加えて引数や戻り値の所有権が分かるのもRustのうれしいポイントかと

**デフォルトの名無しさん** · 2022/01/03(月) 23:28:42.03

fool proofの話をすると Option<T> でも闇雲に unwrap はできるので考えなしのプログラムだとクラッシュする点は変わらない
SEGVじゃなくpanicになるとか、落ちる可能性のある箇所が明示される点でnullよりはマシだが

**デフォルトの名無しさん** · 2022/01/03(月) 23:34:21.19

ほんま、そういうことやな
null安全で助かるケースなんてそもそもわずかしかないんだ
unwrapだとかゼロ除算だとかいろんなロジックミスで結局は落ちる

borrow checkerのおかげでデータ競合が起きない、とからへんが重要なメリットと思う

**デフォルトの名無しさん** · 2022/01/03(月) 23:35:17.83

いやいやww

**デフォルトの名無しさん** · 2022/01/04(火) 00:27:33.52

>>402
> よっぽどのクソコードでテストもしてないときだけだろ
そう言うのがボロボロ転がってますけどw

**デフォルトの名無しさん** · 2022/01/04(火) 00:32:09.36

こちらはNull安全協会です、今なら3,000円お支払い頂くとより安全になり免許証入れまでついてます。
本協会ではNullは許しませんが、DBなどの道路にNullが転がっています。
また外部値など入力が無いことを示すのはResult::Errや特異値:-1やNaNなどで表すものではありませんので
クソ設計はやめてください、Option::NoneでNullを示し、ほかの言語と同じく必ずmatchで検査してください。
unwrapもダメです。Null安全協会では皆様に頂いたご声援でド素人が語れてゴリラのマウントのように
ウッホウッホホと潤っています。またNull安全語り部Rusterの攻撃性は以上ですので近づかないでください

**デフォルトの名無しさん** · 2022/01/04(火) 10:11:55.33

C++の利点は何だろ？

**デフォルトの名無しさん** · 2022/01/04(火) 10:32:59.80

>>409
自由であること

**デフォルトの名無しさん** · 2022/01/04(火) 10:52:02.62

Rustはコーディング刑務所

**デフォルトの名無しさん** · 2022/01/04(火) 11:03:52.07

Null安全性はまともなUXを提供したい場合に生産性を改善する道具
なくても落ちることはほとんどないみたいな視点でしか捉えてないなら価値を理解してない

**デフォルトの名無しさん** · 2022/01/04(火) 12:02:58.31

誰のUXやねん
誰の生産性やねん

**デフォルトの名無しさん** · 2022/01/04(火) 13:26:40.47

>>386
GCはメモリーリークおこすし
どこで起こすかが実装によって変わる

GCはゴミなんよ

**デフォルトの名無しさん** · 2022/01/04(火) 13:32:57.78

>>409
もっとも健全なアプリを作りうること

**デフォルトの名無しさん** · 2022/01/04(火) 14:39:07.88

>>409
鼻から悪魔が出てきたりしても言語仕様を逸脱していないこと

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

Rustはコンパイルできたら問題は起きないみたいに思ってたけど違うのね
これじゃやっぱり初心者に毛が生えたようなのがゴミコード量産するのかな

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

ゴミコーダ矯正所

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

それはそう
たとえPrologを使ってもバグはなくならない

でもコンパイラのチェックでなくせる類のバグならなくしたいよね

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

コンパイルを通すために問題の発生するコードを書くとかも考えられるんじゃねーの
そっちのほうが分かりにくいような気がする

**デフォルトの名無しさん** · 2022/01/04(火) 19:35:35.54

>>417
あらゆる問題が起きないかというとそうではない(というかそんなプログラミング言語存在しないと思う)けど
大部分のコードのメモリ安全性がコンパイル時に保証されるのはかなり大きなメリットだと思う

例えばuse-after-freeやバッファオーバーフロー、データ競合なんかは問題が発生してもプログラムかその場でクラッシュするとは限らず、しばらく正しく動くように見えてしまう場合もある
この手の異常の原因特定は難しいので、rustでコンパイルエラーや実行時の問題発生時のpanicなどで即問題箇所が分かるようになっているのはかなり嬉しい

**デフォルトの名無しさん** · 2022/01/04(火) 19:41:25.66

初心者に毛の生えたようなのがゴミコード量産しないようなプログラミング言語ってそもそもどういったものなんだろうか
記述に自由度がなく誰がどう書いても同じになるような言語？

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

それpythonがうたってたきがする

**デフォルトの名無しさん** · 2022/01/04(火) 19:52:02.24

386みるとメモリリークの原因が不明っぽいんだけど
言語処理系にメモリ関連任せられるにしても結局原因不明のバグが残るんじゃ意味ないんでわ

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

>>424
OS書いてるのに言語処理系にメモリ管理任せられるわけないだろ
自作したメモリアロケータのバグとしか思えんが

**デフォルトの名無しさん** · 2022/01/04(火) 20:06:56.90

>>424
バグの数が0じゃなきゃ意味がないというのは違うのでは
100個バグがあるのと1個しかないのでは開発効率が全然違う

**デフォルトの名無しさん** · 2022/01/04(火) 20:50:34.04

>>409
C++の利点は過去資産
既にバグが枯れた過去資産を活用するのが得策
その他の点ではRustが全て完全に有利

**デフォルトの名無しさん** · 2022/01/04(火) 20:53:09.33

Google&MS「バグの70%はC/C++。Rustにする」
https://medaka.5ch.net/test/read.cgi/prog/1619943288/

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

C++でうまくかけないヤツとか構造化の仕方がヘタクソなだけだろ

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

>>424
そう思うんならそれでいいじゃない
意味ないってことで

**デフォルトの名無しさん** · 2022/01/04(火) 22:20:27.31

>>430
それでいいということを認めるなら、>>424にもちゃんと反論しろ

**デフォルトの名無しさん** · 2022/01/04(火) 22:35:39.57

>>428
で、バグが減ったか？まるで変わらんやろ。馬鹿馬鹿しい。

**デフォルトの名無しさん** · 2022/01/04(火) 22:39:34.49

C++の存在意義がゼロになったわけではない
C++で作られた過去の莫大なライブラリは今後も併用される
C++しか使えない過去のプログラマーの活用のためにC++を用いる案件もしばらくは残る

**デフォルトの名無しさん** · 2022/01/04(火) 22:40:33.65

議論したいならまず相手を選ぼうね
ルサンチさんを相手にしても理性的な議論にはならんから

**デフォルトの名無しさん** · 2022/01/04(火) 22:57:10.37

個人的には大規模なC/C++の組み込み開発で散々メモリ破壊系の不具合に泣かされてきたから組み込みでRustを使う流れがきてるのに期待してる
国産RTOSだとKMCのToppersベースのOS、SOLIDが最近Rustに対応し始めた

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

>>435
メモリ破壊ってそんな起きる？
lock,off,len,remainさえ揃ってたら破壊なんて起きなくね？

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

>>436
そんなには起きないけど1,2機種に1個ぐらいは難問と言われるような不具合があるかな？
共通してるのは再現性がとても低いかつランダムな領域のメモリを破壊する
でもいざ何週間もかけて仕込み入れて再現されて原因特定するとしょーもない不具合だったりする
それこそRustじゃコンパイル通らないような初歩的な原因だったこともある
静的解析ツールは回してるけどどうしても漏れることはある

**デフォルトの名無しさん** · 2022/01/05(水) 07:47:37.79

嘘くせえｗメモリ破壊を理由にRustに期待とか意味わからん
MMUがちゃんと設定できてないか、スタック不足でリークしてるだけとか、あるいはスレッド競合に見えるし
比べてる対象がOS前提のRustと、そんなもの無い開発を比べてないか

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

>>436
同意だな
Cなんて学習の過程でなんぼでもメモリ壊すもんだから
逆説的だけどメモリなんて壊し慣れてるんだよ
どうやって壊してるのかどうやったから壊れたのか
だからだんだん目新しい壊し方が無くなってきてスリルは無くなる

**デフォルトの名無しさん** · 2022/01/05(水) 10:11:35.03

バカだろおまえ

**デフォルトの名無しさん** · 2022/01/05(水) 12:14:32.80

このスレがム板内で一番勢いあるのが笑える
C++やRustの本スレより勢いあるやん

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

>>437
すまん、よく分からんわ…

>>439
分かる
壊し方も調査方法もパターン化してくるし、熟れてくると糞コードセンサーが働いて「この辺じゃね？」って見当つくしな
ログもコアもダンプもないなら難しいけども

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

本当に調査が難しいのは、並列処理があって競合状態が起きてるときかなあ

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

ランダムな領域のメモリを破壊が毎回起きて組み込みやってます！キリッ

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

HaskellとRustはコンパイル出来た時点でバグが無いことを保証される。

**デフォルトの名無しさん** · 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

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