Rust part26

**デフォルトの名無しさん** · 2024/09/20(金) 22:18:38.38

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

公式ドキュメント
https://www.rust-lang.org/learn

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

※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 part25
https://mevius.5ch.net/test/read.cgi/tech/1722354386/

ﾜｯﾁｮｲスレ
プログラミング言語 Rust 4【ﾜｯﾁｮｲ】
https://mevius.5ch.net/test/read.cgi/tech/1514107621/

**デフォルトの名無しさん** · 2024/10/31(木) 22:06:07.79

>>570
そのまとめてブロックでメモリ確保して一気に返す方法はRustや他の言語でも使われている普通の方法

**デフォルトの名無しさん** · 2024/10/31(木) 22:08:28.63

まとめて解放するため循環参照があってもまとめて解放される

**デフォルトの名無しさん** · 2024/10/31(木) 22:57:51.93

C言語で出来る事はRustでも出来るよという事がイマイチ浸透していない気がする。
カスタムのメモリアロケーターも作れるし、GC欲しければ自分で実装するか、人が作ったクレート使えばいいし。
循環参照の管理が難しいならそういうシステム最初に作るでしょ？

**デフォルトの名無しさん** · 2024/10/31(木) 23:23:13.46

GC自作とかいう大二病しぐさは大学生のうちに卒業しておけよ

**デフォルトの名無しさん** · 2024/10/31(木) 23:37:38.88

>>576
仕事で普通に使うぞ。
用途決まってれば別に特別でもない。

**デフォルトの名無しさん** · 2024/10/31(木) 23:50:49.71

まとめてメモリ解放の究極版として
常駐プログラムでないなど単発処理プログラム対象だと
Rustはleak()を使ってライフタイムの'static化つまりプログラム終了まで解放しない宣言することでプログラミングが簡易になるよ
Cで一部をfreeしないのと同じことだね

**デフォルトの名無しさん** · 2024/11/01(金) 00:52:09.22

C言語で出来ることの大部分は実はRustでは出来ない。

**デフォルトの名無しさん** · 2024/11/01(金) 00:52:09.90

C言語で出来ることの大部分は実はRustでは出来ない。

**デフォルトの名無しさん** · 2024/11/01(金) 01:18:56.49

longjmpとか？

**デフォルトの名無しさん** · 2024/11/01(金) 01:28:27.65

いや。ほとんどのデータ構造とアルゴリズムが、Rustでは効率良く使用不可能。

**デフォルトの名無しさん** · 2024/11/01(金) 01:34:16.91

>>578
おいおい、Cでexitするときにfreeすべきか否かの論争はまだ決着がついてないぞ
勝手に決めつけるな

**デフォルトの名無しさん** · 2024/11/01(金) 03:23:25.98

rustのgcって型に情報はみ出てんじゃん
ローカルでしか使えんし

**デフォルトの名無しさん** · 2024/11/01(金) 05:52:59.83

RustにGC無いよ

**デフォルトの名無しさん** · 2024/11/01(金) 08:50:35.34

>>579
激遅でいいんならRustで出来るだろ

**デフォルトの名無しさん** · 2024/11/01(金) 09:12:07.99

libcクレート使えば、CとそっくりのRustプログラムできるでしょ

**デフォルトの名無しさん** · 2024/11/01(金) 11:20:36.22

>>577
作りたいから作ってるだけだろ
仮に委託先がGC作成費用請求して来たらブチ切れて契約切るわ

**デフォルトの名無しさん** · 2024/11/01(金) 18:44:17.66

>>579
名前空間が無いからってマクロで識別子を生成するのはもう勘弁してください

**デフォルトの名無しさん** · 2024/11/01(金) 18:49:49.50

GCついてるRustが欲しい
rustのtraitシステムは好きだが静的メモリ安全性まではいらない

**デフォルトの名無しさん** · 2024/11/01(金) 19:00:04.84

>>590
ちょっと探したらGc機能を提供するクレートたくさんあったよ。
どれが良いのかは知らん。

**デフォルトの名無しさん** · 2024/11/01(金) 19:25:45.68

まともなGCライブラリなんかないよ
おとなしくRustらしいコードを書くか、Rustをやめるかだ

**デフォルトの名無しさん** · 2024/11/01(金) 21:49:04.02

>>583
freeやdeleteは不要
freeせずにプログラムが終了したり落ちたりしてもメモリリークは起きない

**デフォルトの名無しさん** · 2024/11/01(金) 22:49:51.10

