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/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界隈の常識が覆された

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

>>672
暗黙にキャッシュは固定文字列パターンの時だけではないか？
パターン内の式の値が毎回替わりうる可能性があるから
言語側としては>>671のように毎回評価し直す仕様や
regex literalを用いず明示的にコンパイルする関数を呼ぶ仕様になっている

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

>>674
いや、キャッシュというかいわゆるメモ化かな。
入力される値は変わりうるが、同じ入力に対しては同じ結果であることは保証される (かつ現実的な用途では同じ値が入力される可能性が高い) ので値とセットで記憶しておく方法で十分に処理コストを減らせる。

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

全く異なるユースケースを持ち出してまで
「どの言語も同じ」ということにしたいらしい

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

>>674
Pythonのreなら直近の512個まで自動的にキャッシュされてるよ

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

ワンライナーみたいな使い方をする言語では (結果的に無駄になってでも) 暗黙に色々やっといてくれるほうが便利ってこともあるからどんな言語でも Rust と同じ方式のはずとは言えんわな。

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

>>673
Arcは要らない
何度も使う固定の正規表現ならその関数かモジュールのstatic変数で十分
変数部分を持つ正規表現それぞれを何度も使い回すならその呼び出したい元の構造体フィールドに入れておけば十分

>>675
そんな一般的なメモ化は論外
ハッシュマップ相当のコストがかかる上に再利用しないものや不要になったものを持ち続ける愚かさ

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

>Arcは要らない
ふーん

https://docs.rs/regex/latest/src/regex/regex/string.rs.html#101-104

**デフォルトの名無しさん** · 2024/11/09(土) 00:23:52.73

それはRegexの内部実装なので無関係だね
CloneできるようにArcを使ってるよくある手だよ

**デフォルトの名無しさん** · 2024/11/09(土) 01:08:06.88

？
内部実装の話をしてるんではないのか

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

再コンパイルを避けるためにstaticで持ったりオブジェクトメンバーで持ったりと利用プログラマー側の話でしょ
その時に必要ならCloneもできるということ

**デフォルトの名無しさん** · 2024/11/09(土) 01:27:01.06

何の話をしてるのか、誰か一人でも分かってるんだろうか

**デフォルトの名無しさん** · 2024/11/09(土) 04:13:52.23

>>679
「言語はどれも正規表現のコンパイル結果を記憶する処理はプログラマの責任」に対しての「そうではない」という実例が挙げられたのであって、良し悪しを論じる文脈ではない。
なにが言いたいのだ？

**デフォルトの名無しさん** · 2024/11/09(土) 05:26:31.68

話の流れが良く分からないけど、つまり正規表現をconst文脈でコンパイルできないRustはクソってこと？

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

単に複オジがクソだってこと

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

いわゆるlet over lambdaがなかった時代には
static over fn
だったという話

**デフォルトの名無しさん** · 2024/11/09(土) 12:56:57.97

コーディング時に確定できる静的な正規表現と
実行時にならないと確定できない動的な正規表現は
用途も違うしプログラム内での扱い方も全然違うよね

前者が他言語なら正規表現リテラルでRustならstaticを使う分野
後者は普通staticは使わない(immutableなのかmutableなのかでまた少し違う)

Javaでstaticというのは前者だろうな
後者でも使えなくはないけど純Java脳の人は違うやり方をするはず

**デフォルトの名無しさん** · 2024/11/09(土) 13:21:26.67

いつになったら、Rustで正規表現をconst文脈でコンパイルできるようになるの？
原理的に見込みない話？

**デフォルトの名無しさん** · 2024/11/09(土) 14:07:10.40

ヒープの話に戻るが、サイズが静的に確定すればヒープを一切使わない保証もできる

**デフォルトの名無しさん** · 2024/11/09(土) 14:59:50.94

>>690
マクロ使えばできるが大変なので誰も作らない
言語に組み込まれるのは良くて20年後やろな

**デフォルトの名無しさん** · 2024/11/09(土) 15:06:22.46

>>690
https://github.com/rust-lang/regex/issues/913
クソ面倒なうえに劇的な効果があるわけでもなさそうだからやらねーとのこと

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

>>693
失望した
別の正規表現クレートが誕生するのを待つしかないのか

**デフォルトの名無しさん** · 2024/11/09(土) 17:12:28.10

>chronoのようなほとんどのプログラムで使われない機能を
こういうことを書くやつに限って>>661みたいなコードを書いちゃうんだよなぁ
そういう時代じゃねぇだろっつーの

**デフォルトの名無しさん** · 2024/11/09(土) 17:13:55.79

