Yes, and also dual interpretations it didn't handle (two pointers to the same thing that claimed to be different types). Both of these would be pretty easy to handle if you were trying to make a system that was meant to be a "standard" system people could use as a library.
-
-
Replying to @cmuratori @Jonathan_Blow and
IIRC the first problem hurts execution time a fair bit because you're not just doing pointer equality comparisons, you're doing range comparisons. And speed was (is!) important. I guess we could have had two different serialisation paths.
1 reply 0 retweets 1 like -
Replying to @tom_forsyth @Jonathan_Blow and
But it also requires two traversals, which is even worse. So not supporting, or optionally supporting it, probably does make sense since it is almost never done.
1 reply 0 retweets 2 likes -
Replying to @cmuratori @Jonathan_Blow and
In ten years of using it in apps, I've only ever vaguely wanted this support twice. Once I worked around it with a pointer-to-start+plus index (it was an array), rather than direct pointer. The other time was actually a terrible idea once I thought harder about the problem.
1 reply 0 retweets 2 likes -
Replying to @tom_forsyth @Jonathan_Blow and
Yeah, I don't consider an actual problem with Granny's system, it's just interesting to think about how much speed you sacrifice if you want to support it...
1 reply 0 retweets 2 likes -
Replying to @cmuratori @Jonathan_Blow and
You could also annotate the pointers as whether or not they are this special type or not, so only do the expensive test for them. But it's still two passes for the whole thing even if there's only one pointer like that.
1 reply 0 retweets 1 like -
Replying to @tom_forsyth @cmuratori and
Oh - you could do a pre-pass of the TYPE system and "poison" that whole branch of TYPES. Then you make sure that branch gets done last. There will be cases (e.g. circular references) that can't be solved like this though. Then you still need two passes.
1 reply 0 retweets 1 like -
Replying to @tom_forsyth @cmuratori and
Never seen serialization work well when references were to isolated objects: a good reference refers to an array, and to an index in that array. e.g. "texture library FOO, entry #12" This at least keeps the door open to batch processing, which you eventually need anyway.
2 replies 0 retweets 8 likes -
Replying to @bmcnett @tom_forsyth and
Everything about how a language like C# is designed and their paradigms teaches people not to do stuff like that though, because C# is just like "we can just solve this with reflection", and then you get overwrought stuff like BinaryFormatter and gaping security holes
3 replies 0 retweets 1 like -
Like I'm not saying you're wrong but I can almost guarantee that most C# using gamedevs have never once in their lives considered indirect referencing like that, especially given C# constantly tells you "it's coo', you don't gotta worry about it"
1 reply 0 retweets 0 likes
It does seem like there's a lot of "we handle everything for you!" and then when you go, "so you can save to disk right?", it goes, "well... er... we didn't mean _everything_ everything..." :/
-
-
Replying to @cmuratori @Enichan and
It does seem odd that serialisation isn't "just" a side-effect of the GC.
1 reply 0 retweets 2 likes -
Replying to @tom_forsyth @cmuratori and
(the GC seems like an insanely difficult problem to me, but given that people have apparently solved it...)
2 replies 0 retweets 3 likes - Show replies
New conversation -
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.