>>592
だよな

**デフォルトの名無しさん** · 2024/11/01(金) 23:32:34.62

>>593
メモリリークするかどうかはOSやアロケータ依存

**デフォルトの名無しさん** · 2024/11/01(金) 23:58:44.68

>>593
お前、組込みソフトの開発したことないだろ

あ、俺もなかったわ

**デフォルトの名無しさん** · 2024/11/02(土) 00:41:46.39

>>593
メモリリークチェッカーが反応してしまうから、今時きちんと解放処理書くから
不要とかそういうのは前時代的だぞ

**デフォルトの名無しさん** · 2024/11/02(土) 01:36:59.35

Tと&TとRc<T>を区別できるのは静的型付けの成果なんだよな

LispがすべてをGCの対象にするのは型を宣言しないからだし
それに、副作用のある関数とない関数を「型」で区別できなかったから
すべてが純粋な関数だったら (動的型でも) 分かりやすいという話になった

**デフォルトの名無しさん** · 2024/11/02(土) 04:46:39.55

成果でもなんでもない
言語的にそうせざるをえないだけ
型で区別するのはいいことばかりじゃない

**デフォルトの名無しさん** · 2024/11/02(土) 07:03:08.78

技術の話をたまにしかしない人達に
技術は善いことばかりじゃないと説教するのは的外れすぎるだろ

**デフォルトの名無しさん** · 2024/11/02(土) 07:06:40.35

技術的な話をしてるから的外れ
型の弊害の経験ないからピンとこない

**デフォルトの名無しさん** · 2024/11/02(土) 09:53:55.89

enumで解消

**デフォルトの名無しさん** · 2024/11/02(土) 14:38:12.14

とりあえず両極端を経験してみるのはじつは拙速で、巧遅でも清書でもない
どっちも弊害があると語る第三者が最も遅いのだ

**デフォルトの名無しさん** · 2024/11/02(土) 23:52:01.28

>>595
それはむしろ逆
freeを完全にすることでメモリリークを防ぐことはできない
freeはアロケータが管理するメモリバッファへ返還する動作しかしない
malloc/free交互にするたびにそのバッファをゼロにするためOSやその他システムへバッファを返還する非効率をしない
アロケータが管理するバッファはfree後も常に一定量が残っている
つまりバッファを完全にシステム側に返還する責務をfreeは持たないしfreeで実現は無理だ
そこは各システムが別の機構として責務を持っている
普通のOSならプロセス終了でバッファ含めて使用メモリ全体を自動解放することになる
組み込みシステムでもそのプログラム終了時に少なくともバッファ部分を解放する仕組みを持たなければならない
freeを忘れてもあるいはfreeせぬまま異常終了となってもその仕組みによりメモリリークは起きない

**デフォルトの名無しさん** · 2024/11/03(日) 01:07:42.39

>>604
君が想定している仕組みや振る舞いが
あらゆるOSやアロケータに当てはまるわけではないんだよ

>>595に戻る

**デフォルトの名無しさん** · 2024/11/03(日) 08:19:11.87

まともなOSならfreeせずに終了しても問題が起こらないように作ってあるよ
そうしないと異常終了のようなケースでリークし続けることになるし
(古いものやマイナーなものも含めた全てのOSがそうだとは言い切れないけど)

その上でだけど、上記はOSの動作の問題であって、言語のルールとしては「mallocしたら対になるfreeを呼ぶこと」だろうから、自分の好みとしてはfreeをちゃんと呼ぶよう作りたい派
「OSが解放するから問題ない」というのは「プログラマが責任をサボっても問題は起こらない」という感じがしてて、行儀の良いコードでないように感じる

**デフォルトの名無しさん** · 2024/11/03(日) 08:27:05.14

mallocしたら対になるfreeを呼ばずに終了するのはマナー違反
目上のOSに対して失礼に当たる

**デフォルトの名無しさん** · 2024/11/03(日) 08:32:32.56

こういうやつに限って問題が起きると「想定外でした」と恥ずかしげもなく言うんだよな

**デフォルトの名無しさん** · 2024/11/03(日) 08:32:33.64

メモリリークが問題になるのは、むしろ終了させずに長期間稼働させ続ける場面でのことだと思うが…。
特に鯖とか医療機器・自動車組み込みなど、経済・人命に影響が大きい分野。

**デフォルトの名無しさん** · 2024/11/03(日) 08:37:43.84

