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

**デフォルトの名無しさん** · 2023/10/28(土) 13:45:00.38

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

っていう雑談スレ。

・C/C++ <=> Rust いまさら聞けない移行質問なども適当にどぞ
・レスバはじめんのは勝手だけど、面白いこと・へぇなこと書いたヤツが優勝
・マな話は、マのスレもご活用ください↓

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

関連スレ(マ板): Google&Microsoft「セキュリティバグの70%はC/C++のメモリ管理ミス。Rustにする」
https://medaka.5ch.net/test/read.cgi/prog/1619943288/

**デフォルトの名無しさん** · 2023/12/05(火) 08:01:23.94

std::byteを使ってみた結果
危険な計算ができるのがC/C++を使う理由という結論になった

**デフォルトの名無しさん** · 2023/12/05(火) 08:50:09.72

一人で何役やってるの？

**デフォルトの名無しさん** · 2023/12/05(火) 09:49:41.30

>>881
数えてみろよ

**デフォルトの名無しさん** · 2023/12/05(火) 10:22:23.63

>>877
Factoryメソッド経由でしかインスタンス化できないようにするとかして常にshared_ptrやunique_ptrで返すようにすればいいのでは？

**デフォルトの名無しさん** · 2023/12/05(火) 10:50:40.33

>>879
delegateに欲しいのはあくまでAdaptorの実装を簡単にする機能。

参照外しとかして型を変えるのはNG。

**デフォルトの名無しさん** · 2023/12/05(火) 11:56:35.63

Rustのdelegate!のようなことがC++ではまだ出来ないということか
汚いマクロ書けばできそうだけど綺麗に書くにはReflection待ちなのかな

**デフォルトの名無しさん** · 2023/12/05(火) 13:26:22.00

>>882
こういうキチガイ対策にワッチョイ必要かもな

**デフォルトの名無しさん** · 2023/12/05(火) 13:34:36.87

>>882
きっしょw

**デフォルトの名無しさん** · 2023/12/05(火) 14:18:15.60

>>884
スマートポインタなのだから
Derefにより自動的に参照できれば十分だろ

**デフォルトの名無しさん** · 2023/12/05(火) 14:23:46.88

ﾜｯﾁｮｲ立てたってところで結局また次世代言語スレと同じ流れになってRustスレに帰ってくるんだろ

**デフォルトの名無しさん** · 2023/12/05(火) 14:24:46.44

×立てたってところで
○立てたところで

**デフォルトの名無しさん** · 2023/12/05(火) 14:31:18.82

Adaptorにだけ執拗にこだわるオジもアレだか
Adaptorも知らずにDerefを勧めるオジは論外

**デフォルトの名無しさん** · 2023/12/05(火) 14:58:30.60

>>883
ユーザーに返す型では流石に気持ち悪いと思うなあ
C++難し過ぎるだろ
選択肢が多過ぎる
かといって安全でもない
もうRust使わせてくれ

**デフォルトの名無しさん** · 2023/12/05(火) 15:21:39.57

>>892
別の理由でfactory使うときはどのみちshard_ptrかunique_ptrにせざるを得ない
(生ポインタはありえない)
だからそこを気持ち悪いと言っても仕方ない

**デフォルトの名無しさん** · 2023/12/05(火) 15:51:48.29

>>892
Rustでもそこは同じだと思うよ
ライブラリからBoxやArcが返されるものもあればそれらをラップした型が返されるものもある
シンプルなケースなら前者の方が圧倒的に使いやすい
内包する型のネストが深い場合などで便利メソッドを提供するなら後者ってイメージ
要はラップするだけの付加価値があるかどうか

**デフォルトの名無しさん** · 2023/12/05(火) 15:52:25.13

>>854
馬鹿は平気で二重に解放したりする
全然気にしないから馬鹿なんだけどね

**デフォルトの名無しさん** · 2023/12/05(火) 16:00:15.02

>>854
いやいやいやいやw

**デフォルトの名無しさん** · 2023/12/05(火) 16:26:52.90

リファレンスカウンタ方式のGCを基本にするんならGC言語でいいんじゃねってならない？

**デフォルトの名無しさん** · 2023/12/05(火) 16:45:36.42

>>889
えー

**デフォルトの名無しさん** · 2023/12/05(火) 16:47:29.78

ならない
リアルタイム系アプリでGCは困る

**デフォルトの名無しさん** · 2023/12/05(火) 17:17:38.64

