Rust part16 - 暇つぶし2ch

Rust part16 at TECH

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

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

252:デフォルトの名無しさん
22/07/08 09:30:47.62 Gv4jmnae.net
>>241
PijulもPRQLなど最近の新たな試みはRustで実装されることが多いが
それらはRust言語のためのものではなく汎用的なものであり
それらの問題点もRustとは直接関係がない
今後Rustで書かれた新たなものがどんどん増えていくだろうがそこは区別すべきところかな
一方でそれらをRust言語で使うためのクレートなどがあれば
Rustプログラミングにおいて使う特有の話なので
それらの話題自体を避けるべきではないね

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

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

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

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

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

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

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

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

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

260:デフォルトの名無しさん
22/07/08 14:56:50.59 bBPWEvXX.net
>>257
メモリを解放しないCopying GCの方が高速なんだけどなぁ。
Rustもメモリ解放しない実装なのかね？RAIIならスタック領域しかメモリを確保しないとか。

261:デフォルトの名無しさん
22/07/08 16:11:26.76 VZayErSn.net
>>258
C++もRustも仕組みは同じ
RAIIによりスコープを外れた対象のスタック部分が解放される時にそのデストラクタによってヒープ部分が解放される
汎用的にはこれが最も高速かつ利便性 >>253が高い
Copying GCは特殊な環境で特殊な使い方に限定する場合は速いこともありうるがデメリットも多く一般的には使われることが少ない
使用メモリが多くなるとかコピーで値を移動させるため非常に遅いなどのデメリットの他に
そこを指す全てのポインタ値をGCのたびに全て修整しなければならないという致命的な欠陥がある
C/C++/Rustなどでスタック上に置かれたポインタ値の全てを的確に書き換えるのは不可能なので使えない

262:デフォルトの名無しさん
22/07/08 16:24:07.17 atE4xqm8.net
短時間で終了するプログラムはfree呼ばずにexitした方が高速な場合がある
copy gcも条件付きだが高速な場合がある
常にRAIIによるメモリ解放が他の手段より高速というのは誤り
100%正しいという風に断言するから枝葉の議論になるし最初から論理的に厳密な文章書いた方が良いよ

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

264:デフォルトの名無しさん
22/07/08 17:23:29.15 cRmlWf2z.net
copying GCはJavaで使われているのだが
解放しない、以外でスタックの解放(malloc的なものに対する)freeより速いものはあるの？

265:デフォルトの名無しさん
22/07/08 18:32:33.29 r9xh0XFc.net
>>246
C++にもweak_ptr<>あるけど。

266:デフォルトの名無しさん
22/07/08 18:32:40.38 IcalP2aj.net
RAIIがGCより高速なら
RAIIの一例であるshared_ptrはGCの一例であるARCより高速ということになるが
どういう原理で高速になるの？

267:デフォルトの名無しさん
22/07/08 18:42:02.74 r9xh0XFc.net
でも、Firefox良く落ちるじゃん。

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

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

270:デフォルトの名無しさん
22/07/08 18:52:55.66 hlO59OkW.net
>>264
shared_ptrではRAIIによって解放しない
RAIIによってデクリメントするだけ
SwiftなどでのARCが遅い理由は参照型の全てにおいてshared_ptrを使用しているような状況であるためコストが高い

271:デフォルトの名無しさん
22/07/08 18:54:07.09 r9xh0XFc.net
じゃあ、unique_ptr<>でいいじゃん。

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

273:デフォルトの名無しさん
22/07/08 20:02:01.67 A8oltmgp.net
>>268
参照型の全てにshared_ptrを利用したら何で遅くなるの？

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

275:デフォルトの名無しさん
22/07/08 21:53:34.22 G/CdBPp1.net
所有者がいないとメモリ解放って間違ってるよね？
所有者がいてもブロックから出たら解放されるからコンパイルエラーが出てコンパイルされない

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

277:デフォルトの名無しさん
22/07/08 22:23:05.26 RqLk9Xjf.net
>>272
そんなバカな認識するのはオマエだけだろｗ

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

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

280:デフォルトの名無しさん
22/07/08 23:06:47.48 QSUHt/6/.net
お前ら何回同じ話ループさせたら気が済むの？

