結局C++とRustってどっちが良いの？ 2traits

**デフォルトの名無しさん** · 2023/04/02(日) 00:42:57.53

「C++の色々配慮してめんどくさい感じは好きだけど、実務になったらメモリ安全性とか考えて今後Rustに変わっていくんかな」
「うだうだ言ってないで仕事で必要なのをやればいいんだよ、趣味なら好きなのやればいい」

っていうスレ。

前スレ: 結局C++とRustってどっちが良いの？
https://mevius.5ch.net/test/read.cgi/tech/1677286186/

**デフォルトの名無しさん** · 2023/04/24(月) 00:29:33.47

速度を抜きにしてc++の利点は生ポインタを使って直感的にコードを書けたりするところにもあったと思う
それが今は捨てられたのでまあ他の言語でもいいじゃんと思う

**デフォルトの名無しさん** · 2023/04/24(月) 00:40:24.53

>>445
従来の非GC言語と比べて
Rustは以下の点でGC言語に近くなっていて書きやすいわー
・メモリや競合など色んなことをRustは安全だと保証してくれる
・メモリ解放も常に何もしなくてよくてRustは完全に自動でやってくれる
・各GC言語のモダンな機能がRustも取り入れていて便利に使える
という感じ
対象言語やコードによっては数倍Rustが速くて
エコでリソースコストも少なくて金銭的コストも数分の1になるのが魅力的

**デフォルトの名無しさん** · 2023/04/24(月) 00:40:47.69

C++にあってRustにない特徴はCを包含していること
Rust派は欠点と考えているだろうが
この特徴がなければ普及しなかっただろうね
ハゲの慧眼だよ

**デフォルトの名無しさん** · 2023/04/24(月) 01:05:01.61

>>445
そのへんC++はGC言語と比べて余分なコードレビューコストやメモリ関連のデバッグコストなどもかかっていたけど
Rustはコンパイラがやってくれるから困っていない

**デフォルトの名無しさん** · 2023/04/24(月) 04:53:42.06

個人的には、Rustは、メモリ安全であると言う以外に魅力は無いと思ってる。
しかも、Java、C#、JS、Ruby、PHP、Perl、Python、Kotlin、Go
は全てメモリー安全。

**デフォルトの名無しさん** · 2023/04/24(月) 04:56:59.60

それに、C++やCでずっとプログラミングしているが、メモリー関連バグが
生じる頻度は非常に低い。大部分はロジックのバグで、少しずつテストを
するのでその段階で取れることが多い。
メモリー関連バグが起きる場合でも、VisualStudioでは容易に原因箇所が
発見できることが多い。
特にC++では、デストラクタの中にポインタ型のメンバ変数の delete 文を
書いておけば、メモリー関連バグはまず起きない。
その意味では、C++は、それで賄えない特殊な場合を除いては、メモリー解放が
自動化されていると言える。

**デフォルトの名無しさん** · 2023/04/24(月) 05:04:26.63

メモリー関連バグは、VisualStudioではコンパイル段階での静的な発見は一般的
には出来ないが、動的には、デバッガを使うことでかなり高い確率でメモリー
関連バグの原因箇所が分かる様になっている。
昔、C言語を使っていて、メモリー関連バグで困るのは、全く原因が分からないような
ことがありえることであったが、C++では、classのデストラクタの中にdelete文を
閉じ込めることによって、メモリー解放が自動化される。
だから、メモリー関連バグが起きるのは、それでまかなえない場合に限る。
同じ関数の上の方とnew文と下の方でdelete文を単純に対応させて書けば
「どう見ても安全」のような書き方ができる。
また、それで書けない場合でも、delete文を、EndXxx()のような「終了関数」
の中だけに書く様にすれば、滅多なことでメモリー関連バグは入らない。

これでも原因不明なメモリー関連バグが起きた場合でも、VisualStudioの
場合はあの手この手で、メモリー関連バグの原因を動的検査で特定し易くなっている。

