結局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/16(日) 21:53:57.59

>>195
差分としているunique_ptrの学習コストってなんやw
問題にしてるのは他の言語との変数の振る舞いにRustのみ乖離があるということ
プログラミングをRustで始めるんなら
プログラミング言語の変数ってそういうもんだと覚えるから
たぶん問題にはならん

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

C++でも所有権くらい知らないと話にならないので、所有権があるからRustは学習コストが高いとの主張は無理があるんじゃないかな
それにプログラミングができる人にとって所有権なんて大した難しい話じゃないし、誤差でしょ

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

>>197
>>193
>C++ユーザならある程度は分かるけども

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

まあ、「C++書けます」とか、そうそう口にできないよな
「Rust書けます」…も似たようなもんな気も

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

総じて学習コストの高いC++が不利というかさ
拡張が建て増しになってるため無駄に覚えなければいけないことが多すぎなんだよね
学習コストはRustが少なく楽

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

>>197
そういう知らないと話にならない、という物のを纏めた
公式のドキュメントが存在しないってのが致命的なんよ

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

>>201
C++の所有権の話ってunique_ptrの使い方だけだよ
これ以上ないくらい簡単なクラスだよ
公式ドキュメントにこだわるなら
Rustにはまだ無かろうがC++には規格書があるので
それを読むと良いよ

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

>>202
規格書はドキュメントにならないんだけど、そんな事も理解できないん？
C++学習する人に、規格書だけ渡すの？

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

>>202
unique_ptrは使い方を間違えると終わるので簡単な話ではないよね
コンパイルエラーにしてくれるRustの方が学習も早そう

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

>>203
規格書が難しならハゲ本でもメイヤーズでも定番読めばええがな
C++の方が文献は多いよ

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

>>204
>unique_ptrは使い方を間違えると終わるので簡単な話ではないよね
どういう間違え方ですか? コードで書いてみて

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

C++衰退してる原因が良くわかるな
そもそも使ってる連中も普及しなくていいと思ってそうな雰囲気

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

>>202
規格書があるから学習コストが低いという主張はバカげてるよね
公式の各種ドキュメントが学習用もリファレンス用も整備されてるRustも十分すぎることになるね

>>204
コンパイルでエラーにしてくれるだけでなくエラー指摘方法と解説の丁寧さはプログラミング言語全体で比較してもRustが最も秀逸だね

**デフォルトの名無しさん** · 2023/04/17(月) 00:02:25.14

>>208
>規格書があるから学習コストが低いという主張はバカげてるよね
誰がそんな主張をしたのかな?
勝手に自分で作成した主張にバカげてるって一体どういうことだよw

>公式の各種ドキュメントが学習用もリファレンス用も整備されてるRustも十分すぎることになるね
Rustのドキュメントは別に否定はしていないよ
ただしC++の方が歴史が長い分だけ当然のことながら多い

>>204
>unique_ptrは使い方を間違えると終わるので簡単な話ではないよね
どういう間違え方ですか? コードで書いてみて

**デフォルトの名無しさん** · 2023/04/17(月) 00:26:32.06

使い方を間違えなければよいだけだ

C++11スマポで避けるべきミスTop10
https://www.acodersjourney.com/top-10-dumb-mistakes-avoid-c-11-smart-pointers/

ただし間違えてもエラーを出してくれるわけではないから自己責任
複雑化するとミスが入り込んでセキュリティの穴になったりもするので厳格に要注意

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

・所有権の概念の理解はどちらでも必須
・言語仕様としての使い勝手はスマポ後付けのC++が不利
・使い方の過ちでコンパイルエラーとならず実害を出してきたC++が不利

**デフォルトの名無しさん** · 2023/04/17(月) 06:25:51.67

耳の痛い話なんだが、「所有権の概念とかブッチでも書けちゃう」まであるからね
いいや動けば、みたいなコードが、思わず生き残ってしまうみたいなやつがまずい
自分だって、所有権なにそれおいしいの、みたいな(初学者の)時期は当然あった
気を付けるのが当たり前、みたいな時代だったんだ

なによりC++に欠いているのは、安全を担保・強制する枠組みの決定打
つまり、unsafe{ } の存在 (unsafeがあるということは、逆説的? にsafeが当然にあるという意味)

