Rust part12

**デフォルトの名無しさん** · 2021/08/24(火) 22:55:27.78

公式
https://www.rust-lang.org/
https://blog.rust-lang.org/
https://github.com/rust-lang/rust

Web上の実行環境
https://play.rust-lang.org

日本語の情報
https://rust-jp.rs/

※Rustを学びたい人はまず最初に公式のThe Bookを読むこと
https://doc.rust-lang.org/book/

※Rustのasyncについて知りたければ「async-book」は必読
https://rust-lang.github.io/async-book/

※C++との比較は専用スレへ
C++ vs Rust
https://mevius.5ch.net/test/read.cgi/tech/1619219089/

前スレ
Rust part11
https://mevius.5ch.net/test/read.cgi/tech/1623857052/

**デフォルトの名無しさん** · 2021/10/12(火) 14:51:47.32

>>633
Rustは書き換え競合を避けるために、書き換え可能な可変参照(for writer)と、書き換えられない参照(for reader)の区別をして、
書き換えられない参照は同時に複数を持てる(multiple readers)けど、可変参照は同時に一つだけしか許さない(single writer)とすることで、競合を避けている。
Rustではmutかどうかもその観点からなので、変数が別のVecになるだけでなく、同じVecのまま配列内容や長さの変化しても、内容長さ同じだが領域拡大で場所移動でも、書き換わりとしてmutが必要。
だから、Vecのメソッドでmutを要求してるのはそれらの結果論にすぎないし、Vecの内部構造がこうなってるからという説明は不要で筋違い。

>>661
それは違うな。
むしろ頭を一旦ゼロにする柔軟な人ほど理解が早い。
他言語での様々なモデル(メモリモデルやクラスモデルや…)をベースに難しく考える人ほど混乱して理解が遅い。

**デフォルトの名無しさん** · 2021/10/12(火) 14:59:49.12

>むしろ頭を一旦ゼロにする柔軟な人ほど理解が早い。
>他言語での様々なモデル(メモリモデルやクラスモデルや…)をベースに難しく考える人ほど混乱して理解が遅い。
これを本気で考えてるならバカとしか言いようがない。
C、もしくはアセンブラをバインディングした時に確実にぶっ壊れるコードになるわ。

**デフォルトの名無しさん** · 2021/10/12(火) 15:34:41.08

>>663
それはABIやFFIの話であってRustの話ではない。
Rustで完結するシステムでは一切考慮する必要ない。
他言語ライブラリなど利用の際も、適切な仲介モジュールがあれば、利用側で考慮する必要はない。
各言語との連携部分では、それぞれその言語の知識が不可欠なのは当たり前。
だが、それはRustの話ではなく、Rustにおいてはその知識は必要ない。

**デフォルトの名無しさん** · 2021/10/12(火) 16:09:45.89

メモリモデルって並行プログラミングやらないならあんまり関係なくない？？？

**デフォルトの名無しさん** · 2021/10/12(火) 16:12:51.35

アトミック操作のOrderingの話なんかはC++の定義に丸投げしてるから他の言語の知識が必要というのは一応正しい

**デフォルトの名無しさん** · 2021/10/12(火) 16:27:05.41

>>666
それは理解するのにC++の知識を一切必要としない。
なぜならC++言語仕様とは独立して定められている。
つまり、その件についてもRustを理解習得するために他の言語の知識は必要ない。

**デフォルトの名無しさん** · 2021/10/12(火) 18:24:19.63

>>662
「Vecの内部構造がこうなってるからという説明は不要で筋違い」うーん、それこそ趣旨が違うよ。
vec[0] = 2などとして内容長さ同じの場合の理解では、１つの可変参照と、複数の参照を持つ事を
知っているのは必要だが通常では長さや容量が拡張されるpushやinsertは内部構造により説明される。
mutatorであるpushを呼ばない限りはmutは必要なければ、「mutをつけたベクター型」では無くて
配列という質問になるのでは？

**デフォルトの名無しさん** · 2021/10/12(火) 19:12:36.47