**デフォルトの名無しさん** · 2023/04/24(月) 05:06:00.35

CやC++でメモリー関連バグに悩まされている人は、gccなどのフリーのコンパイラ
を使っている人ではないかと思う。
Visual StudioのIDEとデバッガを使えば、メモリー関連バグで悩むことは滅多に
なくなる。
それと、C++の場合は、正しい流儀で書けば、そもそもメモリー関連バグが
入り込む可能性が劇的に減る。

**デフォルトの名無しさん** · 2023/04/24(月) 05:12:08.93

gccとVisual Studioのメモリー安全性に関する違いは、ヒープメモリに対しての
さまざまな工夫に有る。プログラマが明示的に初期化して無い部分には 0xcccccccc
のようなデータで初期化するコードをコンパイラが書きこむ。
それに、ヒープメモリーのリンクチェーンにも何らかの工夫がされている。
「デバッグビルド」では、そういった構造を、適切なタイミングでチェックする
コードが自動的に付加されるので、「おかしなことをやった直後に近いタイミングで」
IDEが「異常」を報告してくれる。
また、MFCの場合は、さまざまな場所にASSERT() 文で検査コードを入れてあるので、
メモリー関連バグも気付き易い。なんらかの異常は、早い段階で発覚するので、
原因がどこにあるかが特定し易くなっている。
このおかげで、多くの場合は、異常が発見された直前の処理を疑えばよくなっている。

**デフォルトの名無しさん** · 2023/04/24(月) 05:45:34.11

SNSで、「オブジェクト指向は意味が無く、むしろ駄目」というような話題が
出ることがあるが、C++のclassのデストラクタは、メモリー安全性に大きく
寄与しており、Cよりもメモリー安全になっている。
逆にclassがなければ、メモリー管理にバグが入りやすかったことであろう。
それだけでも、「オブジェクト指向」の意味がある。

**デフォルトの名無しさん** · 2023/04/24(月) 07:52:58.48

気をつければ大丈夫というのはプログラマーの考え方ではない
少なくとも向いてない

**デフォルトの名無しさん** · 2023/04/24(月) 08:08:18.28

c++erにとってRustはウザいけど、他人にライフタイム管理を強制できるというメリットが大きい。
基本的にRustは他人にやらせるための言語。

**デフォルトの名無しさん** · 2023/04/24(月) 08:23:30.04

ツールやコンパイラがいろいろやってくれる優位性を語っておいて
Rustの利点に目をむけないって意味わからんなあ

**デフォルトの名無しさん** · 2023/04/24(月) 08:50:49.89

セキュアコーディングについて、誰かがキメてくれるというのがデカい
Rustはそれをやったんだ

欲しいのはunsafeのやり方であって、それができるんならC++でもいいんだよ
そうと決まれば、処理系も実装者もどんどん追従する

だから、採用すると言い切ったんだから、APIもとっととRust化してほしい
そうしたら速攻で、unsafeがC++にも来る

**デフォルトの名無しさん** · 2023/04/24(月) 09:49:02.72

>>459
>セキュアコーディングについて、誰かがキメてくれるというのがデカい
>Rustはそれをやったんだ
まぁある方がマシだけどもrustcが検出してくれるのは一部で
>>451に指摘されてるように頻度が少ないので有用性は俺も疑問に思ってる
（率直に言ってあんまり嬉しくない）

**デフォルトの名無しさん** · 2023/04/24(月) 10:03:11.22

Rustを難しいとかウザいとか言ってる人は単にまだ慣れていなかったり知識が足りていないだけだ
C++できちんとコーディングできていた人にとってRustは難しくなく慣れと知識を獲得した後はC++よりも全体効率がアップする
したがってRustを難しいとかウザいとか言ってる人の発言は全て無視してよい

**デフォルトの名無しさん** · 2023/04/24(月) 10:18:34.43

>>461
覚えるの面倒くさいねん
将来性もまだちょっと...
だけど面白いので取り入れられるところはC++に取り入れてるよ
Arcパクらせて頂いた

