David Kastrup <d...@gnu.org> writes: > Han-Wen Nienhuys <hanw...@gmail.com> writes: > >> On Tue, May 5, 2020 at 5:49 PM Jonas Hahnfeld <hah...@hahnjo.de> wrote: >>> >>> Am Dienstag, den 05.05.2020, 17:09 +0200 schrieb David Kastrup: >>> > I am currently digging back and forth regarding implementation of our >>> > Smobs (Scheme objects) and garbage collection and STL, and I think I am >>> > converging on the realisation that we'll have to end up duplicating >>> > those parts of STL that we are using. >>> >>> Please forgive my ignorance, but I'm missing a bit of context. Are we >>> talking about vector/lists/... of Smobs? Or is the issue that Smobs >>> contain STL containers? >>> >>> In any case I'm not really fond of duplicating code. Given that it >>> seems to "work" right now, IMHO this needs to give some very clear >>> advantage over keeping the status quo. >> >> I'm siding with Jonas here. Unless there is a realliy strong >> overriding concern, we should not be reimplementing STL. > > I was not planning on reimplementing STL. I was planning on only using > those parts of STL as part of Smob that we had a reimplementation for > and otherwise either keeping away or providing a substitute.
Well, I may be able to figure out a way to analyse STL nodes after all without too much of a negative performance impact. If a "Pointer" initialises from a static variable instead of a constant, I can create instances with different initial values and compare their memory images. It remains likely that variants actually taking available Scheme features into account would perform better. But it's possible that a first pitch using a native STL version would work out, even if with regard to best performance it is likely going to be a stopgap measure. An interesting corollary of the overall design might be that we can drop Simple_smob, namely objects without implied Scheme identity. The equivalent of smobbed_copy () could be implemented without affecting the class itself as long as we know its "GC traits". For smobs with self_scm, this isn't possible. And they cannot themselves be placed into STL nodes, merely as an SCM reference, since their having a self_scm requires them to be allocated as one entity. -- David Kastrup