>>668
公開(pub)されていないstruct Vecの内部構造や非公開のRawVecなどを持ち出してくる人たちがいるから、
「Vecの内部構造がこうなってるからという説明は不要で筋違い」と書いた。
そこは長さや容量を持っている等の概念の理解だけで十分であるし、実際に公表されている情報もそこまで。

**デフォルトの名無しさん** · 2021/10/12(火) 19:33:58.77

>>667
C++の知識を「あまり」必要としないのは確かだがC20/C22などの仕様を「参考」にしているのは明らか。
というかLLVMから見てClangっぽく見えるように頑張っていると公式が言っている

**デフォルトの名無しさん** · 2021/10/12(火) 19:37:41.99

>>669
なるほど言いたい事は理解してるが、長さや容量を持っている等の概念の理解ならライブラリソースを
示した方が明らかでしょう。親切だと褒められる事はすれど不要と切って捨てるほどではないのでは？

**デフォルトの名無しさん** · 2021/10/12(火) 21:00:30.83

>>664
rustが単独で使われるなんてことは絶対にない。
低レイヤーのことがまるでわかってないってことがよくわかったよ。

**デフォルトの名無しさん** · 2021/10/12(火) 22:00:42.97

>>662
「multiple readers or single writer」のセーフティルールは
参照だけに適用されるものではなくて参照の所有者を含めて適用されるもの

**デフォルトの名無しさん** · 2021/10/12(火) 22:09:23.38

>>672
Rustでプログラムを書くに当たってRustを構成する様々な低レベルのレイヤーのうちどこまで書き手は意識すべきと考えますか？

さすがにCPUを構成するシリコンひとつひとつの振る舞いを意識することは出来ないので、
これより先は気にしなくて良いという境界は存在すると思うのですが、それはどのあたりにあるとお考えでしょうか

**デフォルトの名無しさん** · 2021/10/12(火) 22:18:28.12

>>672
no_stdでさらにシステムコール(あるいは相当)はasmでレジスタ渡しで呼び出しに至るまでRust完全単独で既存OS(など)利用もあるしOS作成ならOS側もRust単独

**デフォルトの名無しさん** · 2021/10/12(火) 23:07:50.81

>>664
>Rustで完結するシステムでは一切考慮する必要ない。

それって議論の価値ある？　だって現実的じゃないじゃん
研究者のための言語だっていうなら、それもありだけど
ここにいる人間は実用を求めてるわけでしょ。多分……

**デフォルトの名無しさん** · 2021/10/12(火) 23:22:14.99

すまんが何を言っているかさっぱり分からない
自分が書いてるのは9割方Rustで完結したプロジェクトだけど、みんなFFIばっかり書いてるのか？

**デフォルトの名無しさん** · 2021/10/12(火) 23:52:39.59

Win32APIとリンクしたり、そういうプログラムは書かないってことね

**デフォルトの名無しさん** · 2021/10/12(火) 23:56:08.22

Win32API使いたいんなら単にwindows-rsクレート使えば良いだけで
その先のC ABIがどうなってるかとか気にする必要はないと思うが

**デフォルトの名無しさん** · 2021/10/12(火) 23:57:43.15

ああでもwindows-rs自体は割とunsafe あるから気にしないとダメかな

**デフォルトの名無しさん** · 2021/10/13(水) 00:00:43.80

いや、そもそもwindows-rsクレート使おうが
C理解してないと使えないよ
だってwindows-rsの型定義は「今のところ」まともじゃないもん
ポインタは何でもかんでもDWORDだし

**デフォルトの名無しさん** · 2021/10/13(水) 00:05:34.07

確かに例が悪かった。windows-rsに関してはunsafe がある以上呼び出し先のCの知識は必須だね
言いたいのは自分でunsafeを書かない限り、Rustだけで完結するってこと
そりゃ分野によってはまだライブラリ不足で完結しにくいのもあるだろうけど、多くの分野で完結すると思うがなぁ

**デフォルトの名無しさん** · 2021/10/13(水) 00:37:10.90

で、そういうメモリをほとんど気にしないソフトはrustで書く必要がないものなんだよね。
ファッションでやってることがバレちゃったね。

