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

**デフォルトの名無しさん** · 2023/04/02(日) 00:42:57.53

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

っていうスレ。

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

**デフォルトの名無しさん** · 2023/04/03(月) 12:47:23.54

>>53
言い得て妙
マジでこれw

**デフォルトの名無しさん** · 2023/04/03(月) 12:54:34.40

>>50
C++の参照とRustの参照はかなり違うぞ
C++の参照はちょっとミスるとダングリングになる

**デフォルトの名無しさん** · 2023/04/03(月) 13:50:16.07

「数学的」連呼してる割には名前に直交性が無いな

.iter
.indexed_iter
.iter_mut
.indexed_iter_mut

.outer_iter
.outer_iter_mut

not exist .indexed_iter_mut
not exist .enumerate_iter_mut

.enumerate_pixels_mut

いちいち覚えてられるか？

**デフォルトの名無しさん** · 2023/04/03(月) 13:54:52.87

違ったので訂正
誤 not exist .indexed_iter_mut
正 not exist .indexed_outer_iter_mut

**デフォルトの名無しさん** · 2023/04/03(月) 14:01:30.74

あ。「数学的」連呼してたのは、C++側の俺
そして、あんまり、数学的な安全の論拠ってのはみつからない

ありゃあC++で真似するんだよ手本にしない手はない

**デフォルトの名無しさん** · 2023/04/03(月) 14:08:12.25

>>56
各ライブラリで命名方針が異なるのは、プログラミング言語の比較の話と全く無関係じゃね？
あと、enumerate_pixels_mutをその提案のenumerate_iter_mutとしてしまったら、肝心なピクセルが消えて意味不明じゃん。

**デフォルトの名無しさん** · 2023/04/03(月) 14:14:18.67

雑談としては、そのへんも「きれい」になってくれるとありがたいね
これはC++も同様

**デフォルトの名無しさん** · 2023/04/03(月) 14:28:24.56

直交性の意味がよく分からなかった
index_of（先頭から検索）とlast_index_of（末尾から検索）は直交性がないことになるのかな
標準と非標準の関係で考えると自然な命名だと思うけど

**デフォルトの名無しさん** · 2023/04/03(月) 14:29:57.73

かわいそうだから答えてやるか
数学的な保証が云々ってたぶんRustBeltプロジェクトのことだよね
https://plv.mpi-sws.org/rustbelt/

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

>>62
どの辺を指して数学的と言ってるのか謎

**デフォルトの名無しさん** · 2023/04/03(月) 15:39:46.50

Rust 安全論文、で上手く引き当てられなかったんだよ
仕事サボって、ちょっと読んでみるｗ

>>63
いや、いいんだ。「それっぽいの」って俺も言った。

**デフォルトの名無しさん** · 2023/04/03(月) 15:53:08.55

>>62
unsafeを使ってsafeなインタフェースを作っている部分、すなわち人間が安全性を保証しなければならなかった部分を、数学的に保証する試みがあるのか

**デフォルトの名無しさん** · 2023/04/03(月) 15:56:35.02

そこも気を付けて読んでみるけど、
unsafeを撲滅しようと思ったら、SoCのサポートが必要ってのが今のところの俺の考え
そう考えないと、C++も永遠にsafeに成れないことになってしまう

unsafe部分にバグが、っていう古い記事が出てきたりするんだけど、
どうせ、safeでいいものまでunsafeでいっぱい書いたんでしょ、と思ってる
これは個人の推測

**デフォルトの名無しさん** · 2023/04/03(月) 16:08:23.20

>>65
数学的とは一言も書いてなくね？

**デフォルトの名無しさん** · 2023/04/03(月) 16:11:48.88

学術的とか、論理的とか、適当に読み替えてくれよ、俺がうまく言えなかったのがいけなかっただけ

**デフォルトの名無しさん** · 2023/04/03(月) 17:01:07.96

>>61
last_index_ofはlast occurrenceのindexを示すだけで検索方向を示すものでは無いと思う

**デフォルトの名無しさん** · 2023/04/03(月) 17:14:21.15

