結局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/18(火) 19:54:50.00

>>254-255
ほんそれ

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

コンパイラのエラーメッセージを見ずにヒントだけを見るようなバカは
他のことでも重要部分を見ずに枝葉だけを見て失敗してきているんだろうな

**デフォルトの名無しさん** · 2023/04/18(火) 22:19:21.28

いやーすんませんねバカで
実際ライフタイム系エラーメッセージって他のエラーに比してかなり分かりづらいと思うんだけど、読み方のコツとかあったら教えてくれませんかね？

**デフォルトの名無しさん** · 2023/04/18(火) 22:56:45.81

OOP言語のクラスと同じ感覚で構造体のフィールド組むとライフタイムのトラブルに嵌る気がする
Rustの構造体は一緒に使うデータというより一緒に捨てるデータのイメージだから
ライフタイム無しの構造体：データベースのテーブルのレコード
ライフタイム有りの構造体：↑を参照するビューのレコード
みたいな設計を意識するといいかも（RDBほど正規化を気にする必要はない）
こうするとビューが参照するテーブルごとにライフタイムパラメータが存在する形になる
あくまで個人の考え方というか経験論だから参考程度に

**デフォルトの名無しさん** · 2023/04/19(水) 00:20:32.62

教師ありでも教師なしでも遅かれ早かれ同じ道を通りそうな方向に行く
教師ありの場合にしか通らない所で過学習しない

**デフォルトの名無しさん** · 2023/04/19(水) 00:45:23.08

>>259
スクリプト言語から来たんだけど
これまでなんでも連想配列に突っ込んでいたのが
実はアクセス毎にハッシュ値を計算して、ハッシュテーブルの衝突比較をして、ようやくたどり着くのを実感しちゃった
基本的にVecで持っていて、テーブルを引かなければならない時だけ使うHashMapを持つのがいいのかな

**デフォルトの名無しさん** · 2023/04/19(水) 09:43:31.13

>>246
狙ってできるということは、ぼーっとしてると踏むかもしれないってことだよな?

ライフタイムは銀の弾丸だ! みたいに、お題目のように言ってくるコピペへの反論として、
ちゃんと書かなきゃいけない、の主戦場がライフタイムの記述に移っただけじゃんってことでおっけー?

うんでも、template<> に近い感覚を覚えた、親しみを覚えたかな
はやくC++にも来ればいいのに

**デフォルトの名無しさん** · 2023/04/19(水) 10:00:52.83

普通に使われない書き方を恣意的に作らないと起きないため
実害なしとして放置となっている

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

別にいいよ、放置で
でもそれを、(コピペ勢がいうような)安全っては言わない

俺は正確に、どう安全か知って使いたいんだ

C++だって、「そんな書き方すんなよ」ってのを踏むヤツが後を絶たない
だから、「書きようが悪いだけ」なんて反論が出るわけだ

**デフォルトの名無しさん** · 2023/04/19(水) 10:31:19.03

C++は初心者が自然に間違えて踏んでしまう
慣れているプロですら複雑化したときには間違えて陥ってしまう
そして現実に何度も何度も何度もプロたちがミスってきたからMicrosoftやGoogleなどIT大手も匙を投げ始めた

そのRustの件は初心者が間違えて踏んでしまうことは決してなく
慣れているプロが複雑化したときもそんな状況に陥ることはない
強引に恣意的にそれを目指して作り出さないと生じない

**デフォルトの名無しさん** · 2023/04/19(水) 10:35:26.97

> 初心者が間違えて踏んでしまうことは決してなく

ここだねえ穴があったら、落ちるもんなんだよ

そこんとこは、コピペ勢に証明してもらうとするわ
俺が気に入らないのはコピペ勢だ、あいつら俺の母語を侮辱するからね

**デフォルトの名無しさん** · 2023/04/19(水) 11:03:31.64

現状追認主義ここに極まれり
もはや信者以外の何者でもない

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

ソースコードで示してって言うと
理解しないままの受け売りなのですぐにボロが出る
ChatGPTの流行をマジで危惧してるよ

**デフォルトの名無しさん** · 2023/04/19(水) 11:57:16.55

>>266
初心者が誤ってunsafe宣言するかな？

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