**デフォルトの名無しさん** · 2021/10/13(水) 00:38:57.86

Rust以外のプログラミング言語を考えれば理解しやすい
C言語を全く知らなくても使えるようにその言語だけで書かれたAPIで何でも利用できる
Rustも同様でC言語を全く知らなくても使えるようにRustだけで書かれたAPIで何でも利用できるようにすることができるし実際にほとんどの分野ではそうなっている
その上でRustの場合は効率面から元のAPI向き出しで例えばCStr使ったりするなどC言語でのAPIのまま提供するモジュールも存在するというだけにすぎなくてそこはあくまでもFFI領域
したがって「他の言語と同様にRustもC言語を全く知らなくても使える」で正解

**デフォルトの名無しさん** · 2021/10/13(水) 01:08:46.05

>>683
rustで書く必要性が薄いってのは結構当てはまるとは思うが、
だからといってメモリ回りの知識がrustで何か書くには絶対必須とはならんだろう

**デフォルトの名無しさん** · 2021/10/13(水) 01:16:25.82

>>683
例えばstd::fsやstd::netなどは本来ならCのABIでやりとりするものだが
そんなこといっさい気にする必要なくRustの型で渡してRustの型で返ってくるようにRustの標準ライブラリが作られている
そこにCの知識は全く必要としない

**デフォルトの名無しさん** · 2021/10/13(水) 07:24:31.94

たくさん書くのは自信がなさの表れ
そんな必死になるような話じゃないだろうに

**デフォルトの名無しさん** · 2021/10/13(水) 09:00:38.12

Cを理解してないとRustは使えない、と
ウソをつく人がいるからだろう

**デフォルトの名無しさん** · 2021/10/13(水) 09:25:52.29

そう思い込んでりゃいいんでない？
近くにいなけりゃ放置するよ。近くにいればボコボコにするけど。

**デフォルトの名無しさん** · 2021/10/13(水) 09:41:01.46

>>674
cpuはシリコンウエハ一枚から切り取ったものからなっている
複数のシリコンの集合体ではない

**デフォルトの名無しさん** · 2021/10/13(水) 10:15:02.35

>>688
そういうやつの相手をムキになってやってるうちは自分も同じレベルだって気付けよな

**デフォルトの名無しさん** · 2021/10/13(水) 10:36:12.77

>>690
ちなRyzenとか、組み込みマイコンとかは、マルチチップを繋いで一つにパッケージしてるのもあるけどね。
シリコン一つ一つとかポエムっぽいのは秋になったからか？

**デフォルトの名無しさん** · 2021/10/13(水) 14:45:58.97

>>690
シリコン原子一粒一粒の意味

**デフォルトの名無しさん** · 2021/10/14(木) 18:50:15.29

コンピュータアーキテクチャの基礎知識(メモリモデル、アクセスオーダ、スレッディング等)やOSのシステムコール、APIの知識の事を "C言語の知識" と呼ぶ人が居るのね。
まあどうでもいいけど。

**デフォルトの名無しさん** · 2021/10/14(木) 19:43:21.65

システムコールにしても最終的にはレジスタに積んでsyscall命令もしくは割り込みするだけだからCでもRustでもasmと共存するだけか
C言語の知識は要らないな

**デフォルトの名無しさん** · 2021/10/14(木) 20:55:23.77

まあシステムコールやAPIは C や CPP のヘッダ形式で定義/提供されてるという事を言いたいなら判らんでもないが、
そこまでコアな言語仕様知識は要らないねえ。

**デフォルトの名無しさん** · 2021/10/14(木) 21:55:10.80

rustは書けるけどCが書けない人いる？
そういう人がいないとCがいるかいらないかわからない
自分はCの知識が役に立ったと思う

**デフォルトの名無しさん** · 2021/10/14(木) 22:21:20.24

RustでWebバックエンド書いてる人になら普通にいるんじゃない？
Web系ならこれまでのキャリアで全くCに触れなくてもおかしくないし

**デフォルトの名無しさん** · 2021/10/15(金) 10:55:12.45

