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/11(月) 00:12:55.43

>>630
アルゴリズムではなくて、ポインタを渡すのか、実数値を渡すのか
そこを明確にしているRustの仕様から引数を可変参照にするのは・・という意味では

そして>>617が何を読みにくいといっているのかも、よくわからんし

**デフォルトの名無しさん** · 2021/10/11(月) 00:34:40.68

>>624 >>627
がねがねその通りで、言った通りトレイトだが、「Num型があるよりももっと高度なことができる」これは弁明的。
近代的な言語はmixinもしくはアドホック多相で（高度なことが）出来る場合がほとんどであり、無いものを無いと
要求できず弁護をするのはちょっと違う。他にも角度のように、0-360まで制限したいプリミティブ型が欲しいのに
PascalのようなSubrange型も足りていない。範囲を表す表現、0..360はあるのに。些細な事だが、コンパイラを
速くする事を現在は主眼なので（仕様に矛盾が無ければ）いずれは拡張されるのかもしれないが

**デフォルトの名無しさん** · 2021/10/11(月) 06:54:36.68

mutをつけたベクター型について教えてください
これはまず、入っているのは参照なんですか？
また、参照が変わらない(?)のに、参照先を変更するにはmutがなぜ必要になってくるのですか？
(所有権概念のせいなのでしょうか？それともスマートポインタの仕組み上、参照するアドレスが変わるのでしょうか？)

**デフォルトの名無しさん** · 2021/10/11(月) 08:28:39.20

>>633
let mut x = vec![1,2,3];

xに入ってるのはVec<i32>、これはスマートポインタ(pointer, capacity, length)。
「参照」というのはRustでは&Vec<i32>のようにアンパサンドがついてる型のこと
なのでxに入ってるのは参照ではない

例えばx.push(10)するのにxがmutじゃなきゃいけないのは
直接的にはpushのシグニチャが&mut selfを要求してるからだけど
考え方としては「multiple readers or single writer」ルールをコンパイル時に強制するため

連続したバッファを確保できなければアドレスが変わる可能性も有るし
ゼロキャパシティなら具体的なアドレスを持ってない

**デフォルトの名無しさん** · 2021/10/11(月) 13:32:30.30

Cortex-M対応がClangよりRustの方が進んでいて草

**デフォルトの名無しさん** · 2021/10/11(月) 14:07:37.59

core::ptr::unique::Uniqueもalloc::raw_vecもただのdoc(hidden)なのに
Vecがスマートポインタってデタラメ広めてる奴らどこが出処だよ。

以下の関係で、
Vec has-a RawVec
RawVec has-a Unique

- Vecがrustの作法を強制するためのnewtypeパターン←composition
- RawVecが動的配列の低レベルapi←composition
- Uniqueがユニークポインタ←smart pointer

これだけだろ。
rustのコレクションはデータ構造上直接実装することになる型以外
Box含めて基本newtypeパターン(composition)だぞ。

>>633
GCのある言語しか触ったことない限りその発想にはならんから
まずアロケータの仕組みからやりな。

**デフォルトの名無しさん** · 2021/10/11(月) 14:34:19.59

ホラふきがあらわれた！

**デフォルトの名無しさん** · 2021/10/11(月) 14:44:50.63

また他人のフリして間違いを指摘するレスが来るから乞うご期待www

**デフォルトの名無しさん** · 2021/10/11(月) 15:28:05.06

compositionだからスマートポインタでないという理屈だと Rc も Arc も非公開な内部型の composition だからスマートポインタでなくなってしまう

**デフォルトの名無しさん** · 2021/10/11(月) 15:42:18.11

>>636
C++のことは一旦忘れて、Rustにおけるスマートポインタの意味を学ぶことをすすめる
https://doc.rust-lang.org/book/ch15-00-smart-pointers.html

**デフォルトの名無しさん** · 2021/10/11(月) 18:57:50.60

>>640
The concept of smart pointers isn’t unique to Rust: smart pointers originated in C++ and exist in other languages as well.
とあるけど？

**デフォルトの名無しさん** · 2021/10/11(月) 19:29:34.65

We’ve already encountered a few smart pointers in this book, such as String and Vec<T> in Chapter 8, although we didn’t call them smart pointers at the time. Both these types count as smart pointers because they own some memory and allow you to manipulate it. They also have metadata (such as their capacity) and extra capabilities or guarantees (such as with String ensuring its data will always be valid UTF-8).

