[表示 : 全て 最新50 1-99 101- 201- 301- 401- 501- 601- 701- 801- 901- 1001- 2ch.scのread.cgiへ]
Update time : 02/22 14:52 / Filesize : 279 KB / Number-of Response : 1015
[このスレッドの書き込みを削除する]
[+板 最近立ったスレ&熱いスレ一覧 : +板 最近立ったスレ/記者別一覧] [類似スレッド一覧]


↑キャッシュ検索、類似スレ動作を修正しました、ご迷惑をお掛けしました

Rust part16



1 名前:デフォルトの名無しさん mailto:sage [2022/06/27(月) 08:17:03.45 ID:gDlfKP6u.net]
公式
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を学ぶ際に犯しがちな12の過ち
https://dystroy.org/blog/how-not-to-learn-rust

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

※次スレは原則>>980が立てること

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

201 名前:デフォルトの名無しさん mailto:sage [2022/07/05(火) 23:19:42.19 ID:I5LuZ1z+.net]
>>197
>具体的になにが違うの
平日の昼ひまでこのスレにくるおじさん・じじいは
C++のshared_ptrと同じじゃないということを知ってさえいれば激十分なんだよ。
だから、具体的になにが違うかは(知らないから)答えられない。
C++とRustの深い知識あるようなすごい奴が平日の昼暇でここで遊んでいる
なんてことはないだろう。

202 名前:デフォルトの名無しさん mailto:sage [2022/07/06(水) 11:32:12.50 ID:jpnjV9Mh.net]
Full Stack Rust App Template using Yew + Actix!
https://youtu.be/oCiGjrpGk4A

203 名前:デフォルトの名無しさん mailto:sage [2022/07/06(水) 11:45:22.14 ID:UGbPogY6.net]
UIフレームワークはスレチだよしんどけ

204 名前:デフォルトの名無しさん mailto:sage [2022/07/06(水) 12:20:02.69 ID:b0Oxubv9.net]
ここRustプログラミングに関することならば何でも歓迎
各々の関心がないことの和集合を取ると全体集合になる
特定の人にとって関心がないからと言って排除してはいけない

205 名前:デフォルトの名無しさん mailto:sage [2022/07/06(水) 14:24:50.14 ID:oR52wNCu.net]
違いが大きすぎるとどこが違うとかいうのを説明するのが難しくなる。
織田信長とオムライスの違いを説明できるか?
まあ shared_ptr と Rc の違いはさすがにそこまで大きくはないけども、
前提となる C++ と Rust の違いも小さくはないので比較する意味を感じないな。
shared_ptr は shared_ptr だし Rc は Rc としか言いようがないだろう。

206 名前:デフォルトの名無しさん mailto:sage [2022/07/06(水) 16:11:44.19 ID:rco22hfx.net]
リファレンスカウント方式の複製可能なスマートポインタという点では類似のものと言って良いのでは
元々はc++とrustで実行効率に差があるという話だがその観点でどういう差があるのかね
そもそも実行効率が何のことを言っているのかがよくわからんから議論しても仕方ないか

207 名前:デフォルトの名無しさん mailto:sage [2022/07/06(水) 18:50:47 ID:cl7AdtI8.net]
原理と詳細を区別できない人はちょっと……

208 名前:デフォルトの名無しさん [2022/07/06(水) 23:39:03.25 ID:DBl9eUwS.net]
>>203
全く別物の比較なら、信長は人間、オムライスは食べ物、というようなザックリした説明で良くなるのでは?

209 名前:デフォルトの名無しさん [2022/07/06(水) 23:45:15.32 ID:DBl9eUwS.net]
Arcとstd::shared_ptr<>が似てるという人に対して、「いや、std::shared_ptr<>とRcは全然違う」と反論するのがおかしいのでは?



210 名前:デフォルトの名無しさん mailto:sage [2022/07/07(木) 00:18:57.43 ID:6JbvD3+y.net]
>>206
そうだよ。
それを適用するなら
shared_ptr は C++ のスマートポインタ、 Rc は Rust のスマートポインタということしか言えなくなる。

