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

**デフォルトの名無しさん** · 2023/05/04(木) 07:49:56.33

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

っていう雑談スレ。

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

関連スレ(マ板): Google&MS「バグの70%はC/C++。Rustにする」
https://medaka.5ch.net/test/read.cgi/prog/1619943288/

**デフォルトの名無しさん** · 2023/05/21(日) 02:34:22.95

C++ってCを内包してるので異なる言語なのかっていうと
それはちょっと違う

**デフォルトの名無しさん** · 2023/05/21(日) 03:10:59.62

だからC使いをC++使いに含めましょうって？

**デフォルトの名無しさん** · 2023/05/21(日) 03:28:43.95

C使いをRust使いに含めるのはないけどね

**デフォルトの名無しさん** · 2023/05/21(日) 03:51:32.22

K&R CとC++98使えるから両方名乗ってもいいよね

**476** · 2023/05/21(日) 09:07:29.95

CとC++は人気シェア被ってるだろうから、単純に加算じゃいかんだろうなｗ

ちな、最強は…ってのの意味は、C++かRustかとかって言ってる間に、
世界最強はJavaScriptじゃねーか、まあ確かにｗｗってつもりだったよ

Rust流のメモリ管理がJavaScriptに流れ込んだら、どうなるかね

◆QZaw55cn4c · 2023/05/21(日) 09:09:30.69

>>502,503
二つは一緒でしょう？
私はね C++ コンパイラを通らない C は書く気がしなくなりました、いまや C コードを C++ コンパイラでコンパイルが通るか試すのが日課ですね
そりゃCでかくときはCの書き方で、C++ で書くときはC++の書き方で書きますが、C++ はCの上位互換であるように気をつけていますね

◆QZaw55cn4c · 2023/05/21(日) 09:11:09.27

>>505
＞C++ってCを内包している
べきで、C++ コンパイラを通せないCコードは書かないようにしてますね

**デフォルトの名無しさん** · 2023/05/21(日) 09:13:04.25

C/C++にダングリングは存在しない
C/C++は実体の無いものを参照出来る
もちろんポインタに代入して良い
アクセスさえしなければ問題は発生しない
問題を起こすのは馬鹿プログラマの責任
頭の良いプログラマは承知の上で使ってる

**デフォルトの名無しさん** · 2023/05/21(日) 09:16:06.07

C/C++って書くとき、どっちも生ポ世代の、息の長い人気言語、って意味かなあ
そこを踏まえてRustが生まれた

なによりCにunsafe{ } 追加待ったなしだと思う Cに来れば、C++に来るのも早いだろう
そんな流れを想像するに、またC/C++って書いたりする

**デフォルトの名無しさん** · 2023/05/21(日) 09:17:42.54

>>512
この一行一行に頭の悪さ出てるのスゲーな
釣りとして考えたら上出来だけど

**デフォルトの名無しさん** · 2023/05/21(日) 09:20:34.24

>>512
Google＆Microsoft「セキュリティバグの70%はC/C++のメモリ管理不備が原因。問題の起きないRustにする」
https://medaka.5ch.net/test/read.cgi/prog/1619943288/

**デフォルトの名無しさん** · 2023/05/21(日) 09:21:35.31

想像以上に、ダメ人間がC/C++系に動員されてたって証左だね俺を含むｗ

**デフォルトの名無しさん** · 2023/05/21(日) 09:23:48.78

片方の小手先の文法にばかり文句つけて反対側の長所は言えない
サンプルコードレベルしか理解できず書けないからそんなことしかできない
だからクソスレになるんだよここ

**デフォルトの名無しさん** · 2023/05/21(日) 09:26:46.33

>>517
小手先の文法のいちゃもんは、
「まあそんなこと言っても始まらないから着手してるけど、やっぱ慣れんなあ」みたいな愚痴だぞｗ

**デフォルトの名無しさん** · 2023/05/21(日) 09:50:40.36

