[表示 : 全て 最新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/

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もあり得るから。

301 名前:デフォルトの名無しさん [2022/07/09(土) 16:39:05 ID:g+WH1rkE.net]
だめだ、こいつに聞いても無駄だ。
誰かわかるやつ居ないのか。

302 名前:デフォルトの名無しさん [2022/07/09(土) 16:52:06 ID:3+oPDqor.net]
この板で最も勢いのあるスレになりましたな

303 名前:デフォルトの名無しさん mailto:sage [2022/07/09(土) 17:15:21.88 ID:ziCGmT1x.net]
>>284
アンチ君は皆に論破されると毎回
思い込みの仮想敵を作り人格攻撃を始めて逃避するようだが
そんな下らないことはアンチスレでやってほしい

304 名前:デフォルトの名無しさん [2022/07/09(土) 17:29:07.29 ID:g+WH1rkE.net]
自分より詳しいやつは全部アンチか。
それじゃダメだろ。

305 名前:デフォルトの名無しさん mailto:sage [2022/07/09(土) 17:45:35.96 ID:bJtJfEbP.net]
Rust信者スレ作ったらそっちに移動してくれますか?

306 名前:デフォルトの名無しさん [2022/07/09(土) 17:54:41.59 ID:g+WH1rkE.net]
つまり、C++0xをパクって機能限定して簡単にしたのがRustだろ?

307 名前:デフォルトの名無しさん mailto:sage [2022/07/09(土) 17:58:46.63 ID:QKZ/1qEu.net]
>>295
プログラミング言語の進化の中で、
そのメモリ自動解放における高速性と安全性の両立をRustが初めて実現したってことになるのかな

308 名前:デフォルトの名無しさん mailto:sage [2022/07/09(土) 18:04:41.00 ID:SVLGLpJF.net]
Region-based Memory Management の構想は Cyclone から始まってる。
この段階では実用化したとは呼びにくいが、実現は出来ていた。

309 名前:デフォルトの名無しさん mailto:sage [2022/07/09(土) 18:22:19.04 ID:HoR4NOuF.net]
>>304
C++以外からもいろいろパクってるからその言い方だと不正確に思う



310 名前:デフォルトの名無しさん mailto:sage [2022/07/09(土) 18:46:05.22 ID:hyXSHlQu.net]
正確にはこうだな

プログラミング言語の進化の中で
メモリ自動解放における高速性と安全性の両立を実現した初めての実用的な言語がRust

311 名前:デフォルトの名無しさん mailto:sage [2022/07/09(土) 18:55:55 ID:FBd+xess.net]
実用的の定義が無いので不正確です

312 名前:デフォルトの名無しさん [2022/07/09(土) 18:58:45 ID:g+WH1rkE.net]
C++0xがなかなか標準化されないので、それなら自分で作ろうと立ち上がったと本人が言ってるじゃん。

313 名前:デフォルトの名無しさん mailto:sage [2022/07/09(土) 19:05:24 ID:hyXSHlQu.net]
>>309
そこは常識の範囲内で実用的をどのように定義しても>>308を満たすのはRustだけだから問題ない

314 名前:デフォルトの名無しさん mailto:sage [2022/07/09(土) 19:22:48.72 ID:kZfneOfi.net]
別にC/C++でもちゃんと作れば高速性と安全性は両立してるよ
ちゃんと作るのが難しいかどうかの話でしかないだろ

315 名前:デフォルトの名無しさん mailto:sage [2022/07/09(土) 19:29:47.99 ID:TbjkUF4v.net]
>>312
C/C++では不可能
うっかり危険なコードを書いてもコンパイラが通してしまう
Rustはコンパイラが指摘して通さないため安全

316 名前:デフォルトの名無しさん mailto:sage [2022/07/09(土) 19:30:20.48 ID:6ug5/LDh.net]
難しさを度外視してちゃんと作ればいいと言うならアセンブラでも同じわけで。

317 名前:デフォルトの名無しさん mailto:sage [2022/07/09(土) 19:36:03.58 ID:hyXSHlQu.net]
>>312
残念ながらCとC++は安全性を満たしていない
現状Rustだけが安全性と高速性を両立させている

318 名前:デフォルトの名無しさん mailto:sage [2022/07/09(土) 19:48:49.13 ID:HoR4NOuF.net]
>>315
rustだけが満たしている根拠教えて

319 名前:デフォルトの名無しさん mailto:sage [2022/07/09(土) 19:51:24.99 ID:zb7jG/MW.net]
じゃあChromeやSafari、Edgeじゃなく、お前のブラウザーふぁいあーふぉっくすにしろよ?安全じゃないんだろ?ぷゲラ



320 名前:デフォルトの名無しさん mailto:sage [2022/07/09(土) 19:52:51.29 ID:FBd+xess.net]
うっかり前提条件が保証できていないunsafe fnの呼び出しを書いてもRustコンパイラは通してしまうではないですか

321 名前:デフォルトの名無しさん mailto:sage [2022/07/09(土) 20:07:34 ID:kZfneOfi.net]
>>313,315
ああ、Rustが決めた安全性か
まあ>>274みたいなのには目をつぶるならそれでいいんじゃねw
はたから見たらオナニーにしか見えないけど

>>314
そうだよ、突き詰めたらレベルの違いでしかない
普通のひとは突き詰めること自体が馬鹿らしいって思うからこんなことで揉めたりしないけど

322 名前:デフォルトの名無しさん mailto:sage [2022/07/09(土) 20:08:04 ID:TbjkUF4v.net]
>>318
うっかりunsafe関数を呼び出しのは不可能
Rustコンパイラが通さない

323 名前:デフォルトの名無しさん mailto:sage [2022/07/09(土) 20:29:03 ID:r2wQepG1.net]
C++が敗北した理由が安全性を疎かにしたことは事実だけど
当時は安全性なんてそこまで重視されていなくて速ければよい時代だった
さらに安全性と速さを両立させる使い物になるプログラミング言語が出てくるとは想像できなかった
ここ数年でC++がようやく退場する時代となったたけでありそれ以前はC++の天下であった

324 名前:デフォルトの名無しさん mailto:sage [2022/07/09(土) 20:47:42.85 ID:FBd+xess.net]
― フクオジ書 12:4-5

325 名前:デフォルトの名無しさん mailto:sage [2022/07/09(土) 21:21:56.68 ID:6ug5/LDh.net]
>>319
そのレベルの違いが重要なわけじゃん

326 名前:デフォルトの名無しさん mailto:sage [2022/07/09(土) 21:26:07.86 ID:rB16NsHU.net]
>>318
実際にプログラミングをしたことがないからアンチはそんな間違った発言をうっかりしてしまう

327 名前:デフォルトの名無しさん mailto:sage [2022/07/09(土) 21:36:29.93 ID:TbjkUF4v.net]
>>319
天と地ほどの差がある
コンパイル時点でエラーとして弾いてくれてコンパイラが修整すべき点をアドバイスしてくれるRust
コンパイラは何も言わずに通してしまい実行運用中に問題が発覚するC/C++

328 名前:デフォルトの名無しさん mailto:sage [2022/07/09(土) 21:37:18.68 ID:FBd+xess.net]
「前提条件が保証できていない」に触れていないのはうっかり読み飛ばしたのかな?それともわざとかな?

329 名前:デフォルトの名無しさん mailto:sage [2022/07/09(土) 21:40:36.28 ID:N6dBVNoC.net]
マ板のコテハンが常駐するとどのスレも不毛地帯になるな



330 名前:デフォルトの名無しさん mailto:sage [2022/07/09(土) 21:51:31.23 ID:8h5AdXRe.net]
>>323
レベルの違いは重要、90点より95点の方が良いのは確か
ただ100点かどうかを争ってもあんまり意味ないだろ

>>325
> まあ>>274みたいなのには目をつぶるならそれでいいんじゃね
オナニーは言い過ぎだけど自分の決めた範囲で100点だーって言うのはまあ勝手に言ってりゃいいので相手に無理強いしてもしょうがない

331 名前:デフォルトの名無しさん mailto:sage [2022/07/09(土) 22:07:58.78 ID:dPnpzXnF.net]
アンチ連呼おじさんの主張は「おまえらはプログラミングしたことが無い」

332 名前:デフォルトの名無しさん mailto:sage [2022/07/09(土) 22:17:01.66 ID:5J/+jd/X.net]
話は単純
RustはC++における問題のうちみんなが挙げてるような重要な部分を解決してしまった
それにプラスしてC++よりpRustの方がプログラミングしやすい点も非常に大きい

333 名前:デフォルトの名無しさん [2022/07/09(土) 22:18:10.11 ID:GNVCknQf.net]
コテハンとは一体

334 名前:デフォルトの名無しさん mailto:sage [2022/07/09(土) 22:29:14.97 ID:FBd+xess.net]
>>330
そうだな
そしてRustが解決したという「問題」の範囲を大きく見せて誇大広告している人がいたのでぶっ叩かれたと
単純な話だ

335 名前:デフォルトの名無しさん mailto:sage [2022/07/09(土) 22:30:12.39 ID:dcG9hbvO.net]
>>329
「おまえらはもうプログラミングしていないだろ」
じゃないのか
若い時はしていたんだろうが、おっさん・爺になって仕事ではもうプログラミングしていない
比較は必死にするが実際のRustプログラミング話が無いおじさん・爺のRustスレだからな

336 名前:デフォルトの名無しさん mailto:sage [2022/07/09(土) 22:36:53.48 ID:qKBLdUt5.net]
年寄りはRustに構わないで欲しい
黙ってCでも書いてて

337 名前:デフォルトの名無しさん mailto:sage [2022/07/09(土) 22:44:39.49 ID:3KUXTO+D.net]
>>332
Linus含めたLinux開発陣も同じ結論
C++はダメな言語なので不採用
Rustは良い言語なので採用

338 名前:デフォルトの名無しさん mailto:sage [2022/07/09(土) 22:46:38.67 ID:dcG9hbvO.net]
>>334
歳をとってもうプログラミングしていないん(実質現役引退)だから
Cすら仕事で書いていないだろ

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

読んでなるほどなと思った
よくわかんないけどとりあえず動けばいいという人と、
ちゃんと理解して自分の思う通りに動かしたい人の違いだなと



340 名前:デフォルトの名無しさん mailto:sage [2022/07/09(土) 23:05:49.23 ID:dcG9hbvO.net]
>>335
俺,win使っているが
そのよい言語のRustをコンパイルするのに(C/C++する気ないのに)駄目な言語のmsvcを入れないと
とコンパイルできないてのがな

で、なんでmsvc必要なんだ?
ひょっとしたら、linuxでもgccとかを入れないと駄目なのか

341 名前:デフォルトの名無しさん mailto:sage [2022/07/09(土) 23:15:33.27 ID:yHOdCoxc.net]
>>337
その人があまりにも知識不足の可能性が高い
Rustでも他の言語と同様に(C互換FFIを除いて)メモリ構造なんて公開も保証もしていない
ほとんどのプログラミング言語はメモリ構造なんて低いレベルで使うものではなくもっと抽象度の高い部分でその定義と保証がなされるもの
だからRustでも他の言語と同様にメモリ構造は考えなくて良いし考えてはいけない
メモリ構造は言語として保証していないし保証しないからこそ大胆なコンパイル最適化を行なっている

話を戻してその人はメモリ構造ではなくデータ構造と言いたかったのではないか?
データ構造は他の言語と同様にRustでも考えなければならない
それがプログラミングの中心だから

342 名前:デフォルトの名無しさん mailto:sage [2022/07/09(土) 23:30:15.11 ID:hVKa6Imk.net]
>>338
そんなこと知らずに、そういうレスしているところにドン引きだな
自分で調べた?
調べたら、その結果をここで報告よろしく

343 名前:デフォルトの名無しさん mailto:sage [2022/07/09(土) 23:45:37.10 ID:yHOdCoxc.net]
>>338
Rust批判派があまりにも知識不足で驚いた
ちなみにこちらはLinuxだがrustc(=Rustコンパイラ)だけあればコンパイルできる

344 名前:デフォルトの名無しさん mailto:sage [2022/07/10(日) 00:12:02.83 ID:VXHYDjJa.net]
>>339
SwiftとかABI stabilityを実現してるやつは仕様としてメモリレイアウトを定義して公開してるやろ

345 名前:デフォルトの名無しさん mailto:sage [2022/07/10(日) 00:13:44.27 ID:ZPTgd3k2.net]
>>341
["rust linker cc not found"] [検索]

346 名前:デフォルトの名無しさん mailto:sage [2022/07/10(日) 00:16:59.60 ID: ]
[ここ壊れてます]

347 名前:CjJVLv20.net mailto: まあ>>287の書いてるメモリ構造という言葉はメモリレイアウトでもデータ構造でもないのは明らかだけどな []
[ここ壊れてます]

348 名前:デフォルトの名無しさん mailto:sage [2022/07/10(日) 00:18:51.99 ID:z1Ut0loV.net]
隔離スレ復活させないとノイズだらけできつくなってきた

349 名前:デフォルトの名無しさん mailto:sage [2022/07/10(日) 00:30:08.21 ID:tvXCky2C.net]
>>342
そのABIはコンパイル後のバイナリのフォーマットの話だぜ
今回の『気楽にコーディングできるわけでもなくメモリ構造考えなければいけないんですね』はプログラミングの際の話だから関係ない

プログラミングする上でメモリ構造は考えなくていい
例えばRustの型VecやStringなども各々のがどんなメモリ構造になるかは規定も公開もない
もちろんソースコードを読めば内部のデータ構造までは分かるがそれに依存してコードを書いてはいけないし依存できないよう抽象化されたインタフェースのみ規定公開されている



350 名前:デフォルトの名無しさん mailto:sage [2022/07/10(日) 00:33:22.94 ID:tvXCky2C.net]
>>345
同感
アンチ活動は別のスレでやってほしい
ここ本スレでやるのはマナー違反だと思う

今後Rustへのアンチ活動は以下のスレへ書くこと
Rustアンチスレ
https://mevius.5ch.net/test/read.cgi/tech/1509028624/

351 名前:デフォルトの名無しさん mailto:sage [2022/07/10(日) 01:01:37.00 ID:/Pm6re6i.net]
複オジに絡んだ俺がバカだったわw

352 名前:デフォルトの名無しさん mailto:sage [2022/07/10(日) 01:02:48.63 ID:qjKEOyYX.net]
>>343
なるほど、
>341
>ちなみにこちらはLinuxだがrustc(=Rustコンパイラ)だけあればコンパイルできる
は、比較的新しいrustを使えばgcc(リンカ)イラネってことか
rustでリンカ作った方がgccのリンカよりずっと良いものになるだろうからな

353 名前:デフォルトの名無しさん mailto:sage [2022/07/10(日) 01:09:37 ID:ZPTgd3k2.net]
https://mevius.5ch.net/test/read.cgi/tech/1657382429/

隔離対象をアンチに限定しない汎用隔離スレ立てた
もう全部こっちでやってくれ

354 名前:デフォルトの名無しさん mailto:sage [2022/07/10(日) 01:48:41.75 ID:LxkGLd0V.net]
>>350
おまえ低能だな
そんな内容と設定ではそのスレは過疎って終わることくらい予測できるだろ?

355 名前:デフォルトの名無しさん [2022/07/10(日) 04:45:49.56 ID:T5qatPVB.net]
荒らしてるのはLinux板の連中か。

356 名前:デフォルトの名無しさん mailto:sage [2022/07/10(日) 08:32:10.98 ID:VKvLuEGz.net]
Cellを使っていて思ったんだが例えば

trait CellUpdateWith<T> {
fn update_with(&self, f: impl FnOnce(&mut T));
}

impl<T: Default> CellUpdateWith<T> for Cell<T> {
#[inline]
fn update_with(&self, f: impl FnOnce(&mut T)) {
let mut inner = self.take();
f(&mut inner);
self.set(inner);
}
}

このようにメソッドupdate_with()を用意しておけば
内部更新もわかりやすく記述できるな

let foo = Cell::new(vec![1, 2, 3]);
foo.update_with(|v| v.push(7));

身代わりにself.take()でdefault値を入れてCellから取り出し
self.set()でCellへ戻すという無駄な操作は最適化で消えるようだ
https://godbolt.org/z/19c4EbErG

357 名前:デフォルトの名無しさん mailto:sage [2022/07/10(日) 12:00:25.54 ID:oYFJk9+G.net]
>>351
それをわざと狙ってんだろうなww
いかにもやりそうなこと

358 名前:デフォルトの名無しさん mailto:sage [2022/07/10(日) 13:59:32.22 ID:blpABUiA.net]
>>354
この手の人は自分が排除されることを最も恐れてるんだよ
そうならないための策ならなりふり構わず何でもやる

自分が排除される側にいる自覚がなければそんなことやらない

359 名前:デフォルトの名無しさん mailto:sage [2022/07/10(日) 19:54:18.59 ID:/ZDhY4rW.net]
>>308
糞言語で自意識過剰の公開オナニーをする信者、マジきもい



360 名前:デフォルトの名無しさん mailto:sage [2022/07/10(日) 23:37:14 ID:nSquZ6Rt.net]
>>308
プログラミング言語界に大革命をもたらした画期的な言語だな

361 名前:デフォルトの名無しさん [2022/07/11(月) 00:14:06.35 ID:triNevnR.net]
15年近くc/c++触ってなくて(ずっとjava触ってた)
rustの所有権とか何故こんな仕様になったのか経緯がわからなくて
最近のc11以降の仕様の?unique_ptrとかshared_ptrとかstd::moveとかstd::forward学んで
(元々boost にスマートポインタがあった記憶があるけど記憶が曖昧)
どうしてこう言う機能が出来たのか少しわかった

今のc++はconst 地獄だしとにかくコードが汚くなる
こりゃrust の方が良いわ

あと型名の付け方が好き。u32とかf32とか
昔cで書いてた頃typedefでわざわざ定義してたよ






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

前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