循環参照で発生するリークを検出するか放置するか
あるいは循環参照を回避するか
それが問題だ

**デフォルトの名無しさん** · 2023/12/05(火) 17:29:27.24

>>899
マークスウィープの話をしてないぞ
リファレンスカウンタ方式のGCすら使えないというならshared_ptrも同様に使えないということになる

**デフォルトの名無しさん** · 2023/12/05(火) 17:59:20.81

手動メモリ管理のできないGC言語は高コストをかけて循環参照を回収せざるをえない
手動メモリ管理のできるC++/Rustは循環参照を避けることができて低コスト

その話とは別にshared_ptrやRc/Arcは参照カウンタによるコストがかかる
そのため複数所有者を使わざるを得ない場合に限定して用いる

**デフォルトの名無しさん** · 2023/12/05(火) 18:13:07.15

>>902
Weak Reference等を使って循環参照を手動で避ける方法が用意されてるかどうかは手動メモリ管理かどうかとは全く関係ないよ

**デフォルトの名無しさん** · 2023/12/05(火) 18:43:14.63

>>894
気持ち的にはラップしたいかなあ

**デフォルトの名無しさん** · 2023/12/05(火) 19:04:48.69

全銀システム障害「詳細設計書見落とし」でオーバーフローの痛恨、再発防止なるか
https://xtech.nikkei.com/atcl/nxt/column/18/00001/08680/

Rustを使えばいいじゃない

**デフォルトの名無しさん** · 2023/12/05(火) 19:13:25.15

IBMだったらJavaだったのに

**デフォルトの名無しさん** · 2023/12/05(火) 19:18:25.05

積極的にC++を使いたがる人ってC++のどこに魅力を感じているんだ

**デフォルトの名無しさん** · 2023/12/05(火) 19:24:31.25

Cとの互換性

**デフォルトの名無しさん** · 2023/12/05(火) 19:32:43.32

>>897
問題はGC言語は *常に* GC機能ありなところ。

**デフォルトの名無しさん** · 2023/12/05(火) 19:40:36.09

>>907
オブジェクト指向ｗ

**デフォルトの名無しさん** · 2023/12/05(火) 20:04:51.38

リファレンスカウンター気にするくらい速度を求めるなら、RAIIすら嫌だとはならんのかな
mallocはプログラムの最初に一回呼ぶ以外は許されない

**デフォルトの名無しさん** · 2023/12/05(火) 20:31:30.51

>>907
組み込み系でオブジェクトやりたい人
あと意図的に悪意あるコードを仕込む人とか。

**デフォルトの名無しさん** · 2023/12/05(火) 21:15:38.20

やりたいことが出来るのが一番の理由
アンリミテッドが魅力

**デフォルトの名無しさん** · 2023/12/05(火) 21:36:14.43

参照カウントて結構コストあったよな……と探したら解説見つけた。
yamasa.hatenablog.jp/entry/2021/01/29/012525

昔は並列処理と相性悪いと言われていたけど、今はどうかね？

**デフォルトの名無しさん** · 2023/12/05(火) 21:36:19.50

++C Unsafety Unlimited C++

**デフォルトの名無しさん** · 2023/12/05(火) 21:43:08.45

>>909
GC言語でもunsafeで手動管理とかできるよ
Rustと同じで基本がsafeだからC++をsafeにしていくよりもずっと簡単で問題が起きにくいアプローチ

**デフォルトの名無しさん** · 2023/12/05(火) 21:59:57.96

>>902
>そのため複数所有者を使わざるを得ない場合に限定して用いる
複数所有者を使わざるを得ない状況かどうかを確実に見分けるのはそれなりに難しい
Rustの場合はコンパイル通らないから無駄にRc/Arcを違うことはあっても逆はないので安全
C++は逆もある
>>853が「めちゃくちゃ安全になる」と言ってる理由もその辺にあるのでは

**デフォルトの名無しさん** · 2023/12/05(火) 22:10:46.45

>>911
RAII自体はコストゼロ
RAIIで解放されるスタック上の値の型にデストラクタがある時にその実行コストがかかる
そしてヒープ領域を所有していればヒープ解放コストがかかる
何度もヒープ確保解放を繰り返すよりはなるべく最初に確保するのはもちろん正しい
スタック領域で済ませられるならさらに望ましい

**デフォルトの名無しさん** · 2023/12/05(火) 22:57:00.41

全部独り言だったりしてｗ