昔からRust for Rubyistsとかあるしスクリプト系言語から流れて来る人もそれなりにいるかと

**デフォルトの名無しさん** · 2021/10/15(金) 12:44:17.46

スマートポインタやシェアードポインタ、所有権なんかは、C++0xあたりで導入された考えだから
どの程度の範囲をC言語と言っているのかによる。要らない派が多く「見える」が、知識があって
理解をを妨げるという考えは全否定する。「あって困るものではない」

**デフォルトの名無しさん** · 2021/10/15(金) 14:00:41.51

>>695
OSプログラムしてるとレジスタ内容をメモリに載せるなんて普通にあることなんだが。
まあrustでOSなんて書かないから関係ないですけどね。

**デフォルトの名無しさん** · 2021/10/15(金) 14:27:53.37

>>701
OSなんて書いたこともないくせに語るなド素人

**デフォルトの名無しさん** · 2021/10/15(金) 15:04:44.50

>>702
ソースコード読むことすらしてないバカは黙ってて。

**デフォルトの名無しさん** · 2021/10/15(金) 15:15:35.47

なんか低レベルな話で盛り上がってるな

**デフォルトの名無しさん** · 2021/10/15(金) 15:16:50.75

そんなことよりシステムコールの呼び出しにCの知識は必要ないっていうコメント対して>>701のレスが噛み合ってないんだが、何を言いたかったのか解説してくれないか

**デフォルトの名無しさん** · 2021/10/15(金) 15:20:05.89

なるほど、レジスタからメモリ書き込みの同期タイミングなどが必要とかそこまで具体的に言わないと理解できないレベルなのか。
すげー馬鹿しかいないのなら仕方ないな。

**デフォルトの名無しさん** · 2021/10/15(金) 15:33:44.29

システムコールの呼び出しとはまったく関係ないな

**デフォルトの名無しさん** · 2021/10/15(金) 15:40:54.74

OS書いたことも無いのに恥ずかしい奴

**デフォルトの名無しさん** · 2021/10/15(金) 15:45:02.58

>>705
それな

> OSプログラムしてるとレジスタ内容をメモリに載せるなんて普通にあることなんだが。

何でいきなり一人だけ見当ハズレなこと言い出したのかだけでも説明してほしいわ

**デフォルトの名無しさん** · 2021/10/15(金) 16:38:42.56

>>701
Rustはインラインasmできるので好きなレジスタと好きな変数(メモリ)の行き来演算できるしRustだけでOSも書ける

**デフォルトの名無しさん** · 2021/10/15(金) 17:41:49.92

>>710
どうせunsafeなんだろ

**デフォルトの名無しさん** · 2021/10/15(金) 18:11:50.56

寒色は人権すらないからな

**デフォルトの名無しさん** · 2021/10/15(金) 18:54:33.37

>>711
そりゃアセンブリですから
safeにするには不変条件を満たすように自分でやらなきゃいけない

**デフォルトの名無しさん** · 2021/10/15(金) 18:55:28.40

Rust？　人気らしいね、でもオイラやらないよ
Cは嫌いだし、その後釜狙いの言語はどうせ肌に合わないさ
大半の人には必要ない言語だよね、だからオイラGoをやるよ

**デフォルトの名無しさん** · 2021/10/15(金) 18:58:20.72

GoのほうがよっぽどCの後釜感あるがな
GCのあるCという感じ

**デフォルトの名無しさん** · 2021/10/15(金) 19:22:21.57

>>711
unsafeを誤解しているようだけど
CやC++と同じ状況すなわちその部分のメモリ安全性は自己管理となるだけ
だから論理的に安全な操作でそれがローカルに閉じ込められて他に影響を及ぼさないならば使われうる
例えば標準ライブラリのVecもその内部実装の一部でunsafeが使われているが我々はVecを安全に使うことができる

>>715
つまりGoはCやC++の代替になれない

**デフォルトの名無しさん** · 2021/10/15(金) 19:27:43.08

rustの強みである静的メモリ安全性っていうのが活かせてないやんって意味で言ったんやけど
cやc++と同じ状況ならむしろrustよりcやc++使うよね？

