David Kastrup <d...@gnu.org> skribis: > l...@gnu.org (Ludovic Courtès) writes: > >> Andy Wingo <wi...@pobox.com> 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 support. 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. Thoughts? As an aside, please keep the tone friendly as is the norm on this mailing list. Thanks, Ludo’.