**デフォルトの名無しさん** · 2023/12/06(水) 01:20:30.01

メモリに展開するのにオーバーフローしてもエラーを通知しないの？
https://japan.zdnet.com/article/35212258/

言語はCらしいけどどういうプログラムなんだろう
まじでmallocしてそこにmemcpyしてるだけなんじゃないか
対策はRustで書き直せ

**デフォルトの名無しさん** · 2023/12/06(水) 01:23:15.09

たとえクソレガシーだったとしても書き込むアドレスの範囲が想定してるものかのチェックは入れるべきだろう
どうせオフセットも手計算だろうし

**デフォルトの名無しさん** · 2023/12/06(水) 01:40:45.31

>>916
＞>>909
＞GC言語でもunsafeで手動管理とかできるよ

どの言語？具体名あげてくれ。

**デフォルトの名無しさん** · 2023/12/06(水) 01:58:21.86

[gc unsafe] [🔍]

**デフォルトの名無しさん** · 2023/12/06(水) 09:15:07.04

>>867-868
循環参照は？

**デフォルトの名無しさん** · 2023/12/06(水) 09:17:14.31

>>867
>あらゆる本で紹介されてない

a)全ての本で紹介されていない
b)紹介された本がひとつもない

どっちの意味？念のため確認

**デフォルトの名無しさん** · 2023/12/06(水) 09:18:07.12

>925 補足
a)全ての本で紹介されていない (紹介されてる本は少なくとも一つ以上ある)

**デフォルトの名無しさん** · 2023/12/06(水) 09:20:39.56

>>868
思い付いている人は大勢居る

>>865
>C++で極力Rustっぽく書く

いやいや Rust 以前から Rust 無関係に C++ で普通に C++ っぽく描いた結果でしょ
きみ承認欲求強過ぎるね

**デフォルトの名無しさん** · 2023/12/06(水) 10:53:51.94

>>922
メジャーなとこで言えばC#とかSwiftとか

**デフォルトの名無しさん** · 2023/12/06(水) 11:45:54.12

>>905
やっぱりNATテーブル不良で再起動したら治るルーターじゃん

**デフォルトの名無しさん** · 2023/12/06(水) 12:09:32.50

>>929
頭大丈夫か？

**デフォルトの名無しさん** · 2023/12/06(水) 12:31:44.18

型推論の是非を問いたい
書くのは楽かもしれないが読みにくくね？
型の重複記述は省きたいがまったく型がわからなくなると理解が難しくなる
読みやすさを優先すべきだと思うがどうだろう
IDEやエディタのサポートでカバーされるという考え方もあるが、カーソル合わせないとわからないしな

**デフォルトの名無しさん** · 2023/12/06(水) 12:44:38.03

>>931
ややこしい型の手書きとか効率悪化の元だから駄目。

せいぜいIDEに型のコメントを自動生成させるくらいまでだな。手動は更新されなくなってバグの温床になる。

**デフォルトの名無しさん** · 2023/12/06(水) 12:46:06.06

>>931
けっこう同意。
変数初期化ではリテラルでの場合だけ型推論利用して、そうでなければ型書いちゃうことも多い。

**デフォルトの名無しさん** · 2023/12/06(水) 12:51:11.58

>>932
＞手動は更新されなくなってバグの温床になる。

型変わったらコンパイル通らないし、型明示がバグの温床になるってのは無い。
修正の手間が増えるってのはわかる。

**デフォルトの名無しさん** · 2023/12/06(水) 12:54:09.75

複雑な型名を知る必要がない場合も多い
例えばRustなら関数の引数型も返り型でも具体的な型名を書かずに
impl Trait名　と使う機能のトレイト名だけを指定したり

**デフォルトの名無しさん** · 2023/12/06(水) 12:56:26.38

>>934
c++はスライシングあるからエラーにならない例外もある。
レアケースだけど。

**デフォルトの名無しさん** · 2023/12/06(水) 13:09:40.96

同じ情報を二重に書くのはプログラマなら普通疑問に思う

**デフォルトの名無しさん** · 2023/12/06(水) 13:12:47.35

>>924
コピー時はweak_refで渡すので良いかと思うのだが

**デフォルトの名無しさん** · 2023/12/06(水) 13:14:02.81

>>925
普通に考えてaじゃないの？
なんで紹介とか出てくるんだ？

**デフォルトの名無しさん** · 2023/12/06(水) 13:17:03.16

