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

**デフォルトの名無しさん** · 2023/02/25(土) 09:49:46.74

C++の色々配慮してめんどくさい感じは好きだけど、実務になったらメモリ安全性とか考えて今後Rustに変わっていくんかな？

**デフォルトの名無しさん** · 2023/03/17(金) 17:42:50.37

>>404
マジ？信じられん
もし本当ならそのunsafeを使わざるを得なかった例を具体的に出せばいいんじゃね

**デフォルトの名無しさん** · 2023/03/17(金) 17:43:39.56

unsafeをゼロにするよりも、極小なunsafeブロックを組み込んで華麗にキメてほしいね
これはC++も同様

**デフォルトの名無しさん** · 2023/03/17(金) 17:52:35.17

>>400
そういう枯れた古いものをわざわざ書き直すことに熱意を燃やせる人間は少ない
新世代のデータベースやcrypt/blockchainのように金になる新しい成長分野ではc/c++よりもrustがよく使われてる

技術の自然な世代交代は既存システムの置き換えから始まるものではない

**デフォルトの名無しさん** · 2023/03/17(金) 18:01:30.86

>>405
次のことが成り立っていれば教えてもらわなくても自然に分かる:
・マルチスレッドの事を理解している。
・Rustのことを理解している。
・算数的直観力に優れる。

**デフォルトの名無しさん** · 2023/03/17(金) 18:03:48.04

複製おじさん vs 100点おじさん
Fight!

**デフォルトの名無しさん** · 2023/03/17(金) 18:24:08.50

>>401
そのへんの問題もRustだと安全安心なのがいいよなー
特に例外機構を無くしたのは大成功
あとResult放置してると警告もしてくれるしな

>>404
そのunsafe使わないと書けなかったコードを出してみ
寄ってたかって添削してやろう

**デフォルトの名無しさん** · 2023/03/17(金) 18:36:02.65

>>410
俺は天才だから、お前みたいな凡人に無料でヒントをくれてやらない。

**デフォルトの名無しさん** · 2023/03/17(金) 19:13:16.48

Rustって、削ぎ落したものは復活させません、って宣言とかしてるん?

**デフォルトの名無しさん** · 2023/03/17(金) 19:55:25.86

>>408
Rustをあんまり知らんけど言語間に根本的な差はなくね？

**デフォルトの名無しさん** · 2023/03/17(金) 20:02:50.35

>>408はいつものキチガイ
RustもC++もコードを書けたことがない
相手にするだけ無駄

**デフォルトの名無しさん** · 2023/03/17(金) 20:19:10.88

>>414
今さらなに言ってるんだ？
ここにはキチガイしかいないぞ？
俺もお前もな

**デフォルトの名無しさん** · 2023/03/17(金) 20:29:34.70

>>413
ん？だから何？

**デフォルトの名無しさん** · 2023/03/17(金) 21:29:42.97

>>416
アルゴリズムを書ける書けないの差はでない

**デフォルトの名無しさん** · 2023/03/17(金) 23:44:57.66

Rustほとんど知らん俺でも総合的にRustのほうがC++よりはいいだろと思う
C++より後発言語で、で、ライバルになるC＋＋に劣っているようじゃダメだからな
で、お前らは、すごいRustで具体的に何を作っているんだ？

**デフォルトの名無しさん** · 2023/03/18(土) 00:11:15.51

ChatGPT先生に聞いてみた
>>404の言う通り

template <typename T>
class LockFreeStack {
public:
void push(const T& value) {
Node* new_node = new Node(value);
new_node->next = head.load(std::memory_order_relaxed);
while (!head.compare_exchange_weak(new_node->next, new_node,
std::memory_order_release,
std::memory_order_relaxed));
}
std::shared_ptr<T> pop() {
Node* old_head = head.load(std::memory_order_relaxed);
while (old_head && !head.compare_exchange_weak(old_head, old_head->next,
std::memory_order_acquire,
std::memory_order_relaxed));
return old_head ? std::make_shared<T>(old_head->value) : nullptr;
}
private:
struct Node {
T value;
Node* next;
Node(const T& value) : value(value), next(nullptr) {}
};
std::atomic<Node*> head{nullptr};
};