そうじゃないけど、それもあるな
ちゃんと規制しないと、unsafe 使いまくられたら一緒じゃんｗｗって反論もできるな

**デフォルトの名無しさん** · 2023/04/19(水) 14:59:19.03

思わぬところに反論しときたいんだが

>>265
> 何度も何度も何度もプロたちがミスってきた

ここはちょっと要検証じゃねたとえば、Chromium/Chromeは精鋭だけで書かれたのか
ガチプロはそんなミスしないんだよ、ガチプロはスマポを使いこなすし、静的解析に通るように綺麗に書く
だから、「馬鹿にするな、C++が悪いんじゃない、悪い奴が悪いんだ」って反論も出る

C++はプロじゃない人間も使う、例えば俺だから、C++にもunsafe{ } が必要なんだ

些細なようだが、ちゃんとしてるプロをバカにすることはない
敬意を払うのは人の為ならず(自分のため)

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

>>271
>ガチプロはそんなミスしないんだよ、ガチプロはスマポを使いこなすし、
使いこなすって表現するほどスマートポインタは御大層なものではない
そもそもmake_uniquやmake_sharedするのは
俺の場合は全インスタンスの1割弱だよ（newは一切無い）
operator newを呼ばずにインスタンスを作るのが9割超

**デフォルトの名無しさん** · 2023/04/19(水) 16:53:43.84

>>264
>C++だって、「そんな書き方すんなよ」ってのを踏むヤツが後を絶たない

これな
前にも誰か言ってたが vector にぶっこんだデータを参照するときに
再配置が起きると参照先が無くなって困るとか
そりゃ再配置が起きるような書き方してる方が悪いんだよ

**デフォルトの名無しさん** · 2023/04/19(水) 18:49:07.48

よくわからんが、プログラマーはlifetimeのパラメーターを明示的に実体化できないんだよね
人間の代わりにコンパイラが暗黙に自動的に実体化する
なんで人間が何か踏んだとか人間が穴に落ちたみたいに言われてるんだ？

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

コンパイラが調整する余白部分はあるけど包含関係を明示する程度にはプログラマが指定できる

ライフタイムは
「関数内のローカル変数の参照を関数の外にreturnしても受け取った側では使えなくなってる」
みたいなC++でも一般的なルールを概念的に表してるだけだよ
関数じゃなくブロック単位でスタックを伸縮させるコード生成があるかは知らないけど
ライフタイムはスタックのどの辺にそのデータ（の根拠）が置かれているかにおよそ対応してて
スタックの先端の方ほどライフタイムは短くなるし根元に近いほどライフタイムは長くなる

参照値の場所より根元の方を参照する分にはとりあえず安全だけど参照値より先端の方を参照してると
知らないうちに処理が進んでスタックが短縮されて参照先が無効になるかもしれない
そういう参照エラーをコンパイラで排除するためにライフタイムが使われてる
参照先は参照元より根元に近い（長生きする）ことが保証されてる範囲でしか認めない感じかな

実際は参照値もデータもスタック上で引っ越したりするし
被参照中はそのデータが動かせなくなるみたいな別のルールもあるからややこしいけど

**デフォルトの名無しさん** · 2023/04/20(木) 00:49:58.65

Rustについて教えてちょ
以下はsizeが実行時に与えられるので
vについてアクセス違反を起こしていないかコンパイル時には
チェックできないと思うのだけどRustで書くとどうなるのかな?
#include <iostream>
#include <vector>
using namespace std;
int main () {
vector <int> v {1, 2, 3};
size_t size;
cin >> size;
if (v.size () < size)
{
cerr << "The specified number must be less than or equal to " << v.size () << ".\n";
return -1;
}
for (size_t i {0}; i < size; ++ i)
cout << v [i] << '\n';
return 0;
}

**デフォルトの名無しさん** · 2023/04/20(木) 00:51:46.92

そ、そんなに言うんだったら、お、俺もRust始めてみるよ

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

>>276
Rustは基本bound checkがされるからそれっぽいコードだと実行時にパニックで落ちる

bound checkも避けて落ちないようにするならイテレータをtake(size)する

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

他言語なら0..min(v.len(), size)とかもあるだろうけどRustではあんまりやらないと思う

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

Rustにはindexでアクセスするコンテナってやっぱないのかな?

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