願望は笑いものになるが失望はそうでもない
前者は単独犯で後者は不特定多数だからだ

**デフォルトの名無しさん** · 2024/11/09(土) 17:22:40.75

正規表現の単なる説明例じゃないのか
しかも正規表現自体も単なる例でstaticに突っ込む話の説明例だろ
そもそもの話はヒープをプログラムの最後まで解放しなくていい話でstaticはその一例として出てきただけだよな
一番どうでもいい末節の正規表現で騒いでいて違和感

**デフォルトの名無しさん** · 2024/11/09(土) 17:29:31.37

>>693
読んでみたが機能充実(制限)と実行速度とバイナリサイズのどれを優先するかもしくはどの二つまで両立させるかで
どのエンジンやどんな中間表現やどこまで機能制限を行なうかのバリエーションが多すぎるようだ
万人の矛盾した要求を全て満たす万能なものを実現するのは不可能だから別々に叶えるしかないな

**デフォルトの名無しさん** · 2024/11/09(土) 18:03:48.00

>>690
RustのconstってC++のconstexprだよな
どうやってヒープ領域を返すんだ？
C++だとconstexprの計算中はnew/deleteでヒープを一時利用できるけど
deleteせずに返すのはできないよな

**デフォルトの名無しさん** · 2024/11/09(土) 18:14:19.13

正規とか文脈自由とかいうのは仕様のバリエーション
実装のバリエーションなど知ったことではない

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

>>697
例として出したものが
正規表現リテラルの代替策な上に
内部実装の都合上ヒープを確保してるだけで
本来はヒープである必然性もない

機能不足の代替策として
プログラムの最後まで開放しないような
ヒープの使い方もあるだろうという話なのか？

**デフォルトの名無しさん** · 2024/11/09(土) 23:06:21.72

ロックして解放してロック解除しなければいい

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

>>701
基本的な知識を身に着けろよ
正規表現を内部コードにコンパイルして持つ役目がRegex構造体
可変長になるのでVecで持っていて当然ヒープは必須

**デフォルトの名無しさん** · 2024/11/10(日) 00:07:10.13

>>703
それは現状の内部実装上の都合の話
本質的にヒープが必須という話ではない
文字列リテラルにヒープが必須でないのと同じとでも言えばわかるかな？

**デフォルトの名無しさん** · 2024/11/10(日) 02:33:30.98

は～～～～キレそう

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

なんの意味があんねや、このスレ

**デフォルトの名無しさん** · 2024/11/10(日) 02:36:54.54

Rustプログラマにとって有益な情報はこれ以上出ないし、まともなRustプログラマは全員逃げたことが確定して久しいので
次スレあたりから「Rust vs 世界中の全言語 Part27」とか「複製おじさんと遊ぼう Part27」とかにしましょっか
他にもスレタイ案募集

**デフォルトの名無しさん** · 2024/11/10(日) 06:48:35.70

>>704
おまえバカだろ
正規表現パターンは実行時に確定してコンパイルサイズも実行時に確定し上限サイズはわからない
ヒープは必須だ

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

入力がコンパイル時に確定してるならサイズも確定するでしょ
理屈としては以下のようなものは作れると思う

struct CompTimeRegex<const N: usize> {
　data: [u8; N]
}

// 正規表現オブジェクトをコンパイル時に計算
// サイズは入力に応じて変わる
// 入力はリテラルのみ
let r = make_regex!("+\\d");

面倒だし、それでパフォーマンスが劇的に良くなるわけでも無いだろうから必要性は微妙なところ
詳しくないけど、手続きマクロの中なら計算のためにヒープを使うこともできるよね？

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

BurntSushiのベンチ結果見た？

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

それは入力固定で出力の型も別仕様の別の話だな
regex::Regexは実行時に正規表現が作られてもよく
それをコンパイルするためヒープが
使われている

**デフォルトの名無しさん** · 2024/11/10(日) 12:23:01.33

正規表現をコンパイルするのと比べてヌル代入を許容するのは極めて容易で
ヌルを代入すればヒープが解放される

**デフォルトの名無しさん** · 2024/11/10(日) 12:27:06.24

const文脈って、実際今なんか有効な活用されてるの？

**デフォルトの名無しさん** · 2024/11/10(日) 12:30:28.79

ちなみにzigの似た機能は有効活用されまくり

**デフォルトの名無しさん** · 2024/11/10(日) 12:38:27.50

ぐちゃぐちゃできるとかできない言ってるが自分で実装する気のある人間は一人もいねえんだろ？？？
だったら終わりだよ