**デフォルトの名無しさん** · 2023/03/18(土) 00:31:48.86

先生にからかわれとるぞｗ

**デフォルトの名無しさん** · 2023/03/18(土) 00:53:02.93

>>419はこれと同じのをRustで書いたらunsafeになる(だろ?)
って言いたいんだろ
偉大なるChatGPT先生が言うんだから間違いないだろな

**デフォルトの名無しさん** · 2023/03/18(土) 00:58:57.68

>>421
いやChatGPTは信用しない方が良い
俺はRustは良く分からんがChatGPT曰く
>Rustには、このようなロックフリーなデータ構造を提供する
>クレート（ライブラリ）が存在します。その一つがcrossbeamです。
>このクレートは、スレッドセーフで効率的なデータ構造を提供しており、
>crossbeam内でUnsafeな操作が行われているにもかかわらず、
>APIを通じて安全に使用できます。
だそうな
crossbeamってRustで書かれとらんのかな?

**デフォルトの名無しさん** · 2023/03/18(土) 01:14:24.86

>>422
本当は、ライブラリの中だけをunsafeにして、アプリ側はsafeに出来るケースも有れば、
アプリ側も unsafe を消せないケースもありえる。

**デフォルトの名無しさん** · 2023/03/18(土) 01:17:39.13

unsafeってキーワード使えばチェックをオフにできるのね

**デフォルトの名無しさん** · 2023/03/18(土) 01:29:02.55

>>420
Rustで書いてみよう！

**デフォルトの名無しさん** · 2023/03/18(土) 04:35:18.48

ArcとAtomicでほぼそのまま書けるけど
pointer dereferenceのためにunsafeは必須

**デフォルトの名無しさん** · 2023/03/18(土) 10:03:55.24

言語マウントごっこにしか使われてないrust

**デフォルトの名無しさん** · 2023/03/18(土) 10:25:46.77

no chance

**デフォルトの名無しさん** · 2023/03/18(土) 11:41:47.24

平日の昼にID真っ赤なのは仕事か
板違いのスレで必死に毎日お疲れさん

**デフォルトの名無しさん** · 2023/03/18(土) 14:02:46.54

ちょうどオライリーから「Rust Atomics and Locks」という本が出てるよ

基本的な内容を説明してる本なのでC++でatomicsやmemory orderingに慣れ親しんでる人がわざわざ買うほどのものではないかもしれないけど
かなりわかりやすくまとまってるのでRustでこの辺りの機能を使ったコードを良く書く人は読んで置いて損はないと思う

**デフォルトの名無しさん** · 2023/03/18(土) 16:09:57.63

ほう
https://bokuweb.github.io/undefined/articles/20230205.html

**デフォルトの名無しさん** · 2023/03/18(土) 18:42:10.12

Lock-Freeなデータ構造を自分で作りたい人はこれを見るといい

Porting Java's ConcurrentHashMap to Rust (part 1)
https://www.youtube.com/watch?v=yQFWmGaFBjk

**デフォルトの名無しさん** · 2023/03/19(日) 12:22:41.89

> cargo new hoge
> cargo run
→ 3MB
main.rs に
use clap::Parser;
追加すると
> cargo run
→ 100MB 超えるんだが
どうすれば容量減らせるん？

**デフォルトの名無しさん** · 2023/03/19(日) 12:44:51.20

とりあえず--releaseつける

**デフォルトの名無しさん** · 2023/03/19(日) 13:32:03.94

しらんけど
https://igaguri.はてなぶろぐ.com/entry/2020/06/07/133847
https://crates.io/crates/cargo-clean-recursive

**デフォルトの名無しさん** · 2023/03/19(日) 13:35:18.59

とりあえずは
cargo clean
で良いはず
最初から余計なのは造りたくないって言う話ならほんまにしらん

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

>>436
ありがとうございました

**デフォルトの名無しさん** · 2023/03/20(月) 08:59:55.73

やっぱC++にもボローチェッカ欲しい
なんならCにも欲しい
attributeとか併用したら、やってできないことはないんじゃねーの

