結局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/15(月) 09:37:02.63

>>411
ハゲ麦紐じゃなかった？

**デフォルトの名無しさん** · 2023/05/15(月) 09:38:10.71

>>414
型で厳格に区別できるから使い間違えることや問題がおきることはなく
さらにfoo.barとfoo->barを一本化してfoo.barだけにしたRustが便利で合理的かな

**デフォルトの名無しさん** · 2023/05/15(月) 11:36:55.02

>>414
Rustでも区別されてるけど場所によってはDeref Coercionが働くから
区別されてないように見えるというだけ
https://doc.rust-lang.org/book/ch15-02-deref.html

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

>>415
いつの話だよ。
C++11以降を知らんのか。

**デフォルトの名無しさん** · 2023/05/15(月) 12:36:46.16

じゃあジェネリクスの記号を何にすればよかったのかの話は無いよね。
代替案が無いなら貶さない方がいいよ

**デフォルトの名無しさん** · 2023/05/15(月) 12:58:13.92

Box[T]
Box t
't box
(box t)

**デフォルトの名無しさん** · 2023/05/15(月) 13:30:47.16

今さら代替案を出したってもう広まってるから無理だし、本気でこれを変えて「改善」になるなんて思ってる人はいないだろうが
C++の山かっこがC++11で改善されるまで長いことクソクソ言われてたのになぜRustは……ってだけのただの冗談だよ
本気にさせちゃったようですまないね

**デフォルトの名無しさん** · 2023/05/15(月) 13:45:50.28

Rustのジェネリックスの記法はこうこうこうだから美しい！マンセー！
って言わなきゃ話が続かないよ

**デフォルトの名無しさん** · 2023/05/15(月) 13:49:25.75

http://www.kmonos.net/alang/d/templates-revisited.html
クソクソ言われていた時代にRustと似た動機で作られたD言語はBox!(T)だったんだね
みんないろいろ考えるんだね～

**デフォルトの名無しさん** · 2023/05/15(月) 14:23:03.39

> C++構文定義上の最大の罪である山括弧ジェネリクス
> C++の山かっこがC++11で改善されるまで長いことクソクソ言われてた

完全にコイツはエアプ
当時そんなとこに文句言ってるやつ見たこと無い
みんな真顔で「> >」隙間開けてたわ
指がオートマチックでスペース叩いてるはず

仕事やってりゃ色々クソなことはあるが
それを言語に転嫁するようなザコはここにはいないよね？

**デフォルトの名無しさん** · 2023/05/15(月) 14:37:29.92

C++11までそんなので頑張ってたんだねw

**デフォルトの名無しさん** · 2023/05/15(月) 14:44:13.08

「もう広まってる」とは言うがRustがわざわざ山かっこ<>をジェネリクス用に選んだ経緯とかはあるのか？
本当に惰性と流れで<>にしたの？

Dみたくa!(b,c)にしなかったのはなんでだ？
やっぱりDのa!(b,c)なる記法は純粋に見映えがダサくて、C++的なa<b,c>なやつはなぜかイケてる、ていうだけのことだろ

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

()が増えるのは良くない

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

https://github.com/rust-lang/rfcs/pull/2544#issuecomment-422078938
https://github.com/rust-lang/rust/commit/014c6922e12d4faa6a2181674d12a7f487c06bb6

0.1すら出る前の超初期は角括弧だったんすねえ

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

https://soc.me/languages/stop-using-angle-brackets-for-generics.html
ここに書いてあることも一理あるけど
Goのようにsquare bracketでのインデックスアクセスを残したままFoo[T]にするのも微妙
unlimited look-aheadが必要だとしても実際にそんな長く先まで読む必要性なんてないので
読みやすさが勝るのならそれでいいと思う
ターボフィッシュはイケてないけど

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

>>425
C++がだらしないから、こんだけRust勢に煽られてる、っては思ってるけどね

あまりに煽られて、一行もRust書いてないのに、併用する心の準備ができつつある
でもぜってえC++は捨てねえ、ぜってえにだｗｗｗ > 煽り勢

**デフォルトの名無しさん** · 2023/05/15(月) 15:44:34.72

言語そのものを作ってるような人じゃなければ
あまり特定の言語に固執しないほうがいいよ
RustだろうがC++だろうがレゾンデートルに特定の言語を組み入れてる人は成長が止まりやすく老害化しやすいので自分が損するだけだから
所詮は使い分ける道具の一つ

**デフォルトの名無しさん** · 2023/05/15(月) 18:44:18.46

プログラミング言語をただの道具と言うやつは大抵無能

**デフォルトの名無しさん** · 2023/05/15(月) 18:58:00.82

>>433
ただの道具とそうでない道具の違いは何？
定義を説明してみて

**デフォルトの名無しさん** · 2023/05/15(月) 19:22:58.71

何か作るときに道具に拘る気持ちはめっちゃわかるけどなあ

**デフォルトの名無しさん** · 2023/05/15(月) 19:25:10.97

道具によって成果物の品質が変わるのだからこだわるのは当たり前
ただの道具とか言うやつは安定してゴミを作るからそういう感覚がないのよ

**デフォルトの名無しさん** · 2023/05/15(月) 19:32:41.90

ここからは理論無用でレスできるのでスレが進むのか？

**デフォルトの名無しさん** · 2023/05/15(月) 19:32:43.22