281:デフォルトの名無しさん
22/07/08 23:08:26.12 h7kEq7Ot.net
なんか合ってるのか分からんけど最近思うこと
Rustの言語仕様内に明確に含まれているのはlifetimeだけで
所有権とか所有者ってのは実はただのメタファーでしかない？

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

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

284:デフォルトの名無しさん
22/07/09 03:43:55.29 dAPednzC.net
>>256
こいつのような気持ち悪い反吐が出る輩がいるからRustがいまいちメジャーにならない。公式ドキュメント書き換えてこいゴミ
上の文章読んでどの辺が「アンチ」だ？ゴミのくせにイキって恥かいてんじゃねーわｗ
The Rust Programming Language 日本語版
循環参照は、メモリをリークすることもある
循環参照を回避する: Rc<T>をWeak<T>に変換する
URLﾘﾝｸ(doc.rust-jp.rs)

285:デフォルトの名無しさん
22/07/09 06:36:52.71 x6eGZQ2/.net
>>276
間違ってることを合ってると強弁するのいい加減辞めなよ

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

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

288:デフォルトの名無しさん
22/07/09 11:42:59.26 lwwTn4Ql.net
理解してないと書いてる人間が理解してないことは多いですよね

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

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

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

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

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

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

295:デフォルトの名無しさん
22/07/09 14:57:08.15 gD3yh/Bo.net
>>283
見たけど正しいやん
間違ってる！とウソをつくけど間違ってる点を指摘できないいつもの人かね？

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

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

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

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

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

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

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

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

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

305:デフォルトの名無しさん
22/07/09 17:45:35.96 bJtJfEbP.net
Rust信者スレ作ったらそっちに移動してくれますか？

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

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

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

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

310:デフォルトの名無しさん
22/07/09 18:46:05.22 hyXSHlQu.net
正確にはこうだな
プログラミング言語の進化の中で
メモリ自動解放における高速性と安全性の両立を実現した初めての実用的な言語がRust

311:デフォルトの名無しさん
22/07/09 18:55:55 FBd+xess.net
実用的の定義が無いので不正確です

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

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

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

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

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

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

318:デフォルトの名無しさん
22/07/09 19:48:49.13 HoR4NOuF.net
>>315
rustだけが満たしている根拠教えて

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

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

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

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

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

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

324:デフォルトの名無しさん
22/07/09 20:47:42.85 FBd+xess.net
― フクオジ書 12:4-5

325:デフォルトの名無しさん
22/07/09 21:21:56.68 6ug5/LDh.net
>>319
そのレベルの違いが重要なわけじゃん

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

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

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

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

330:デフォルトの名無しさん
22/07/09 21:51:31.23 8h5AdXRe.net
>>323
レベルの違いは重要、90点より95点の方が良いのは確か
ただ100点かどうかを争ってもあんまり意味ないだろ
 >>325
> まあ >>274みたいなのには目をつぶるならそれでいいんじゃね
オナニーは言い過ぎだけど自分の決めた範囲で100点だーって言うのはまあ勝手に言ってりゃいいので相手に無理強いしてもしょうがない

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

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

333:デフォルトの名無しさん
22/07/09 22:18:10.11 GNVCknQf.net
コテハンとは一体

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

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

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

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

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

339:デフォルトの名無しさん
22/07/09 22:59:01.59 hVKa6Imk.net
> 287 名前：デフォルトの名無しさん　[sage]　投稿日：2022/07/09(土) 11:50:07.31 ID:lwwTn4Ql [2/3]
> どちらにしてもRust使っても気楽にコーディングできるわけでもなく
> メモリ構造考えなければいけないんですね
読んでなるほどなと思った
よくわかんないけどとりあえず動けばいいという人と、
ちゃんと理解して自分の思う通りに動かしたい人の違いだなと

340:デフォルトの名無しさん
22/07/09 23:05:49.23 dcG9hbvO.net
>>335
俺,win使っているが
そのよい言語のRustをコンパイルするのに(C/C++する気ないのに)駄目な言語のmsvcを入れないと
とコンパイルできないてのがな
で、なんでmsvc必要なんだ？
ひょっとしたら、linuxでもgccとかを入れないと駄目なのか

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

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

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

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

345:デフォルトの名無しさん
22/07/10 00:13:44.27 ZPTgd3k2.net
>>341
["rust linker cc not found"] [検索]

346:デフォルトの名無しさん
22/07/10 00:16:59.60

347:CjJVLv20.net

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

