Go language part 6 (70ﾚｽ)
上下前次1-新
抽出解除 ﾚｽ栞
25(1): デフォルトの名無しさん [sage] 2025/06/14(土) 22:51:31.08 ID:GCb7U03w(2/2) AAS
>>2020(3): デフォルトの名無しさん [sage] 2025/06/14(土) 21:14:48.29 ID:/OxuSDvW(4/10) AAS
ついでに13:16のwhy not Rust?も見てみたが、
cyclic structureが使えねえから、とか言ってるんだが、これってどうなんだ？
元がTS(JS)だから子が親を参照してるcyclicとかありまくりで、Rustだと苦労する、と言っている事自体には同意するが、
俺はそもそもcyclicが有用なことがない、という認識で、これは俺がC出身で、
「ヒャッハー、GCだぜ！！！
これまで(自分で寿命を管理しないといけない)Cでは出来なかった複雑怪奇な構造も楽勝だぜ！
ついに俺の真なる力が開放される時が来たぜ！」
と思って色々試したものの、俺的には寿命管理はどんなケースでも出来るし、Cでも全く問題ないとの結論になったから
ただNimの連中は同様に「Cでは出来ないような構造もー」とか言ってるので、Nimも確認しないと駄目かとは思ってた
今回ヘルズバーグは「スクラッチから作るのならRustにするが、ポーティングだからね」なので、
彼の見立ては俺に近く、「Cyclicなんて無くても作れるし、スクラッチならそうするからRustで問題ない」なのだろうが、
元々がCyclicを多用してる理由を知りたい、というか、
・Cyclic(や出鱈目参照ありまくり構造)を許可すれば楽勝に組めるが、無しでは手間が増える
なケースなんて有るか？
まあこれが今回tscということなのだが、どういうケースでどういう選択でそうなったのか知りたい
(つってもソースコード読めではあるが、知ってたらよろしく)
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
>>2323(1): デフォルトの名無しさん [sage] 2025/06/14(土) 22:38:33.86 ID:GCb7U03w(1/2) AAS
>>20
「スクラッチから作るのならRustにする」なんて言ってないだろ
「Cyclicなんて無くても作れるし、スクラッチならそうするからRustで問題ない」なんてことも言ってない
勝手に脳内変換しちゃいかんよ
ああ確かにRustで駄目な理由を述べてるだけで、Rustにするとは言ってないな
不用意に信者を召喚してしまう発言は申し訳なかった
(が、まあ、そこは本筋ではない)
>>25
そこはそう言ってるが、ASTなんてただの木構造だし、相互に複雑に参照されたところで、寿命は同一だろ
(＝その中のオブジェクトの全てはソースコードの寿命と同じ)
だから全く問題にならない
全部のオブジェクトをルート点の寿命で管理すればいいだけだし、何ならこれはただのグローバルだろ
C++的に参照カウンタで管理した場合は無駄にクソ遅くなるが、これはGCなGoでも同じ
Rust的に代入/参照する際にいちいち寿命管理しろと言われたら、手間が全く無駄なだけだが、グローバルにも出来たはず
まあ最初からグローバルと分かりきってるなら、Cが一番楽ということになるが
ソースコード(当然静的)を解析してASTを作りました、なら、
当たり前だが各オブジェクトはソースコードの寿命以上にはならないので、苦労することはないよ
func somefunc(){
// ソースコード読み込み
// AST木生成
// いろいろ処理
// AST木破棄
}
にしかならんだろ
複雑な循環参照はそりゃあるのだろうが、問題になるのは、
『寿命の異なるオブジェクト間の』複雑な循環参照であってね、26のとおり
上下前次1-新書関写板覧索設栞歴
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ AAｻﾑﾈｲﾙ
ぬこの手 ぬこTOP 0.551s*