211 名前:デフォルトの名無しさん mailto:sage [2022/07/07(木) 00:49:54.35 ID:Sq6Pkb7P.net]
>>208
俺らのレベルではその程度の知識で十分だろ
で、スマートポインタでもなんか違いあるの?と質問されても具体的に答えられなくても
全く問題ないからな。
一方、すごい人からすれはstd::shared_ptr<>とRcは全然違うとなるんだろうが
(すごい人敵にはそれらは例えばstd::shared_ptrは信長で人間、一方、Rcはオムライスで食べ物ぐらい違う!
でも、俺らは人間だって餌として食べることができるから同じだろ)

212 名前:デフォルトの名無しさん mailto:sage [2022/07/07(木) 05:04:39.45 ID:WPmCyDkS.net]
>>196
>>193
> C++のshared_ptr = RustのArc = SwiftのARC が同じ機能であり、スレッドセーフなリファレンスカウンタ利用の共有ポインタ方式。
って書いてるんだから同じじゃないとか全然違うとかフワフワしたこと言ってないで
・機能
・スレッドセーフ
・リファレンスカウンタを利用
の各項目について違いを書きなよ

213 名前:デフォルトの名無しさん mailto:sage [2022/07/07(木) 08:43:50 ID:M+xvnEsX.net]
共有ポインタって何?

214 名前:デフォルトの名無しさん mailto:sage [2022/07/07(木) 10:54:08.79 ID:LNwVrqhE.net]
shared pointerじゃね?

215 名前:デフォルトの名無しさん mailto:sage [2022/07/07(木) 11:14:16.23 ID:xmv5m6Ag.net]
結局参照カウント方式なのは一緒なんでしょ

216 名前:デフォルトの名無しさん mailto:sage [2022/07/07(木) 12:48:02.98 ID:kuHYrppG.net]
>>212
だとするとshared pointer方式ってどんな方式??
リファレンスカウンタを利用しないshared pointer方式もあるってことだよね?

217 名前:デフォルトの名無しさん mailto:sage [2022/07/07(木) 14:09:00.32 ID:1csywUpz.net]
>>214
shared pointerはc++のが有名すぎるからなんとも言えないなぁ。

参照カウント以外でポインタを共有するのはリンクリスト方式とかあるよ。

218 名前:デフォルトの名無しさん mailto:sage [2022/07/07(木) 15:30:16.82 ID:jjCeBJbE.net]
ARCで管理してる時点でRustはガベコレじゃないからすごい!って理論は破綻してるんじゃありませんかね?

219 名前:デフォルトの名無しさん mailto:sage [2022/07/07(木) 15:41:53.87 ID:6JbvD3+y.net]
>>216
誰がそんなこと言ってんの?

静的に管理できるものは静的に管理するし、実行時にしかわからないものは実行時に管理するってだけのことだ。
参照カウンタの適用範囲を間違えてるプログラマがいるならそれはそいつが無能。



220 名前:デフォルトの名無しさん mailto:sage [2022/07/07(木) 16:01:25.39 ID:HUExG/fK.net]
Rust公式の日本語意訳にはしっかりRustはガベコレじゃないから高速って書いてあるね

221 名前:デフォルトの名無しさん mailto:sage [2022/07/07(木) 16:16:37 ID:I5wN0SQd.net]
>>216
Objective-C/SwiftのARCとRustのArcは同じ3文字略語だけど別のものだよ
それを理解した上で言ってるのなら別にいいんだけどさ

222 名前:デフォルトの名無しさん mailto:sage [2022/07/07(木) 18:43:04.02 ID:u5IGnUan.net]
>>216
そもそもRust公式が「メモリリークはメモリ安全の範疇」と言っているしな。

223 名前:デフォルトの名無しさん mailto:sage [2022/07/07(木) 18:52:31.81 ID:pAImJ0Xg.net]
>>220
それはRustの定義がおかしい
一般的にはメモリリークがあるとメモリ安全だとは言わない

224 名前:デフォルトの名無しさん mailto:sage [2022/07/07(木) 18:55:30.53 ID:V91F8QUY.net]
流れぶった切りだけど単純にRustの人たちはGUIどうしてんの?

225 名前:デフォルトの名無しさん [2022/07/07(木) 19:11:09.29 ID:Efq0h4+x.net]
なんだ、じゃあ、バグはセーフティと定義したら、Rustは安全高めなのか。

226 名前:デフォルトの名無しさん mailto:sage [2022/07/07(木) 19:29:21.10 ID:webRw0a6.net]
rust にクラスはないのですか?

