David Kastrup <[email protected]> writes: > David Kastrup <[email protected]> writes: > >> Han-Wen Nienhuys <[email protected]> writes: >> >>> On Tue, May 5, 2020 at 5:49 PM Jonas Hahnfeld <[email protected]> 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.
I think I actually found a way to implement the original plan of a temporary internal structure-recording allocator without performance impact for the continued operation. So we can can this topic until there is code. There might still be a point in preferring approaches making more use of Guile facilities when working with Guile data types. -- David Kastrup