349:デフォルトの名無しさん
22/07/10 00:30:08.21 tvXCky2C.net
>>342
そのABIはコンパイル後のバイナリのフォーマットの話だぜ
今回の『気楽にコーディングできるわけでもなくメモリ構造考えなければいけないんですね』はプログラミングの際の話だから関係ない
プログラミングする上でメモリ構造は考えなくていい
例えばRustの型VecやStringなども各々のがどんなメモリ構造になるかは規定も公開もない
もちろんソースコードを読めば内部のデータ構造までは分かるがそれに依存してコードを書いてはいけないし依存できないよう抽象化されたインタフェースのみ規定公開されている

350:デフォルトの名無しさん
22/07/10 00:33:22.94 tvXCky2C.net
>>345
同感
アンチ活動は別のスレでやってほしい
ここ本スレでやるのはマナー違反だと思う
今後Rustへのアンチ活動は以下のスレへ書くこと
Rustアンチスレ
ｽﾚﾘﾝｸ(tech板)

351:デフォルトの名無しさん
22/07/10 01:01:37.00 /Pm6re6i.net
複オジに絡んだ俺がバカだったわw

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

353:デフォルトの名無しさん
22/07/10 01:09:37 ZPTgd3k2.net
ｽﾚﾘﾝｸ(tech板)

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

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

355:デフォルトの名無しさん
22/07/10 04:45:49.56 T5qatPVB.net
荒らしてるのはLinux板の連中か。

356:デフォルトの名無しさん
22/07/10 08:32:10.98 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へ戻すという無駄な操作は最適化で消えるようだ
URLﾘﾝｸ(godbolt.org)

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

358:デフォルトの名無しさん
22/07/10 13:59:32.22 blpABUiA.net
>>354
この手の人は自分が排除されることを最も恐れてるんだよ
そうならないための策ならなりふり構わず何でもやる
自分が排除される側にいる自覚がなければそんなことやらない

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

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

361:デフォルトの名無しさん
22/07/11 00:14:06.35 triNevnR.net
15年近くc/c++触ってなくて(ずっとjava触ってた)
rustの所有権とか何故こんな仕様になったのか経緯がわからなくて
最近のc11以降の仕様の？unique_ptrとかshared_ptrとかstd::moveとかstd::forward学んで
(元々boost にスマートポインタがあった記憶があるけど記憶が曖昧)
どうしてこう言う機能が出来たのか少しわかった
今のc++はconst 地獄だしとにかくコードが汚くなる
こりゃrust の方が良いわ
あと型名の付け方が好き。u32とかf32とか
昔cで書いてた頃typedefでわざわざ定義してたよ

362:デフォルトの名無しさん
22/07/11 10:40:05.73 1W23UOpt.net
const 地獄 ← 判る
static_cast うぜー ← 判る
Rust 万歳 ← 判らん

363:デフォルトの名無しさん
22/07/13 23:59:24.88 qlTJEO+a.net
>>353
もっと便利にできるぜ
use std::cell::Cell;
trait CellWithMethod<T> {
fn with<R>(&self, f: impl FnOnce(&mut T) -> R) -> R;
}
impl<T: Default> CellWithMethod<T> for Cell<T> {
#[inline]
fn with<R>(&self, f: impl FnOnce(&mut T) -> R) -> R {
let mut inner = self.take();
let result = f(&mut inner);
self.set(inner);
result
}
}
fn main() {
let foo = Cell::new(vec![1, 2, 3]);
foo.with(|v| v.push(7));
assert_eq!(4, foo.with(|v| v.len()));
assert_eq!(7, foo.with(|v| v[3]));
assert_eq!(vec![1, 2, 3, 7], foo.with(|v| v.clone()));
}

364:デフォルトの名無しさん
22/07/15 21:39:01.85 qV4GyRtM.net
>>360
CellでVec使えるのか
何か間違って学習していた
URLﾘﾝｸ(qiita.com)
＞ 1. Cellの中身の型はCopyをimplしていなければならない
URLﾘﾝｸ(dev.classmethod.jp)
＞・Cellの中の型はCopyトレイト実装が必須
URLﾘﾝｸ(qiita.com)
＞ Cell は値の "移動" によって内部可変性を実装するため <T> は Copy 可能な "値" 向けのコンテナーで、
＞ i32 や Copy trait を実装した何かを扱うのに"適した"コンテナーです。
URLﾘﾝｸ(zenn.dev)
＞ Cell<T> の大きな制約として， T は Copy トレイト境界があることです．
実際にはCellはCopyを要求していない
やってみたら >>360のコードが動いてCell<Vec<_>>が使えた

