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

[David Kastrup]

Jonas Hahnfeld <address@hidden> writes:

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

Vectors/lists of Smobs are inherently not protected from garbage
protection even when in "auto" stack space or other GC-scanned space
(Guile-2 has different options there).  That's a problem.  One important
GC-scanned space that we'd ultimately want to automate scanning of are
Smobs.  STL containers cannot be automatically scanned even when they
are formally located in scanned memory.

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

GC performance remains a major troublesome point.

I want to get the point to where we don't need mark hooks, and where we
don't need finalisation hooks.  Either are causing performance problems,
and with Guile2, they also have a history of causing stability problems
as well as "nobody wants to do that, so we are not really interested in
your problems" reactions from Guile developers.

What I was writing about is to reduce the amount of code duplication by
not considering use of STL as free for the taking (which might cause
more and more need for reimplementation of stuff).  I do not see that at
the current point of time regarding both code bases and standards
(reflection is not in current C++ standards though it may appear at some
point of time) we have a reasonable chance to make STL free for the
taking.  The underlying dynamic allocation and destruction model is not
really a perfect match to what Scheme does and expects, and what the
garbage collectors we are dealing with are good at.

But I am not arguing API duplication: there is a point in making the
semantics of SCM-aware reimplementations follow STL Container semantics.
That will allow us at one point in the future when the SCM memory model
is a better match to STL allocators, to go back to STL.

But the different lifetime models will always mean that we are pressing
our luck when using STL under the assumption that running destructors is
optional.

I might still try coming up with some reflection engine that would work
with STL without significant performance impact and some reliability,
but I would not expect it to come cost free.

-- 
David Kastrup