**デフォルトの名無しさん** · 2023/03/21(火) 17:20:17.93

rg3d はなぜ
https://github.com/rg3dengine/rg3d
から
https://github.com/FyroxEngine/Fyrox
に改名したのですか？

**デフォルトの名無しさん** · 2023/03/21(火) 17:50:34.39

rustの読み物公式が面白いのしっかり出してるから
それ読むだけでも大分良い
後発言語らしくイイトコどりしまくってる
null無くした代わりになんでもかんでもラップしてるから若干だるいけど
すげー面白い

**デフォルトの名無しさん** · 2023/03/21(火) 19:41:09.03

Unity超えるゲームエンジン作ってから言え

**デフォルトの名無しさん** · 2023/03/21(火) 19:42:14.14

Blenderとかでもいいよ

**デフォルトの名無しさん** · 2023/03/21(火) 21:54:25.24

cpp2rsみたいのがじきできるから、そしたら一発
ただ、それだと、safeではあるけど、Rustのシンプルさは(メリットとして)失うな

**デフォルトの名無しさん** · 2023/03/22(水) 07:30:44.03

>>443
ほんとにできる？

**デフォルトの名無しさん** · 2023/03/22(水) 09:09:27.85

文法がRustなだけで
Rustのコードとして使い物にならん
ゲテモノが出て来るわ
今のGPTも酷い

**デフォルトの名無しさん** · 2023/03/22(水) 09:47:28.48

ああ、あと全自動とは言わないあっちこっちで、あれなおせーこれなおせーって言われるかと

**デフォルトの名無しさん** · 2023/03/22(水) 10:40:01.19

たしかに、C++でメモリ安全性を静的チェックするツールを作るのはなかなか難しいもんかね？

**デフォルトの名無しさん** · 2023/03/22(水) 12:19:59.74

gccだとvargrindとかあるけどね

**デフォルトの名無しさん** · 2023/03/22(水) 14:27:48.09

valgrindはgcc関係なくないか？
rustでもメモリリークの確認に使う

有用なツールだけど静的チェックと呼べるのかは疑問

**デフォルトの名無しさん** · 2023/03/22(水) 21:31:28.83

valgrindは実行時チェックだから出現レアケースだと時間内に検出できない

**デフォルトの名無しさん** · 2023/03/22(水) 21:43:05.82

AddressSanitizerでもValgrindでもmtraceでも好きなの選べ
https://kivantium.hateblo.jp/entry/2018/07/14/233027

**デフォルトの名無しさん** · 2023/03/22(水) 21:46:10.74

全て実行時チェックだな

**デフォルトの名無しさん** · 2023/03/22(水) 21:54:30.07

静的ツールだとこんなのもあるね
https://cppcheck.sourceforge.io/

スマートポインタ使えばそもそもいらんがね

**デフォルトの名無しさん** · 2023/03/23(木) 11:01:43.91

C++で出来る人には要らん

**デフォルトの名無しさん** · 2023/03/23(木) 11:35:46.79

メモリ不安全の何が悪いかってメモリリークじゃなくて間違った場所にアクセスしちゃうことだと思うのだが

**デフォルトの名無しさん** · 2023/03/23(木) 11:37:47.99

>>455
例えばどういう状況かな?

**デフォルトの名無しさん** · 2023/03/23(木) 13:26:58.89

>>456
ゲームのバグとか

**デフォルトの名無しさん** · 2023/03/23(木) 13:54:38.12

Segmentation fault：呼んだ？

**デフォルトの名無しさん** · 2023/03/23(木) 14:56:19.59

Windowsで実行しています
https://doc.rust-lang.org/stable/std/process/
ここを観て
use std::process::{Command, Stdio};
let c = "cmd";
let a = "/c echo Hello, world!";
let o = Command::new(c).arg(a).output().expect("Failed to start process");
let v1 = o.stdout.as_slice();
すると v に必ず
[0x48, 0x65, 0x6c, 0x6c, 0x6f, 0x2c, 0x20,
0x77, 0x6f, 0x72, 0x6c, 0x64, 0x21, 0x22, 0x0d, 0x0a]
が入ります
let p = Command::new(c).arg(a).stdout(Stdio::piped()).spawn().expect("Failed to start process");
let e = p.wait_with_output().expect("Failed to open stdout");
let v2 = e.stdout.as_slice();
としても結果同じです
Hello, world!"+改行
で余計な"が入っているのですがなぜでしょう？どのように取り除くのが正しい対処方法を教えて！！