365:デフォルトの名無しさん
22/07/15 22:48:49.30 fFdw7/F8.net
#[derive(Clone)]のコーナーケースに遭遇した
URLﾘﾝｸ(play.rust-lang.org)

366:デフォルトの名無しさん
22/07/15 22:50:32.95 SBkpZpFk.net
やっぱりrustcはバグが多いね

367:デフォルトの名無しさん
22/07/15 23:12:58.85 nxNpCMHU.net
>>362
標準ライブラリのderiveは型パラメータに無条件にトレイト制約課すようになってるから
derivativeみたいな制約を自分で指定できるcrateを使うと良いよ
URLﾘﾝｸ(github.com)

368:デフォルトの名無しさん
22/07/16 00:28:56.56 730D9OZt.net
>>361
get()がCopyを要求するからってのもあるけど
古いThe BookにはCellはCopy専用・RefCellはCopy以外も使えるという説明があったので
それが日本語訳とかで残ってたんじゃないかな

369:デフォルトの名無しさん
22/07/16 23:27:56 MG4+BxCd.net
>>360
!Syncで参照無しならデータ競合を起こさない、という点を使った用法だな
便利だから公式サポートすればいいのにな

370:デフォルトの名無しさん
22/07/20 00:26:56.65 XqWqiApN.net
StackOverflowで「好きな言語No.1」だそうだが、調査方法に問題が有り、
二位以下も聞いた事が無いような言語ばかり。

371:デフォルトの名無しさん
22/07/20 01:36:05.55 bF1qPY0V.net
>>367
お前の観測範囲が狭いだけ。

372:デフォルトの名無しさん
22/07/20 08:04:49 XbfHqe9W.net
CarbonとかいうRustとC++のあいのこみたいなのが出てきた

373:デフォルトの名無しさん
22/07/20 12:35:25 FCfDFeLf.net
Carbonは最強言語ぞ

374:デフォルトの名無しさん
22/07/20 12:39:05 MUkQlR/e.net
RustがCarbonに勝ててるところが見つからないな

375:デフォルトの名無しさん
22/07/20 12:45:18 ThH+Z+BW.net
Rust vs Carbonスレ立ててそっちでやれ

376:デフォルトの名無しさん
22/07/20 13:30:14 S6pSKHOi.net
このスレにはRust好きの愚民がたくさんいるようですね。
Carbonさん、やっておしまいなさい

377:デフォルトの名無しさん
22/07/20 13:30:16 S6pSKHOi.net
このスレにはRust好きの愚民がたくさんいるようですね。
Carbonさん、やっておしまいなさい

378:デフォルトの名無しさん
22/07/20 14:11:36.68 xLuB33a9.net
1.0が出てからにしてください

379:デフォルトの名無しさん
22/07/20 14:52:25.57 IMMZUJf4.net
CarbonとRustは名称の紛らわしさではどっこいどっこいだな

380:デフォルトの名無しさん
22/07/20 14:54:39.84 igxVbWbR.net
ほーん
URLﾘﾝｸ(github.com)

381:デフォルトの名無しさん
22/07/20 17:02:14.65 xLuB33a9.net
とりあえずcarbon自体のコードの8割がcarbonで書かれるエコシステムが確立してからだろう

382:デフォルトの名無しさん
22/07/20 19:50:56 hGf+NvAH.net
JSのTypeScript
C++のCarbonって感じかね

どうなるんだろうね
確かにC++を無くすのは勿体ないがまだ0.1かいつ1.0になるかなぁ 10年後くらいか
Rustよりも難しくはなくメモリ管理も楽になるのかな

383:デフォルトの名無しさん
22/07/20 20:00:37 xdIX6xM1.net
Rustはあらゆる面で安全と高速の両立する抽象化を実現した言語だから
現在のCarbonのドキュメントを見る限りRustの領分に入ってきていないでしょう
それよりもC++と書き方がかなり変わっていて互換性がなく別言語の様相でCarbonは中途半端な立ち位置に見える

