[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Almost, but not quite: C++ STL in LilyPond
From: |
Hans Åberg |
Subject: |
Re: Almost, but not quite: C++ STL in LilyPond |
Date: |
Tue, 5 May 2020 18:49:21 +0200 |
> On 5 May 2020, at 17:09, David Kastrup <address@hidden> wrote:
>
> One reason is that we want to get rid of finalisers particularly in
> connection with the Boehm GC. Finalisers are called when garbage is
> collected, the collection of garbage is typically indicative of the
> expected lifetime of our objects (there are a few that might be
> unambiguously dead before), and thus it will cause C++ destructors to be
> called. And those trigger, among other things, the deallocation of
> memory resources, but we'd rather want the deallocation to be determined
> by Scheme mechanisms and not have any resources in need of destruction
> other than falling into oblivion.
For the GC objects, I use operator new/delete with an extra argument, the
latter with empty body, wrapped in structure similar to std:shared_ptr. Then
the memory resources of those objects are only handled by the GC, regardless of
finalizers.
> I've tried to come up with a clever callback scheme where the first use
> of a structure causes fake nodes to be created with a "Pointer" type
> that actually calls back with its address to its caller that then
> constructs a layout of SCM elements within its governed class. However,
> I have found no way to make this "parallel construction" where I could
> then swap out this specific "Pointer" behavior for regular SCM.
Similarly, it is necessary to call GC_INIT() on the first use on MacOS, which
can happen before ‘main’ is called. So for that, I let operator new/delete call
a function pointer which on the first call initializes, and also changes the
pointer to the ordinary function pointer on future calls.
- Re: Almost, but not quite: C++ STL in LilyPond, (continued)
- 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, 2020/05/07
- 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 <=
Re: Almost, but not quite: C++ STL in LilyPond, Dan Eble, 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, Dan Eble, 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, David Kastrup, 2020/05/05
- Re: Almost, but not quite: C++ STL in LilyPond, Dan Eble, 2020/05/05
- Re: Almost, but not quite: C++ STL in LilyPond, Carl Sorensen, 2020/05/05
- Re: Almost, but not quite: C++ STL in LilyPond, Dan Eble, 2020/05/05