>>56 >>59
.indexed_pixel_mut も欲しいです

**デフォルトの名無しさん** · 2023/04/03(月) 17:34:14.59

>>70
はあ？
indexed_iter_mutがあるのはndarray crateの話
enumerate_pixels_mutがあるのはimage crateの話
pixelのイテレータとrowのイテレータがあるためiterではなくpixelsおよびrowsと名付けている
>>56が無関係な両ライブラリをごっちやに取り上げてその意味も分からず批判しているだけにすぎない

**デフォルトの名無しさん** · 2023/04/04(火) 09:48:59.96

前スレを読んだ感想だが
Rustのvtableは1つに合成されているのがへーだった
ちなみにC++は各基底毎にある
https://i.stack.imgur.com/rK5xx.jpg
https://i.stack.imgur.com/TJ1k6.jpg

**デフォルトの名無しさん** · 2023/04/04(火) 09:57:45.04

>>72
それ読み間違えてるぞ

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

複オジメソッド発動

**デフォルトの名無しさん** · 2023/04/04(火) 10:08:21.90

>>72
Rustは継承がなくトレイト合成なんだから当然だろ

>>73
間違ってはいないだろ

**デフォルトの名無しさん** · 2023/04/04(火) 10:10:16.77

まあ、ちゃんとキャストできるようにできてるというか

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

何が間違ってるかは教えてあげない

**デフォルトの名無しさん** · 2023/04/04(火) 13:10:25.87

プッ

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

C++を知ってしまったことかな。。

**デフォルトの名無しさん** · 2023/04/04(火) 14:47:11.16

日本人はtraitとtoiletの区別がつきにくい

**デフォルトの名無しさん** · 2023/04/04(火) 17:52:01.37

もうGPTがどの言語でも変換してくれる時代

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

rustのcrateはdependenciesで入るのが多過ぎるし大き過ぎるわ
要らないものまで無理やり入れさせられてる気分になる

**デフォルトの名無しさん** · 2023/04/04(火) 21:26:41.04

依存crate問題が最大の弱点ではある

**デフォルトの名無しさん** · 2023/04/04(火) 21:32:45.26

node_modulesとどっちがヤバいかな？

**デフォルトの名無しさん** · 2023/04/05(水) 15:18:19.83

node_modules は -g で解決

**デフォルトの名無しさん** · 2023/04/05(水) 15:43:59.95

dependenciesに5個程度指定するだけで
依存crateが100個近くになるのも珍しくない
nodeとは比べ物にならないくらいひどいよ

**デフォルトの名無しさん** · 2023/04/05(水) 15:47:38.76

しかもビルドすると500～1GB超の容量使うからノートの内蔵SSDを使ってると残す必要のないのは積極的にcleanしないときつい

**デフォルトの名無しさん** · 2023/04/05(水) 15:49:19.66

そんだけファイルの読み書きするなら
IOの速度に影響されそうだね

**デフォルトの名無しさん** · 2023/04/05(水) 15:55:51.93

マイコンでも大人気と聞いたんだが、どうなってるんだ

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

容量使うのはインクリメンタルビルド用の中間生成物で配置するものとは違うよ

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

C++もPCHファイルを生成するとアホほどでかかったりするが…世の中うまくいかんな

**デフォルトの名無しさん** · 2023/04/06(木) 14:03:59.93

チンチン汁出るッ

**デフォルトの名無しさん** · 2023/04/06(木) 15:09:52.63

C++なら明示的インスタンス化を使おうよ
使っている人をほぼ見ないけども

**デフォルトの名無しさん** · 2023/04/06(木) 15:52:41.86

こう書いておけば、インスタンス化した関数に、こんな風に溶け込むだろうな、とか思って書いてたりはする
時間があれば、生成コードを汗で確認する
びっくりするほどスパゲッティな出力になってて、びっくりすることがあるまあ実力不足を痛感する瞬間

**デフォルトの名無しさん** · 2023/04/06(木) 18:12:44.37

Cargo はゴミ

**デフォルトの名無しさん** · 2023/04/06(木) 20:01:46.11