**デフォルトの名無しさん** · 2023/04/24(月) 10:33:40.77

>>1 のとおり、職務とかでやれといわれたらやるんだけど、
Rust勢がいうとおり、デファクトスタンダードになりそうなら、C++にもほぼ間違いなく「来る」だろうしねえ
それなら、安全になったC++でいいや、Rustに限らず、新言語とかたりぃな、とかは思う
新言語覚えるかわりに、安全になったC++勉強しなきゃだし、と言ってもいい

**デフォルトの名無しさん** · 2023/04/24(月) 10:39:05.54

C++とRustの比較は簡単

両方使いこなせるプログラマーはどちらを選んでいるか？
・多くのことをコンパイラに任せられて開発保守効率の良いRust
・その逆でそれらの開発保守効率に劣るC++

企業はどちらを選んでいくか？
・客観的に各種の安全性が保証されるRustで書かれたコード
・その逆で各プログラマーの腕により保証されるC++で書かれたコード

プログラマーと企業どちらの視点に立っても
RustもC++も選べる環境状況にあるならば
新規のプロジェクト(案件)でC++を採用する動機は完全に無くなった

**デフォルトの名無しさん** · 2023/04/24(月) 10:47:20.17

>>464
企業の視点に立つとRustはプログラマが確保できんだろw

**デフォルトの名無しさん** · 2023/04/24(月) 10:56:55.08

dropboxは2,3年前にRust一部導入でオジにもてはやされたけど、直近はGoなんだよね
https://dropbox.tech/frontend/edison-webserver-a-faster-more-powerful-dropbox-on-the-web

**デフォルトの名無しさん** · 2023/04/24(月) 11:02:11.39

急速に解決していってるからあとわずかな時間の問題かな
C++しかできない人が既存C++コード保守に群がる構図になっていくんだろうね

**デフォルトの名無しさん** · 2023/04/24(月) 11:19:03.31

あと、C++一本でだいたいなんでも回してる俺のようなアマ
(安全になってくれたら)C++でいいやもう的な

**デフォルトの名無しさん** · 2023/04/24(月) 11:28:23.43

>>466
Dropboxの中核部分の分散同期ファイルシステムがRustで書かれていて
表層部分は別部門でTypeScriptとGoを使っている話だろ
GoはC/C++/Rustの代替になれない

**デフォルトの名無しさん** · 2023/04/24(月) 11:32:07.93

VSでメモリ安全性に関わるバグを見つけるのが簡単なら
毎月毎月クリティカルなパッチが出る訳がないわな

MSスタックで満足してるうちは井の中の蛙なんだよね
初級者でもビジュアルに分かりやすくデバッグできるように作ってるのがVSなんだから

**デフォルトの名無しさん** · 2023/04/24(月) 11:35:12.19

>>469
Dropboxの分散同期ファイルシステムってGoで書けないの? 何で?
カーネルモードで動かしてる?

**デフォルトの名無しさん** · 2023/04/24(月) 11:38:34.52

流行り廃りの激しい表層部分がUXの中核だからな

2,3年前のRust分散同期ファイルシステム
→若気の至り、もう弄らない、保守だけ

これから10年
>How Dropbox re-wrote its core web serving stack for the next decade
→Rustは不採用、Goで決定

**デフォルトの名無しさん** · 2023/04/24(月) 12:02:37.33

>>472
その表層部分はPythonで書かれていたものをGo＋TypeScriptに移行しただけでRustはもともと関係ない
サービスを支えている基盤部分がRust製に移行した

**デフォルトの名無しさん** · 2023/04/24(月) 12:10:50.29

GoのWebフレームワークのコミュニティは標準ライブラリでかけ勢がおおくて、こいつらについて行くの不安になったからRust勉強する
Rustは頑張ってフレームワーク作る気がありそう
無能に優しくしない言語は伸びないよ

**デフォルトの名無しさん** · 2023/04/24(月) 12:14:12.33