227 名前:デフォルトの名無しさん mailto:sage [2022/07/07(木) 19:39:16.69 ID:6JbvD3+y.net]
>>221
Rust が言語の仕組みによって防ごうと努力する範囲にメモリリークは含まないという定義だよ。
それを表すのに「Rust の仕様の中では」メモリ安全という用語を使っているのであって、
定義におかしいもクソもない。 定義なんだから。

228 名前:デフォルトの名無しさん mailto:sage [2022/07/07(木) 19:46:35.34 ID:6JbvD3+y.net]
>>224
クラスと名付けられている概念はない。
あなたにとってクラスとは何のこと? 何が出来ればクラス?

229 名前:デフォルトの名無しさん mailto:sage [2022/07/07(木) 19:48:37.87 ID:UC7ZSmFv.net]
型クラスの事を聞いてるんじゃない?



230 名前:デフォルトの名無しさん mailto:sage [2022/07/07(木) 19:49:32.87 ID:idvDnT2E.net]
>>216
ARCで管理しているのはSwift
RustはC++と同じくRAIIなので高速
どうしても共有メモリを使いたい時のみshared_ptrやRc/Arcを用いる

231 名前:デフォルトの名無しさん mailto:sage [2022/07/07(木) 20:00:40.75 ID:pAImJ0Xg.net]
>>225
そのRustの仕様の中でメモリ安全性を達成できていないんだから
Rustの仕様の中でメモリ安全性という用語を使うのは不適切
Rustの謳うメモリ安全性は世間一般のメモリ安全性とは異なる概念なんだからそれを表すには他の用語を使うのが適当かと

232 名前:デフォルトの名無しさん mailto:sage [2022/07/07(木) 20:06:09.82 ID:idvDnT2E.net]
>>224
クラスはその根幹の継承がデメリットだらけと結論が出ているためGoやRustなどでは採用されていない
メンバー変数やメンバーメソッド等とは構造体で使えるため困ることはない
Rustでは構造体を含む任意の型に対して横断的に共通適用可能なトレイトがあり非常に強力で利便性がよい

233 名前:デフォルトの名無しさん mailto:sage [2022/07/07(木) 20:09:54.71 ID:6JbvD3+y.net]
>>229
知らんがな。
大抵の専門用語は一般名詞に (その分野における) 明確な定義を与えることで成り立ってるのはごく普通のことだろ。

234 名前:デフォルトの名無しさん mailto:sage [2022/07/07(木) 20:25:04.56 ID:idvDnT2E.net]
>>229
世間一般なんてものはなくそれぞれがそれぞれの定義域に依る
そしてそれが明確になっていればよい
例えばRustではメモリ競合は防止可能と明確化しつつ、より一般的な競合状態は対象外と明確化している
原理的に無理なものは無理なのだからそこは明確化してあればそれでよい

235 名前:デフォルトの名無しさん mailto:sage [2022/07/07(木) 21:01:30.61 ID:0wlfNyVX.net]
>>228
aliasingの話してるところにRAIIが来るのもよくわからないがRAIIだと高速という理屈はさらにわけわかめ

236 名前:フ名無しさん mailto:sage [2022/07/07(木) 21:12:46.12 ID:PQWZgdhj.net]
>>222
windows-rsでunsafe祭りになりながら書いたよ。オススメはしないが。

237 名前:デフォルトの名無しさん mailto:sage [2022/07/07(木) 21:39:23.64 ID:pHkHW2c/.net]
SwiftのARCとRustのArcの区別がつかない人は論外なので発言を控えてほしい
ただでさえしょうもないのにしょうもなさが倍増するからね・・・

SwiftのARCはAutomatic Reference Counting
https://docs.swift.org/swift-book/LanguageGuide/AutomaticReferenceCounting.html

RustのArcはAtomically Reference Counted
https://doc.rust-lang.org/std/sync/struct.Arc.html

238 名前:デフォルトの名無しさん mailto:sage [2022/07/07(木) 22:03:40.09 ID:webRw0a6.net]
>>230
継承をやめて委譲にすれば割とまともになると思います
https://mevius.5ch.net/test/read.cgi/tech/1434079972/51
https://mevius.5ch.net/test/read.cgi/tech/1434079972/84

