Go language part 6 (70ﾚｽ)
上下前次1-新
抽出解除 ﾚｽ栞
ﾘﾛｰﾄﾞ規制です｡10分ほどで解除するので､他のﾌﾞﾗｳｻﾞへ避難してください｡
23(1): デフォルトの名無しさん [sage] 2025/06/14(土) 22:38:33.86 ID:GCb7U03w(1/2) AAS
>>20
「スクラッチから作るのならRustにする」なんて言ってないだろ
「Cyclicなんて無くても作れるし、スクラッチならそうするからRustで問題ない」なんてことも言ってない
勝手に脳内変換しちゃいかんよ
29: デフォルトの名無しさん [sage] 2025/06/14(土) 23:21:32.37 ID:/OxuSDvW(8/10) AAS
>>23
ああ確かにRustで駄目な理由を述べてるだけで、Rustにするとは言ってないな
不用意に信者を召喚してしまう発言は申し訳なかった
(が、まあ、そこは本筋ではない)
>>25
そこはそう言ってるが、ASTなんてただの木構造だし、相互に複雑に参照されたところで、寿命は同一だろ
(＝その中のオブジェクトの全てはソースコードの寿命と同じ)
だから全く問題にならない
全部のオブジェクトをルート点の寿命で管理すればいいだけだし、何ならこれはただのグローバルだろ
C++的に参照カウンタで管理した場合は無駄にクソ遅くなるが、これはGCなGoでも同じ
Rust的に代入/参照する際にいちいち寿命管理しろと言われたら、手間が全く無駄なだけだが、グローバルにも出来たはず
まあ最初からグローバルと分かりきってるなら、Cが一番楽ということになるが
ソースコード(当然静的)を解析してASTを作りました、なら、
当たり前だが各オブジェクトはソースコードの寿命以上にはならないので、苦労することはないよ
func somefunc(){
// ソースコード読み込み
// AST木生成
// いろいろ処理
// AST木破棄
}
にしかならんだろ
複雑な循環参照はそりゃあるのだろうが、問題になるのは、
『寿命の異なるオブジェクト間の』複雑な循環参照であってね、26のとおり
上下前次1-新書関写板覧索設栞歴
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ AAｻﾑﾈｲﾙ
ぬこの手 ぬこTOP 0.020s