[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Almost, but not quite: C++ STL in LilyPond
From: |
David Kastrup |
Subject: |
Re: Almost, but not quite: C++ STL in LilyPond |
Date: |
Thu, 07 May 2020 10:41:18 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) |
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
- Almost, but not quite: C++ STL in LilyPond, David Kastrup, 2020/05/05
- Re: Almost, but not quite: C++ STL in LilyPond, Jonas Hahnfeld, 2020/05/05
- Re: Almost, but not quite: C++ STL in LilyPond, David Kastrup, 2020/05/05
- Re: Almost, but not quite: C++ STL in LilyPond, Han-Wen Nienhuys, 2020/05/06
- Re: Almost, but not quite: C++ STL in LilyPond, Hans Åberg, 2020/05/06
- Re: Almost, but not quite: C++ STL in LilyPond, David Kastrup, 2020/05/06
- Re: Almost, but not quite: C++ STL in LilyPond, David Kastrup, 2020/05/06
- Re: Almost, but not quite: C++ STL in LilyPond,
David Kastrup <=
- Re: Almost, but not quite: C++ STL in LilyPond, Han-Wen Nienhuys, 2020/05/07
- Re: Almost, but not quite: C++ STL in LilyPond, Jonas Hahnfeld, 2020/05/07
- Re: Almost, but not quite: C++ STL in LilyPond, David Kastrup, 2020/05/07
Re: Almost, but not quite: C++ STL in LilyPond, Hans Åberg, 2020/05/05
Re: Almost, but not quite: C++ STL in LilyPond, Dan Eble, 2020/05/05