239 名前:デフォルトの名無しさん mailto:sage [2022/07/07(木) 22:05:44.36 ID:idvDnT2E.net]
>>233
C++とRustはヒープ利用に対してRAIIによるデストラクタ呼び出しによりリファレンスカウンタ無しでメモリ解放するので高速
さらに加えてRustでは所有権と借用のルール明確化により解放の安全性も静的に保証している
一方でSwiftはヒープ利用に対して常にリファレンスカウンタを用いるARCによりメモリ解放の管理をするため低速



240 名前:デフォルトの名無しさん mailto:sage [2022/07/07(木) 22:11:56.95 ID:hEh+9Mpq.net]
>>236
その流れで継承不可のクラスベースのオブジェクト指向言語がどういうものになるか思考実験的に考えてみなよ

241 名前:デフォルトの名無しさん mailto:sage [2022/07/08(金) 03:25:18.13 ID:CKdXv9cu.net]
それよりSQLが超苦手な俺はPRQLにめちゃくちゃ期待しているのだがラスタシアン達はSQLも達者なのかね?

242 名前:デフォルトの名無しさん [2022/07/08(金) 03:34:35.68 ID:tnmgUx+u.net]
うーん。
このスレ↓では、Rustはメモリーリークしない、Cはリークすると議論してたからなあ。

https://mevius.5ch.net/test/read.cgi/tech/1650185555/

243 名前:デフォルトの名無しさん mailto:sage [2022/07/08(金) 07:13:21.57 ID:vMUJBeEa.net]
pijul使ってみたけど、改行コードがCRLFだと非対応で
バイナリファイル扱いになるという謎仕様でまいった
差分とか出せなくなる
ファイルタイプ判別を変えるオプションは無い

それは置いといても、表示もドキュメントも超簡素で
もうすぐ1.0.0リリースを迎えるとは思えない状態

ほとんどの入門記事で使われている重要コマンドpijul statusが
最近のバージョンで削除されたのも謎すぎる
だいじょうぶなのかこれ

244 名前:デフォルトの名無しさん mailto:sage [2022/07/08(金) 07:47:38 ID:ifo4L8le.net]
>>239
今の開発のトレンドが互換性維持で苦労して中途半端なものになるくらいなら好きな仕様にして最後全部トランスパイルすりゃいいじゃん!になってしまったな
世の天才が叡智を絞った結果がRust界隈含めて今まで散々馬鹿にしてたウェブ(JS)の後追いなの草生えるわ
ちなみに英語圏ではSQLはシークェルと発音するから覚えとけ
ラスタシアンの紳士諸君はえすきゅーえるとかクソダサい発音禁止な

245 名前:デフォルトの名無しさん mailto:sage [2022/07/08(金) 08:02:14.74 ID:i9Nd4OSx.net]
PRQL 書き味が CloudWatch logs Insightと似てそうだけどあれもそんなにいいもんじゃないぞ。

246 名前:デフォルトの名無しさん mailto:sage [2022/07/08(金) 08:04:43.63 ID:pMnIhSXO.net]
>>242
外人の禿げたおっさんはだいたいエスキューエル言うてるやろ

247 名前:デフォルトの名無しさん mailto:sage [2022/07/08(金) 08:11:32.47 ID:i9Nd4OSx.net]
コントロールも無視もできない処理系や既存資産の上でまともな進化や開発体験を維持しようとしたらトランスパイルになるのは必然だったんだろうな。

それが必要になるクソさと、トランスパイルコストの損益分岐点が最初に現れたのがJSってだけだと思うよ。

248 名前:デフォルトの名無しさん mailto:sage [2022/07/08(金) 08:44:10.67 ID:efA8XUrt.net]
>>240
メモリリークに関しては

まず、Rustは自動的に即座にメモリ解放されるため他の言語と比べて高速かつ安全
ただし、Rustにおいて循環参照は他の言語と大きく異なり、
・意図的に色々と明確に指示して作成しないと、循環参照は自然に発生しない
・強い参照と弱い参照を使い分けることが出来るため、強い参照のみによる循環参照を避けることが可能
・意図的に強い循環参照を作成した場合は、それはRustにとって自動的なメモリ解放の対象とならない

したがって、Rustにおいて強い循環参照を意図的に作成した場合のみメモリリークが起こりうるが、わざと作成したのだから意図通り、という扱い

249 名前:デフォルトの名無しさん mailto:sage [2022/07/08(金) 09:06:34.18 ID:ujjjtz1g.net]
ほんと無知って怖いね