Rust信者の期待に反して、現実はこんな感じでしょう

2,3年前、インフラのごく一部でRustでも問題ない適用事例があった→今は技術的負債
当然、他の分野(webで言えばfront/back両方)ではRustは不採用
wasmとか勘違いしてごめんなさい
Pythonの置き換えはRustには無理

**デフォルトの名無しさん** · 2023/04/24(月) 12:26:21.82

C++とRustの比較スレで
新インフラ(分散同期ファイルシステ厶)構築にC++ではなくRustが採用されたDropboxの話をRustアンチが持ち出してる時点で
C++とRustの勝敗はついてしまってるなｗ

**デフォルトの名無しさん** · 2023/04/24(月) 12:28:56.90

ディフェンスラインが後退したな

**デフォルトの名無しさん** · 2023/04/24(月) 12:41:41.74

このスレ眺めていてもC++のメリットが一つも出てこないもんね
『他の言語を覚えるのは面倒、C++を使ってきたからC++だ』という理由ばかり

**デフォルトの名無しさん** · 2023/04/24(月) 12:45:26.61

C++製の既存ライブラリが100%使える

**デフォルトの名無しさん** · 2023/04/24(月) 12:48:27.02

C++はCを包含している
C++を習得すればCを別に習得する必要はない
Rustを取得してもCを別に習得する必要がある

**デフォルトの名無しさん** · 2023/04/24(月) 13:24:51.24

Rustってインラインアセンブラは使えないの？

**デフォルトの名無しさん** · 2023/04/24(月) 13:28:00.07

>>479
C製とC++製の既存ライブラリはRustでも当然使える
そして既存の枯れた安全なものを中心に実際に使われている
機能追加や更新をきっかけにライブラリの設計が変わる機会にライブラリもRust製にするエコ方式も多い

>>480
もはやCで新たに何かを書き始めることはないから枝葉は不要だがCの基幹部分は基礎知識として重要
とはいえ生ポインタとヒープ確保解放を学ぶだけで十分だから学習はすくに終わる
C++は今さら覚えても意味のあるメリットはないからこれからの人は学ぶ必要ない

>>481
RustもインラインアセンブリをRust変数を使ってRustコードの中に書ける

**デフォルトの名無しさん** · 2023/04/24(月) 13:29:40.61

gccのimplicit-constexpr凄すぎ
>no leaks, no UB
https://www.reddit.com/r/cpp/comments/12hdj3x/c20safety_static_assert_is_all_you_need_no_leaks/
https://godbolt.org/z/Ydc886bjq
最初のバージョンの実装ミスもコンパイルエラー
>didn't compile with 3 push_backs

3年ごとの進化が半端ない
>>459
逆にsafeexpr/safefuncが出来て、しかもimplicit-(un)safeでコンパイル時に自動推論してくれそう

**デフォルトの名無しさん** · 2023/04/24(月) 13:30:26.73

>>482
>C製とC++製の既存ライブラリはRustでも当然使える
C++で例外投げるやつどうするの?

**デフォルトの名無しさん** · 2023/04/24(月) 13:34:04.01

>>446
unsafe 大好き💛

**デフォルトの名無しさん** · 2023/04/24(月) 13:35:31.02

>>448
>Cを包含

完全に部分集合ではないけどなー

**デフォルトの名無しさん** · 2023/04/24(月) 13:38:41.99

>>482 C++製の既存ライブラリはRustでも当然使える
こんな嘘つく時点でry

>>486
今はC側がC++に寄せてきてる

**デフォルトの名無しさん** · 2023/04/24(月) 13:39:21.83

>>486
そんなことは分かってるよ
C++を習得すればCを別に習得する必要がないことを述べるのが主旨
些末な差異は問題ない

**デフォルトの名無しさん** · 2023/04/24(月) 13:41:37.19

ちょっと聞いてみるか
Rustではある程度書けるけどC言語では書けない人っている?

**デフォルトの名無しさん** · 2023/04/24(月) 13:41:45.01

