Re: Rational

[David Kastrup]

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