>>278
>Rustは基本bound checkがされるからそれっぽいコードだと実行時にパニックで落ちる
あれ!? ということはコンパイルは通るの?

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

Rustでは普通こう書く
for n in v.iter().take(input_size) {
println!("{n}");
}

どうしてもインデックスでアクセスしたいなら
他の言語と同じく小さい方まで回す
let ok_size = min(v.len(), input_size);
for i in 0..ok_size {
let n = v[i];
println!("{n}");
}

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

あとはインデックスを使いminを使わないならばこうかな
for i in (0..v.len()).take_while(|&i| i < input_size) {
let n = v[i];
println!("n={n}");
}

3つとも同じ動作となるけど
簡潔かつインデックス不要な最初の方法がRustでは普通

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

>>282
ありがとう
最初のはinput_sizeがvの要素数よりデカかったらどうなるの?

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

>>282,283
3つともunsafeで囲まなくてもコンパイルは通るのでしょうか?

**デフォルトの名無しさん** · 2023/04/20(木) 02:22:14.41

>>284
イテレータのtake(n)は最大n個になる
その前のv.iter()からv.len()個の参照が来る
だからnがv.len()より多くてもそれ以上ポインタは進まず安全

>>285
unsafeは必要ない
自分ですぐ試せるからここで何でもやってみればいい
https://play.rust-lang.org/
Rustで普通に使っていてunsafeは出て来ない

unsafeが出てくるのは例えば
FFIでC言語など別言語からの変換とか
既存ライブラリにない新たな仕組みの型を作り出すときに
unsafeを使わざるを得なくてunsafeを閉じ込めて安全なインタフェースを提供する場合

**デフォルトの名無しさん** · 2023/04/20(木) 02:38:45.55

>>283
(0..v.len())でインデックスを作ってると思うのだけど
コンパイラはfor節の中でアクセスされるvのサイズと
インデックスの最大値の比較まで行ってるってことかぁ

**デフォルトの名無しさん** · 2023/04/20(木) 02:54:57.60

>>287
例えば 0..10 は0から10未満つまり0から9までの数値を返すイテレータ
インデックスかどうかは関係ないし配列やVecとも無関係
非負数値だからたまたまインデックスとしても使えるというだけ

いずれにせよ配列やVecのシーケンシャルアクセスにインデックスを使うのは無駄なので
インデックスは使わずに>>282の前者を使おう

**デフォルトの名無しさん** · 2023/04/20(木) 03:11:11.34

ボローチェッカの挙動を知りたいのだよ
以下だとコンパイルは通らないんだよね?

for i in (0..100).take_while(|&i| i < input_size) {
let n = v[i];
println!("n={n}");
}

**デフォルトの名無しさん** · 2023/04/20(木) 05:14:11.17

コンパイルも通る
そこには借用(ボロー)つまり参照がないからボローチェッカーは無関係
厳密にはtake_whieは参照を取るが対象が整数値なのでコピーして比較していて無関係
let n = v[i]; も整数値のコピーなので無関係

ちなみにC以外ほとんどの言語と同様に v[i] は安全にインデックス範囲チェックが行われる
範囲チェックの結果を受け取りたいならばget()によりOptionを得ることもできる
例えばこれで安全にアクセスできる
if let Some(n) = v.get(i) {
println!("n={n}");
}

シーケンシャルアクセスならインデックスによるアクセスの必要性がないので
v.iter()を使い安全に各要素の参照を得ることができる
したがって>>282の前者が簡潔で可読性もよく安全で高速なRustでの普通の書き方

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

>>290
なるほど

>ちなみにC以外ほとんどの言語と同様に v[i] は安全にインデックス範囲チェックが行われる
C++でいうと以下のような感じなのかな?

for (size_t i {0}; i < input_size; ++ i)
cout << v.at (i) << '\n';

Rustはメモリアクセス違反を何でもかんでもコンパイルで弾けるわけじゃないのね

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

アクセス違反が発生しても何となく動き続けることがなければとりあえずセーフの精神
unsafe内でuncheckにするオプションも用意されてることが多いけど

**デフォルトの名無しさん** · 2023/04/20(木) 11:29:56.72