>>457
ほんそれ

**デフォルトの名無しさん** · 2023/04/24(月) 13:42:39.88

>>458
白目はむいてる

**デフォルトの名無しさん** · 2023/04/24(月) 13:44:58.25

>>461
Rustは楽勝だ
だれも難しいとは言っていない
面倒臭いと言ってる人は多い

**デフォルトの名無しさん** · 2023/04/24(月) 13:46:10.70

>>483
C++版geigerが出来てsafeに修正していく未来案件が見えて来たw

**デフォルトの名無しさん** · 2023/04/24(月) 14:08:38.59

>>487
FFIラッパーの半自動化によりCライブラリとC++ライブラリはRustで使えるし多数使われているよ

>>484
例外を出すライブラリだけはC++側ラッパーでcatchする形で変換
各言語で例外やエラーハンドリングの仕方が異なるからこれはどの言語でも避けられない

**デフォルトの名無しさん** · 2023/04/24(月) 14:13:20.49

テンプレートは変換のしようもなく全滅ですが

**デフォルトの名無しさん** · 2023/04/24(月) 14:19:07.70

>>495
それは例外を遥かに越えて痛いね

**デフォルトの名無しさん** · 2023/04/24(月) 14:20:27.48

>>478
C++を踏まえてできたのがRustなんだろ、優位性を争う気はあんまりないな
C++で十分だって言ってる改良されればだけどね

**デフォルトの名無しさん** · 2023/04/24(月) 14:34:55.91

>>494
Rustは例外処理がネックだよな(Rustに限らないけど)
現実には xor rax,rax ですら例外が発生し得るから
async exception handlerをSEHでzero overheadで
実行ファイルに記述する仕組みを(64bit-)OSが提供しているのに

**デフォルトの名無しさん** · 2023/04/24(月) 14:44:47.56

C++とRustのコード相互呼び出しはこんな風に自動化されてる
https://cxx.rs/
https://i.imgur.com/ffKzJ3n.png

**デフォルトの名無しさん** · 2023/04/24(月) 14:53:54.93

Rustは余り普及しないのでは。

**デフォルトの名無しさん** · 2023/04/24(月) 14:59:09.48

>>498
おまえバカだろ
CPUの例外とC++の例外からして仕組みもレイヤも全く異なる

**デフォルトの名無しさん** · 2023/04/24(月) 15:09:12.38

おいおい馬鹿はお前w

レイヤが異なろうがどんなに泥臭かろうがシステム言語の宿命
Rustはシステムプログラミングの何たるかを言語設計の初期段階で考慮していない
CPU例外(≒非同期例外)を構造的にキャッチ出来ない出来損ないシステム言語w

**デフォルトの名無しさん** · 2023/04/24(月) 15:28:07.95

>>502
RustはCPU例外も割り込みも扱えます
Rustは組み込み用途やOS作成などシステムプログラミングにも使えるように設計されています
Rust(やGoなどの言語)がエラーハンドリングの例外機構を非効率なものとして排除していることとは全く無関係です

**デフォルトの名無しさん** · 2023/04/24(月) 15:31:17.42

Rustは設計段階ではシステム言語のつもりじゃなかったのでは？
言語構文で非同期例外を扱えないのは野暮ったいし

**デフォルトの名無しさん** · 2023/04/24(月) 15:40:24.08

>>503 RustはCPU例外も割り込みも扱えます... エラーハンドリングの例外機構を非効率なもの
まあPythonですら扱えます、と言うだろうし、非効率ってw？
なんか色々と498が意味するところの理解が追いつかないようだね
講釈するつもりはないから自分で調べてね

**デフォルトの名無しさん** · 2023/04/24(月) 16:01:06.96

