Re: Almost, but not quite: C++ STL in LilyPond

[Han-Wen Nienhuys]

On Tue, May 5, 2020 at 5:49 PM Jonas Hahnfeld <address@hidden> 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 - address@hidden - http://www.xs4all.nl/~hanwen