>>609
そういう分野では、そもそも動的にメモリ確保しない

**デフォルトの名無しさん** · 2024/11/03(日) 09:04:30.66

動的確保をしないものもあればするものもある
自分の知ってる範囲が世の中の全てだと勘違いしないことだな

**デフォルトの名無しさん** · 2024/11/03(日) 09:25:18.11

医療機器や自動車ほど重要なものではないけど、自分の仕事だと組込みでも動的確保を使うよ
Windows EmbeddedやUbuntuようなOSが入ってるし、それなりのリソースがある環境での話だけど
「大きなバッファはプログラムの最初に1度だけ確保する」ことはするけど、それ以降のヒープ確保をしないとか、static領域のみを使うとかまではしてない
(Rustスレでいうのもなんだけど現状はC++)

一般化できる話かは分からないけど、例えばカメラを使う機器かつ複数種類のハードウェアを扱うプログラムなら動的確保は必要じゃない？
想定するカメラ画像のうち最も大きいサイズに合わせたメモリを静的確保する作りでも良いと思うけど、プログラム起動後にハードウェアに問い合わせて、それを元に必要分のバッファを確保する作りも多いと思う

**デフォルトの名無しさん** · 2024/11/03(日) 10:22:36.62

>>612
確実にメモリ不足が起こらないこと保証できるのそれ？
まあ動くっしょ？ダメなら再起動で、みたいな感じ？
品質に対する意識すごいね

**デフォルトの名無しさん** · 2024/11/03(日) 11:21:00.89

mallocが駄目ならsbrkを使えば良いじゃない。by マリー

**デフォルトの名無しさん** · 2024/11/03(日) 11:34:52.74

> malloc/free交互にするたびにそのバッファをゼロにするためOSやその他システムへバッファを返還する非効率をしない

なんやこの悪文は

**デフォルトの名無しさん** · 2024/11/03(日) 11:49:46.99

>>609-610
手術中にGC走り出したら困るもんなー

**デフォルトの名無しさん** · 2024/11/03(日) 11:52:19.67

>>615
chatGPTに聴いて造らせたような文章だな

**デフォルトの名無しさん** · 2024/11/03(日) 13:59:19.14

ChatGPTはそんな変な文を作らない。

**デフォルトの名無しさん** · 2024/11/03(日) 16:50:47.89

MS-DOSですら、free忘れようが何しようが、
プロセス終了時にちゃんとOSがプロセスが確保した
メモリーを解放してたよ。

**デフォルトの名無しさん** · 2024/11/03(日) 17:05:19.83

なんせ、MS-DOSのように「意味的には」ページングして無い場合には、
メモリー解放はOS目線で見れば簡単と言えば簡単だからね。
for ( プロセスが確保していたメモリーブロックを全て巡る ) {
　(そのメモリーを解放);
}
みたいなロジックであって。
WindowsやLinuxのようなOSでは、ページングや色々なこと
してるから複雑だけど、それでもOSは頑張って解放するよ。

**デフォルトの名無しさん** · 2024/11/03(日) 17:20:04.38

素人質問で大変恐縮ですが、CPU/GPUのファームウェアをrustで書くことは可能？

**デフォルトの名無しさん** · 2024/11/03(日) 17:46:00.06

>>613
>確実にメモリ不足が起こらないこと保証できるのそれ？
それは悪魔の証明に近くないか？
保証はできないけど、普通に使う分には使えてるものだよ
人命に関わるような分野ではない&長時間 (例えば24時間以上) 連続で動かす機器ではないという条件だけど

「組込みでは動的確保をしてはならない」と言うなら、例えば組込みJetsonなんて製品が世に存在するわけがないでしょ
あれはNVIDEAのGPUを積んでて、CUDAを使った処理などを行える機器だけど、組込み向けとして売られてる
GPUメモリの確保は当然動的確保になるわけで

**デフォルトの名無しさん** · 2024/11/03(日) 18:50:54.75

>>621
デバイスドライバって意味なら書ける。
https://qiita.com/lalafell/items/be50f696a35fc6dbce62

win以外
ラズパイのキーボードファームウェアの記事。
https://zenn.dev/nazo6/articles/keyball-embassy-rp2040

こんな調子でCPUやGPUも理論的には行けるはず。
Googleはある程度道筋経ててるみたいね。