C++の例外は実は途中の関数の各スタックフレームを全て処理してから実行されるため非常に遅い
なぜそうしているかというと途中の各関数で全てデストラクタ処理をしないと正しい継続動作ができないため
結果的に例外といっても各関数で早期リターンするのと同じだけの各処理を行なっている
そして各関数で例外が下からやってくることに備えて対処するコードが余分に必要となっている
そのため例外で返すと速く処理されそうなイメージとは真逆で現実のC++の例外は遅く非効率なものとなっている

**デフォルトの名無しさん** · 2023/04/24(月) 16:08:44.38

まあ初めはシステム言語のつもりはなかっただろうな。
ガベコレのパフォーマンスへの影響が気に入らないけどC++のメモリ管理におけるエラーはきつい
てのがRustの動機だろうし。

**デフォルトの名無しさん** · 2023/04/24(月) 16:09:33.04

そこんとこは、たまに、吐き出されてるバイナリを確認する習慣がほしいとこだね

**デフォルトの名無しさん** · 2023/04/24(月) 16:17:07.56

途中(503,506)から手抜きしてChatGPT的な文が続いているからディフェンスラインは諦めてると思う

**デフォルトの名無しさん** · 2023/04/24(月) 16:27:16.35

>>506
GC言語ならデストラクタを呼ばなくていいから速い例外を作れるけど、
C++は飛ばす部分で必要なデストラクタを漏れなく呼び出す必要があるのか。
C++の例外重すぎだろ。

**デフォルトの名無しさん** · 2023/04/24(月) 16:31:03.25

>>506
設計思想的には、C++の例外機構は、エラーなどの
「例外的に起きる(=滅多に起きない、レアケース)」
の場合のためのものなので、「例外が起きた時」の速度はほとんど考慮
されていない。ただし、誤解無きように捕捉しておくと
「例外が起きなかった時」のコストは配慮されている。

**デフォルトの名無しさん** · 2023/04/24(月) 16:32:38.06

>>510
えぇっと、Rustはdrop漏らしちゃうの？

**デフォルトの名無しさん** · 2023/04/24(月) 16:32:44.46

設計思想としては、C++の例外機構は関数からの戻り値を返す目的には設計されてない。
なので、その目的でも使おうと思えば使えるが、速度面の配慮がされてない。

**デフォルトの名無しさん** · 2023/04/24(月) 16:44:40.41

あまり詳しくないけどバイナリ出力はLLVMの守備範囲だと思うから
LLVMが対応しないシステムはRustも対象外ってことでいいんだよね

>>510
GC言語でも必要な時はちゃんとfinallyでdisposeすることをお勧めします

**デフォルトの名無しさん** · 2023/04/24(月) 16:45:19.17

>>513
簡潔に言えば、C++の例外機構は、エラー発生時のためのもので
アプリの正常走行時には一度も利用されない設計思想になっている。

**デフォルトの名無しさん** · 2023/04/24(月) 16:50:59.79

>>512
Rustにtry throw catchの例外はないのでその話はRustに無関係
代わりにResult返しと？オペレータになって普通にdrop処理もされる
C++のような例外対処コードの付加は必要ない
途中関数で必要に応じて自動エラー型変換も可能だからC++より便利

**デフォルトの名無しさん** · 2023/04/24(月) 16:59:10.31

>>516
Rustは非同期例外が発生しない謎保証をしてるの？
まさかdrop漏らしちゃうの？システム言語失格だよ？

**デフォルトの名無しさん** · 2023/04/24(月) 17:05:38.54

>>515
その正常走行時の意味合いがプログラミング言語によっても変わるし分野によっても変わる
つまりエラー時の意味合いがバラバラで役立たない

例えば指定ファイル複数が一つも存在してなかったら作成して見つかれば内容を返すとしよう
あるファイルが一つ存在しなくても正常走行だが存在しないと例外を出す文化もある
指定ファイル複数全て見つからなくても作成する正常走行だが例外を出す設計する人もいる
エラーとか異常とかの意味するところが色んな人で違ってる

結果としてC++でも例外を使いまくる関数やライブラリがあったり
全てをエラー値として返すライブラリもあったりする
そしてC++の例外は負荷コストがかかる
Googleのように例外使用禁止ルールを設けているところも多い