手続き型言語は基本的にはどれも大差はなく文法や言語仕様は慣れの問題しかないもんな
スクリプト的な使い方をするだけならどの言語でも良いと思う
ただし本格的にプログラミングするなら速さや省メモリが効いてくる
とはいえC++の仕様では静的解析に実行時解析デバッグでも>>515が残りうる

**デフォルトの名無しさん** · 2023/05/21(日) 09:55:14.09

小手先の文法っていうと、「hoge/fuga/b.rs」モジュールを「hoge/a.rs」から触りたい時に
なんでいちいち「hoge/fuga.rs」作って、人間が「pub mod b」みたいなこと書かなきゃならないんだろ
b.rsの先頭にでもpubって書いとけば、単にa.rsで「mod fuga::b」とか書くだけで認識できるようにするんじゃあかんのか

**デフォルトの名無しさん** · 2023/05/21(日) 10:20:50.76

>>520
どの言語でもモジュールの目的は隠蔽にある
つまり必要となる最低限のものだけを外部に公開して他は内部構造として隠蔽するのがプログラミングの基礎
言語によって基本状態が何でも公開と何でも隠蔽があって後者は公開必要のあるものだけにpub等を付ける

そのモジュールfugaのサブモジュールbも同様で無指定ならばfugaの内部構造として隠蔽してくれる
公開したいならばRustではpubあるいは公開範囲を指示してpub (xxx)を付ける
例えばそのクレート内部だけに公開したいならばpub (crate)を付ける

**デフォルトの名無しさん** · 2023/05/21(日) 11:01:39.93

まともなプログラミングをしたことない人は隠蔽の重要性をなかなか理解しづらいかも
Rustのようにデフォルトがあらゆる隠蔽の言語の方が保守性の良いコードに導きやすいね

**デフォルトの名無しさん** · 2023/05/21(日) 12:03:09.15

複オジ演やめろ

**デフォルトの名無しさん** · 2023/05/21(日) 13:05:49.48

>>520
>>32

**デフォルトの名無しさん** · 2023/05/21(日) 13:31:45.59

デフォで不可視なのとか、パスとモジュール階層が対応してるのは文句なくて
パスと対応してるのに、いちいちpub modが並んでるだけのフォルダ名と同名ファイル「hoge/fuga.rs」作らないと
サブフォルダに切ったサブモジュールさわれないらしいのがウザいなあって思ったんだけど、今「hoge/a.rs」で
mod fuga {
pub mod b;
}
って書いたら普通にhoge/fuga/bを触れたんで、そもそもフォルダ分けてもfuga.rsなんて作る必要なかったんか？

**デフォルトの名無しさん** · 2023/05/21(日) 13:36:22.22

他のファイルからfuga.rs触らないならまあそうなのか
普通はやらないけど

**デフォルトの名無しさん** · 2023/05/21(日) 13:36:56.71

>>526
×fuga.rs
○fugaモジュール

**デフォルトの名無しさん** · 2023/05/21(日) 14:43:05.00

他のファイルからはa::fuga::bとかでアクセスできるやろ
依存性や役割のまとまりに応じてモジュール階層を切ればいい

**デフォルトの名無しさん** · 2023/05/21(日) 15:41:33.08

>>525
そこは>>10と>>13に書かれてるように3つの自由度がある
ただし今回の場合はその対処でよいならばfugaというモジュール自体が本質的には不要なのだろう
fugaという名前空間を外に見せる必要がないならばaのサブモジュールとしてa/b.rsとするかhoge直下にhoge/b.rsとするところ

**デフォルトの名無しさん** · 2023/05/21(日) 16:12:13.12

ついにC#の時代がきた
AzureでChatGPTが動かせるサンプルが来たぞ
なんとjupyterでC#を動かしている
(python以外の言語も使えたのかよ)

そさてサンプルの豊富さと美しさよ
ここまできても無視してる奴らは本当に技術力が低いと思う

https://github.com/Azure-Samples/openai-dotnet-samples/blob/main/tweet-classifier.ipynb

**デフォルトの名無しさん** · 2023/05/21(日) 16:39:30.76