**デフォルトの名無しさん** · 2023/04/17(月) 08:12:32.44

>>211
オイオイ
C++では別に所有権の理解は必須ではないよ
make_uniqueなどせずに（普通に?）インスタンス作ることの方が圧倒的に多い
unique_ptrを使うならそれがRustでいう所有権ってだけ（Rustの拝借元?）

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

それを言うなら、スマポに頼らずとも、いや、スマポに頼るような複雑な構造をいたずらに作るなかれ、ってほうが近い
でも、めちゃくちゃ書く人とか、めちゃくちゃ書いちゃうときとか、うっかり書いちゃうときとか、あるんだよね
コンパイラにチェック任せられるのはたしかにうれしい

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

Rust の macro_rules! で
macro_rules! hoge<T> {
(略)
}
って描くと怒られるので
Trait を使って <T> 出来ないかと思ったら
Trait の中に macro_rules! ってどう描けば良いの？

**デフォルトの名無しさん** · 2023/04/17(月) 10:11:13.47

>>125 >>134
安全に運用するための unsafe {} なのに
unsafe は上位(呼び出し側)に伝播しないのも面白仕様

**デフォルトの名無しさん** · 2023/04/17(月) 10:24:16.64

>>159
ラマヌジャンは凄いわ

**デフォルトの名無しさん** · 2023/04/17(月) 10:31:53.63

>>179
C++をWinAPIに適合しようとしてMFC造って失敗した頃のMSと同じ過ちを繰り返してるな

**デフォルトの名無しさん** · 2023/04/17(月) 10:42:37.51

>>208
>エラー指摘方法と解説の丁寧さは

言いたいことは判るが
提示された修正案がぴったり嵌った時はナイスと思えるが
逆のパターンもあるよね？

**デフォルトの名無しさん** · 2023/04/17(月) 10:46:09.44

>>213
それもC++でメモリ安全バグそしてセキュリティホールを産んできた一因
C++でも所有権の理解とスマポ利用は避けることができない

https://xtech.nikkei.com/atcl/nxt/column/18/00692/042700054/
> (途中略)
> グーグルによればAndroidに存在した深刻なセキュリティー脆弱性の70％近くがメモリー安全に関するバグに起因するという。
> 同様にマイクロソフトも、同社製品に存在したセキュリティー脆弱性の70％がメモリー安全に関するバグに起因すると述べている。
> C/C++を使う限りセキュリティー脆弱性を根絶するのは不可能と考えて、Rustを採用するに至ったというわけだ。

**デフォルトの名無しさん** · 2023/04/17(月) 11:13:07.86

>>215
それどうやって呼び出すつもり？
マクロが展開されるタイミングを考えなよ

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

ほんと低次元
小学校低学年のけんか

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

>>221
解決しました
ほんとうにありがとうございました

**デフォルトの名無しさん** · 2023/04/17(月) 12:02:11.37

いつまでたっても安定化しないBtrfsを先にRustで完全実装してみせるくらいの実績を出してみやがれってんだ

**デフォルトの名無しさん** · 2023/04/17(月) 15:31:33.55

質問です
例えば画像データの上下反転をしたい場合
let ppix: *mut std::ffi::c_void = im.pixels;
const W: usize = 640;
const H: usize = 480;
const D: usize = 24;
let q = ppix as *mut [[u8; W * D / 8]; H];
for j in 0..h/2 {
let t: [u8; W * D / 8] = (*q)[(h - 1 - j) as usize];
(*q)[(h - 1 - j) as usize] = (*q)[j as usize];
(*q)[j as usize] = t;
}
で実際に可能だったのですが W, H, D を固定にしたくなくて(続く)

**デフォルトの名無しさん** · 2023/04/17(月) 15:32:27.02

ファイルシステムのようなクリティカルな用途で使うわけないだろ

**デフォルトの名無しさん** · 2023/04/17(月) 15:36:19.73

