[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Rational

From: David Kastrup
Subject: Re: Rational
Date: Wed, 23 May 2018 18:36:11 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/26.0.50 (gnu/linux)

Hans Åberg <address@hidden> writes:

>> On 23 May 2018, at 18:12, David Kastrup <address@hidden> wrote:
>> Hans Åberg <address@hidden> writes:
>>> I ended up using GC_malloc_uncollectable, because it turned out too
>>> tricky to use malloc.
>> This is C++, so we basically end up with operator ::new and operator
>> ::delete unless overriden by individual classes.  They use
> This what they suggest for the Boehm GC, and it is what caused
> problems in my program.

Likely because of the expectation that it would be managed by the Boehm
GC.  The Guilev2 documentation states:

       For memory that is not associated with a Scheme object, you can
    use ‘scm_malloc’ instead of ‘malloc’.  Like ‘scm_gc_malloc’, it will
    either return a valid pointer or signal an error.  However, it will
    not assume that the new memory block can be freed by a garbage
    collection.  The memory must be explicitly freed with ‘free’.

So memory allocated with the standard allocator in a Guile application
is not managed by the Boehm GC.

>>> And I found no reference to it in LilyPond, so I got curious about
>>> how you do it. But you are not going to tell me, so forget about it.
>> You know, if you actually bothered _asking_, you'd increase your
>> chances of getting an answer.
> Typically when the item is brought up people would say "Yes, we use
> this or that", rather than long bodies of text with no such
> information.

If you want an answer, ask a question.  Just stating something in the
hope that the correction will work as an answer is trying your luck.

David Kastrup

reply via email to

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