Go language part 6 (70ﾚｽ)
上下前次1-新
抽出解除 ﾚｽ栞
ﾘﾛｰﾄﾞ規制です｡10分ほどで解除するので､他のﾌﾞﾗｳｻﾞへ避難してください｡
25(1): デフォルトの名無しさん [sage] 2025/06/14(土) 22:51:31.08 ID:GCb7U03w(2/2) AAS
>>20
cyclic data structureの例はwhy not Rust?のところで説明しとるやろがい
AST with both child and parent pointers
symbols -> decorations -> AST -> reference back to symbols
循環参照のメモリ管理を自動でやってくれる言語の場合は
親子の相互参照みたいなのを特殊な状況を除くと何も気にせず作れる
特別な手順を踏む必要がないだけでなくモデルと実装が乖離しない
Cや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.015s