>>937
ある程度の重複さによってミスを早期発見できる効果があるから一概にそうはいえないぞ

**デフォルトの名無しさん** · 2023/12/06(水) 13:31:08.88

俺のプログラムにバグがあるのは
俺がまだ本気出してないだけだから

**デフォルトの名無しさん** · 2023/12/06(水) 13:38:13.20

どれだけスレが進行しても客観的な基準が示されず
主観バトルを発生させ続け
留まるところを知らない概念

可読性

**デフォルトの名無しさん** · 2023/12/06(水) 13:40:26.85

>>938
いやそれだとshared_ptrの意味ないから
shared_ptr使う限りは本質的には解決は難しい
それは生でshared_ptr使う場合も同じ
get_weakというメソッドでweak_refでラップして返すメソッドを提供するとかだろう

**デフォルトの名無しさん** · 2023/12/06(水) 13:44:37.37

全銀のシステムこの規模で低レイヤーのメモリ操作しまくるのにC使ってるのマジで狂気としか思えないな
コードレベルのユニットテストもないのだろうし
絶対こういうこと起きるやん

**デフォルトの名無しさん** · 2023/12/06(水) 13:55:39.00

>>940
保守できなくなるから必ず避けるべき

**デフォルトの名無しさん** · 2023/12/06(水) 14:04:56.53

>>945
プログラミング言語自体、ある程度の冗長性があるようにデザインされている
たからこそコンパイルエラーという現象が起こる
そもそもテストを書くという行為が重複した作業なのだけどやるだろ？
仕様変更したら書き直しなのは仕方ない

**デフォルトの名無しさん** · 2023/12/06(水) 14:06:40.52

Cであることは関係なくね？
データ形式の共有に失敗すればどこでも起こりそう
記事だけだとよく分からんけどAAABBBをABABABって誤認した感じでしょ

**デフォルトの名無しさん** · 2023/12/06(水) 14:10:35.44

ABAP

**デフォルトの名無しさん** · 2023/12/06(水) 14:11:26.67

>>946
>プログラミング言語自体、ある程度の冗長性があるようにデザインされている
それは妥協の産物で悪だよ

>たからこそコンパイルエラーという現象が起こる
冗長性がない言語があったとしてコンパイルエラーは起こるし意味がある

>そもそもテストを書くという行為が重複した作業なのだけどやるだろ？
>仕様変更したら書き直しなのは仕方ない

最初に型名が正しいと確認されたら型推論に任せるべきです

**デフォルトの名無しさん** · 2023/12/06(水) 14:17:11.63

>>947
どこを読んだらそうなるんだ？

**デフォルトの名無しさん** · 2023/12/06(水) 14:41:23.05

>>945
>保守できなくなるから必ず避けるべき

保守する気がなくなるから必ず避けるべき
ならわかる

**デフォルトの名無しさん** · 2023/12/06(水) 14:44:32.97

>>947
なんも分かってなくて草
あの記事だけで普通は全部理解できるぞ

**デフォルトの名無しさん** · 2023/12/06(水) 14:52:19.97

>>949
> 最初に型名が正しいと確認されたら型推論に任せるべきです

その最初の確認ってどうすんのさ？
まったく字面では現れない場合があるよね
もともとはその場合の話

**デフォルトの名無しさん** · 2023/12/06(水) 15:01:15.76

>>952
記事から全部理解できたならたぶん別の記事だと思う

**デフォルトの名無しさん** · 2023/12/06(水) 15:07:10.91

>>954
正確にはスライド
普通にわかる

**デフォルトの名無しさん** · 2023/12/06(水) 15:12:14.26

>>953
まぁそうだね
>>932で私の言いたいことは書かれてたや

**デフォルトの名無しさん** · 2023/12/06(水) 15:22:00.69

全銀のやつは記事に書いてることはわかるがめちゃくそ疑問だらけ

なんで生成時にサイズチェックしないのか
なんで生成されたテーブルをチェックしてないのか
なんで生成されたテーブル使った試験をしてないのか

一般企業でもなかなかお目にかかれないひどい内容だがそれを金融系のしかも全銀がやっちゃうってのが信じられないわ

**デフォルトの名無しさん** · 2023/12/06(水) 15:26:41.21

>>944
同感

**デフォルトの名無しさん** · 2023/12/06(水) 15:33:52.57

型推論よりインテリセンスとか補完がうざい。
こっちの入力リズムに合わないとイラっと来ることある。