DoSにつながるから、落ちるのはよくないみたいに言われたりするんだけど、
変に無理に動き続けるより、異常を見つけたら落としたほうがいいときってあると思うんだよな
落ちるバグはコールスタック残ってればいち早く潰すだろうし

**デフォルトの名無しさん** · 2023/04/20(木) 11:44:16.22

バッファオーバーフローみたいな脆弱性につながるから落とすほうが安全なんだよ

**デフォルトの名無しさん** · 2023/04/20(木) 11:48:21.96

C/C++とは異なり、Rustは範囲外メモリアクセスを絶対に起こさないことが保証される点が決定的な違い
シーケンシャルアクセスでは、Rustではv.iter()とイテレータを使い、結果的に終端アドレスに達するまでポインタが進むのと同じ生成コードになるので、最高速かつ安全に範囲内のみのコードになる
そのうえで、v.iter().take(input_size)など様々な条件や加工などをするイテレータメソッドを複数組み合わせて、メソッドチェーンにより簡潔な記述をするのがRustでの書き方

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

>>295
ディフェンスラインが後退したな
STLのコンテナもatでアクセスすれば範囲外アクセスで例外を投げるので同じ
オーバーヘッドが気になるならoperator[]によるアクセスも
イテレータによるアクセスも選択できる

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

C/C++はポインタと配列の区別があやふやだ

まず配列という概念がない言語でポインタの問題だけを解決し
それから配列をたんなるライブラリとして追加するほうが無駄なトラブルが少ない
配列すらない状態に一旦後退するのは正しい

その意味では、ジェネリクスがない状態に後退できるC/C++を見習うべきだったとも言える

**デフォルトの名無しさん** · 2023/04/20(木) 18:25:05.04

>>296
違いはここ
・安全な言語：　範囲外アクセスをすることが絶対にない
・安全でない言語：　範囲外アクセスをしてしまう
CとC++は不合格

**デフォルトの名無しさん** · 2023/04/20(木) 19:53:34.14

>>298
範囲外かどうかチェックのオーバーヘッドがあるのではないのかな?
C++はチェックありもなしも選択できるんだよ

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

Rustもインデックス範囲内チェックの有り無しを選べる
基本的にはインデックスは使われず、安全な範囲内に動くポインタのみを、自在に各種イテレータメソッドで扱うため、オーバーヘッドはゼロ
唯一の例外が真のランダムアクセスで、範囲内のインデックス値か不明なものを扱うため、インデックス毎に範囲内チェックは絶対に不可避なためコストがかかる
その場合でも、範囲内のインデックス値しか来ない構造ならば、新たな型をunsafeなget_unchecked()を用いてそれを閉じ込めて、安全なインターフェースとして提供できるため、オーバーヘッドはゼロ

**デフォルトの名無しさん** · 2023/04/20(木) 21:12:04.09

>>300
それC++と何が違うのかな?

**デフォルトの名無しさん** · 2023/04/20(木) 21:17:13.53

チェックを忘れて脆弱性を埋め込むリスクが桁違い

**デフォルトの名無しさん** · 2023/04/20(木) 21:33:10.92

>>302
すまんが何が違うかを書いてくれないかな?
あるいは>>300が何を言わんとしているか
他の人の解説でもいいんだけど

**デフォルトの名無しさん** · 2023/04/20(木) 21:38:15.36

＞その場合でも、範囲内のインデックス値しか来ない構造ならば
この判断を誤ると結局脆弱性が埋め込まれそうだけど、
チェックを忘れることに比べれば起こりにくいのかもね

**デフォルトの名無しさん** · 2023/04/20(木) 21:40:24.96

>>301
オーバーヘッドに関してはC++もRustも最小限にすることができて同じ
安全性に関しては範囲外アクセスが生じうるC++のみ安全でない

**デフォルトの名無しさん** · 2023/04/20(木) 21:40:47.43

私は違いがサッパリ分からんぞ

**デフォルトの名無しさん** · 2023/04/20(木) 21:44:22.16

>>305
>安全性に関しては範囲外アクセスが生じうるC++のみ安全でない
範囲外チェックなしでインデックスでアクセスしたら
Rustも危険なのでは?

**デフォルトの名無しさん** · 2023/04/20(木) 21:51:17.50

