== Quote from Dmitry Olshansky ([email protected])'s article > slackCat should probably use the common type, not the first one passed?
Good point. Will fix. > Also it would be cool to have addRange/removeRange somehow automated for > types that have indirections. > Or it's too much state to carry around? Yeah, I don't want this because a major purpose of TempAlloc is to allow efficient parallelism, and addRange/removeRange involves locks. Besides, I think they use linear search in the current GC implementation rather than something more efficient. Once you're doing stuff like this, the advantages of TempAlloc go away rapidly. Besides, it's perfectly safe (at least now, while the GC isn't moving) to store a reference to GC memory in TempAlloc, as long as it's not the **only** reference. It's also perfectly safe to have indirections from TempAlloc data into other TempAlloc data, as long as the LIFO freeing order isn't violated.