C/C++からRustへ：Googleが示すファームウェア進化の道筋
https://xenospectrum.com/google-revamps-firmware-with-rust/
Googleは最近、Android仮想化フレームワークの保護された仮想マシン用ファームウェアをRustプログラミング言語で書き直し、その経験をもとに他の開発者にも、“メモリセーフ”な言語である、Rustへの移行を強く推奨し、ブログでその詳細を解説している。

**デフォルトの名無しさん** · 2024/11/03(日) 18:52:21.77

Linuxなんて勝手にプロセス殺して知らんぷりする糞OSですし

**デフォルトの名無しさん** · 2024/11/03(日) 18:56:19.56

>>619
話聞いてた?
free忘れで問題になるのは、そのプロセスを数か月/数年単位で終了させない時に出る。
終了時にメモリ解放されるのは当たり前。

**デフォルトの名無しさん** · 2024/11/03(日) 19:43:19.04

>>623
ありがとうございます

**デフォルトの名無しさん** · 2024/11/03(日) 20:51:25.90

>>622
動的確保をするなではなくメモリ不足にならないことを保証しろだ
お前の周りの組み込み機器でメモリ不足エラー見たことあるか？
まともな会社でまともなスキル身につけたほうがいいぞ

**デフォルトの名無しさん** · 2024/11/03(日) 21:09:49.26

Staticこそ至高

**デフォルトの名無しさん** · 2024/11/03(日) 21:34:55.27

>>627
書いた通り、大きなメモリ (主に画像用) は最初に必要分を確保して使い回してるし、当然そのサイズは機器の搭載RAMサイズを考慮しているよ
処理によっては一時的なメモリ確保は生じるけど、適切に解放してるしメモリリークしてるわけでもない

組込みって分野が広いし、あくまでこれは自分の分野の話だというのは念頭においてくれ
メモリが32KBしかないマイコンと、8GBや16GBのメモリを積んでる機器とでは条件が全然違う
リソースが限られていたり、24時間360日動くような機器なら動的確保を避けろというのはその通りだと思う

**デフォルトの名無しさん** · 2024/11/03(日) 21:46:04.58

>24時間360日
これは365日の誤字

**デフォルトの名無しさん** · 2024/11/03(日) 22:22:34.29

>>607
普通のプログラマーが対象とする普通のOS環境においてfree()とOSは関連がない
そしてfree()せずにプログラムが終了してもメモリリークは起きない
関係するのプログラム動作中にメモリの再利用ができないことでメモリを使い果たさないかどうかのみだ

つまりGCに頼る言語でGCが起きる以前にプログラム実行が終わってしまうようなタイプのプログラムなら同様にfree()を行わなくても構わない
起動時にまとめてメモリを確保して終了時まで放さないタイプでもfree()を行なう必要はない
free()を行なわないことでプログラミングをより平易かつ安全にすることができる

**デフォルトの名無しさん** · 2024/11/03(日) 22:34:17.00

結論:
複オジが対象としているタイプのプログラムではfree()を行なわないことでプログラミングをより平易かつ安全にすることができる
以上。

**デフォルトの名無しさん** · 2024/11/03(日) 22:50:04.49

freeしないコードのコードレビューはしたくないな
こだわりが強そうだし、本当に安全なのか確かめるのも大変

**デフォルトの名無しさん** · 2024/11/03(日) 23:14:53.65

>>633
freeしなければダングリングも多重解放なども起こらないから絶対に安全だよ
freeしていると安全なのか確かめるのが難しくなる

**デフォルトの名無しさん** · 2024/11/04(月) 01:39:27.51

freeを使ってないがreallocは使ってるみたいな
敵視してない敵がいる
つまり敵味方は自由に選べないので、同意してないコストを強制されることもある

**デフォルトの名無しさん** · 2024/11/04(月) 02:53:23.37

Rustの話を、しよう

**デフォルトの名無しさん** · 2024/11/04(月) 14:38:06.42

>>634
安定の複オジ品質
草草草

**デフォルトの名無しさん** · 2024/11/04(月) 14:59:59.47

お話してから、しましょう

**デフォルトの名無しさん** · 2024/11/04(月) 16:28:27.25

>>637
いや俺はそいつとは違うが絶対安全なのは事実

**デフォルトの名無しさん** · 2024/11/04(月) 17:33:20.85

何が絶対安全なの？

**デフォルトの名無しさん** · 2024/11/04(月) 17:41:55.51

>>639
いや完全に脳みそ複オジでしょ

**デフォルトの名無しさん** · 2024/11/04(月) 18:04:13.97