jupyterってjuliaとpythonとrの略なんですよMAUI君

**デフォルトの名無しさん** · 2023/05/21(日) 16:49:36.80

>>530
Web APIだからどの言語でも使えるんだぞwww
MAUI君は技術力低過ぎて理解できないかもしれないが

**デフォルトの名無しさん** · 2023/05/21(日) 18:21:13.72

>>496
やりたかったことが出来た
豚々

**デフォルトの名無しさん** · 2023/05/21(日) 18:22:09.48

jupyterって確か前からC#は使えてただろ

**デフォルトの名無しさん** · 2023/05/21(日) 18:29:15.16

>>520
その仕様は許容範囲というか
むしろ余計なものを隠したい時に重宝すると思うが？

**デフォルトの名無しさん** · 2023/05/21(日) 19:14:19.33

>>530
AOAI_KEYにSMS認証要らなくなってから来てください
いろいろとボトルネックはそこなので

**デフォルトの名無しさん** · 2023/05/22(月) 09:51:12.40

>>496
Occupied とか Vacant とか便所の扉でしか観たことなかったが
こんな使い方するんだな勉強になったわ

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

C++でnewはヒープ領域にメモリを確保するけど
Rustのnewは可変サイズでなければスタック領域にメモリを確保しちゃうんだな

**デフォルトの名無しさん** · 2023/05/23(火) 20:51:13.22

おじ～ん

**デフォルトの名無しさん** · 2023/05/23(火) 22:24:35.02

>>538
C++と違ってRustのnewは言語仕様じゃなく
関数の慣習的な命名にしかすぎないので
メモリ確保がどう行われるかは関数の実装による

**デフォルトの名無しさん** · 2023/05/23(火) 22:50:52.99

関数名がnewかどうかは自由だが
Selfを返すことになるのでそれは必ずスタック上に置かれる

Selfの中のフィールドなどがVecなどであれば間接的にヒープも使うことになるが
あくまでも間接利用であり直接のSelfの実体はスタック上となる

Selfをヒープ上に置きたいならば明示的にBoxで包めばよい
常にヒープ上に置く使い方のみをするならば
newという関数がSelfを返すのではなくBox<Self>を返す仕様にすることも可能

**デフォルトの名無しさん** · 2023/05/23(火) 22:54:27.65

分数みたいな論理演算は昔からあったのに
Rustになってそれが強化されたみたいに感じるのは
ただ単にハードウェアの性能が上がったからじゃないの

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

Rustは後でスタックにもヒープにも移動できるから
最初にどこに確保しようが関係ない

C/C++は合算の対価として、値の移動ができないCの仕様を守る
対価を支払ったのだから合算していい

**デフォルトの名無しさん** · 2023/05/24(水) 00:05:18.37

>>541
なんじゃそりゃ
C++のnewも返される値(ポインタ)はスタックに置かれる
Box<T>だってTはヒープでもBox<T>はスタック
さすがにそんな話をしてるわけではないと思うんだが

**デフォルトの名無しさん** · 2023/05/24(水) 00:10:06.89

>>544
インスタンスの値の話じゃないかな
C++だとnewしてヒープに置かれる
RustだとBox使わない限りスタックに置かれる

**デフォルトの名無しさん** · 2023/05/24(水) 00:33:20.12

>>545
それを言うなら「C++だとnew使わない限りスタックに置かれる」だろ

**デフォルトの名無しさん** · 2023/05/24(水) 00:42:05.36

>Selfを返すことになるのでそれは必ずスタック上に置かれる
C++のnewは「ポインタを返すことになるのでそれは必ずスタック上に置かれる」と言ってるのと同じ
以降の文もだけどポイントがズレてるってことわかんないかな

**デフォルトの名無しさん** · 2023/05/24(水) 00:54:21.12

RustのBox ＝ C++のnew
どちらもインスタンスをヒープで作ってそれを指すポインタを返す

**デフォルトの名無しさん** · 2023/05/24(水) 00:57:06.07

