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

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

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

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

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

>>504
(1)の段階では問題ないけど
(2)の段階ではitrとpush_backがコンフリクトするからコンパイルエラー

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

>>504
当然エラーは起きない

fn main() {
let mut v = Vec::<i32>::new();
v.reserve_exact(1);
dbg!(v.capacity());
v.push(10);
let first = &v[0];
dbg!(*first);
v.push(11);
dbg!(v.capacity());
dbg!(v.len());
// dbg!(*first); // dangerousなこれを入れたときだけコンパイルエラー
}

[src/main.rs:4] v.capacity() = 1
[src/main.rs:7] *first = 10
[src/main.rs:9] v.capacity() = 4
[src/main.rs:10] v.len() = 2

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

>>505,506
どっちが正しいんだい?

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

ああそれはそうね

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

>>506が正しいよ
オレはdangerousがある前提で考えてたから

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

(2)の段階より前に参照や可変参照があっても
(2)の段階より後に使われなければ
(2)の段階より前までにそれらの参照のスコープが自動的に終わる(＝ライフタイムが尽きる)
したがってコンフリクトは起きない

一方でもしdangerousの部分のコードがある場合は
(2)の段階より後に使われているため
コンフリクトが起きるためコンパイルエラー

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

有難う
reserve_exactの引数が定数1のときには
最終行のdangerousを入れるとコンパイルエラーを出すということだが
reserve_exactの引数が変数で実行時にしか定まらんときは
コンパイルエラーにできないと思うんだが危険じゃね?

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

>>510
なるほどー
Rustってデストラクタはいつ呼ばれるの?
ライフタイムの終わり? あるいはデストラクタはない?

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

>>511
指定サイズは一切関係ない
データ競合が起きないようにmultiple readers or single writerの鉄則に基づく
pushすなわち書き換えたいならば他にreader(参照)もwriter(可変参照)も生きていてはいけない

>>512
所有権を持っている変数がスコープから外れると
所有者が居なくなりデストラクタ相当が呼ばれて自動的に安全にメモリ解放される

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

>>513
>>>511
>指定サイズは一切関係ない
>データ競合が起きないようにmultiple readers or single writerの鉄則に基づく
>pushすなわち書き換えたいならば他にreader(参照)もwriter(可変参照)も生きていてはいけない
pushしたあとはたとえcapacityの範囲内で再配置が行われてないとしても
参照を取得し直すってことかな?

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

>>513
Rustのスコープ=ライフタイムとすると
デストラクタが呼ばれるタイミングが分かり難くないかい?
ちょっとソースをいじって後ろの方でインスタンスを触ると
呼ばれるデストラクタが呼ばれるタイミングも
自動的に後ろになるということかな?
C++ほどデストラクタに処理を書かないのかな?

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

>>514
再配置だけでなく値が書き換わる可能性もある
それらの可能性やそれらの操作を跨いで参照を保持してはいけない
逆に言えば参照を持ち続けることができているならば指している値が変わらないことが保証される
これはバグを防ぐとともにコンパイラによる最適化の余地も広げ高速化にも寄与する

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

>>516
なるほどね
まぁ俺は再配置が起こらないと分かるところで
いちいち参照は取り直したくはないな

Rustのデストラクタが呼ばれるタイミングは
インスタンスのライフタイムで変わりうるということで良い?

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

>>515
デストラクタが呼ばれるのはその変数の「ブロックスコープ」のブロックを出るタイミングだから一定している

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

ブロックスコープって多分C++のスコープと同じだよね?
ライフタイムとまた違うのかな? 複雑だなぁ

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

>>519
誤解をしている
ブロックの途中で打ち切られる可能性があるのは参照のライフタイム
そして参照にはデストラクタはない

一方で値そのもののライフタイムつまり所有権が尽きるのは常にブロックスコープに従う
デストラクタが存在すればブロックを抜けるタイミングで呼ばれる
その後でメモリ解放が自動的に行われる

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