**デフォルトの名無しさん** · 2021/10/15(金) 19:36:00.75

量の概念がないやつが定期的に現れるな
コード全域がunaafeなのと局所的なのは全然違うでしょ

**デフォルトの名無しさん** · 2021/10/15(金) 19:46:42.29

>>717
例えばVecは実装内部でunsafeを用いているが
Vecはメモリ安全性を保証する
そしてVecを用いたプログラムもRustコンパイラが通ればメモリ安全性が保証される

**デフォルトの名無しさん** · 2021/10/15(金) 19:48:51.64

それならC++も同じでは？

**デフォルトの名無しさん** · 2021/10/15(金) 19:49:28.65

>>719
unsafeなのにメモリ安全性どうやって保証してるの？

**デフォルトの名無しさん** · 2021/10/15(金) 19:52:54.07

C++の場合は、vector自身がメモリーの所有権を持ってるので安全性が保障されるんだけど。

**デフォルトの名無しさん** · 2021/10/15(金) 20:08:04.69

>>721
え？何を言ってるの？
Vecに限らずRustの各型を含めた標準ライブラリの内部はもちろんunsafeだらけだけど
論理的に安全な操作のみ、かつ、内部に閉じ込められていて外部に影響を及ぼさないもののみ
だからそれら型を含めた標準ライブラリを我々は安全に使うことができる
そしてそららを用いた我々のプログラムはコンパイラが通ればメモリ安全性を保証される

**デフォルトの名無しさん** · 2021/10/15(金) 20:14:36.90

>>723
じゃあC++と変わりませんね。

**デフォルトの名無しさん** · 2021/10/15(金) 20:15:19.52

>>723
だからアスペか？
論理的に安全な操作のみ、かつ、内部に閉じ込められていて外部に影響を及ぼさないってことをどうやって保証してるのか聞いてんだけど？
国会の答弁みたいな返答やめろよ
というか外部にメモリ及ぼさないはメモリ安全性が保たれるの必要条件じゃないんだけど

**デフォルトの名無しさん** · 2021/10/15(金) 20:15:56.65

外部にメモリ及ぼさないじゃなくて外部に影響及ぼさないだった

**デフォルトの名無しさん** · 2021/10/15(金) 20:21:27.95

>>724
C++はコンパイルが通ってもメモリ安全性は保証されません
Rustはコンパイラが通ればメモリ安全性が保証されます
全く異なります

>>725
論理的にそれらを満たす操作かどうかです
Rustコンパイラが通ればメモリ安全性を保証するかどうかも論理的に基づいて保証されます

**デフォルトの名無しさん** · 2021/10/15(金) 20:33:33.14

>>727
メモリ安全性を保証することを諦めればコンパイル通るのは当然だよね？
こんな基本的なこともわからないんですか？

**デフォルトの名無しさん** · 2021/10/15(金) 20:36:47.57

Cしか知らない人ってプログラミング言語の仕様とコンピュータのアーキテクチャが区別できないってマ？
型理論も知らないってマ？

**デフォルトの名無しさん** · 2021/10/15(金) 20:40:52.58

>>728
その通りでC++はコンパイルが通ってもメモリ安全性が保証されない言語
一方でRustはコンパイルが通ればメモリ安全性が保証される言語

**デフォルトの名無しさん** · 2021/10/15(金) 20:50:24.31

>>730
>unsafeを誤解しているようだけど
>CやC++と同じ状況すなわちその部分の>メモリ安全性は自己管理となるだけ
って自分で言ってるよね？自分の過去の発言と言ってること矛盾してない？
rustのunsafeはメモリ安全性を保証することを諦めてるって言いたかったようだけど今は言ってること無茶苦茶じゃない？

**デフォルトの名無しさん** · 2021/10/15(金) 20:51:16.86

>>722
これが一般的なC++erの認識だとしたら恐ろしいな

**デフォルトの名無しさん** · 2021/10/15(金) 20:58:34.88

unsafeなコードが周りを滅茶滅茶にしない保証は無いよ

**デフォルトの名無しさん** · 2021/10/15(金) 21:01:02.97