250 名前:デフォルトの名無しさん mailto:sage [2022/07/08(金) 09:12:01.24 ID:1lqt9Ku2.net]
「循環参照は自然に発生しない」なんていう解説狂信者おじさんがいる限り、プロジェクトには絶対Rustは採用しない......

251 名前:デフォルトの名無しさん mailto:sage [2022/07/08(金) 09:29:57.41 ID:L1lQIkzy.net]
ほんとこの種の信者は迷惑だわ
普通は多人数で作業して、データー構造をRc<T>をWeak<T>にあらかじめしておくようなことはしないし、”わざと作成したのだから意図通り”とか
相手(これから学ぶ人や新人)を騙すために都合の良いことを吹き込んでいるようにしか見えない・・・
それなら自動メモリ管理ではないので、作り方/使い方により自然/意図しない使い方でリークも場合もあると明確に認めて、その分だけ
自動メモリ管理ではないないので速度が速いし、メモリー解放のタイミングもある程度コントロール出来ると誠実に話したほうが余程、印象が良いのに。
胡散臭い宗教の勧誘に見えるような態度だから叩かれる

252 名前:デフォルトの名無しさん mailto:sage [2022/07/08(金) 09:30:47.62 ID:Gv4jmnae.net]
>>241
PijulもPRQLなど最近の新たな試みはRustで実装されることが多いが
それらはRust言語のためのものではなく汎用的なものであり
それらの問題点もRustとは直接関係がない
今後Rustで書かれた新たなものがどんどん増えていくだろうがそこは区別すべきところかな

一方でそれらをRust言語で使うためのクレートなどがあれば
Rustプログラミングにおいて使う特有の話なので
それらの話題自体を避けるべきではないね

253 名前:デフォルトの名無しさん mailto:sage [2022/07/08(金) 09:41:28 ID:v7XD1ZOP.net]
循環参照は自然に発生しないって、コードを何も書かなければ発生しないって意味かな

254 名前:デフォルトの名無しさん mailto:sage [2022/07/08(金) 09:42:55 ID:QpPOct5C.net]
>>248
新たなプロジェクトが次々とRustを採用している現実を直視しようぜ

>>249
循環参照はRust以外だと知らぬ間に発生してしまう自然なよくあるものだが
Rustでは複雑な操作で意図的に作り出さないと出現すらしない点を理解しようぜ

255 名前:デフォルトの名無しさん mailto:sage [2022/07/08(金) 09:58:58.97 ID:BqWLp+Ol.net]
RAIIでメモリをケアするのは
GC方式にくらべて高速ってのはまぁそうなんだけど
それよりも
開放タイミングが決定的であることのほうが特徴
オブジェクトの生存期間によってメモリの使用期間もプログラマが管理できて嬉しい

256 名前:デフォルトの名無しさん mailto:sage [2022/07/08(金) 12:01:11.06 ID:bBPWEvXX.net]
>>236
参照カウント方式と区別したいなら、「GC方式」みたいな曖昧な用語はやめて「トレーシングGC」を使おうぜ。

257 名前:デフォルトの名無しさん mailto:sage [2022/07/08(金) 12:37:51 ID:4Cg/jdLt.net]
>まず、Rustは自動的に即座にメモリ解放されるため他の言語と比べて高速かつ安全
この時点で嘘だらけなんだから、それ以上読む必要無い

日本語ブログだとこういう複オジレベルの人が多数派なので
Rustを本気で学びたいやつは英語のリソースメインで学ぶことを強くすすめる

258 名前:デフォルトの名無しさん mailto:sage [2022/07/08(金) 12:39:17 ID:u4+He/YT.net]
>>249
アンチは実際にプログラミングしたことがないのかね
Rc<T>自体は書き換えできないのでRc<T>だけでは循環参照を作ることができない
Rc<T>とWeak<T>は互いに対称ではないため直接置き換える対象ではない
例えばnewもRc::new(T)とWeak::new()で引数Tの有無からして異なる
さらに多人数で作業するから強い循環参照を知らぬ間に作ってしまうとの言い訳も意味不明だ

259 名前:デフォルトの名無しさん mailto:sage [2022/07/08(金) 12:42:18 ID:u4+He/YT.net]
>>255
Rustは所有者がいなくなると自動的に即座にメモリ解放されるため他の言語と比べて高速かつ安全で合っている