**デフォルトの名無しさん** · 2023/12/06(水) 16:16:19.10

>>957
同感

**デフォルトの名無しさん** · 2023/12/06(水) 16:17:28.30

>>959
判る
入力enterで違う単語になってたら殺意を覚える

**デフォルトの名無しさん** · 2023/12/06(水) 18:22:40.40

Pimplが説明してるある本がないか立ち読みしたのだがあった
最近出たC++ソフトウェア設計という本にモロに書いてあった
こんな本いつの間に出てたんだ？
モロに俺がドヤ顔したパターンじゃねえか...
この本内容もめちゃくちゃ良いぞ

**デフォルトの名無しさん** · 2023/12/06(水) 18:31:32.46

pimplってGoFになかったっけ?

**デフォルトの名無しさん** · 2023/12/06(水) 18:37:31.41

ヘッダファイルの変更のせいで再コンパイルされるC++特有の問題に対処するのが主目的のpimplがなんでGoFにあると思ったんですか？

**デフォルトの名無しさん** · 2023/12/06(水) 18:54:10.35

>>962
pimpl、10年前の本「C++のためのAPIデザイン」(2012年)にも載ってるぞ。

**デフォルトの名無しさん** · 2023/12/06(水) 18:55:40.21

まあPimplの主張はコンパイルサイズを固定するとか
内部を隠蔽することが主目的っぽいね
この本ではImplにunique_ptrを使ってコピー時にmoveする実装になってる

**デフォルトの名無しさん** · 2023/12/06(水) 19:05:32.22

知ってると役に立つけどC++使う気が失せる技法のひとつだな

**デフォルトの名無しさん** · 2023/12/06(水) 19:09:45.42

>>966
>unique_ptrを使ってコピー時にmoveする

恐怖！auto_ptr再発明男！

**デフォルトの名無しさん** · 2023/12/06(水) 19:24:48.89

>>965
紙本は絶版っぽい
kindleがあるから買うか悩むなあ
クソ高いし

**デフォルトの名無しさん** · 2023/12/06(水) 19:26:54.33

確かに不毛過ぎる気はする
本質的じゃない部分ですげー頭使わなきゃならんし
面白い部分でもない
素直にrust使うべきだわ

**デフォルトの名無しさん** · 2023/12/06(水) 19:48:07.27

銀行はやったこと無いけどSIerの下請けで
お役所のシステム移行の
仕事したときにライブラリ一つに数万個のテストケースが
用意されてあらゆる仕様適合をチェックしていたので
実装でアホなことしててもテストで叩き落とせばよいという
思想なのかも

**デフォルトの名無しさん** · 2023/12/06(水) 20:02:44.32

>>964
GoFのBridgeパターン

**デフォルトの名無しさん** · 2023/12/06(水) 20:16:14.69

ヘッダーに実装書きまくるのが今のクソc++だからpimplにしたところでというのはある

**デフォルトの名無しさん** · 2023/12/06(水) 20:37:00.46

実装を書かざるを得なくなってヘッダーと呼ぶのが不適切になったから.hの拡張子がなくなった

**デフォルトの名無しさん** · 2023/12/06(水) 20:57:06.52

Pimplの良い説明を見つけた
この中のstd::shared_ptrの場合が今議論されている項目のようだ
http://www17.plala.or.jp/KodamaDeveloped/LetsProgramming/details_pimpl_idiom.html

**デフォルトの名無しさん** · 2023/12/06(水) 22:01:15.11

IT大手がRustへ舵を切るわけだな

**デフォルトの名無しさん** · 2023/12/06(水) 22:38:24.64

pimplはScott MeyersのEffective Modern C++が詳しい(Effective C++にもある程度書いてある)
shared_ptrじゃなくunique_ptrを使えと書いてる
https://en.cppreference.com/w/cpp/language/pimpl
https://herbsutter.com/gotw/_100/

**デフォルトの名無しさん** · 2023/12/06(水) 22:38:53.88

>>972
構造が似てるだけで全然別のもの

**デフォルトの名無しさん** · 2023/12/07(木) 00:06:56.11

デザインパターンとは構造について述べたもの
pimplはBridgeパターンの一適用例
別のものではない

**デフォルトの名無しさん** · 2023/12/07(木) 00:37:25.72

>>979
>デザインパターンとは構造について述べたもの
全然違うよ
GoFにもそういう考えを明確に否定する内容が書いてある