**デフォルトの名無しさん** · 2023/03/23(木) 15:07:48.89

let o = Command::new(c).args(&["/c", "echo Hello, world!"]).output().expect("Failed to start process");

**デフォルトの名無しさん** · 2023/03/23(木) 17:25:27.77

C++は例外処理とかもバグを生みやすくしていると思う

**デフォルトの名無しさん** · 2023/03/23(木) 19:55:36.72

C++にmoveや右辺値参照ができる前に挫折した連中がRustスゲーとか言うのは何か違うと思う。

**デフォルトの名無しさん** · 2023/03/23(木) 20:30:50.18

失敗だか挫折だか知らんけど
失敗してもお金が減らない失敗は半分大成功だよ

**デフォルトの名無しさん** · 2023/03/23(木) 23:42:04.79

とりあえず3つに絞るとして
(1)ダングリングがないメモリ安全性の保証
(2)データやポインタのヌル安全性の保証
(3)データ競合がない安全性の保証
Rustはコンパイラが通れば保証されるが
C++は(2)(3)は無理として(1)についてもプログラマーがどんなに複雑化してもミスなく記述できた場合のみその自己責任で実現
そのためC++ではバグやセキュリティの穴が現在進行形で量産されている

**デフォルトの名無しさん** · 2023/03/23(木) 23:55:58.81

でもRustはLockFreeQueueをunsafeにしか書けないでしょ?

**デフォルトの名無しさん** · 2023/03/24(金) 00:33:14.50

LockFreeQueueもsafeなインタフェースを提供できている
https://docs.rs/lockfree/
中身はunsafeを使う部分が一部あるが全てコメントに理由が記述されているようにsafeな操作でありその部分の安全性のみを人が保証
Rustの最大の特徴はこのようにunsafeを使ったsafeな操作を内部に封じ込めて外部にsafeなインタフェースを提供できること
そしてそのライブラリを使った任意のプログラム全体の安全性がRustコンパイラにより保証される

**デフォルトの名無しさん** · 2023/03/24(金) 01:00:04.81

>>466
Rustにはunsafeを認めるんだなw アンフェアだね
C++もスマートポインタを使えばメモリリークは起こらんのだよ

**デフォルトの名無しさん** · 2023/03/24(金) 01:01:07.83

full safeが至上なんじゃないんだよ
それだとマイコンでrustが使えなくなるし、safe C++だって実現しなくなる

**デフォルトの名無しさん** · 2023/03/24(金) 01:08:19.45

C#もAOTコンパイルに対応したしもうこっちでよくねる

**デフォルトの名無しさん** · 2023/03/24(金) 01:13:06.10

>>468
safeじゃないRustねぇw 苦しいな
言語を覚えるのが趣味なら使えば

**デフォルトの名無しさん** · 2023/03/24(金) 01:15:17.05

スマポスマポいうけどさ、なら、スマポオンリーっていうpragmaつくればよくね
それとC++はなんでもかんでもnewする習慣がついちゃって、
そこはスタックに物を置きたくなるRustのほうが能率よくなっちゃってねえか

**デフォルトの名無しさん** · 2023/03/24(金) 01:22:55.16

>>467
違いは明白

C++はプログラム全てがunsafeエリア(＝人が安全性を保証する)
Rustはプログラムのほとんとがsafeエリア(＝コンパイラが安全性を保証する)
（Rustには一部の閉じ込められた局所的な部分のみunsafeが存在しそこに限定して人が安全性を保証する）

**デフォルトの名無しさん** · 2023/03/24(金) 01:25:05.80

C#でいいやって時代が来そうだな
.NET7でAOTコンパイル対応したから
Rustなんかより遥かに簡単だし