260 名前:デフォルトの名無しさん mailto:sage [2022/07/08(金) 14:56:50.59 ID:bBPWEvXX.net]
>>257
メモリを解放しないCopying GCの方が高速なんだけどなぁ。

Rustもメモリ解放しない実装なのかね?RAIIならスタック領域しかメモリを確保しないとか。

261 名前:デフォルトの名無しさん mailto:sage [2022/07/08(金) 16:11:26.76 ID:VZayErSn.net]
>>258
C++もRustも仕組みは同じ
RAIIによりスコープを外れた対象のスタック部分が解放される時にそのデストラクタによってヒープ部分が解放される
汎用的にはこれが最も高速かつ利便性>>253が高い

Copying GCは特殊な環境で特殊な使い方に限定する場合は速いこともありうるがデメリットも多く一般的には使われることが少ない
使用メモリが多くなるとかコピーで値を移動させるため非常に遅いなどのデメリットの他に
そこを指す全てのポインタ値をGCのたびに全て修整しなければならないという致命的な欠陥がある
C/C++/Rustなどでスタック上に置かれたポインタ値の全てを的確に書き換えるのは不可能なので使えない

262 名前:デフォルトの名無しさん mailto:sage [2022/07/08(金) 16:24:07.17 ID:atE4xqm8.net]
短時間で終了するプログラムはfree呼ばずにexitした方が高速な場合がある
copy gcも条件付きだが高速な場合がある
常にRAIIによるメモリ解放が他の手段より高速というのは誤り

100%正しいという風に断言するから枝葉の議論になるし最初から論理的に厳密な文章書いた方が良いよ

263 名前:デフォルトの名無しさん mailto:sage [2022/07/08(金) 16:35:35 ID:VZayErSn.net]
>>260
これは特殊な使い方限定の話を持ち出したら意味がない話
既に書いたようにCopying GCは汎用的には使いものにならない
一般的にはRAIIによる解放が最も高速かつ利便性が高い
そのためC++でもRustでもその方法がとられている

264 名前:デフォルトの名無しさん mailto:sage [2022/07/08(金) 17:23:29.15 ID:cRmlWf2z.net]
copying GCはJavaで使われているのだが

解放しない、以外でスタックの解放(malloc的なものに対する)freeより速いものはあるの?

265 名前:デフォルトの名無しさん [2022/07/08(金) 18:32:33.29 ID:r9xh0XFc.net]
>>246
C++にもweak_ptr<>あるけど。

266 名前:デフォルトの名無しさん mailto:sage [2022/07/08(金) 18:32:40.38 ID:IcalP2aj.net]
RAIIがGCより高速なら
RAIIの一例であるshared_ptrはGCの一例であるARCより高速ということになるが
どういう原理で高速になるの?

267 名前:デフォルトの名無しさん [2022/07/08(金) 18:42:02.74 ID:r9xh0XFc.net]
でも、Firefox良く落ちるじゃん。

268 名前:デフォルトの名無しさん [2022/07/08(金) 18:45:00.33 ID:r9xh0XFc.net]
でも、JavaはC++も20倍速いってサイト無くなったじゃん。

269 名前:デフォルトの名無しさん [2022/07/08(金) 18:50:36.37 ID:r9xh0XFc.net]
>>261
だって、RustはC++0xのパクリじゃん。



270 名前:デフォルトの名無しさん mailto:sage [2022/07/08(金) 18:52:55.66 ID:hlO59OkW.net]
>>264
shared_ptrではRAIIによって解放しない
RAIIによってデクリメントするだけ

SwiftなどでのARCが遅い理由は参照型の全てにおいてshared_ptrを使用しているような状況であるためコストが高い

271 名前:デフォルトの名無しさん [2022/07/08(金) 18:54:07.09 ID:r9xh0XFc.net]
じゃあ、unique_ptr<>でいいじゃん。

272 名前:デフォルトの名無しさん mailto:sage [2022/07/08(金) 19:10:19.78 ID:hlO59OkW.net]
>>269
unique_ptrとshared_ptrの役割の違い、動作の違いを理解できていない君が
間違えて用いてもC++ではコンパイルが通ってしまったりして実行時に問題を引き起こす
Rustは間違えて用いるとコンパイルエラーとなり通らないから安全側に救われる