ぺたんこおっぱい
ぽっこりおなか
つるつるわれめ

**デフォルトの名無しさん** · 2023/04/06(木) 23:30:16.81

>>94
クラスも構造体も使わずに書いているの？

**デフォルトの名無しさん** · 2023/04/06(木) 23:35:22.20

ああ、callで呼ぶようなものはなんでも関数って言っちゃうねつい

**デフォルトの名無しさん** · 2023/04/07(金) 00:17:10.35

https://www.publickey1.jp/blog/22/ccarbon_languagegooglec.html
こちらはC++との互換性を重視しているらしい
Rustはこの先生きのこれるかな？

**デフォルトの名無しさん** · 2023/04/07(金) 00:31:06.23

そこにこれ載ってた
[RFC] Lifetime annotations for C++
https://discourse.llvm.org/t/61377

Rustは勝利したしかし、Rustはその勝利を独占できない

**デフォルトの名無しさん** · 2023/04/07(金) 03:11:25.56

>>100
こう書いてあるね

提案された有効期間注釈に基づく静的分析では、C++ コード内のすべてのメモリ安全性の問題をキャッチすることはできません。
具体的には、すべての時間メモリの安全性のバグ (反復子の無効化によって引き起こされるバグなど) をキャッチすることはできず、
もちろん、有効期間注釈は空間メモリの安全性 (たとえば、C スタイルの配列の範囲外のインデックス作成) には役立ちません。
詳細な議論については、以下のRustとの比較を参照してください。

**デフォルトの名無しさん** · 2023/04/07(金) 03:22:57.43

>>99
Rustを使えるならばRustを使ったほうが良いと明記されているね

ソース
Carbon公式FAQ
https://github.com/carbon-language/carbon-lang/blob/trunk/docs/project/faq.md#why-not-rust

Why not Rust?
If you can use Rust, ignore Carbon.
If you want to use Rust, and it is technically and economically viable for your project, you should use Rust.
In fact, if you can use Rust or any other established programming language, you should.
Carbon is for organizations and projects that heavily depend on C++

**デフォルトの名無しさん** · 2023/04/07(金) 03:34:46.32

>>101
-Wlifetime とかと組み合わせろってことじゃないん
スマポだけでは解けない課題にこれが要るんだろ
(勉強中なので)知らんけど

**デフォルトの名無しさん** · 2023/04/07(金) 15:30:28.71

動きました。ほんとうにありがとうございました。

use std::ffi::c_void;

#[link(name = "user32")]
#[no_mangle]
extern "stdcall" {
fn MessageBoxA(hWnd: *const c_void, lpMsg: *const u8, lpTitle: *const u8, flg: u64) -> u64;
}

fn main() {
let msg: &[u8] = &vec![65u8, 66u8, 67u8, 0u8];
let lpmsg: *const u8 = &msg[0];
let ttl: &[u8] = &vec![97u8, 98u8, 99u8, 0u8];
let lpttl: *const u8 = &ttl[0];

println!("{}", unsafe { MessageBoxA(0 as *const c_void, lpmsg, lpttl, 3) });
}

**デフォルトの名無しさん** · 2023/04/07(金) 16:14:09.83

>>103
知らないなら書くなよアホが

**デフォルトの名無しさん** · 2023/04/07(金) 16:45:18.17

>>104
こうしろよ
let msg: &[u8] = &vec![65u8, 66u8, 67u8, 0u8];
↓
let msg: &[u8] = b"ABC\0";

**デフォルトの名無しさん** · 2023/04/07(金) 16:51:51.07

さらに*constにするならこれだけでいい
let msg: &[u8] = &vec![65u8, 66u8, 67u8, 0u8];
let lpmsg: *const u8 = &msg[0];
↓
let lpmsg = b"ABC\0" as *const _;

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

>>105
しらんがなｗ

**デフォルトの名無しさん** · 2023/04/08(土) 02:42:49.64

>>104
こっち使え
https://github.com/microsoft/windows-rs
https://www.youtube.com/watch?v=-oZrsCPKsn4

**デフォルトの名無しさん** · 2023/04/09(日) 10:11:37.53