**デフォルトの名無しさん** · 2024/11/10(日) 13:02:04.64

>>711
だから>>709はCompTimeRegexという従来のRegexではない型を作って話を展開してるわけ
ちゃんと読めてる？

**デフォルトの名無しさん** · 2024/11/10(日) 13:06:11.38

意図的な誤読、ストローマン論法、誰もがわかりきった説明を脈絡無く貼って議論を拡散させる
マジで不毛

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

結局さ
ヒープは全部開放しなさい派閥は>>661のコードでRegex内部のArcが未解放のままプロセス終了するのは、ええんか？？ええんか？？どうなんだオラ？？って話ってことでええんよな

**デフォルトの名無しさん** · 2024/11/10(日) 13:16:48.60

>>716
全く別の話であり、これまでのregex::Regexについての話への言及・反論にはなっていないことを自覚できているならそれでよろしい

**デフォルトの名無しさん** · 2024/11/10(日) 13:18:41.74

>>718
Rustの標準ライブラリstdは
プログラム終了時に自動的にメモリが解放されるようなまともなOS環境を対象にしていて区別しているので大丈夫
OS無しの組み込み環境では#![no_std]を宣言してcoreライブラリのみサポートされる中でのプログラミングを行なう

**デフォルトの名無しさん** · 2024/11/10(日) 14:48:06.15

>>707
みんな何処に逃げた？

**デフォルトの名無しさん** · 2024/11/10(日) 15:04:06.89

>>661
スコープを外れた場合と同じようにモジュールがアンロードされる際にデストラクトされる

**デフォルトの名無しさん** · 2024/11/10(日) 16:19:33.44

>>720
OS側でプロセスを終了させる際にメモリマップを捨てる処理のことを「解放」って呼んでるから君と君以外で話がすれ違うんだと思うよ

**デフォルトの名無しさん** · 2024/11/10(日) 16:24:01.76

あと、ええんかオラ？ってのは俺の直接の質問ではない、それに答えられてもへえそうですか
元の議題は>>661、さらに遡れば>>593であって、議題内容はそれでよいか？という確認をしているだけだ

**デフォルトの名無しさん** · 2024/11/10(日) 16:26:17.63

>>721
非匿名でまともな交流ができるコミュニティかもね
rust-jpのzulipとか、あるいは英語を頑張って公式コミュニティとかに行ったか、発言しなくてもROM専してるかも

**デフォルトの名無しさん** · 2024/11/10(日) 16:30:14.58

5chで聞くよりもChatGPTの方が適切な回答をくれると思う
Rustに限らず他の言語でも

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

ChatGPTもついでにCopilot Chatもゴミだよ
省略されたライフタイムの展開が自分でやったのが合ってるか自信がなくて、試しにやらせてみたらメチャクチャなことばっか言いやがった挙げ句、キレてthe Refrenceのelision rulesのところをペタペタ3回くらいコピペしたらすみません間違っていました、何度も申し訳ございません言いながらやっと正解を返してくれた
決定論的な問題を解かせるのにはまったく向いてない

**デフォルトの名無しさん** · 2024/11/10(日) 16:36:43.08

>>727
最初からキレて始めればいいのでは？

**デフォルトの名無しさん** · 2024/11/10(日) 16:39:08.93

英語が話せる人はこっちに移住しよう！！！できない人もDeepL片手にカモン！！！
https://www.rust-lang.org/community

日本語コミュはこちら！！！ってかいい加減放置されきった翻訳版の責任者のケツ叩きに行こうぜ！！！
https://rust-lang-jp.zulipchat.com/

**デフォルトの名無しさん** · 2024/11/10(日) 16:41:30.83

>>728
キレるはともかく最初からelision rules貼ればよかった説は確かにそう、残念ながら二回目の機会がないが次はそうしてみるぜ
でもよお……こんなのrust-analyzerが完璧なinlay hint実装してくれりゃやらなくて済む話でもあるんだぜ

**デフォルトの名無しさん** · 2024/11/10(日) 16:42:25.60

およ？ ID変わった
ID:OGC8ujy2=ID:tFJCBt9mです

**デフォルトの名無しさん** · 2024/11/10(日) 16:53:56.32

>>722
staticはdrop呼ばれない

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

C++ で static オブジェクトの初期化順 (解体順) は問題を起こしがちだし、いっそそのへんは取り扱わないというのも妥当な判断のひとつではあるわな。

**デフォルトの名無しさん** · 2024/11/10(日) 17:43:15.44

自動化をあきらめることは賛成
だが手動で解放する技術を不要な技術と見なすことには反対する