**デフォルトの名無しさん** · 2023/03/24(金) 01:25:34.49

たとえば、メモリマップドI/Oが扱えない言語は、本気でやりこもうとは思えない
ちなみに、C#はプリコンパイルできるスクリプト言語として、とても便利に日々使ってる

**デフォルトの名無しさん** · 2023/03/24(金) 01:34:37.55

>>474
まぁ時期対応するでしょ
使ってる人Rustより遥かに多いし

**デフォルトの名無しさん** · 2023/03/24(金) 01:35:44.19

>>472
後退したなw
Rustを覚えるよりもスマートポインタ使う方がずっと楽だよ
どうせC言語は覚えなきゃならんのだから
C/Rustを覚えるよりC/C++を覚える方がずっと効率的

**デフォルトの名無しさん** · 2023/03/24(金) 01:36:16.07

>>473
C#はC++やRustのカバーする範囲を全く満たせないのでこのスレでは論外
C#はGCがあるし省メモリや高速性もないし更にはインラインアセンブリも書けない

**デフォルトの名無しさん** · 2023/03/24(金) 01:39:04.57

>>477
AOTにするとGCとか無くなるよ

**デフォルトの名無しさん** · 2023/03/24(金) 01:39:24.39

>>477
AOTに対応したんだから速度では勝負できるよ

**デフォルトの名無しさん** · 2023/03/24(金) 01:41:10.62

まぁこれ見てくれ
https://takym.github.io/blog/general/2022/12/25/osdotnet.html

**デフォルトの名無しさん** · 2023/03/24(金) 01:41:24.23

>>478
へー
JavaのAOTってgcjのやつはGCなかったっけ?
C#のAOTはGCなくなるんだ

**デフォルトの名無しさん** · 2023/03/24(金) 01:42:48.96

>>476
後退って何？
Rustはコンパイラが安全性を保証できる言語でC++は人が安全性を保証する言語で何も変わっていない
C++スマポでなんとかできる安全性の範囲は>>464のうちの(1)だけだから話にならない

**デフォルトの名無しさん** · 2023/03/24(金) 01:45:09.38

>>482
>後退って何？
おまいさんのディフェンスライン

**デフォルトの名無しさん** · 2023/03/24(金) 01:48:33.41

また髪の話してる

**デフォルトの名無しさん** · 2023/03/24(金) 01:52:02.45

>>478
嘘つき
C#はGC言語なのでAOTコンパイルしようがGCは無くなりません
C#がC/C++/Rustの代わりになることはできません

**デフォルトの名無しさん** · 2023/03/24(金) 01:54:42.93

C++って今もvectorの要素を参照しながら末尾に要素を追加しまくると参照先がいなくなる事故は発生すると思う
最近のC++はよく知らないけどスマートポインタで防げるの？

**デフォルトの名無しさん** · 2023/03/24(金) 01:54:57.32

>>464
>(3)データ競合がない安全性の保証
共有データをスマートポインタに入れといて
アクセスする際には共有データではなくて
一時Proxyを経由してアクセスすればよい
Proxyのコンストラクタでロックしてデストラクタでアンロックする
RustのMutex相当で簡単に実装出来る

>(2)データやポインタのヌル安全性の保証
これはどういうこと? 静的に保証しろってことかな?

**デフォルトの名無しさん** · 2023/03/24(金) 01:57:35.21

>>486
vectorは連続するアドレスに領域を取ることが保証されているコンテナなので
末尾に要素をしてcapacityを超えると当然再配置が起こる
他のコンテナを使うべし

**デフォルトの名無しさん** · 2023/03/24(金) 02:03:47.17

>>486
もし最大要素数が決まってるなら
vectorで領域をreserveしといて
その範囲で追加ってことなら
再配置は起こらない
いずれにしても仕様を調べて使うべし

**デフォルトの名無しさん** · 2023/03/24(金) 02:07:17.26

>>488
>>489
サンクス
なんかスマートポインタ推されてるからリアロケーション追跡するポインタとか出来てるのかと思った

**デフォルトの名無しさん** · 2023/03/24(金) 02:12:19.33