384:デフォルトの名無しさん
22/07/20 20:01:46 sReX4jGj.net
Carbonは「Rustが難しすぎるから簡単にしたい」とは言ってなくて、C++と相互運用できる言語を目指してるだけっぽいからなぁ
結果的にRustより難しくなっても驚かないけど

385:デフォルトの名無しさん
22/07/20 20:33:50.16 sReX4jGj.net
そもそもCarbonの使い所ってC++のレガシーコードが大量にあるところだから
C++も当然マスターしてないといけなくて、学習量は明らかに増えてる気もする

386:デフォルトの名無しさん
22/07/20 20:52:36.69 oyesoq1v.net
ドラゴンボールのゲームでドドリアの色違いでカーボスと言うのがいたのを思い出した
どちらかと言うとザーボンの色違いがカーボスなら納得なんだけど…

387:デフォルトの名無しさん
22/07/20 21:27:24.19 mJssGRdK.net
Carbonって中途半端すぎね？
まともな言語設計者ならオブジェクト指向もう採用しないと思うんやけどなんか継承機能もあるみたいだし
なんでこういう中途半端のところもC++参考するんだよこういうところこそRust参考にしろよ

388:デフォルトの名無しさん
22/07/20 21:44:56.66 qLBZujX3.net
>>384
C++とシームレスに相互運用することが最優先課題だから、そこはC++と同じにしておかないとそもそも存在意義がなくなる

389:デフォルトの名無しさん
22/07/20 22:16:07.31 gROTqHCf.net
ま、2-3年後にどうなってるかだな
バックにGoogleいるらしいから開発終了なんてことはなさそうだが

390:デフォルトの名無しさん
22/07/20 22:21:24.71 9oJrmZpV.net
>>386
逆じゃね？企業だからこそ開発者の熱意とか関係なくコストに見合わないとなれば容赦なく切られるかと
Goみたいに社内で使うことが確定してしまえば安泰だけど

391:デフォルトの名無しさん
22/07/20 22:28:16.35 3tivAU0I.net
SDGsの流れ的にCarbonは使われなくなる運命

392:デフォルトの名無しさん
22/07/20 22:43:27.67 xLuB33a9.net
なる、元素記号Cからの名称か

393:デフォルトの名無しさん
22/07/21 00:45:01.09 g1dckGB4.net
5年たったらまたオブジェクト指向が再燃してるかもしれない
と言うか業務では大規模開発にはオブジェクト指向が必須なんだな
モジュールでは全体が見通せない

394:はちみつ餃子
22/07/21 00:52:44.62 /hG5LMVG.net
話題が逸れるが >>384 が C++ の型システムをオブジェクト指向と呼んでるっぽいのが気になる。
オブジェクト指向はオブジェクト同士がメッセージを送りあう形でプログラムを構成する思想のことで、
それを言語機能としてどのように支援するのかには様々なバリエーションが有りうる。
型システムとは独立した概念だよ。
ふんわりした概念なので定義によるが Rust もオブジェクト指向 (をサポートする) 言語に分類されることはある。
それはそれとして、 C++ の型システムもベストとは言えないが最悪というわけでもない。
実際にかなり多くの場面で活用されている実績は認めないといけない。
要するに「この程度で十分」ではあるんだよ。
C++ の本当につらいところは C から引き継いだガバガバさや歴史的事情のワケわからんところであって、
型システムの根本的な改善はそれほど切実に必要だとは思わないな。
C++ が駄目だと否定するんじゃなくて C++ みたいなことを C++ より上手くやるという方向性はアリだろう。

395:デフォルトの名無しさん
22/07/21 00:54:52.22 0vTmbBj3.net
話題が逸れるが、...で読む気失せたわ

396:デフォルトの名無しさん
22/07/21 00:58:24.47 MOkaWH3B.net
>>391
前半は正しいが
後半のクラス継承システム程度で十分という点には賛同しかねる
今までの現実の多くのケースはクラス継承システムしか使えない環境だったから無理矢理にそれを使っているだけである

397:デフォルトの名無しさん
22/07/21 01:00:56.06 g1dckGB4.net
似たような機能のものを大量に書く場合どのように実装するのが楽かどのように管理するのが楽か
モジュールではないな