Haskellでrustみたいに
型引数だけじゃなく型引数を引数に取るデータ型に対しても型制約書けたりできるんですか？

**デフォルトの名無しさん** · 2023/04/09(日) 11:45:46.52

逆では？

**デフォルトの名無しさん** · 2023/04/09(日) 14:32:11.00

>>110
もちろんできる
HaskellはRustにできないHKTもサポートしてる

**デフォルトの名無しさん** · 2023/04/10(月) 12:58:57.54

HaskellはH言語に名を改めるべきだな
そしたら興味持つ奴がたくさん出てくる

**デフォルトの名無しさん** · 2023/04/10(月) 13:12:23.09

「すごいH たのしく学ぼう」という本が出版されるのか

**デフォルトの名無しさん** · 2023/04/10(月) 15:02:02.71

いやん、のび太さんのHaskell

**デフォルトの名無しさん** · 2023/04/10(月) 15:30:45.65

はじめてのH

**デフォルトの名無しさん** · 2023/04/12(水) 01:19:12.28

https://i.imgur.com/qUbcNx0.jpg

**デフォルトの名無しさん** · 2023/04/13(木) 18:14:06.57

100%検索引っ掛からねー糞がって話になるわ

**デフォルトの名無しさん** · 2023/04/14(金) 11:40:41.31

無能の内輪ノリで人口への膾炙が遅れただろその本の名前
キモいこと分かってないんだからそういうヤツラが使ってると思われる
日本でコケたのは本の題名のせいだ

**デフォルトの名無しさん** · 2023/04/15(土) 02:05:35.34

ChatGPＴでいいじゃゆ

**デフォルトの名無しさん** · 2023/04/15(土) 09:46:37.00

気が付くと unsafe {} 描きまくってるんだよなぁ orz

**デフォルトの名無しさん** · 2023/04/15(土) 09:48:12.09

>>118
Julia の二の舞だな

>>121
ほんそれ

**デフォルトの名無しさん** · 2023/04/15(土) 10:48:22.69