>>487
C++のスマポは使い方をミスったらおしまいで実際に問題を起こし続けている欠陥品
null安全か否かは言語仕様で決まりもちろん静的に防げる
当然C++はnull安全な言語ではない

>>488
vectorの自動メモリ再配置によるダングリング発生がうっかりミスで容易に発生するC++は欠陥言語

**デフォルトの名無しさん** · 2023/03/24(金) 02:30:27.68

>>491
>C++のスマポは使い方をミスったらおしまいで実際に問題を起こし続けている欠陥品
どういうミスかな? 書いてみ

>null安全か否かは言語仕様で決まりもちろん静的に防げる
これもどういうケースを言っているのか分からんので書いてみて

>vectorの自動メモリ再配置によるダングリング発生がうっかりミスで容易に発生するC++は欠陥言語
連続するアドレスに領域を取ることが保証されているコンテナはRustにはないのかな?
C++はもちろんメモリ再配置しない（領域が連続しない）コンテナを選択できる

反論したいので具体的に書いてね
無理かもしれんがもし書けるならC++のソースで例示してね

**デフォルトの名無しさん** · 2023/03/24(金) 02:43:13.61

ちゃんと書けば動く、は言語として甘え
C++は一刻も早く進化すべきだ

**デフォルトの名無しさん** · 2023/03/24(金) 02:54:47.10

具体的にね

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

>>491
欠陥言語というか他の言語たちと比べればCやC++はわずかなミスで危険なことになるから大きなマイナスかもしれないけど
省メモリで高速という他の言語では得られない巨大なプラスがあるからC++は必須の存在だったのよ
今はその巨大なプラスがありつつマイナスのないRustが登場したからC++は価値がなくなり役目を終えたけどね

**デフォルトの名無しさん** · 2023/03/24(金) 04:28:25.21

>>495
役目を終えたならC++で書かれた全てのソフトウェアがRustになってもおかしくないけど全くそうじゃないよな？

**デフォルトの名無しさん** · 2023/03/24(金) 04:38:49.00

>>496
既存システムの書き直しは時間と費用がかかるからやるとしても少しずつでしょ
多くのシステムは大規模更新時の機会にでしょ
新規に登場したシステムはRust製になっていってますね

**デフォルトの名無しさん** · 2023/03/24(金) 04:46:18.91

>>497
ならないと思うけどね
まぁ何言っても無駄かw

**デフォルトの名無しさん** · 2023/03/24(金) 05:43:54.98

そもそもC++ってCと比較しても脆弱性が下がる気がする。
なんか初心者泣かせのトラップが多すぎるんだよな。

**デフォルトの名無しさん** · 2023/03/24(金) 05:50:11.50

>>460
ありがとうございました

**デフォルトの名無しさん** · 2023/03/24(金) 05:58:04.68

>>484
GCって禿のことだったんですね

**デフォルトの名無しさん** · 2023/03/24(金) 06:06:32.31

>>499
>初心者泣かせのトラップ

むしろ知ったかがドツボに嵌る

**デフォルトの名無しさん** · 2023/03/24(金) 10:43:05.72

>>492
rustのvectorは再配置される可能性がある操作時は他からの参照がないことがコンパイル時に保証されるので連続領域でも問題ないよ

**デフォルトの名無しさん** · 2023/03/24(金) 11:32:45.65

>>503
ほう! Rustはよう知らんのでC++で聞いて申し訳ないが
以下コメントの部分(1)と(2)は
Rustで相当するコードを書いたらコンパイルが通らないということかな?
#include <iostream>
#include <vector>
#define DOUT(arg) std::cout << #arg": " << arg << '\n';
int main () {
std::vector <int> v;
v.reserve (1);
DOUT (v.capacity ());
v.push_back (10); // (1) Rustで許容 or エラー?
auto itr {v.begin ()};
DOUT (*itr);
v.push_back (11); // (2) Rustで許容 or エラー?
DOUT (v.capacity ());
// DOUT (*itr); // dangerous
return 0;
}
$ ./a.out
v.capacity (): 1
*itr: 10
v.capacity (): 2