結局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/17(水) 11:15:53.89

>>460
無い。
特に「所有」の一般的な概念に含まれる(他から制限を受けないという意味での)排他性・専有性は無い。

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

C++の参照がダングリングを引き起こす根本的原因は、
値の所有とその生存期間を参照に対してはっきりさせていないため？

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

use Hoge; と
extern crate Hoge; の違いが判ったわ
新しいとか古いとか言ってる人が以前居たけど嘘だったω

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

待て待て
そもそもC++でダングリングを起こしたことがない

Rustは言語仕様上関数でヒープまで消しちゃうから
仕組みがないとダングリングを起こしやすい

ダングリングはRust固有の持病

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

>>464
逆だよな
ダングリングポインタが生じるのはC++

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

>>464
関数でヒープを自動解放する仕組みすなわち自動的にデストラクタが呼ばれる仕組みはC++とRustで同じ

**デフォルトの名無しさん** · 2023/05/17(水) 13:36:00.32

デバッグビルドでよければ、結構重厚にチェックしてくれるんだけどね
リリースビルドでも一定程度チェックが残ってくれるようになれば、まだましになるか

**デフォルトの名無しさん** · 2023/05/17(水) 13:56:37.30

>>462
C++でも値に対する所有とライフタイムを明確にして参照のライフタイムがそれ以内に収まる枠組みにすればダングリングを防げるようになる

**デフォルトの名無しさん** · 2023/05/17(水) 16:33:36.81

それスマートポインタでええやん

**デフォルトの名無しさん** · 2023/05/17(水) 16:47:08.88

Rustの知名度の上昇は、WasmのWASIのサンプルがCではなくRustで書かれている
ことにも起因するらしい。だから、Wasmで検索するとRustが出てきてしまう。
しかし、このことは、WASIの普及の足を引っ張るかも知れない。
なぜなら、C言語が基本だから。

**デフォルトの名無しさん** · 2023/05/17(水) 16:58:32.53

>>468
「～でも～できるようにすれば～できる」
万能だねw

**デフォルトの名無しさん** · 2023/05/17(水) 18:52:30.65

なぜなら、の後が願望100%やん

**デフォルトの名無しさん** · 2023/05/17(水) 20:08:10.12

願望だから嘘だとか万能だから嘘だとかいう雑な説明は蛇足だな

説明しない自由があるべき
嘘でもいいから何か説明した方がマシというのは大嘘だ

**デフォルトの名無しさん** · 2023/05/17(水) 22:54:42.20

C++君はコンパイルでチェック出来るようになってから出直してきなさい

**デフォルトの名無しさん** · 2023/05/18(木) 23:15:13.15

5ch見ない間に変なスレ立ってんじゃん
どっちが優勢なのこれ

**デフォルトの名無しさん** · 2023/05/19(金) 00:20:59.53

ちょうどこれが出た
https://gigazine.net/news/20230517-redmonk-programming-language-rankings-january-2023/