>>547
RustがSelfつまりインスタンスを返す時にポインタは返さない
つまりC++のnewとは異なる

**デフォルトの名無しさん** · 2023/05/24(水) 03:23:05.87

>>549
さらにズレたレスだね
しかも間違ってる

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

>>543
C++でオブジェクトのmoveは値が移動するわけではないが
Rustでmoveは値がスタック⇔ヒープと移動することも必要なら可能だからか

**デフォルトの名無しさん** · 2023/05/24(水) 06:21:18.27

Python3.12betaの話の#2でRustって質が悪い

https://www.phoronix.com/forums/forum/phoronix/latest-phoronix-articles/1388841-python-3-12-now-under-feature-freeze-with-beta-1-released

**デフォルトの名無しさん** · 2023/05/24(水) 20:33:36.47

move等が無かった時代に書かれた仕様を現代の価値観で解釈するのは誤読と言われそうだが
C/C++は常習的にそれをやっていた
CのstructにはOOPの機能が無い・・・のではなく省略できることを書かなかっただけ
と解釈される

**デフォルトの名無しさん** · 2023/05/24(水) 23:36:30.94

どこかのタイミングで　c++　→　c+++ 辺りに解明白

**デフォルトの名無しさん** · 2023/05/25(木) 00:10:13.85

int i {0};
cout << ++i++ << ' ' << i << '\n';
何と表示?

**デフォルトの名無しさん** · 2023/05/25(木) 01:15:55.63

>>551
C++のmoveは機能が非常に小さく限られてるのね

**デフォルトの名無しさん** · 2023/05/26(金) 10:16:10.06

今からやるならrust

**デフォルトの名無しさん** · 2023/05/26(金) 10:32:38.85

でもRustって使いどころがないんだよなあ

**デフォルトの名無しさん** · 2023/05/26(金) 11:54:59.67

.NET普通に使えるRust#欲しいかな
要らんな

**デフォルトの名無しさん** · 2023/05/26(金) 14:07:09.39

>>558
データがないんだよなあって言うだけならまあいいけど
データがない、ゆえに使いどころが (論理的に) ないと言ってはいけないよ
ほぼ死亡フラグに近い

**デフォルトの名無しさん** · 2023/05/26(金) 14:32:09.72

社内でもRust化は検討してるけど、一番のネックはRustを使える人が集まらないことやね

**デフォルトの名無しさん** · 2023/05/26(金) 14:33:58.09

言語のアシストがあるから、C++よりは安全といっても…習熟が要らないかっていったらまた別の話だしな

**デフォルトの名無しさん** · 2023/05/26(金) 17:56:10.48

まぁ実際“安全”って言ったって実際どうなんってよくわからんよな
ただ、マーケティング的に「今Rustってのが出てきました、Microsoftのwindowsも使い始めました、Linuxもです、これからはこういう安全性の高い言語で開発されたものがおすすめできます」というのは売りにはなるやろな
実際ほんとにどれほど安全なのかはわからんけど

**デフォルトの名無しさん** · 2023/05/26(金) 18:04:34.59

GCの使いどころを知るためにGCを追放してみた感がある
自分が絶対正しい的な動機がなくても、身の程をわきまえた上でGCをクビにする

**デフォルトの名無しさん** · 2023/05/26(金) 22:03:14.80

>>554
解明白？
国語やり直すか？

**デフォルトの名無しさん** · 2023/05/26(金) 22:09:14.92

>>562
ゼロから習得スタートならば
C++よりRustがすっきりしていて習得しやすい
C色んな機能や概念を後付けしてきたC++との違い

**デフォルトの名無しさん** · 2023/05/26(金) 22:22:16.39

ソフトウェアの売り文句がその通りだった試しはないんだけどな

**デフォルトの名無しさん** · 2023/05/26(金) 22:58:51.65

柵はソフトウェアでは利点も欠点もあるからね

**デフォルトの名無しさん** · 2023/05/26(金) 23:42:30.81

