結局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(日) 11:51:39.68

>>165
>C++ほど安全に使うための予備知識が多く必要ない
その予備知識を覚えるコストが
所有権システムの振る舞いを覚えるコストに
吐き出されたというだけでは?

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

C++は安全な利用の統一的な技法が普及してない、まさにこれから
言語によっておおむね統一されてるRustはそのへんを学ぶにあたって効率はいい模様

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

>>167
>C++は安全な利用の統一的な技法が普及してない、まさにこれから
は?
（Rustの言語に含めるってアイデアはありだと思うよ）

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

>>166
言語の標準機能で実現されてるってのが大きい
C++は調べようと思ってもレガシーな情報にぶち当たる可能性が非常に高い

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

>>169
そこは独特な所有権システムを受け入れることととのトレードオフだけども
そのぶち当たるC++のレガシーな部分って
要するにCなので難しくもないと思うのだが? そんなので挫折するかい?
俺はC++の規格のうち最近に拡張された機能を覚える方が大変だよ

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

普及してたら、こんだけ虫だらけになってないからさｗ

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

>>158
ところが「数学的」という言葉を使うのは理系が多いんだなこれが
まあちょっと考えればわかることだけど

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

>>170
結局Ｃ++は言語としての基礎がまともじゃないから、拡張繰り返してキメラみたいになってんだよ
今更新規で薦められる言語ではない

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

まともな文系は、数学も勉強してるから、数学っていうだろうな
まともじゃない文系…って、こんな板来んやろ(ｗ

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

>>173
スタンダードであったCを呑み込むことが当初からのC++の戦略だからね
後方互換性ってのは大多数の人間にとっては魅力なんだよ
後方互換性を犠牲にしてディファクトスタンダードに食い込んでいくのは懐疑的だよ
PCのOSしかり携帯しかり

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

> PCのOSしかり携帯しかり
LinusもRust導入に舵切ってるし、MSもRust採用始めてるんですがそれは

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

>>176
$ wget 'https://cdn.kernel.org/pub/linux/kernel/v6.x/linux-6.2.11.tar.xz'
$ tar xJf linux-6.2.11.tar.xz
$ find linux-6.2.11 -name *.c -o -name *.h | wc -l
55980
$ find linux-6.2.11 -name *.rs | wc -l
37
僅かに0.07%未満だよ
最後のプロンプトから | wc -l を取ればRustが何に使われているか分かる
MSは知らん Visual Rust++は出たのかな?

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

これから始めるのに、今の%出す意味ある？

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

そこで止まっちゃってないかってことじゃねえの、しらんけど

Windowsには、これが出てるけど…
https://github.com/microsoft/windows-rs

そこにあるサンプルからして、unsafe{ } じゃ、説得力ないよな
>>16-17 に書いた通りだよ Win32 APIに所有権情報が付いてなかったらなんにもならない
MS Rustチームもっと仕事しろ

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

>>178
>最後のプロンプトから | wc -l を取ればRustが何に使われているか分かる

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

Rust for Linuxは現状ドライバをRustで書けるようにしましたってだけ
Rustで置き換えて安全化！なんてわかりやすい成果は現状出ていない
何回言わせんねん

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

Rustと違ってC++にはEditionがないからね
safe/unsafeを導入するの10年経っても無理
Clang-Tidyのような外部ツールで頑張るしかない

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

>>182
ちゃんと調べて書けば?
Rustは規格すらないやろ?

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

>>183
Editionが何かも知らんのかw
そんなんでよく書き込みするなぁ

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

Rustは実装がまだ1つだし仕方ないか

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

>>159
これまでの会話からして、この板の人は、証明しても誰一人として理解できない
から時間の無駄であることが分かった。
恐らく、10年後くらいにやっと理解できるかも知れない。
そういうものだ。

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

せっかくに日曜日をもっと有意義に過ごせばいいのに

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

板違いのスレで真っ赤とか人生見直した方がいいな

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

C++はEditionがどうとか以前に、方言だらけなわけだが

なので、所有権関係が取り込まれるのも早いとこは早いかもね

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

C,C++は1995～2000年ごろGCブームが来てて
大学の課題もGC使ってた
当たり前に使ってた
取り込まれるのかと思ったら取り込まれなかった

今は潤沢なメモリがあるからメモリリーク放置violation放置みたいだけどそもそもがc++じゃなくてpython使ってるみたい

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

>>190
そんな素人の話をされてもね

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

>>166
学習コストは確実にRustの方が低くて覚えやすい
所有権関係はunique_ptrすらなくシンプルなRustがわかりやすいのは言うまでもないが
あらゆる分野で整理されて高機能になるとともにわかりやすくなっている
例えばイテレータにしてもC++はC++20でようやく機能強化と大整理が行われたが普及には程遠い

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

>>192
初めて覚えるのがRustってんなら否定はしないが
所有権システムは他の全ての言語と勝手が違うからね
C++ユーザならある程度は分かるけども

>例えばイテレータにしてもC++はC++20でようやく機能強化と大整理が行われたが普及には程遠い
これなーに? ついて行けてないんだけども便利なのあるかな?

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

言語仕様でごちゃごちゃ議論したがるのはコードまともに組めない奴
これ豆な

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

単純な話だよな
所有権の概念の学習コストはC++もRustも同じ
所有権の実際の使い方の学習コストはunique_ptrすらないRustが易しい
学習コストでC++に勝ち目はない

**デフォルトの名無しさん** · 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の件は初心者が間違えて踏んでしまうことは決してなく
慣れているプロが複雑化したときもそんな状況に陥ることはない
強引に恣意的にそれを目指して作り出さないと生じない