最強はもちろん…(ｗ

**デフォルトの名無しさん** · 2023/05/19(金) 00:48:25.47

PowerShellの下ｗ

**デフォルトの名無しさん** · 2023/05/19(金) 04:15:06.52

C++ってasync/awaitもまだstableではないんだな
大変だね

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

GitHubとStack Overflowか
まあお世話になってるけどそれでランキング付けされてもなあ
5chのム板を集計してみてよ外人

**デフォルトの名無しさん** · 2023/05/19(金) 10:02:47.03

Rust では || {} が
closure になるものとばかり思っていたが
関数ポインタとして扱われるケースもあるんだな
区別されてるということを学習した

**デフォルトの名無しさん** · 2023/05/19(金) 10:21:21.01

FnOnce⊃FnMut⊃Fn⊃fn なだけだろ

**デフォルトの名無しさん** · 2023/05/19(金) 10:47:38.97

山括弧の入れ子を許した者だけが||を使いなさい

**デフォルトの名無しさん** · 2023/05/19(金) 11:24:52.99

>>480
クロージャが関数ポインタに自動的にcoerceされてるだけでは？

**デフォルトの名無しさん** · 2023/05/19(金) 13:42:22.37

pythonさんが無名関数を雑に実装したおかげで
雑な名前をつけるより無名のほうがいいという価値観がもうない

**デフォルトの名無しさん** · 2023/05/19(金) 14:23:39.94

lambda式を変数fに入れていくスタイル

**デフォルトの名無しさん** · 2023/05/19(金) 15:00:56.18

fn は短くて好き
lambda は長い

**デフォルトの名無しさん** · 2023/05/19(金) 20:24:24.62

一文字変数って、感覚的に、レジスタだよね

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

>>487
FORTRANの話が始まるからよせ！

**デフォルトの名無しさん** · 2023/05/20(土) 13:19:21.76

map とかで
let e = hogemap.entry(hogeid).or_insert_with(|| Hoge::new());
は確かに便利なのですが
id が重複しないことはどうやって保証するの？
同じ id なら既存のに上書きは判らなくはないけど
それも禁止して上書き前に阻止したいときどう書く？

**デフォルトの名無しさん** · 2023/05/20(土) 13:22:01.56

本スレで聞けや

**デフォルトの名無しさん** · 2023/05/20(土) 13:43:24.13

entryの時点でハッシュ計算と衝突時含めたエントリ探索済
つまりエントリが空か既存かの状態を持つのがentry
あとはその状態により既存のを返すか空ならinsertしてそれを返すのがor_insert_withなどのメソッド

**デフォルトの名無しさん** · 2023/05/20(土) 14:17:02.46

>>489
そのコードで上書きは阻止できてるよ

**デフォルトの名無しさん** · 2023/05/20(土) 15:36:02.57

紛らわしくてごめん
上書きというか
重複してたらシレっと既存のデータ魅せるんじゃなくて
let e = hogemap.entry(hogeid).or_insert_with(|| Hoge::new());
新規の場合しか登録出来ない？みたいな動きを期待しています

**デフォルトの名無しさん** · 2023/05/20(土) 15:40:45.30

それ新規の場合しか登録してないんだよ・・・
すでに同じキーがあった場合にどうしたいのか
もう少し望んでる仕様を日本語で明確にしてくれ

**デフォルトの名無しさん** · 2023/05/20(土) 15:42:10.43

Entryの結果で分岐させたいってことなら
そうすればいいと思うんだが

**デフォルトの名無しさん** · 2023/05/20(土) 15:53:16.36

こんな感じでいいのかな
Entryはmapの型に合わせて別途useする必要があるけど

use std::collections::hash_map::Entry; // HashMapの場合

match hogemap.entry(hogeid) {
Entry::Occupied(_) => {
// エラー返す？
}
Entry::Vacant(e) => {
e.insert(Hoge::new());
}
}

**デフォルトの名無しさん** · 2023/05/20(土) 19:48:56.10

>>476
この表ではCとC++を分けて書いてあるので、10位と7位になっているが、
「合算」して、C/C++ と捉えると、遥かに順位が上がって、
tiobeや日経では一位になっていた。但し、日経は「プロのプログラマ」限定
のランキング。

**デフォルトの名無しさん** · 2023/05/20(土) 19:50:20.05

>>497
海外の掲示板でC++とJavaの投稿数はほぼ互角。
C#はそれらの2/3ほどだった。

**デフォルトの名無しさん** · 2023/05/20(土) 22:11:15.78

>>497
>「合算」して、C/C++ と捉えると
この考え方が既にプロからかけ離れてるだろw
日経wなら納得だけど

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

何で?

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

混ぜたものh単にC++だし純粋なCを使ってる人はC++と区別してるだろ。

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

この板ですらC/C++とかいう表記好むやつおって頭痛いわ
CのこともC++のこともおそらく両方とも聞きかじり程度なんだろう

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

C/C++ってのはCやC++という意味なので
グループ化して扱いたい文脈ならともかく
言語のランキングで異なる言語をまぜちゃダメでしょ

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

世界ランク1位のAIや世界ランク1位の法人は何人分なのかしら

**デフォルトの名無しさん** · 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
データがないんだよなあって言うだけならまあいいけど
データがない、ゆえに使いどころが (論理的に) ないと言ってはいけないよ
ほぼ死亡フラグに近い