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

[David Kastrup]

David Kastrup <address@hidden> writes:

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

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.

It remains likely that variants actually taking available Scheme
features into account would perform better.  But it's possible that a
first pitch using a native STL version would work out, even if with
regard to best performance it is likely going to be a stopgap measure.

An interesting corollary of the overall design might be that we can drop
Simple_smob, namely objects without implied Scheme identity.  The
equivalent of smobbed_copy () could be implemented without affecting the
class itself as long as we know its "GC traits".

For smobs with self_scm, this isn't possible.  And they cannot
themselves be placed into STL nodes, merely as an SCM reference, since
their having a self_scm requires them to be allocated as one entity.

-- 
David Kastrup