結局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(火) 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にもそういう考えを明確に否定する内容が書いてある

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

C++オブジェクト設計という本にはbridgeパターンの一種で継承や多態性が必要がない場合の単純な例としてPimplの説明があった

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

>>980
議論をしたければ
GoFに書いてあるそういう考えを明確に否定する内容
を述べ給え

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

>>981
一見して分かりそうなもんだけどね

**デフォルトの名無しさん** · 2023/12/07(木) 01:04:03.35

C++の不完全型とJavaのインターフェースが同じに見える人には同じに見えるんだろう

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

>>980
そんなこと書いてねーぞ

**デフォルトの名無しさん** · 2023/12/07(木) 09:57:06.17

RustでGUIのアプリがつくりたいです

**デフォルトの名無しさん** · 2023/12/07(木) 11:16:21.90

egui

**デフォルトの名無しさん** · 2023/12/07(木) 13:36:44.52

>>987
ありがとう
これはおもしろそうでごす

**デフォルトの名無しさん** · 2023/12/07(木) 23:09:48.18

えぐい

**デフォルトの名無しさん** · 2023/12/08(金) 09:55:56.32

踏んどくか

**デフォルトの名無しさん** · 2023/12/08(金) 09:58:29.65

結局C++とRustってどっちが良いの？ 9traits
https://mevius.5ch.net/test/read.cgi/tech/1701997063/

**デフォルトの名無しさん** · 2023/12/08(金) 10:01:41.64

unsafe {
次スレいらんわボケ
}

**デフォルトの名無しさん** · 2023/12/08(金) 10:15:03.32

・めとくか

**デフォルトの名無しさん** · 2023/12/08(金) 10:27:55.85

Cで書かれたプログラムがある
Rustに移植せよ
https://uguisu.skr.jp/othello/7gyou.html
https://ideone.com/0xz2SJ

**デフォルトの名無しさん** · 2023/12/08(金) 10:38:32.80

こんな短く書けるんだ!

**デフォルトの名無しさん** · 2023/12/08(金) 10:39:02.81

RustはCとの相性は良いがC++との相性は最悪

**デフォルトの名無しさん** · 2023/12/08(金) 10:39:54.69

どうしてもC++を捨てられない人は
RustよりNim使った方が救われる

**デフォルトの名無しさん** · 2023/12/08(金) 10:40:47.47

>>994
このスレの腕自慢建ちなら一瞬で移植してくれるだろう

**デフォルトの名無しさん** · 2023/12/08(金) 10:41:18.48

間違えた
x 建ち
o 達

**デフォルトの名無しさん** · 2023/12/08(金) 10:41:47.84

次
https://mevius.5ch.net/test/read.cgi/tech/1701997063/

**1001** · Over 1000

このスレッドは１０００を超えました。
新しいスレッドを立ててください。
life time: 40日 20時間 56分 48秒