>>304 >>307
その場合は、一般的にunsafeを閉じ込めてsafeなインタフェースを提供する新たな型をモジュールとして提供する
そのモジュール部分のみを人間が安全性を保証する形になり、その利用者側はRustコンパイラが安全性を保証する
したがってそれを利用する側のプログラマーのミスで範囲外アクセスなどが起きることはない

**デフォルトの名無しさん** · 2023/04/20(木) 21:56:16.00

>>308
今はそのunsafeに閉じ込める部分に
C++とRustで差があるのか無いのかを議論している
お分かりかな?

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

>>307
私はせっかちなので自分で議論を進めると（と言っても私はRustは分からんのだが）
範囲外チェックなしでインデックスでアクセスできる -> Rustも同様に危険
範囲外チェックなしでインデックスでアクセスできない -> Rustはオーバヘッドがある
ということになる

**デフォルトの名無しさん** · 2023/04/20(木) 22:03:11.36

複オジの説明がクソだから伝わらなくても仕方ない

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

>>295
>C/C++とは異なり、Rustは範囲外メモリアクセスを絶対に起こさないことが保証される点が決定的な違い
によると後者ってことになるが

>>300
>Rustもインデックス範囲内チェックの有り無しを選べる
によると前者ってことになる

矛盾しとる
どっちや?

**デフォルトの名無しさん** · 2023/04/20(木) 22:18:01.10

C++に勝ってると主張するために普段はunsafeのことを脇に置いてメリットばっかり語ってるのに
性能で負けてるって言われて悔しいからって急にget_uncheckedの話持ち出すからややこしいことになるんじゃな

**デフォルトの名無しさん** · 2023/04/20(木) 22:26:58.01

昔LISPもそれでCと張り合ってたな
歴史は繰り返すんやな

**デフォルトの名無しさん** · 2023/04/20(木) 22:36:42.26

話は簡単
RustはVecもそこで使われるスライスのイテレータも
unsafeなコードを閉じ込めてsafeなメソッドを提供している
だからその部分の作成は人間がミスるとおしまい
逆に言えばその狭い範囲のみ人間が頑張って安全性を保証すればよい

一方でそれらVecやイテレータなどを利用する一般のプログラマーは
そのsafeなメソッドを使っている限り絶対に安全なことが保証される
もし問題があればコンパイラがエラーを出すので常に安全となる

結論
RustもC++も最小限のオーバーヘッドが可能で同じ
しかしその安全性は全く異なる
C++は常にミスったらおしまい
C++はプログラム全体に対して人間が安全性を保証しなければならない
Rustはsafe利用者がミスることは絶対になくコンパイラがエラーを出してくれる
Rustはunsafe利用部分のみ人間が安全性を保証しなければならない

**デフォルトの名無しさん** · 2023/04/20(木) 22:42:39.55

>>315
一生懸命書いているところを申し訳ないが
>>276の話で始めたように今は
コンパイル時にチェックできない状況の話をしているんだ

**デフォルトの名無しさん** · 2023/04/20(木) 22:43:11.74

>>313
そのunsafeなget_uncheckedの件も同じ
unsafeを利用してsafeを提供する人だけがその安全性の保証できるコードを書けばよい
一方でそこで作られたsafeなものを利用する一般プログラマーはミスってもコンパイラがエラーとして止めてくれる

**デフォルトの名無しさん** · 2023/04/20(木) 22:44:27.28

>>98y/hYCF
>>312はどっちや?

**デフォルトの名無しさん** · 2023/04/20(木) 22:44:35.26

>>316
Rustではコンパイル時に安全性を必ずチェックできる

**デフォルトの名無しさん** · 2023/04/20(木) 22:48:29.32

>>319
実行時にサイズを入力するのにかい?
Rustコンパイラは未来が分かるのかw

**デフォルトの名無しさん** · 2023/04/20(木) 22:49:34.33

>>318
どちらも正しい
効率的なunsafeを使いそれを閉じ込めることで効率的なsafeを提供することがRustの基本
一般プログラマーはそのsafeのみ使えば書いたコードの安全性が保証される

**デフォルトの名無しさん** · 2023/04/20(木) 22:55:08.59

>>320
最初に出ているこのコードのことだろ
for n in v.iter().take(input_size) {
println!("{n}");
}
もちろんinput_sizeの値に関わらず静的に安全なコードだ
そしてインデックスは用いないのでインデックス範囲外チェックは無い
Cでポインタで書いたときと同じ速度になる