let ppix: *mut std::ffi::c_void = im.pixels;
let pitch: usize = im.pitch as usize; // im.pitch: std::ffi::c_int (値はほぼ3)
for j in 0..h/2 {
let a: usize = j as usize * pitch;
let p: *mut u8 = (ppix as usize + a) as *mut u8;
let b: usize = (h - 1 - j) as usize * pitch;
let q: *mut u8 = (ppix as usize + b) as *mut u8;
let mut btm = std::slice::from_raw_parts_mut(p, pitch);
let mut top = std::slice::from_raw_parts_mut(q, pitch);
let mut t: Vec<u8> = vec![0u8; pitch];
t.copy_from_slice(top);
top.copy_from_slice(btm);
btm.copy_from_slice(&t);
}
の様に書き換えて h は可変 w と d は pitch に置き換えで
こちらも動作はするのですがコードが冗長になってしまっています
後者をもう少しすっきりさせたいのですがどんなやり方が考えられますか？

**デフォルトの名無しさん** · 2023/04/17(月) 15:45:58.71

なんでレスバスレで質問してんの？

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

>>220
お前がC++の知識が全く無いことが分かった
批判をするなら勉強しなさい

**デフォルトの名無しさん** · 2023/04/17(月) 16:18:46.99

>>225
ちゃんと動くかは分からん

chunks_exact_mut, rchunks_exact_mutの仕様だとhが奇数でも問題ないはず

fn main() {
let mut ppix = vec![0u8; 640 * 480 * 24];
let pitch = 640 * 24;
let h = 480;
// ↓この辺から参考に
let (top, bottom) = ppix.split_at_mut(pitch * h / 2);
for (top_chunk, bottom_chunk) in top
.chunks_exact_mut(pitch)
.zip(bottom.rchunks_exact_mut(pitch))
{
top_chunk.swap_with_slice(bottom_chunk);
}
}

**デフォルトの名無しさん** · 2023/04/17(月) 16:23:53.42

>>228
レスバはレスバしたい奴に任せてほっとこうぜ
結局Rustも使うC++erが参考になる質問なら見学しとくから
でも質問スレとかないんかな

**デフォルトの名無しさん** · 2023/04/17(月) 16:28:57.08

>>229
安全にするために「C++でも所有権の理解とスマポ利用は避けることができない」で合っとるやろ
まさか自分で管理してdeleteすればいいから不要と言い出すんじゃないだろうな

**デフォルトの名無しさん** · 2023/04/17(月) 16:45:26.70

let ppix: *mut std::ffi::c_void = im.pixels;
let pitch: usize = im.pitch as usize;

for j in 0..h/2 {
let a = j * pitch;
let p: *mut u8 = (ppix as usize + a) as *mut u8;
let b = (h - 1 - j) * pitch;
let q: *mut u8 = (ppix as usize + b) as *mut u8;

let btm = std::slice::from_raw_parts_mut(p, pitch);
let top = std::slice::from_raw_parts_mut(q, pitch);

for k in 0..pitch {
std::mem::swap(&mut btm[k], &mut top[k]);
}
}

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

>>230
let len: usize = h as usize * pitch;
let (top, bottom) = std::slice::from_raw_parts_mut(ppix, len).split_at_mut(len / 2);
で動作しましたありがとう

**デフォルトの名無しさん** · 2023/04/17(月) 18:39:30.36

数学とは
実験データに基づかない証明ばかりしているくせになぜか正しい
現実の影響を受けにくい

前例がなければ何もしなかったのに
実例を見るとついつい行動してしまう模倣犯みたいな感じになりにくい

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

>>208
Rustc の指示通りに修正すると余計にエラーが増えて
状況が悪化して散々振り回されて時間を無駄にする
結局指示と違う修正ですっきり治ることも多い

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

時々的外れな事言ってくるのも ChatGPT と良い勝負

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

最初に&mut [u8]スライスを作るところだけffiサイドに分離しておくのがよいね

>>236
どういう不備があるかの本質をエラーメッセージはまず示してくれている
その補助としてコンパイラが一案を示してくれているから自分の望む案でなくてもエラーの理解に助かる
時間の節約にこそなれど無駄にすることはない
もし時間を無駄にしているなら本質を無視しているバカさを自白してるようなもの

**デフォルトの名無しさん** · 2023/04/17(月) 20:41:01.82

時間を無駄にしたのが本人とは限らんだろ

**デフォルトの名無しさん** · 2023/04/17(月) 21:07:11.98

>>232
もし>>213に>>220とレスを返すのを肯定するとしたら
お前もC++の知識が文字通り皆無なのだと分かる

class Hoge {
public:
void *operator new (size_t p) = delete;
};

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

