[Top][All Lists]

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

Re: Guile foreign object interface

From: Ludovic Courtès
Subject: Re: Guile foreign object interface
Date: Wed, 08 Mar 2017 21:59:37 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1 (gnu/linux)

David Kastrup <address@hidden> skribis:

> address@hidden (Ludovic Courtès) writes:
>> Andy Wingo <address@hidden> skribis:
>>> I am not so sure about about this one.  I think it's not accurate to
>>> characterize beginning to replace a 25-year-old C API (SMOBs) as
>>> "churn".
>> I think the point is that there’s lots of code out there that rely on
>> SMOBs and we shouldn’t break it overnight, precisely because that API
>> is this old.
>> Of course, I agree that pushing users towards an improved API is the
>> right thing long term, no argument here.
> Shrug.  LilyPond has all of its SMOB usage condensed into few C++
> classes, so it is comparatively easy to migrate to a different API as
> long as it offers comparable functionality.
> Which it doesn't (namely the ability of marking objects reached through
> STL-managed data structures).  So it's pretty pointless to "push users
> towards an improved API" and hardly "the right thing".

Thanks for your feedback, this is a kind of use case we’d like to

I’m sure we already discussed it and then I forgot, but would anything
prevent the use of specific C++ allocators in this case?  The STL data
structures could be allocated on GC-scanned memory, in which case mark
procedures are unneeded.

If this cannot be done, there’s always the possibility of having a weak
hash table to keep the C++ and Scheme object life cycles in sync.  That
happens even with C APIs that record a pointer to an object we care
about in non-scanned memory.  Since 2.0 was out I’ve never used mark
procedures for in C bindings.


As an aside, please keep the tone friendly as is the norm on this
mailing list.


reply via email to

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