>>566
亀レスだけどアドレスにリスナーをバインドすればnetstat -aの結果にLISTEN状態で出てくるぞ

**デフォルトの名無しさん** · 2024/11/04(月) 18:21:55.56

>>641
型システム入門って読んだことないん？
13章で確保した参照を絶対解放しない言語考えてその型安全性(つまりメモリ安全)証明しているけどこれ言っても理解できん？

**デフォルトの名無しさん** · 2024/11/04(月) 18:36:09.56

そんなイキれるほど頭のいいこと言ってないから
freeしなきゃ安全！
はずいわ

**デフォルトの名無しさん** · 2024/11/04(月) 18:36:26.40

そりゃ安全ではあるけど別の大問題を生むし……
わざわざそれを言ってるのって「Cであえて解放しないようにするとC++/RustでRAIIに任せるのと比べて（誤差レベルで）早い」って意見に対してくだらない意地張ってるだけじゃないですか

**デフォルトの名無しさん** · 2024/11/04(月) 18:45:22.71

>>643
#include <stdio.h>

int main() {
int x;
printf("%d\n", x);
return 0;
}

↑freeしてないけどメモリ安全ではないよ
何が安全なのか知らんけど

**デフォルトの名無しさん** · 2024/11/04(月) 19:51:08.05

>>644
引用文献載せるだけの行為に過剰反応するとかコンプでもあるんかな？
帰納法とか理解できないからこの本読めなくて可哀想w

**デフォルトの名無しさん** · 2024/11/04(月) 19:52:09.07

>>645
俺は寿命が短時間なのか想定されるプログラムで敢えてfreeしないアプローチを取るのは賛成やが

**デフォルトの名無しさん** · 2024/11/04(月) 19:52:59.06

>>646
この本ではdangling pointerのエラーについては発生しないこどメモリ安全だと主張している

**デフォルトの名無しさん** · 2024/11/04(月) 21:16:42.38

RAIIより単純なアプローチがもしあればRAIIは非科学的だぞという
このオッカムの剃刀自体が、科学的な実験やデータを必要としない哲学の思想だ

**デフォルトの名無しさん** · 2024/11/04(月) 21:43:03.80

>>636
Rustでももちろん意図的に解放しない有用な方法を公式にサポートしている
これはヒープ領域の一部を解放しないことにして例えばスタティック領域のようにみなすことができる
つまりライフタイムを'staticにできるため構造体メンバーに制約なく組み込めて関数からも自由に返せるようになる
この機能はsafeなRustの標準ライブラリとして提供されている

**デフォルトの名無しさん** · 2024/11/04(月) 22:47:38.24

>>649
そりゃ「確保した参照を絶対解放しない言語」ならdangling pointerは発生しないだろ
でもC言語はそうじゃないしはfreeしなくてもdangling pointerは発生するから全然安全じゃない

結局「freeしなければ絶対安全」の正体は
「freeしなければfree起因によるdangling pointerは発生しない」というだけ
当たり前すぎて泣けてくる

**デフォルトの名無しさん** · 2024/11/04(月) 23:29:15.46

政治起因による制約さえ無くなれば経済が偉大になるという謎理論があるからな

**デフォルトの名無しさん** · 2024/11/05(火) 22:33:43.60

>>652
Rustなら色々な安全性を全て保ったまま扱えるよ
所有者と所有権を消滅させることと引き換えに&'static mut Tを得ることも安全に行われている

**デフォルトの名無しさん** · 2024/11/05(火) 23:42:46.08

&'static mut Tに何か代入したらどうなるの
代入前の値にdropが定義されてたら呼び出される？
それは実質的にfreeしてるのと同じなのでは

**デフォルトの名無しさん** · 2024/11/06(水) 00:29:29.78

>>655
デストラクタはその型の値に対して行われるものであって
一般的にはヒープメモリとは関係がない
たまたまその型(の一部)がヒープメモリを所有すれば当然解放される

一方で&'static mut Tの元はBox<T>そして&'static mut [T]の元はVec<T>
つまり解放されないのはBoxやVecという入れ物でありTの話ではない

**デフォルトの名無しさん** · 2024/11/06(水) 07:25:52.71

構造体メンバーに!Copyを入れれば制約が生じる
Box<T>が!Copyだとしても&'static TはCopyだから制約がなくなった
ように見えるが、ヒープとか解放とかいうクソどうでもいい条件が増えてるんだよな

**デフォルトの名無しさん** · 2024/11/06(水) 08:04:15.27