作るものが複雑になると、普段から使ってよく理解している言語でないと
調べ物が多くなって効率が悪い。

**デフォルトの名無しさん** · 2023/05/15(月) 19:34:27.68

問題領域の濃度と文法の濃度を考えれば、全ての用途で便利に使える万能言語なんてありえない。
言語には必ず得意領域と不得意領域があるんだから、問題領域に合わせて言語を選択・作成するのが望ましい。

**デフォルトの名無しさん** · 2023/05/15(月) 19:38:48.81

If all you have is a hammer, everything looks like a nail.

>>437
宗教上の理由でﾜｯﾁｮｲスレに書けない人が荒れることを無限に書き込むから

**デフォルトの名無しさん** · 2023/05/15(月) 19:42:25.96

ちょっとしたスクリプトを書く程度で済むケースは、シェルスクリプトやスクリプト言語を使えば済むから対象外として、
がっちりプログラミングするならば、実行速度やメモリ使用量などのリソース、可読性や保守性を含めた開発効率などで、プログラミング言語を選びたい。
慣れれば大した手間増加にならないのだから、CPUメモリリソースや時間を考えると、C++とRustが選ばれるべきシーンは多そう。
C++とRustが忌避される理由は他言語より「難しい」「面倒」だけど、慣れてしまえば他の言語と大した違いはないわけだから。

**デフォルトの名無しさん** · 2023/05/15(月) 19:47:06.01

目玉焼きに醤油を掛けるのかソースを掛けるのかマヨネーズ掛けるのか塩を掛けるのか
ぐらいのレベルがこの後30レスぐらい続くのかなあ？

**デフォルトの名無しさん** · 2023/05/15(月) 20:18:45.40

塩だろ。俺は邪道のアジシオだな

どんなターゲットにも合う。最悪、スイカにすら合う。
Cもそんな感じ。

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

>>433
道具を「ただの道具」にするかどうかは使い手の問題なんだよ
それがわかってない君は無能

そもそも>>432が「ただの道具」と言ってるように見えるようじゃ終わってるよ

**デフォルトの名無しさん** · 2023/05/15(月) 21:11:38.66

マンパワー依存の無能はさすがに苦笑
エンジニア向いてないよ笑

**デフォルトの名無しさん** · 2023/05/15(月) 22:00:39.87

まあC++にもunsafe{ } は来てほしいけどね
統一的な方法がなかったので、今後Rustのやりかたが他言語にも波及するっしょ

**デフォルトの名無しさん** · 2023/05/16(火) 03:39:12.30

>>446
global deleteを無くすのと、参照渡しのライフタイム保証があればいいよ。

**デフォルトの名無しさん** · 2023/05/16(火) 04:35:10.15

何か未知で不確実だとしてもただの道具ならその目的は既知だったりするでしょ
デストラクタの後で参照しないとか
デストラクタの後でデストラクタを呼ばないとか

だがメモリリークをあまり問題視しない件などは目的自体が変化してしまうから
ただの道具ではない

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

>>447
Rust勢が言っているのは、Rustで書いたものは安全といって納品できる、ということなので、
ガイドラインチェッカとかじゃなく、言語にちゃんとunsafe{ } があるというのはモダン

何をもってsafeとするかには議論があったが、Rustがデファクトスタンダードになるなら、それを取り込めばいい
ひとつの夜明けは近い

**デフォルトの名無しさん** · 2023/05/16(火) 10:02:16.98

>成長が止まりやすく老害化しやすい
道具云々は↑これが図星で悔しかったんだろ
その後のレス見れば成長止まって老害化してる人だとよくわかる

**デフォルトの名無しさん** · 2023/05/16(火) 10:57:49.38

当たり前だけど、攻撃力がレーゾンデートルになるよりは回避力か防御力のほうが
ダメージやストレスが少ない

**デフォルトの名無しさん** · 2023/05/16(火) 11:13:49.28

レーゾンデートルｗｗｗ

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

>>449
shared XOR mutableはちょっと面倒くさい。
せっかくスタックフレームベースなんだから、それ前提にもっと手軽にできないかなぁ。

**デフォルトの名無しさん** · 2023/05/16(火) 13:33:35.88

インテリだなぁwおい

**デフォルトの名無しさん** · 2023/05/16(火) 13:41:37.03

>>453
値を変更する時にそれが他から参照されてるかはRust以外でも多少は意識してるはずだし
変更可能な状態で共有することに意味があるならRefCellとかCellに入れて共有すればいい
面倒といっても安全のための規約レベルでしょ
（違反するとコンパイラに殴られるからある意味手間が省ける）

**デフォルトの名無しさん** · 2023/05/16(火) 15:40:22.92

>>453
正確にはshared NAND mutable

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

所有と参照を区別しない場合は
参照が一つもない値の存在は許されない (循環参照が許されないとは言ってない) ので
むしろxorが正確である場合もあるかも

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

>>457
それじゃ値について述べてるのか参照について述べてるのかそれとも型について述べてるのか曖昧すぎてルールとしては使い物にならない
主語と目的語を明確に意識してないと所有権複製の二の舞だよ

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

ああ、C++では値と参照を区別するとかしないとか言うね
でも動詞を使いたくなったら「参照する」は正しいが「値する」はおかしい
だから値を所有する、値を参照するというのが良い

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

C/C++の値に所有なんてあるのか
参照なら実体側の所有が誰か問題になるかも知れんが

**デフォルトの名無しさん** · 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/