というわけで Rust の定義では Vec<T> はスマートポインタ

**デフォルトの名無しさん** · 2021/10/11(月) 20:38:32.88

クイズ: この中にウソはいくつウソがある？

「またはtypescriptのtype Tree = Leaf | Nodeはサポートされません」
「rustはどちらかと言えばほとんどをトレイトで表現しますが、技術的にはこれらは、Tagged unionと呼ばれ昔はSum typeともバリアント型とも呼ばれていました。」
「rustは可変参照を基本的に好まないスタイルだから、ああなるのは仕方ないな」
「Vecがスマートポインタってデタラメ広めてる奴らどこが出処だよ。」

**デフォルトの名無しさん** · 2021/10/11(月) 23:52:58.48

>>633
pub struct Vec<略> {
buf: RawVec<T, A>,
len: usize,
}
pub struct RawVec<略> {
ptr: Unique<T>,
cap: usize,
alloc: A,
}
pub struct Unique<T: ?Sized> {
　pointer: *const T,
　_marker: PhantomData<T>,
}
push|insertの際にlen|capとアロケート先が変化するという事、上のは難しい事をわざと言ってる
スマートポインタ議論は無視でOK。しかしPhantomDataなんて理解してる人に会ったことない

**デフォルトの名無しさん** · 2021/10/11(月) 23:58:39.10

>>631
その冪剰余関数の引数は全て数値すなわちCopy traitを持つので
関数呼び出しに参照を渡す必要はありません

また、可変参照の数値を渡す必要がある別の関数がもしあったとしても
普通に値を渡して変更値は返り値とする方がわかりやすいでしょう

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

>スマートポインタ議論は無視でOK。
他人のフリして我がフリ直せww

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

>>633
初級者ならばこのスレで言及されている内部実装の話は知らずとも使えるので無視してもよい
それよりもmutableとimmutableの意味となぜ区別が必要かを理解したほうがいい
あと参照の意味も理解していないようだからそこもまず基本だからおさえるべき
それら基本を理解すればVecの中身が書き換わるならばmut指定が必要とわかるはず
Rustは簡素に理解しやすく出来ているのに他言語のポインタ周辺の概念を無駄に持ち出してきて難しく考えて失敗する人たちが一部いる

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

これが基本を理解してないと指摘されたやつのレスw

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

Rusterは他人を同一人物と思い込む素性の悪い病人しか居ないな

**633** · 2021/10/12(火) 08:42:15.75

初心者丸出しの質問で、なんでこうなった・・・・・

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

>>647
>Rustは簡素に理解しやすく出来ているのに

それには賛同できない

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

このスレにはアンチRustのC++爺さんと
間違った知識を上から目線でレスするRust初心者が各1名住み着いてるから

質問者は回答内容を自分で精査しないとダメだよ
特に後者はタチが悪いので注意して

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

Rustに近々追加される機能で熱いものなにかありますか？

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

Rustに関する質問はteratailで

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

現時点でRustなんかどうでもいい
10年後に普及してたら一般プログラマーも使う程度

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

653見る前に654書いちゃったのでちょっと訂正
Rustに関するまじめな質問はteratailでするのがよい

>>653
もうすぐRust2021がくるぞい
熱いのがあるかっていうと微妙かも

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

>>650
mutの必要有無は他言語では一般的じゃないRustのルールに関連してるんだけど
それが少し難しいので回答する側にもそのルールを理解してない人がそれなりにいるということ

基本的にコンパイラが教えてくれるので深く理解してなくても使う分にはそこまで問題にはならない

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

Rustを知るということは、弱点も知ることにつながる

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

vlangもmutがあるが散々否定される、曰く「理論に沿ったコンピューター工学を元にしてない」だとか
「トランスコンパイラでしょ」とか、NoGCが過大広告でLobsterというのは分かるがリークするでしょとか

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

async/awaitの追加で一旦大きな機能追加目標は終わって、以降は処理系の効率化にリソースを割いていく、みたいな話を読んだ気がする

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

結局他の言語でのメモリモデルも理解してないとrustはまともに使えんよ。
そこを誤魔化すやつはクソだわ。

**デフォルトの名無しさん** · 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はコンパイルが通ればメモリ安全性が保証される言語