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

[David Kastrup]

Han-Wen Nienhuys <address@hidden> writes:

> 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.

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.

> 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.

Uh, that sounds pretty much like what I was proposing.

> Or, we could globally map new/delete to GC_malloc and GC_free.

That would vastly increase the amount of GC-scanned memory, and GC
scanning is already slow.

> 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 occasional finaliser is going to match what Guile people are using.
At the current point of time, we have finalisers for everything.  You
have added code that messes with the Boehm GC because its assumptions
are not compatible with that.

> 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).

Sure, but we require them for everything right now and that does not
match normal use.  We could reduce this to require them for everything
that does not use STL.  Which brings us back to the original problem.

At any rate, the principal request here was to consider other options
before using previously unused STL structures as part of Smobs because I
see options that might benefit from them.  Whether to use those options
will be dependent on actual code I put out to preview.  I just don't see
the point in making it harder to get to that point when it can easily be
avoided.

-- 
David Kastrup