>>212 >>216
unsafe で隠蔽してるだけで
Java の Exception みたいに上位にも伝播する訳でもないのに
全体としては安全が確保されてるとか
夢観過ぎ自己満でしかない

問題先送りどころか隠蔽体質

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

握り潰しの握りっ屁でも臭わないのがRustの美学

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

>>241
全くの逆
むしろ例えば生ポインタによる読み書きアクセスがunsafeなように一番下はunsafeに行き着く
しかし例えばある条件を伴ってそのメモリ領域が確保された安全なアクセスであると保証できる状況を満たす場合は
そのアクセス関数をsafeなインタフェースとして提供できる
大雑把な違いは以下

【C++の場合】
プログラム全体にunsafeが散らばっていてプログラム全体がunsafe
つまり人間がプログラム全体に対してその安全性を保証しなければならない

【Rustの場合】
safeなインタフェースの中にunsafeが閉じ込められている
その閉じ込める部分に対してのみ人間が安全性を保証しなけれはならない
プログラム全体の安全性はコンパイラが保証できる仕組み

例えばC++の場合は生ポインタでなく参照を使っている場合でもダングリング発生の危険があるのに対して
Rustの参照はライフタイムが管理されてダングリングが発生しないとともにデータ競合防止アクセスも保証される
さらに他のスレッドと共有できるか否かも含めて型付けと静的型チェックによりコンパイル時に安全性を保証できる言語仕様となっている

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

OOP的な隠蔽だろ?

まあ俺のは素人が書いてるコードだし、自己満と言われようと構わんがなｗ
そして、そういう用途・運用もあるんだ
ガチプロばっかりが、PC・マイコン使ってない

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

気軽に聞かせて
unsafeが残っていながらなにが安全じゃ! っていう反駁をちょくちょく見るけど、
unsafeが要らないようなプロセッサってほんとに作れないもんかな

絵空事じゃないぞ、FPGAにオレオレプロセッサって起こせるようになったらしいし
RustBeltに載ってるのかな(読破はできてない

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

そろそろ貼っとくか
safeでもメモリはぶっ壊せる
https://speakerdeck.com/moratorium08/rustfalseunsound-hole-issue-number-25860woli-jie-suru

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

相関関係ではなく因果関係を立証できる者だけが
safeでも原因になれることを立証できる

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

>FPGAにオレオレプロセッサって起こせる
何十年も前から可能だったよ
っていうか原理的に出来て当たり前だし
「実用的な」って意味ならまあ色んな考え方もあるだろうが

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

限りある脳のリソースをどこに使うかという極々当たり前のことだろ
それすらわからないようなやつがまともにプログラミングできる訳がないんだから何を言っても時間の無駄だよ

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

まともじゃないヤツをプログラミングから排除するのがsafeか
こりゃこまったなｗｗ

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

人を説き伏せる目的で言うのは時間の無駄だけど自分が言いたいことを言うのはいいんだよ

**デフォルトの名無しさん** · 2023/04/18(火) 11:43:26.04

なるほど
言いたいことを言う場がない人たちだから
こんなところで承認欲求剥き出しの長文書くのか

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

試金石と思ってるところはあるな大間違いならツッコミがあるし
自分も、まあそうかな、くらいなら、いちいち「そうだそうだ」って書かないしね

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

>>236
経験的にだけど、ライフタイム関連のヒントは真に受けない方がいい気がするな

多分、構造体や関数の定義側のライフタイムが意図通りにできていない場合に、そっちを直せというヒントを出せないのだと思う
定義を正としてそこから導出されるライフタイムや境界をひたすら書けと言うだけ
そんなヒントにハイハイと従ってるとそこら中ライフタイムパラメータまみれにされた挙げ句、最終的にlifetime conflictで二進も三進もいかなくなったことがある
結局その件はある関数の引数に2個ある参照のライフタイムパラメータの省略をやめて'a,'bに分けるだけでよかった記憶

あと'aで受け取りたいのに「'staticにすることを検討してください」とかもよく見る役立たずヒント

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

グローバル変数をやめろと指示された → ヒープを使った → メモリが壊れた
という長期的な流れもあるので
'staticを検討することは指示を信じているとも言えるし、最初の指示を全力で疑っているとも言える

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