Dan Eble <d...@faithful.be> writes: > On May 5, 2020, at 11:09, David Kastrup <d...@gnu.org> wrote: >> I'd like to come up with an allocator/container programming model >> comparatively similar to the STL one so that one could mostly steal the >> implementations and "just" add the required Scheme awareness while >> removing of destruction/deallocation tracking. > > It might be difficult for me to devote the time to this discussion > that it deserves, but I want to say that I've been working on C++ > wrappers that allow walking SCM lists (of immediate values or Smobs) > with standard iterator syntax and semantics. I suppose that's > tangential to what you are talking about, but it would be > disappointing if we did significant overlapping work.
At the current point of time, I am more concerned with offering container shadows than iterators on existing SCM data structures. The typical SCM list would be somewhat akin to a Forward_list construct. What I have ready-to-use is something that stores like an SCM value but behaves like a Smob pointer with regard to -> and * usage. That would allow to replace a number of Smob members that are now marked with scm_gc_mark (xxx->self_scm ()) with scm_gc_mark (xxx) or scm_gc_mark (xxx.scm ()) which is a first step towards making Smob memory layout be organised where its garbage collection phase can be handled by a struct vtable rather than an explicit hook (this basically shifts the responsibility of whether the whole struct or just individual parts of it participate in the mark phase back to the Guile implementation). But STL containers still require a strategy. -- David Kastrup