273 名前:デフォルトの名無しさん mailto:sage [2022/07/08(金) 20:02:01.67 ID:A8oltmgp.net]
>>268
参照型の全てにshared_ptrを利用したら何で遅くなるの?

274 名前:デフォルトの名無しさん mailto:sage [2022/07/08(金) 21:48:50.65 ID:i9Nd4OSx.net]
>>257
即座に開放というのがOSに返却とか認識してたらアウトだぞ。
アロケーターなに使うかで実際の挙動は変わってくるからな。
普通しないがクソアロケーター使ったら、OSからみたらリーク同然になったりするし。

275 名前:デフォルトの名無しさん mailto:sage [2022/07/08(金) 21:53:34.22 ID:G/CdBPp1.net]
所有者がいないとメモリ解放って間違ってるよね?

所有者がいてもブロックから出たら解放されるからコンパイルエラーが出てコンパイルされない

276 名前:デフォルトの名無しさん mailto:sage [2022/07/08(金) 22:05:32.56 ID:h7kEq7Ot.net]
OSSでうっかり強循環参照作ってしまってた例が過去スレにあったようなと掘り返してみたところ、Part11にて発見

https://github.com/DataDog/glommio/commit/677fe1dfbaf911245fbc5c3eef75532d08d784bf
https://github.com/KWARC/rust-libxml/commit/bd4b120b90b2568ca6d5bfaa368a200573b87d09

277 名前:デフォルトの名無しさん mailto:sage [2022/07/08(金) 22:23:05.26 ID:RqLk9Xjf.net]
>>272
そんなバカな認識するのはオマエだけだろw

278 名前:デフォルトの名無しさん mailto:sage [2022/07/08(金) 22:38:42.99 ID:J0vSCVey.net]
>>273
所有者がいなくなるとメモリ解放であってるよ
スコープを抜けると所有者がいなくなりデストラクタが呼ばれて管理していたヒープ領域があれば解放される

279 名前:デフォルトの名無しさん mailto:sage [2022/07/08(金) 22:51:41.26 ID:j0PLF9Z7.net]
所有権とは?の話に戻っちゃうな
複製おじさんネタで散々繰り返したやつ



280 名前:デフォルトの名無しさん mailto:sage [2022/07/08(金) 23:06:47.48 ID:QSUHt/6/.net]
お前ら何回同じ話ループさせたら気が済むの?

281 名前:デフォルトの名無しさん mailto:sage [2022/07/08(金) 23:08:26.12 ID:h7kEq7Ot.net]
なんか合ってるのか分からんけど最近思うこと

Rustの言語仕様内に明確に含まれているのはlifetimeだけで
所有権とか所有者ってのは実はただのメタファーでしかない?

282 名前:デフォルトの名無しさん [2022/07/08(金) 23:12:47.70 ID:r9xh0XFc.net]
C++はコンテナのアロケータと積み荷のアロケータが別とかできるくらい柔軟ですよ。

283 名前:デフォルトの名無しさん [2022/07/09(土) 00:08:13.16 ID:Xo3+Ls6P.net]
コンセプトをコンパイラにハードコーディングして変えられないようにしたのがRustってこと?

284 名前:デフォルトの名無しさん mailto:sage [2022/07/09(土) 03:43:55.29 ID:dAPednzC.net]
>>256
こいつのような気持ち悪い反吐が出る輩がいるからRustがいまいちメジャーにならない。公式ドキュメント書き換えてこいゴミ
上の文章読んでどの辺が「アンチ」だ?ゴミのくせにイキって恥かいてんじゃねーわw

The Rust Programming Language 日本語版
循環参照は、メモリをリークすることもある
循環参照を回避する: Rc<T>をWeak<T>に変換する
https://doc.rust-jp.rs/book-ja/ch15-06-reference-cycles.html

285 名前:デフォルトの名無しさん mailto:sage [2022/07/09(土) 06:36:52.71 ID:x6eGZQ2/.net]
>>276
間違ってることを合ってると強弁するのいい加減辞めなよ

286 名前:デフォルトの名無しさん mailto:sage [2022/07/09(土) 07:31:04 ID:O4my42l1.net]
認める事を全くせず、大したコードも書いてないのにRustやってる事だけが自尊心だから勝手にアンチだの決めつけて
いつも人を見下して偉そう。プロジェクトチームの雰囲気はそいつがいるだけで常に最悪、チームの重荷・会社の害悪。
口癖は「意味不明」