**デフォルトの名無しさん** · 2023/04/20(木) 22:56:41.18

議論にならんのでスルーして
彼の主張は（正しいのかは分からんが）
要するに範囲外チェックなしでインデックスでアクセスできるということだから
Rustも同様にこの点は危険ということになる

**デフォルトの名無しさん** · 2023/04/20(木) 23:00:30.54

>>322
今はRustでも危険に書けるでしょ?って話をしている
イテレータを使えば安全なのでこう書くべしっていうのなら
それはC++となんら変わらない

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

>>323
Rustはチェックしないけど安全な型を作れるよ
例は何でもいいんだけど例えば将棋盤を表す型を9✕9＝81のインデックスを考えてみよう
その将棋盤の型に対するインデックスの型を新たに作ってメソッドとその操作を限定することでusize化した時に常に0～80の値しか取らない型を作る
あとは unsafeを使ってsafeかつ効率的な実装
impl std::ops::Index<将棋盤インデックス型> for 将棋盤 {
type Output = 将棋駒;
fn index(&self, index: 将棋盤インデックス型) {
unsafe { self.0. get_unchecked(index.to_usize()) }
}
}
これで将棋盤型のアクセス時にインデックスの範囲内チェックは行われずに効率的かつ安全
（将棋盤インデックス型の定義によりindex.to_usize()は常に0～80の値のみをとるため）

将棋の実装を実際にしたことはないが
似たようなデータ型は実際に何度か書いたことがある

**デフォルトの名無しさん** · 2023/04/20(木) 23:29:13.60

C/C++にも、-fsanitize=address ってのが後追いながらちゃんと入ってきてる
その価値は認めていいし、しかし、差は縮まりつつある

**デフォルトの名無しさん** · 2023/04/20(木) 23:32:10.47

Rustでも、unsafe が抜け穴になるよね、って反論はつまり、
コピペ勢に対して、「いやみんなばんばんunsafe使っちゃうからダウト」って返してるってことｗ

ここにたまるようなヤツは、必要に応じてモジュール毎にON/OFFくらいできるヤツ
熱心に張り合うまでもなく、有意義に使うよ

**デフォルトの名無しさん** · 2023/04/20(木) 23:56:26.81

わずかなunsafe封じ込め部分だけに注力することで、効率的なsafeを作ってしまえば、safe利用者はコンパイラに安全性の保証を任せられることがRustの最大のメリット

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

わずかになってくれればいいね

ああ、また釣られてしまったｗ

**デフォルトの名無しさん** · 2023/04/21(金) 00:13:14.15

>>325
安全にも書けるのは分かる（それはC++も同じこと）
9yNISOE6の主張が正しいと仮定して
Vecのアクセス範囲に関して危険にも書けるけど
Rustコンパイラは何もできないよねって話

**デフォルトの名無しさん** · 2023/04/21(金) 00:14:20.12

まちごうた
-9yNISOE6の主張が正しいと仮定して
+98y/hYCFの主張が正しいと仮定して

**デフォルトの名無しさん** · 2023/04/21(金) 00:14:28.54

最適化はunsafeというのはRustではほぼ客観的事実に近い

C++で似たような意見を言えば、最適化の足を引っ張る陰謀と見分けがつかない者もいるだろう

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

範囲がconst/constexprであれば、チェックコストはゼロにしうるのでは
そこにコストをかけてでもsafeにしましょうというのがモダン(含Rust)
そこにコストがかからないように書いてナンボなのがC++(失敗時は: 安全だがコストが生じる)

**デフォルトの名無しさん** · 2023/04/21(金) 00:58:19.29

関係あると思うのできかせて

いまさら人に聞けないんだが、Intel MPXってのが早々にディスコンになったのは、
・MPXでも抜けがあることがわかった
・いまやパイプライン? が優秀すぎて、MPXでもソフトウェアサニタイザでもそんな変わらなかった
っていう理解をしてるけど合ってる?

**デフォルトの名無しさん** · 2023/04/21(金) 01:08:57.82

英語版wikiだと穴が多すぎて実用に耐えなかったって書いてるな
日本語版はなかった
https://en.wikipedia.org/wiki/Intel_MPX