unsafeを使った場合の安全性の保証を機械的にやりたければ↓みたいなので契約プログラミングする手はあるね
https://crates.io/crates/contracts

**デフォルトの名無しさん** · 2021/10/15(金) 21:10:23.11

>>731
もちろんRustの標準ライブラリの実装内部には多数の細かい小さなunsafeがあってその部分はコンパイラによるメモリ安全性保証の範囲外
それそれの内部ローカルのunsafe使用が論理的にメモリ安全であるか否かの保証はコンパイラではなく人間が行ないunsafeはそのためにある
その上でRustコンパイラはプログラム全体のメモリ安全性を保証する

**デフォルトの名無しさん** · 2021/10/15(金) 21:17:10.00

>>735
人間がどうやって行うの？

**デフォルトの名無しさん** · 2021/10/15(金) 21:31:51.20

話は簡単だ
C/C++はプログラム全てがRustのunsafe状態
つまりC/C++はプログラム全てを人間がメモリ安全であると保証しなければならないが人間なので複雑化するとミスも生じる
GAFAM各社はメモリ安全に関するバグが全く減らずセキュリティ脆弱性の多くがこの問題に起因することに気付いた
そこでコンパイラがメモリ安全であると保証するRustを採用して少しずつC/C++から移行させていってる段階

**デフォルトの名無しさん** · 2021/10/15(金) 21:34:04.93

unsafe blockはマーが全力で頑張ります！ゾーンだからな
アルゴリズムにおいてあるアルゴリズムが正当であると判定するアルゴリズムは存在しないんだからラストコンパライでも完全なセーフティは保証は出来ないけどな
ただ完全ではないものの他の注意すべき所をランコンに任せてunsafe部にヒューマンリソース限定出来るのはc++を遥かに優れた点よね(´・ω・｀)

**デフォルトの名無しさん** · 2021/10/15(金) 21:39:33.56

布教しようとしなくたっていいんだよ
めんどくせえから

**デフォルトの名無しさん** · 2021/10/15(金) 21:42:55.26

>>737
GAFAがその体たらくとは信じがたいけど、resource管理は所有権ベースでほぼ解決するし、逆に所有権以外で解決することは出来ないと思う。

**デフォルトの名無しさん** · 2021/10/15(金) 21:45:54.09

>>738
チューリングマシンの停止性問題のこと言ってるんだろうけど違うよ
あるアルゴリズムじゃなくて任意のね
「あるプログラムが正当であると判定するプログラムは存在しない」じゃなくて「任意のプログラムを正当であると判定するプログラムは存在しない」が正しい
これが5chクオリティか

**デフォルトの名無しさん** · 2021/10/15(金) 21:58:02.76

Rustコンパイラによるメモリ安全性の保証は信頼してても、unsafe使ってる標準ライブラリを信頼しない話おもしろいね。
実際に問題なく動いてるんだから仕様を信頼すればいいのに。

**デフォルトの名無しさん** · 2021/10/15(金) 22:06:00.13

>>742
人間が局所的に注力すれば済むのがRust
人間がプログラム全般に注力しなければならず破綻したのがCとC++

**デフォルトの名無しさん** · 2021/10/15(金) 22:07:41.72

>>741
うーんまぁ日本語で論理学考える事なんてあんましないから間違えてるのかもしれんが
あるアルゴリズム、ある整数等々で俺はある集合(=アルゴリズム全体で構成される集合)の元の任意性を表してんたんだけどな(´・ω・｀)

**デフォルトの名無しさん** · 2021/10/15(金) 22:11:36.31

>>743
勝手に破綻したことにするのやめな？
そういうとこやぞお前マジ

**デフォルトの名無しさん** · 2021/10/15(金) 22:18:09.07

>>744
その言い訳は厳しいよ
まあワイもまともに勉強するまでもそこあたりあやふやだったしそんな気にすんなや

**デフォルトの名無しさん** · 2021/10/15(金) 22:39:44.83

>>740
C/C++に限界を感じたGAFAMたち大手IT企業がRustに結集
特定の言語がIT業界を挙げて支持されるのは初めて