&Tにスタック領域かヒープ領域かスタティック領域かの区別はなく意識することさえ必要ない
唯一の制約はライフタイムであり
staticでない&'a Tは所有者である'a Tより延命できない制約がある
一方&'static Tはプログラム終了時まで永遠に生きるため制約がない

**デフォルトの名無しさん** · 2024/11/06(水) 23:12:54.20

同時に意識しろとはいわないが
少しずつでも森羅万象を意識しないと客観的にならない

**デフォルトの名無しさん** · 2024/11/07(木) 22:29:40.21

>森羅万象

いわばまさに、だーらば

**デフォルトの名無しさん** · 2024/11/07(木) 22:47:47.58

static変数へ入れてしまう場合もプログラムの最後までヒープ解放しないよね
例えば以下は正規表現わざわざ使うまでもない簡単な例だけど
ヒープ領域を確保して内部に持つRegexを何度も作り直すムダを避けるためにstaticに持つよくあるパターンとか
それを解放するきっかけは最後までやって来ないよね

fn yyyymmdd(s: &str) -> Option<(u32, u32, u32)> {
const YYYYMMDD: &str = r"(\d\d\d\d)/(\d\d)/(\d\d)";
static RE: LazyLock<Regex> = LazyLock::new(|| Regex::new(YYYYMMDD).unwrap());

if let Some((_, [year, month, day])) = RE.captures(s).map(|caps| caps.extract()) {
let year = year.parse().ok()?;
let month = month.parse().ok()?;
let day = day.parse().ok()?;
Some((year, month, day))
} else {
None
}
}

**デフォルトの名無しさん** · 2024/11/08(金) 07:27:08.10

RustにJAVA厨が流れ着いてるのか

**デフォルトの名無しさん** · 2024/11/08(金) 08:29:50.38

}
else {

**デフォルトの名無しさん** · 2024/11/08(金) 10:14:50.92

汚ジコード乙

**デフォルトの名無しさん** · 2024/11/08(金) 12:15:41.38

毎回初期化を避けるためにstatic←JAVA脳
ローカル変数やauto変数にいちいちstatic描かなくても一回しか初期化されない←関数脳

**デフォルトの名無しさん** · 2024/11/08(金) 12:28:38.12

>>665
JavaだけでなくCでもRustでもどの言語でも同じだろ

**デフォルトの名無しさん** · 2024/11/08(金) 15:26:29.46

regex literalのある言語を知らないとか原始人かよw

**デフォルトの名無しさん** · 2024/11/08(金) 17:32:32.77

>>667
regex literalのある言語でもパターンが変数により変わる場合は別途生成になる
その場合に正規表現からオートマトンへのコンパイル結果をキャッシュする責務はプログラマー
それを何らかのオブジェクトに入れて毎回持ち回るのか避けてstatic変数などに入れてしまうかの話ではないか

**デフォルトの名無しさん** · 2024/11/08(金) 18:37:15.71

>>668
マジでregex literal知らんのだな
raw string literalとは違うのだよ！

**デフォルトの名無しさん** · 2024/11/08(金) 19:37:52.69

今確信したけどここまでの流れを見て断言するけど
Rustが主流の言語になることはないわな

**デフォルトの名無しさん** · 2024/11/08(金) 20:12:43.27

>>669
正規表現パターンに変数やその式を使ったことないのかい？
それら式を用いるとコンパイル結果を自分でキャッシュ管理しなければならなくなる

具体的にはregex literalの有無で
(1) 無い言語の例としてPythonは効率化のためにはre.compile(パターン, ...)結果のキャッシュが必要
(2) 有る言語の例としてRubyは式を含む場合のみ毎回評価し直すためキャッシュが必要
(3) 有るがパターンに式を書けない言語の例としてJavaScriptはnew RegExp(パターン, ...)結果のキャッシュが必要

いずれもregex literalの有無に関わらずコンパイル結果のキャッシュが必要となる

**デフォルトの名無しさん** · 2024/11/08(金) 20:55:31.49

ものによるが暗黙にキャッシュする (プログラマが保存しないでよい) 言語処理系は存在するよ。

**デフォルトの名無しさん** · 2024/11/08(金) 21:02:51.24

むしろ、コンパイルしてないほう（Arc<String>）をキャッシュする
そのStringが生きている間だけコンパイル結果を生かしておく

キャッシュが必要ならArcが必要と判明したせいでGC界隈の常識が覆された