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

[David Kastrup]

Hans Åberg <address@hidden> writes:

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

That does not sound like it has anything to do with SCM garbage
collection.  Nor is it phrased in a manner where I would understand what
you are talking about.  It is not clear what a "GC object" is supposed
to be, it is not clear what "I use" is supposed to mean with regard to
where and how it is being used, "operator new/delete with an extra
argument, the latter with empty body" presumably means that operator
delete rather than the extra argument have an empty body.  It is not
clear what it is supposed to buy us if operator delete has an empty body
when calling operator delete is something triggered by the destructor
and not having to call the destructor is a prerequisite for the life
time being determined by garbage collection without finalisation hook.

It is not clear _what_ is "wrapped in structure similar to
std:shared_ptr" and how that is supposed to interact with Scheme.

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

The ordinary function pointer.  I see.

-- 
David Kastrup