デストラクタは所有してる変数のブロックを抜けるまでに呼ばれることが保証されてるけど
正確なタイミングはコンパイラが決めてるから予測はできない
例えば何かを解放しないと以降で競合が生じる場合はブロックの途中で解放されることもある

ただ
A()
B(&A)
みたいにBがAを参照してるような状況だとBが消えるまでAを動かせないから
結果的にC++と同じように逆順で解放されることになる

ライフタイム周りはコンパイラが制約を満たせる処理順を見つけて裏で調整する感じだから
最初は戸惑うかもしれないね

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

>>521
let _ = x; で棄てる以外に
ブロックの途中でデストラクタが呼ばれるケースあるっけ？

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

>>520
それどこのスマポ

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

>>520,521
なるほどね
参照って読んでるのは>>506だとfirstのことかな?
参照の中にC++のstd::shared_ptrの挙動を内在させてるイメージを持った
Vecのアクセスにiteratorは使わないのかな?

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

>>523
デストラクタにスマポもポインタも関係ない
Rustでは任意の自作型にデストラクタを実装できる
(ただしCopyを実装していないことが条件)

// 例えば整数i32型のみを持つ構造体Foo
struct Foo(i32);

impl Drop for Foo {
// デストラクタ実装
fn drop(&mut self) {
println!("drop: Foo({})", self.0);
}
}

fn main() {
let _x = Foo(123); // メインブロックを終えてからdropされる
{
let _x = Foo(456); // 内ブロックを終えてからdropされる
let _x = Foo(789); // 内ブロックを終えてからdropされる
println!("内ブロック終わり");
}
println!("メインブロック終わり");
}

【実行結果】
内ブロック終わり
drop: Foo(789)
drop: Foo(456)
メインブロック終わり
drop: Foo(123)

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

>>522
すまん
ちょっと勘違いしてた
Dropあると明示的に捨てる必要あるな

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

>>524
C++とRustはiteratorで指すものが微妙に異なるので要注意だがまずは折衷するとして
例えば
let mut v = vec![1, 2, 3];
for p in v.iter_mut() {
*p += 10;
}
これでイテレータを使って11,12,13

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

>>521
Drop scopeがブロックとは限らないだけで予測できないわけではなくね？

>>525
let x = Foo(123).0 * 2;
とか
let mut x = Foo(124);
x = Foo(456);
とか

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

>>527
>>506の let first = &v[0]; の部分をイテレータに差し替えると
（記法は分からんが仮に let first = v.iter() かな?）
イテレータのライフタイムも参照の場合と変わらず
v.push(11);と最終行のdangerousを併存させると
capacityに関わらず問答無用にコンパイルエラーといことかな?

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

>>528
変数が所有している値のデストラクタが呼ばれるのはブロックを抜けた直後だけど
変数が所有しない一時的な値や変数が所有しなくなる代入前の値などは
_へ棄てるのと同じくブロック途中でデストラクタが呼ばれるね

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

Rustってゴミ箱（_）があるんだなw

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

>>529
もちろんイテレータは参照もしくは可変参照を持つ形となるのでsingle writer or multiple readersを満たす必要がある
それを満たせなければコンパイルエラーとなりデータ競合を防げる

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

>>531
棄てるのは _ へ棄てなくてもいくらでも方法があり
例えばブロックを作れば
{
let _tmp = x;
}
これで_tmpへ値が移動してブロックを抜けるときに消える

他にも例えば以下の関数を定義して
fn 棄てる<T>(_tmp: T) {
// 何もなし
}
棄てる(x); とすればその関数へ値が移動して関数ブロックを抜けるときに消える
この棄てる関数は同じものがstd::mem::drop()に用意されているので意図をはっきりさせるためにはそれを使うことで可読性を持たせる

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

>>530
細かいことだけど一時的な値は内部的に一時変数が所有してることになってて一時変数がDrop scopeを抜けていなくなるタイミングでデストラクタが実行される