**デフォルトの名無しさん** · 2023/04/24(月) 17:16:16.97

>>517
Rustならばasync関数からの返り値もResultとなり異常時も受け取れる
Rustは付加コストのかかるtry例外機構を必要としない

**デフォルトの名無しさん** · 2023/04/24(月) 17:25:55.51

0点、ChatGPT？

そりゃRustはシステムプログラミング言語って標榜するしかこの先生きのこることが
出来ないと考えてるのなら必死ですよね

**デフォルトの名無しさん** · 2023/04/24(月) 17:28:30.42

C++は例外対応をオプションでOFFにできるおなじように、safe/unsafeもできるようにはやくなってくれ

**デフォルトの名無しさん** · 2023/04/24(月) 18:06:06.65

>>506
ローカル変数のデストラクタを呼び出すこと自体はC++で例外投げてもRustでErr返しても同じなので
そこは別にRustのアドバンテージではない

その調子でC++の勘違い名言集の量産お願いしますよ

**デフォルトの名無しさん** · 2023/04/24(月) 18:08:15.36

>>519
C++は非同期呼び出しでも例外を投げたり受けたりできるけど、
ライブラリが一旦catchして、値として渡して、再びthrowするからコストは非常に高いな。

**デフォルトの名無しさん** · 2023/04/24(月) 18:13:22.35

>>522
C++の例外がコスト高いと言われているのは、デストラクターを呼び出すこと自体ではなくて、
例外が関数を通過するときに適切にデストラクターを呼び出せるように、そのテーブルやコードを用意することだと記憶してるが。

**デフォルトの名無しさん** · 2023/04/24(月) 18:14:58.99

>>524
そりゃそうだろう。
デストラクタ自体は、Rustでも意味的に似たようなものを呼び出す必要があるわけだから。

**デフォルトの名無しさん** · 2023/04/24(月) 18:15:34.58

>>502以降の流れの非同期例外ってたぶんasync/awaitじゃなくて割り込みやシグナルのことだと思うんですけども……

**デフォルトの名無しさん** · 2023/04/24(月) 18:19:00.14

あと、勘違いしてる人がいるかもしれないので念のため言っておくと、
C++のデストラクタは関数の一種に過ぎないので、デストラクタの呼び出しは、
本質的に関数 call と同じものである。そして、C/C++ の関数 call は
比較的高速であり、簡単な場合であれば数クロックで呼び出せる。
なので、本質的にデストラクタの呼び出しコストは、ほとんど 0 に近くて、
本質的にはデストラクタの中身で処理時間が決まる。

**デフォルトの名無しさん** · 2023/04/24(月) 18:31:14.27

>>523
もちろん非同期で例外を使ったら大きく負け
同期でも自分で例外を投げたら負け
余分な見えないコードなどのコストがかかるだけでなく
例外自体の有無が把握しづらくドキュメントとコードのレビューコストがかかる
下から例外が来るのかどうか把握
それら例外を上へもらしてないか把握
必ずエラー値で返すコード規約にして見える化してるところは賢い

**デフォルトの名無しさん** · 2023/04/24(月) 18:33:19.55

ところで、
Rust で Vec に要素を追加した場合にメモリー不足になったかどうかを検出
するのはどうしたらよいんでしたっけ？

**デフォルトの名無しさん** · 2023/04/24(月) 18:41:55.56

C++との比較に関係しない質問はこっちで受け付けます
https://mevius.5ch.net/test/read.cgi/tech/1514107621/

**デフォルトの名無しさん** · 2023/04/24(月) 18:45:07.77

すげーのびてるけど中身のあるレスが一つとしてなかった
さすが隔離スレ

**デフォルトの名無しさん** · 2023/04/24(月) 18:57:04.81

>>526
割り込みやシグナルは例外とは別物