トロッコ問題もそうなんよ
死者は1人または5人と断定して利点や欠点を皮算用させるけど
現実は0人だったり2人だったりする
問題文がその通りだった試しがないことを知っている人は問題文を否定する

**デフォルトの名無しさん** · 2023/05/26(金) 23:59:03.75

>>566
ほぼすべての人にとってはそうだ
しかし抽象化が進んでいるため一部のバカはRustなどの言語を理解できないようだ

**デフォルトの名無しさん** · 2023/05/27(土) 00:57:04.07

言うほどrustが抽象化されてるか？

**デフォルトの名無しさん** · 2023/05/27(土) 02:06:21.95

そういう具体性皆無の発言にいちいち反応してっからくだらん話になっていくんや

**デフォルトの名無しさん** · 2023/05/27(土) 09:54:08.85

バカには理解できない言語？
それは習得し易いとは言えないのでは

**デフォルトの名無しさん** · 2023/05/27(土) 10:40:48.84

エスペラント流行らないね

**デフォルトの名無しさん** · 2023/05/27(土) 11:01:08.70

習得しやすさを基準にすると宗教に勝てないよ
習得しやすいが残酷な教義を信じて戦争したりするよ

**デフォルトの名無しさん** · 2023/05/27(土) 13:01:04.01

デジタル信号処理の組み込みやるならC++じやね？

**デフォルトの名無しさん** · 2023/05/27(土) 13:12:08.74

C,C++,Rustはそのあたりの機能も性能も同じ

**デフォルトの名無しさん** · 2023/05/27(土) 13:48:56.45

勉強するときに参照するサンプルコードはぼぼCで書かれてるからね
3言語ともまだって人にはRustは選択肢にならんだろうね

**デフォルトの名無しさん** · 2023/05/27(土) 14:01:29.07

言語を勉強するのが目的の人はRustかなと思う。
でも、通信やOSの仕組みが知りたかったら大体の本はCで書かれてるし、デザインパターンの勉強やゲームを作りたかったらC++で書かれている本が多い。
そういった先のことを勉強したい場合、Rustで実装されてることは少ないので、優先順位が下がってしまう。

**デフォルトの名無しさん** · 2023/05/27(土) 14:02:40.43

Rustって何て読むのか知らないけど、なんかあまりカッコよく無いな。カッコで言語選ぶべきじゃないとは思うけどね。

**デフォルトの名無しさん** · 2023/05/27(土) 14:07:13.98

>>575
Rustが宗教なんじゃないの？
Rust推しの人の言動みると宗教信者っぽいんだけど

**デフォルトの名無しさん** · 2023/05/27(土) 14:13:31.68

ラストって勝手に思ってた

**デフォルトの名無しさん** · 2023/05/27(土) 14:28:37.61

Rustを使える人で仮にCを知らない人がいたとしても
残るわずかな差分のC特有の仕様を勉強するには1日あれば十分
だから困ることはないだろう

**デフォルトの名無しさん** · 2023/05/27(土) 14:45:17.55

そもそもがCの文法レベルの勉強自体が8時間で終わるレベル

**デフォルトの名無しさん** · 2023/05/27(土) 14:59:51.85

マジか、じゃあC言語のエンジニアなんて8時間あれはどんどん量産できるんじゃん
最強じゃね？

**デフォルトの名無しさん** · 2023/05/27(土) 15:12:20.67

>>581
(信者数の) 最大化問題を解いているような言動は宗教っぽい

**デフォルトの名無しさん** · 2023/05/27(土) 15:14:49.40

C言語の入門はどこまでなんだろ
個人的には連結リスト作るまで当たりじゃないかと

**デフォルトの名無しさん** · 2023/05/28(日) 00:05:14.68

C・C++はビルド周りが弱すぎる
CMake登場でちょっとはマシになったけど、それでもまだそんな普及してないしな

**デフォルトの名無しさん** · 2023/05/28(日) 00:11:09.42

autoconfとautomakeがありますが何か?