プログラミング言語「Rust」のための「Rust Foundation」設立 -- AWS(Amazon)、Microsoft、Google、Mozilla、Huaweiが創設
https://japan.zdnet.com/article/35166267/

Facebookが「Rust Foundation」に参加
https://japan.zdnet.com/article/35170192/

**デフォルトの名無しさん** · 2021/10/16(土) 00:08:25.70

>>717
それどこの0か100しか無い世界？

**デフォルトの名無しさん** · 2021/10/16(土) 00:34:25.94

C++はこれで鼻から悪魔出るから

vector<int> hoge {0};
int& fuga = hoge[0];
for (size_t i = 0; i < 5; ++i) {
hoge.push_back(i);
}
cout << fuga;
}

nsafeがどうたらぬ気にしてRustはこういうのが防げるってだけでもそれなりの価値はある

ちなみにunsafeブロックは本当に慎重に作らないと、unsafeの外部をちょっといじっただけで鼻から悪魔が出たりする
https://doc.rust-jp.rs/rust-nomicon-ja/working-with-unsafe.html
unsafeブロック外のidx < arr.len()をidx <= arr.len()にしただけで死ぬ

**デフォルトの名無しさん** · 2021/10/16(土) 03:36:57.11

unsafeなコードが1行でもあったらRustで書く意味ないと主張する人が定期的に現れるのはなぜなのか

**デフォルトの名無しさん** · 2021/10/16(土) 03:54:24.52

>>750
C++が劣ることを認めたくない人が「unsafeがあるならC++と同じだからRustの存在意義はない。」という間違った主張をしてるみたい

**デフォルトの名無しさん** · 2021/10/16(土) 04:04:47.91

C++との対決は別の専用スレがあるのでそっち使ってくださいね

**デフォルトの名無しさん** · 2021/10/16(土) 04:11:16.75

>>752
同感
C++な人はここでやらずに
向こうの専用スレでやってほしい

C++ vs Rust
https://mevius.5ch.net/test/read.cgi/tech/1619219089/

**いつもの光景** · 2021/10/16(土) 07:19:55.59

Vec型の質問に高卒が答える
　↓
当然の如く高卒がバカにされる
　↓
高卒発狂
　↓
パソコンがどうの、C++がどうの、いつもの大先生問答に発展

**デフォルトの名無しさん** · 2021/10/16(土) 09:07:15.06

>>749
ちなみになんでこれで悪魔がでるんですか？
無学ですみません

**デフォルトの名無しさん** · 2021/10/16(土) 09:21:09.42

>>755
fugaがhogeのメモリ参照を取った後にhoge.push_back()でデータを追加している。
データ追加ではhogeの内部で確保していたメモリ領域が足りなくなると
新しいアドレスに確保しなおす（元の領域は開放する）ので、
fugaが指しているアドレスはアクセスしてはいけない領域になってる。（ダングリングポインタ）
その状態でcoutでfugaを使ってるから。

**デフォルトの名無しさん** · 2021/10/16(土) 09:48:04.61

>>756
なるほど
ダングリングポインタになっているんですね
教えてくださってありがとうございます

**デフォルトの名無しさん** · 2021/10/16(土) 10:29:54.02

unsafeなtraitとそうでない通常のtraitってどう違うんでしょうか
implにunsafeって書かないといけない点以外で

**デフォルトの名無しさん** · 2021/10/16(土) 12:13:05.40

バカは実際にバグが起きるかどうかを考えてなくて
バグを誰かのせいにできるかどうかしか考えてないんだろ。
だからこんなしょーもないものが持て囃されるってわけだ。

**デフォルトの名無しさん** · 2021/10/16(土) 13:08:52.57

東アジア圏は原因の究明と再発防止より責任の追及と処罰を優先する文化だからな
気をつければ問題ないみたいな精神論が平気で唱えられるのも同様
システム工学先進国のアメリカあたりと比べたらかなり後れている

**デフォルトの名無しさん** · 2021/10/16(土) 20:42:26.55

それは東アジア人の性質ってか東朝鮮の性質だろ(´・ω・｀)