割り込みハンドラやシグナルハンドラが発生したその場で小さい処理でデータを得るか何もせずにフラグを立てる
プログラム本体には影響を与えない
そしてそのフラグなどのチェックはハンドラとは別にプログラム本体のどこかで任意の形で任意のタイミングで自由にチェックする
そこで例外を投げるか否かも自由であり直接関係はない

例外はプログラム本体やライブラリやOSなどが投げる
するとキャッチとの間の関数すべてが飛んでプログラム本体は影響を受ける

**デフォルトの名無しさん** · 2023/04/24(月) 19:27:10.65

>>531
ねーよ

雑スレだぞ、中身なんかないｗ

**デフォルトの名無しさん** · 2023/04/24(月) 19:36:13.19

言語の機能だけが重要ではない
エコシステムとコミュニティが同じくらい大事なんだよ

**デフォルトの名無しさん** · 2023/04/24(月) 22:48:09.25

>>526
そのRust叩きをしている彼がデタラメを言ってる
C++の例外は同期例外なので仮に彼の主張が正しいならばC++もアウトになる

C++の例外は呼び出した関数の中でthrowが投げられてその呼び出し側でのみcatchできる同期例外
関数呼び出しが深くなっても全て同期となる時のみC++は例外をサポートしている
スレッド間など非同期となるときはC++は例外を投げられないのでcatchしてデータとして渡して再びthrowするしかない

**デフォルトの名無しさん** · 2023/04/24(月) 22:51:49.29

つづき
そしてC++のような同期例外は例外を廃止することも可能
例外を値として関数からのリターン値の一つにすることで例外を無くせる
これを実際に行なっている言語がGoやRustであって例外を廃止してエラー値の一つとして返している
C++でも自主的に同じことが可能であってコーディング規則により例外を返すことを禁じているところもある
例外を使うべきでない理由が複数あるためだ

**デフォルトの名無しさん** · 2023/04/25(火) 04:31:54.40

でも、どちらも一長一短があり、好みの差が出て来そうだ。

**デフォルトの名無しさん** · 2023/04/25(火) 07:01:02.99

C++で例外を使うデメリット
・値返しの時よりもコードサイズが増える
・値返しの時よりも実行速度が遅くなる
・どちらもRAIIに基づく自動デストラクタは通過関数で呼ばれるが、それ以外で何かしてると例外時にメモリリークする
・各通過関数で例外が通過するのかどうかがわからず、関連する全てのコードを追う必要があり保守性が悪い
・例外を誰もcatchしない処理忘れが起きやすい
など多数

**デフォルトの名無しさん** · 2023/04/25(火) 07:42:43.52

複おじ頻出単語「デタラメ」

**デフォルトの名無しさん** · 2023/04/25(火) 08:52:43.77

C++の例外の利用を禁止しているプロジェクトも多いし
C++の例外は要らない子

**デフォルトの名無しさん** · 2023/04/25(火) 09:25:09.15

Nim 派の漏れだが
おまいらが執拗に Rust 薦めるから
使っても居ないのに批判はするべきでないと思って
Rust 使って観たがやはり君らの言う通り面倒な言語だ
C/C++ に対するメリットが面倒さを上回っていない
Nim に戻るわ

**デフォルトの名無しさん** · 2023/04/25(火) 09:35:36.87

面倒と言ってるのは使いこなせていないダメな連中ばかりな点が面白い
どの言語でも使いこなせるようになった時点同士で比較しないと意味がない
Rustは少なくともC++よりは開発効率も保守性も良く手間も時間も節約になる

**デフォルトの名無しさん** · 2023/04/25(火) 09:36:03.71

>>529
cargo で build 中に HDD 容量不足になっても可笑しな動きするぞω

**デフォルトの名無しさん** · 2023/04/25(火) 09:49:25.88

>>542
うん
だから C/C++ を批判して Rust 推してる連中も
C/C++ を使いこなせてないんだということも同時に悟った
ホントありがとう

**デフォルトの名無しさん** · 2023/04/25(火) 09:58:33.05

ストレージは事前に確保しとけよw