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. Regarding GC, once we leave behind GUILE 1.x, we could adorn all SCM containing structures with a operator new/operator delete, which calls scm_gc_alloc()/scm_gc_free(). That would get rid of marking functions. For vectors, we could introduce a scm_vector, which is an STL vector with a custom allocator. Or, we could globally map new/delete to GC_malloc and GC_free. We might need finalizers where the smobs refer to outside data structures, like freetype and pango fonts, but I think we could even get away with never deallocating them at all. The GUILE folks may not love finalizers, but is there any evidence that they're really going to get rid of them? Other foreign function integrations willl need them too, because they need them to manage non-memory resources (eg. files). -- Han-Wen Nienhuys - hanw...@gmail.com - http://www.xs4all.nl/~hanwen