unsafeは甘え(自戒

C++の生ポも甘え(自戒

**デフォルトの名無しさん** · 2023/04/15(土) 12:33:08.40

mut 付け過ぎもあるかな
let hoge: &mut Vec<u8> = &mut vec![0u8; 256];
for i in 0..hoge.len() { hoge[i] = 255u8; }
の場合と
let mut hoge: Vec<u8> = vec![0u8; 256];
for i in 0..hoge.len() { hoge[i] = 255u8; }
の場合とか

**デフォルトの名無しさん** · 2023/04/15(土) 14:12:22.83

>>121
通常のプログラムの中にunsafeが出てくることはない
unsafeは本質的に新たな構造や仕組みをその原理部分のみ小さくライブラリ化して閉じ込めるときに用いられる
その場合も多くは再発明なので既存のライブラリを使えばよい

**デフォルトの名無しさん** · 2023/04/15(土) 19:28:04.14

現段階でRustを推している人は、「イノベーター」と呼ばれる人で、
『常に最新の情報をチェックしていて、新しい商品やサービスに対する興味を持ちやすいユーザーです。
「新しさ」に価値を感じているのが特徴で、商品の細かい性能や価格はそれほど気にしません。
「最先端」「革新的」などが感じられる商品を積極的に選ぶ傾向があります。』
ということで、「メリット」は余り考えなくて、最先端や革新的であれば
試す人達らしい。牽引役として重要だが、すぐ飽きると言われている。

**デフォルトの名無しさん** · 2023/04/15(土) 19:33:25.66

普及するには、その次に新し物好きなアーリーアダプターが重要らしい。
こちらは新しさだけでなくメリットも考慮して判断すると言われていて、
なおかつ影響力も大きいらしい。
イノベーターは恐らく説得力に乏しいから人を呼ぶ込む力が弱いかも。

**デフォルトの名無しさん** · 2023/04/15(土) 19:33:29.98

こんなとこ(スレ)に溜まる奴らだろ、ライブラリ内製でもしてんじゃねーの

あるいはガチ学習者。学生なら、車輪の一つや二つ、自分で磨いてみるもんだ
青春やり直してる大人も含む

**デフォルトの名無しさん** · 2023/04/15(土) 19:36:01.37

経験から言うと、余りよくない品物、本当は競合と比べてメリットが余りないもの
でも、一定の人は買ってくれる。そして、なぜかその人達は商品を高く評価する。
しかし、実際にはそれ以上進まない。
実は商品の競争力が本当は余り無くてもそういう人達は高く評価するから。

**デフォルトの名無しさん** · 2023/04/15(土) 19:36:32.22

あらら >>128 >>125

まあ、ガチ勢はコード書いてるよね
今ちょっと半田ごてに逃げてる俺も耳が痛いねｗ

**デフォルトの名無しさん** · 2023/04/15(土) 19:38:31.04

過去の例からすると、Rustは非常に限られた分野で普及が進むのかも知れない。
ただ、言語の場合は、プロには無料である事もそんなにメリットにはならないので
どこまでいくかは見通せない。

**デフォルトの名無しさん** · 2023/04/15(土) 19:40:01.02

マニアは、それ自体を楽しんでいるだけで、実用的な仕事に使うことは想定して
なかったりすることが多い。
Rustもそうなのではないか。

**デフォルトの名無しさん** · 2023/04/15(土) 19:42:50.40

>>128
そういう人は、ライブラリ作りも、作ること自体を楽しんだり、自慢や就職に
利用するためにやってるのではないか。また、そういう人には
「沢山の人に使ってもらえれば満足」
などという人も多い傾向がある。

**デフォルトの名無しさん** · 2023/04/15(土) 19:51:35.04

>>125
Rustのunsafeは効率を落とさない限りはライブラリ内部に閉じ込めることが出来
無い事があることが分かってる。
数学的な才能が無い人は、想像力が無いのでそれが分からない。
反論は不要。結論は出ているので。

**デフォルトの名無しさん** · 2023/04/15(土) 20:02:07.05

>>134
もしかしたら、マシン語を理解できないからそのことが分からないのかも知れないな。
「効率を落とさずに」
の意味がマシン語を知らないから分かって無い。
どういうことかと言えば、C言語では1クロックで書けるところが、
Rustだとunsafeをライブラリの中だけに閉じ込めるだけでは、
どうしても1クロックでは書けないことが有る。

**デフォルトの名無しさん** · 2023/04/15(土) 20:24:11.46

Rustもご多分に漏れず
新しいC/C++チャレンジャーが現れて
忘れ去られるんだと思うよ

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

Cは、広義の安全であることが実装者の責任と権限だけど、
そのために余計なステートメントを書かなくちゃいけなくて、
結局Rustのほうが全体ではステップ数がすくなくなる余地はあるぞ

なので、C/C++は、追いつき、追い越さなければならない

**デフォルトの名無しさん** · 2023/04/15(土) 21:49:44.60

クラウド世界トップシェアのAWSもRustで構築されているらしい

https://japan.zdnet.com/article/35183866/
AWD (Amazon Web Services)は、「Rust」を使っている大きな理由として、エネルギー効率の高さを挙げる。
AWSは早くからRustを採用し、Rust Foundationの創設にも携わった。
現在もRustの普及に熱心に取り組んでいる。

AWSのソフトウェアエンジニアで、Rustの普及に取り組む
Shane Miller氏と主任エンジニアのCarl Lerche氏の投稿によれば、
Rustはメモリー安全性を高め、セキュリティ関連の不具合を減らす役に立つだけでなく「エネルギー効率に優れている」。
Amazonは、2025年までにデータセンターの100％を再生エネルギーでまかなうという目標を掲げ、
データセンターの環境負荷の軽減に取り組んでいる。
Rustの採用はその一翼を担うという。

Rustで構築されたAWSサービスの例としては、
コンテナーアプリ用のサーバーレスプラットフォーム「Lamba」を支える「Firecracker」、
「Amazon Simple Storage Service（S3）」、
「Amazon Elastic Compute Cloud（EC2）」、
コンテンツ配信ネットワーク「Amazon CloudFront」、
LinuxベースのコンテナーOS「Bottlerocket」などがある。

**デフォルトの名無しさん** · 2023/04/15(土) 22:30:48.74

大いに主観が入るけど、もっと高級言語から来てる人も多いんじゃないかな
C++に巻き取りたいねえ、負けていられない

**デフォルトの名無しさん** · 2023/04/16(日) 00:07:26.65

イノベーターは後先考えずに新しいものを試す。しかし、ものがよくなければ、
アーリーアダプターには届かず、失速する。それがブーム。

**デフォルトの名無しさん** · 2023/04/16(日) 00:17:13.72

>>140
厳密に言うと、イノベーターは、知識が豊富で、物の「能書き」や「SPEC」をよく
見て自分に合うものを選んでいると言われている。
但し、能書きどおりのものかどうか誰にも分からないような段階で「人柱」状態
で使い始めるから、後から言われた通りになってないことに気付くこともある。
なお、他の階層の人は失敗をしたくないからその時点では試さない。

**デフォルトの名無しさん** · 2023/04/16(日) 00:20:31.86

8年前のRustはそんな感じだった
まだ先があるのかわからなかった

しかしMicrosoftやGoogleやAmazonなど各社でアーリーアダプターたちが実績を示していった
RustはC++より優れていて実用的だと各社が数年かけて認識を確実なものとした
そしてライバル競合IT大手各社が共同でRust Foundationを設立
安定して信頼できる今後のプログラミング言語の地位を確立した

**デフォルトの名無しさん** · 2023/04/16(日) 00:30:44.93

>>142
そんな風には思わないけどな。
そもそもRustやってる人は、現代段階でも人数からいってイノベーターの域を出て
ないし。
そんな風に語らなくても、本当に優れたものであれば噂がたって人気が出てくるはず。

**デフォルトの名無しさん** · 2023/04/16(日) 01:29:25.91

見えてる世界が違いすぎて話にならんよなw
5年前ならまだしも今はもうキャズムを超えてるかどうかなんて議論の余地無いよ

**デフォルトの名無しさん** · 2023/04/16(日) 02:21:00.95

C++はヘッダファイルというウンコをいつまで引き摺ってるのやら

**デフォルトの名無しさん** · 2023/04/16(日) 04:33:04.30

そのウンコに頼らないとCFFIもできないんだから文句言わんといてください

**デフォルトの名無しさん** · 2023/04/16(日) 06:41:40.93

cmakeとかわりといい仕事してるし、いいだろ

Rustが本格的に採用されれば、C++にもやっとsafeの波が訪れるだろう
福音だね

**デフォルトの名無しさん** · 2023/04/16(日) 08:00:51.32

>>134
サンクがゼロコストになりえないみたいなこと?
safe/unsafe間に行き来があるとしても、うまく書ければ最適化でサンクは消失するんじゃないん
基盤がclangだし、そのうちできるようになるか、とっくにできるようになってるか

**デフォルトの名無しさん** · 2023/04/16(日) 08:59:48.91

>>145
C++はCを包含するってのが方針なんで
そこはバッサリ互換性を切り捨てるRustとは違うのだよ

**デフォルトの名無しさん** · 2023/04/16(日) 09:20:17.30

>>148
そいつ>>134はデタラメな主張を繰り返している基地外
数学的に自明と主張しつつその証明を示せなかったホラ吹き

**デフォルトの名無しさん** · 2023/04/16(日) 10:25:57.47

>>150
示せてるのにこの板の人が理解できないだけ。

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

>>148
そうじゃない。
Rustの安全機構をライブラリ外のアプリレベルまで維持したままでは速度が
上げられないケースが存在することが分かっている。
つまり、ライブラリの中だけにunsafeを書いて、アプリコードの中ではunsafe
を使わなかった場合、安全機構と相性が悪くて必ずオーバーヘッドが生じる
場合がある事が分かっている。

**デフォルトの名無しさん** · 2023/04/16(日) 10:31:26.95

バカ同士仲良くやっとけよ
100点オジと複製オジ