287 名前:デフォルトの名無しさん mailto:sage [2022/07/09(土) 10:34:16.63 ID:OnqDT6DB.net]
>>282
実際にコードを自分で書いて理解したほうがいいよ。
その公式Bookに書かれている内容はもちろん正しいし、
その相手>>256の書き込み内容も正しくて、
両者に矛盾はないよ。

288 名前:デフォルトの名無しさん mailto:sage [2022/07/09(土) 11:42:59.26 ID:lwwTn4Ql.net]
理解してないと書いてる人間が理解してないことは多いですよね

289 名前:デフォルトの名無しさん mailto:sage [2022/07/09(土) 11:50:07 ID:lwwTn4Ql.net]
どちらにしてもRust使っても気楽にコーディングできるわけでもなく
メモリ構造考えなければいけないんですね



290 名前:デフォルトの名無しさん [2022/07/09(土) 13:10:56.08 ID:g+WH1rkE.net]
結局、C++0xのパクリじゃないですか。
C++はそこからさらに10年以上進んでるのに。

291 名前:デフォルトの名無しさん mailto:sage [2022/07/09(土) 13:14:26.15 ID:lwwTn4Ql.net]
それはないかな…
どっちも一長一短で視点がぼやけます

292 名前:デフォルトの名無しさん mailto:sage [2022/07/09(土) 13:41:18.89 ID:ByPaZ1uJ.net]
>>279
説明用に作った概念ではあるけどRustの根幹に関わる重要な概念なので
「ただのメタファーでしかない」という言い方は微妙
自分の好き勝手に解釈した内容を公式見解かのように流布する輩を助長することになるから

293 名前:デフォルトの名無しさん [2022/07/09(土) 14:19:07.01 ID:g+WH1rkE.net]
パクリ元のC++で所有権と呼ばれてるからでしょ。

294 名前:デフォルトの名無しさん [2022/07/09(土) 14:21:22.91 ID:g+WH1rkE.net]
C++は高機能すぎて分けワカメなので、初心者用に出来ることを減らしますという、ジェネリクス界のPythonがRustでは?

295 名前:デフォルトの名無しさん mailto:sage [2022/07/09(土) 14:57:08.15 ID:gD3yh/Bo.net]
>>283
見たけど正しいやん
間違ってる!とウソをつくけど間違ってる点を指摘できないいつもの人かね?

296 名前:デフォルトの名無しさん [2022/07/09(土) 15:04:05.66 ID:g+WH1rkE.net]
誰も所有してないのに解放されないなら意味ないじゃん。

297 名前:デフォルトの名無しさん mailto:sage [2022/07/09(土) 15:25:00.91 ID:3oDyg2LH.net]
>>294
ヒープ領域に対して誰も所有(利用)しなくなった時に
・自動解放しない(要手動解放) ← C C++(下記除く)
・即座に自動解放する ← Rust C++(unique_ptrなど使用時)
・GCする時になってから自動解放する ← ほとんどのGC言語

298 名前:デフォルトの名無しさん mailto:sage [2022/07/09(土) 15:36:21.95 ID:lXmK1DKz.net]
Cで書くにしても、今時のCLIツールならヒープなんか解放せず放置しても実用上問題ないよね

299 名前:デフォルトの名無しさん mailto:sage [2022/07/09(土) 16:18:04 ID:y0LX8Rgp.net]
そもそも間違ってるとは何と照らし合わせて間違ってるという主張なのか
「そうあるべきではない」というべき論なら前提を明確にしない限り知らんがなとしか言えん



300 名前:デフォルトの名無しさん [2022/07/09(土) 16:36:33 ID:g+WH1rkE.net]
>>295
いや、C++はアロケート時にアロケータを選択するから。
デフォルトが準備されてるだけで。
当然、GCもあり得るから。






[ 続きを読む ] / [ 携帯版 ]

前100 次100 最新50 [ このスレをブックマーク! 携帯に送る ] 2chのread.cgiへ
[+板 最近立ったスレ&熱いスレ一覧 : +板 最近立ったスレ/記者別一覧]( ´∀`)<279KB

read.cgi ver5.27 [feat.BBS2 +1.6] / e.0.2 (02/09/03) / eucaly.net products.
担当:undef