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

[David Kastrup]

David Kastrup <address@hidden> writes:

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

I think I actually found a way to implement the original plan of a
temporary internal structure-recording allocator without performance
impact for the continued operation.  So we can can this topic until
there is code.  There might still be a point in preferring approaches
making more use of Guile facilities when working with Guile data types.

-- 
David Kastrup