**デフォルトの名無しさん** · 2023/05/28(日) 01:04:51.11

弱いのはWindowsでしょ
他人がビルドしたライブラリをリンクする仕組みがないから自分の負担が大き過ぎる
最近はLinux依存を躊躇しなくなってきてる

**デフォルトの名無しさん** · 2023/05/28(日) 03:42:47.92

ライブラリを簡単に探したり、依存関係勝手に解決してくれる仕組みがないのでゴミなんだよなぁ

**デフォルトの名無しさん** · 2023/05/28(日) 05:16:42.09

vcpkgとかconanは使ってみた？

**デフォルトの名無しさん** · 2023/05/28(日) 10:19:09.55

色々使ってみるということは当然C++とRustどっちも習得するんだよな

**デフォルトの名無しさん** · 2023/05/28(日) 10:25:45.36

触るけど習得なんてしない

**デフォルトの名無しさん** · 2023/05/28(日) 10:35:03.00

仕事で必要な方にすれば？必要に迫られれば集中して学ぶからどんな言語でも習得するかと。

**デフォルトの名無しさん** · 2023/05/28(日) 10:37:20.20

ライナスはピュアCでgit作ったんだよな
偉いわ
Cオンリーでマルチ文字列操作なんてしたくない

**デフォルトの名無しさん** · 2023/05/28(日) 10:41:38.44

>>596
Rubyかと思ってた

**デフォルトの名無しさん** · 2023/05/28(日) 10:53:49.06

Perlがあったとてもrubyはないかな

**デフォルトの名無しさん** · 2023/05/29(月) 06:25:25.92

所有権とかいる？std::moveで十分だろ

**デフォルトの名無しさん** · 2023/05/29(月) 09:55:20.52

pub const longlongnamehogehoge: i64 = 1;
pub const longlongnamehogehage: i64 = 2;
pub const longlongnamehagehage: i64 = 3;
みたいな定数があって
let fuga: i64 = なんか値; みたいな状況で
match fuga {
longlongnamehogehoge => { println!("oo"); },
longlongnamehogehage => { println!("oa"); },
longlongnamehagehage => { println!("aa"); },
longlongnamehagehoge => { println!("ao"); }, // 無いはず
_ => { println!("other"); }
}
って描いたときコンパイル時エラーを期待してたんだけど
完全スルーで成功されるんだがなんでだろ

**デフォルトの名無しさん** · 2023/05/29(月) 10:08:34.30

事故解決しますた
gist
37751f7d9108e58dd16982f32a2b105f

match に any value って _ のことだけかと思ってたけど
使ってない変数名ならなんでも良いことが判りましたです

**デフォルトの名無しさん** · 2023/05/29(月) 10:10:38.95

あとこれでも実行出来てたのでどこにあるかの問題でもなかった
match fuga {
longlongnamehogehoge => { println!("oo"); },
longlongnamehagehoge => { println!("ao"); }, // 無いはず
longlongnamehogehage => { println!("oa"); },
longlongnamehagehage => { println!("aa"); },
_ => { println!("other"); }
}

**デフォルトの名無しさん** · 2023/05/29(月) 10:52:27.39

>>602
warning: unreachable pattern で気付くだろ

**デフォルトの名無しさん** · 2023/05/29(月) 11:02:56.11

Cでは定数を#defineやenumで定義することが多く
定数は大文字で変数は小文字
Rustのenumも大文字で始まるから通常は定数と変数を間違えない

問題は、#defineよりconstが優れているというのは嘘だったんじゃないかという

**デフォルトの名無しさん** · 2023/05/29(月) 12:35:35.40

いやまあそうなんだけど
match fuga {
longlongnamehogehoge => { println!("oo"); },
longlongnamehagehoge => { println!("ao"); },
longlongnamehogehage => { println!("oa"); },
longlongnamehagehage => { println!("aa"); },
}

longlongnamehagehoge が存在しない状態で
このコードって明らかにバグだと思うんだけど
正常系と看做される訳でωωωなんだかなーと思った次第