lilypond-devel
[Top][All Lists]
Advanced

[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: Wed, 6 May 2020 11:08:28 +0200

> On 6 May 2020, at 08:21, Han-Wen Nienhuys <address@hidden> wrote:
> 
> Regarding GC, once we leave behind GUILE 1.x, we could adorn all SCM
> containing structures with a operator new/operator delete, which calls
> scm_gc_alloc()/scm_gc_free(). That would get rid of marking functions.
> For vectors, we could introduce a scm_vector, which is an STL vector
> with a custom allocator. Or, we could globally map new/delete to
> GC_malloc and GC_free.

One can define the standard operator new/delete to call 
GC_malloc_uncollectable/GC_free, and the C++ standard guarantees that all 
allocations will use them (the linker will replace all occurrences).

Then for objects of indeterminate lifetime, I have user defined operator 
new/delete for GC_malloc, and no GC_free, with which I use a reference class 
similar to std::shared_ptr, but calling these operators instead.

> We might need finalizers where the smobs refer to outside data
> structures, like freetype and pango fonts, but I think we could even
> get away with never deallocating them at all.

As for the Boehm GC finalizers, I could not find that they take up significant 
time, but I had to rewrite the C++ code they suggest.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]