398:デフォルトの名無しさん
22/07/21 01:15:53.78 MOkaWH3B.net
>>394
その点ではRustもC++も同じオブジェクト指向なので何を主張したいのかわからない
Rustの基本はselfに見られるようにオブジェクト指向
違いはC++がクラス継承なのに対してRustはトレイト
ジェネリックから見るトレイト境界による型制約となり
逆の視点から見るとトレイト付加によるメソッド拡張となる

399:デフォルトの名無しさん
22/07/21 03:25:39.61 DiLbgRco.net
いくらRustが有望だと言われていても、ポインターがないと使いづらい場面ってあるよな
ツリー構造とか、ポインターなしで大して実行速度も落とさず記述する技があるようだけど・・・・大掛かりなことをするのなら労力を割くのもいいけど、ちょっと使うだけには労力がかかりすぎる

400:デフォルトの名無しさん
22/07/21 04:26:36.96 VmE9g8Ff.net
ポインタあるじゃん

401:デフォルトの名無しさん
22/07/21 05:01:15.84 hbmQrHo+.net
>>396
Rustにも様々なポインタがあり
様々な仕様と様々な安全度合いで記述できる

402:デフォルトの名無しさん
22/07/21 08:09:40 HHuzACnI.net
>>385
Rustからわかるように、求められているのは膝を打ち抜く自由の無いc++であり、コーダーに使わせる言語。
unsafeはc++で実装すりゃいいので、継承とかは使うだけに限定するという手もある。

403:デフォルトの名無しさん
22/07/21 13:48:15.98 xy799ZfA.net
>>391
話し手がなにをオブジェクト指向の言語としているのかどうか判断する程度の読解力は持ち合わせてくれないかな？
RustはC++のように継承を導入することによってもたらされる問題を回避するためにclassじゃなくてtraitを基本的なプログラムの構成要素として採用することで既存のオブジェクト指向言語と一線を画すというプログラミング言語史に残る進歩を達成していた

404:デフォルトの名無しさん
22/07/21 15:49:13.07 Q1uK5/Rv.net
>>400
Haskellの型クラスの方が先だろ。
「プログラミング言語史に残る進歩」とかさすがに恥ずかしいレベル。

405:デフォルトの名無しさん
22/07/21 16:58:11.12 xy799ZfA.net
>>401
RustのtraitをただのHaskellの型クラスの類似物としてしか認識できないのはお前が単に馬鹿だから
Rustのtraitは本来継承もmixinとも違ったC++のclassより洗練された新たなプログラムの構成要素だっていう側面が理解できていない馬鹿が多すぎる
ただRustではこのtraitという構成要素に実用上の面から今度は型クラスという機能も持たせているというだけで話の順序が違う
こんぐらいRust書いていたらtraitには単に型クラスだけの意義だけじゃないってわかると思うんやがお前にはそういった才能もないただのネット上で繰り返し喧伝されている宣伝にしか注目する脳がないいわばにわかの部類の奴だということがわかった

406:デフォルトの名無しさん
22/07/21 17:50:57.39 eNA5340i.net
traitの画期的な部分はc++のabstract classで実現できないの？

407:デフォルトの名無しさん
22/07/21 17:54:16 F7Gtvv1S.net
>>402
何が言いたいのかよくわからないけど型クラスになくてtraitにあるものって何？

associate typeはrustの発明だと思うけど、そういうこと言いたいわけでもなさそうだし

408:デフォルトの名無しさん
22/07/21 18:07:36 ySHdWcK4.net
自分が崇拝する神だけが唯一正しいと妄信して
他人の考え方を徹底的に糾弾排斥するのがカルト

カルト化した人間とまともな議論ができると思うな

409:デフォルトの名無しさん
22/07/21 18:19:30.67 xy799ZfA.net
>>404
公式サイトにすら出典付きで載ってあることなんだけどなんでここで聞くの？
繰り返しになるがtraitの型クラス以外の側面に気づけないのはお前が単に馬鹿なだけ

410:デフォルトの名無しさん
22/07/21 19:01:28.92 HGs+QJMA.net
>>406
そういうのを誘導しないからお前はダメなんだよ。
prev.rust-lang.org/ja-JP/faq.html#how-do-rust-traits-compare-to-haskell-typeclasses
How do Rust traits compare to Haskell typeclasses?
Rust traits are similar to Haskell typeclasses, but are currently not as powerful, as Rust cannot express higher-kinded types. Rust’s associated types are equivalent to Haskell type families.

次ページ