let _ = Foo(123);やx = Foo(456);は代入によって値の所有者がいなくなるからそのタイミングですぐにデストラクタが実行される

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

>>533
こういうことだわな

#include <iostream>
using namespace std;

struct A {
A () {cout << "constructor\n";}
~A () {cout << "destructor\n";}
};

template <typename T> void drop (unique_ptr <T> &&p) {}

int main () {
auto x {make_unique <A> ()};
{
auto _tmp = move (x);
}
drop (move (x));
return 0;
}

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

dropバグっとるがな

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

ごめんごめん

**デフォルトの名無しさん** · 2023/03/25(土) 09:38:10.15

屁臭

**デフォルトの名無しさん** · 2023/03/25(土) 20:06:44.69

>>504
そういう小さい単純な例ならばdangerousなデータ競合であると自明だが
もっと複雑化して見逃す例が実際に起きてセキュリティの穴になる

**デフォルトの名無しさん** · 2023/03/25(土) 20:52:44.35

デバッガですぐに分かることなので
みょうちくりんな文法を新たに覚えようという動機にはならん

**デフォルトの名無しさん** · 2023/03/25(土) 20:56:23.22

不明な挙動があるのが発見されてない時点でもデバッガ使うの？　変なコード書いた本人に自覚がないから不具合として発現するのであって、正常に動くであろうと期待できてる時点でも？
時間の無駄では？
デバッガでわかるよりコンパイラでわかるなら圧倒的にそっちがベターでもあるし

**デフォルトの名無しさん** · 2023/03/25(土) 20:58:28.17

>>541
>不明な挙動があるのが発見されてない時点で
それはいくらなんでも無理だろw

**デフォルトの名無しさん** · 2023/03/25(土) 20:59:37.07

>>540
デバッガなど実行時でないと検知できないショボいプログラミング言語は滅びそう
昔はC++は神の言語と信じていたけどアドバンテージを全て失ってしまったもの

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

コンパイル時点でチェックが入るのはRustの利点だが
C/C++と乖離した文法を新たに覚えるというコストを払おうとは全く思わん
俺がRustを覚えるとしたらシステムコールがRustで書かれたOSを
使うことになったときだけ
当分ない

**デフォルトの名無しさん** · 2023/03/25(土) 21:04:16.45

>>543
でもLockFreeQueueをsafeで実装できないんでしょ?

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

周りに使用を強制されるほどRustは普及していないので
Rust推しの諸君は自らRustを選択したのだろうけど
そんなにCでのメモリの扱い方に苦労したのかい?
Rust使う人はどちらかというと言語マニアの人達だと思ってたのだが?

**デフォルトの名無しさん** · 2023/03/25(土) 21:14:16.97

>>545
そういうのはすべてsafeなインタフェイスでライブラリが作られてるから
LockFree{Queue,Stack,Map,Set,Chanel}すべてsafeなインタフェイスを用いてRustプログラミングできるよ

**デフォルトの名無しさん** · 2023/03/25(土) 21:17:55.09

>>546
開発効率と可読性が圧倒的にRust＞＞＞C++
Rustはコンパイル時点でミスが見つかるから効率良すぎ
可読性も大差でパターンマッチングの有無も大きい

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

>>547
Rustでプログラミンしたいのではなくて
言語のウリとしている特徴の不備の一例として上げている
平たく言うと中途半端

**デフォルトの名無しさん** · 2023/03/25(土) 21:23:11.57

>>549
すべてがunsafeなC++と違って
RustならLockFree{Queue,Stack,Map,Set,Chanel}をsafeなインタフェイスで使うことで自分の書くプログラムをsafeにできるよ
つまりRustコンパイラが書いたプログラムの安全性の保証をしてくれるよ

**デフォルトの名無しさん** · 2023/03/25(土) 21:36:28.93

>>550
Rustではsafeで全てを表現したいという目論見が破綻した
ということを指摘したい
これで良いかな?
更に良い言語が出るかもね