**デフォルトの名無しさん** · 2023/04/21(金) 02:33:15.05

かのIntel(当時)が頑張ってもこんなもん(こんなことになる)か
難しいもんなんだな。。

俺にできないだけで、本気出せば難しくないもんかと思ってたのに

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

具体的に誰が頑張ったのか全然わからない
いまさら英雄化してももう遅い

**デフォルトの名無しさん** · 2023/04/21(金) 09:34:15.68

>>330
>安全にも書けるのは分かる（それはC++も同じこと）
C++でもRustと同じレベルで安全に書けるというのはさすがにウソでしょ
複オジの説明がショボいからと言ってウソはダメだよ

**デフォルトの名無しさん** · 2023/04/21(金) 10:24:01.60

play.rust-lang.org で
use rstk::*; とか
use wx; とか
もちろん出来ない訳だが
use したときに一瞬一覧で選べるものが出て来るので
これの一覧をテキストファイルで欲しいんだが
どこで観れますか？

**デフォルトの名無しさん** · 2023/04/21(金) 10:33:13.77

>C++に勝ってると主張するために普段はunsafeのことを脇に置いてメリットばっかり語ってるのに
>性能で負けてるって言われて悔しいからって急にget_uncheckedの話持ち出す

ほんそれ

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

>>339
crates.ioのダウンロードTop100とその依存クレート
入れ替えとかどう対処してるのかは知らん
playgroundのヘルプにリスト(Cargo.toml)へのリンクがある

**デフォルトの名無しさん** · 2023/04/21(金) 15:41:39.16

>>341
thx!
自分用のCargo.tomlに置き換えたいときは？

**デフォルトの名無しさん** · 2023/04/21(金) 16:08:14.43

>>342
それは自分の環境でどうぞ

**デフォルトの名無しさん** · 2023/04/21(金) 21:37:21.45

控えめに言って Rust は超マゾ言語

**デフォルトの名無しさん** · 2023/04/21(金) 23:59:16.40

C++もRustも基本的には変わらん
C++で常に安全に書ける人にとってライフタイムなんてすぐ理解できて困らん普通のことだった
Rustでいいと思ったのはイテレータメソッドチェーンのシンプルさとか
あらゆる部分でパターンマッチングできる点とか

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

GC言語は良いと思うし使いけど可視化する気にならない
GC言語が多過ぎるから
Python並みの人気でも過半数に支持されるとは思えない

**デフォルトの名無しさん** · 2023/04/22(土) 01:08:10.55

ライフタイム付き再帰構造体を再帰関数で回してlifetimeのvarianceで苦しむまでがボローチェッカチュートリアルです

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

Rustの弱点突きまくり

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

言語(Rust含む)がせっかく親切にしてくれてるのに、その虚を突く

…っていうか、虚を天然で踏み抜いちゃうのが、シロウトなんだよなあ俺含む(自戒

**デフォルトの名無しさん** · 2023/04/22(土) 07:19:16.96

PythonのAI系のライブラリを
rustで作り直したら爆速になるのかな？

**デフォルトの名無しさん** · 2023/04/22(土) 07:23:17.49

大人気のCUDA版は、CUDAでできてるから Pythonで操ってるだけ

**デフォルトの名無しさん** · 2023/04/22(土) 09:44:15.55

C++のライフタイムが本当に簡単ならライフタイム系のバグを100%検知できるツールなんて簡単に作れるはずだよね？

**デフォルトの名無しさん** · 2023/04/22(土) 09:50:17.61

>>352
そういう意味ではなく逆だろ
C++でもともなコードを書けているプログラマーはRustでライフタイムをすぐ習得してしまう話だろう
逆にライフタイムを難しいと言ってるプログラマーはC++で込み入ってくると正しいコードを書けない

**デフォルトの名無しさん** · 2023/04/22(土) 10:40:59.94

>>352
いくらか指針・実装はあったんだけど、決定打に欠いた
いろいろと自由すぎたんだよ

Rustのやり方が業界標準になったら、C++がそれを取り込むのは早いと思う

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

varianceをOOPにたとえると
変数の型を宣言できないが基底クラスなら宣言できる
という理解でいいんでしょ
変数の型を宣言するツールを簡単に作れるかが問題なのでは