GNOME Bugzilla – Bug 699973
Gee should use GClosure
Last modified: 2019-03-20 10:39:17 UTC
Currently, delegates in Gee such as EqualDataFunc are declared like so: public delegate bool EqualDataFunc<T> (T a, T b) As a result, it's not possible to save a reference to them for later calling inside an object without the compiler warning the programmer that 'copying delegates is discouraged', meaning that, in order to use any custom equality tests, comparisons and the like, a project would have to be compiled with deprecation warnings turned off. This is known to affect at least one application (Shotwell).
To remedy this, it may be helpful to mark Gee.EqualDataFunc, Gee.FoldFunc, Gee.FoldMapFunc, Gee.ForallFunc, Gee.ForallMapFunc, Gee.HashDataFunc, Gee.LazyFunc, Gee.MapFunc, Gee.Predicate, Gee.StreamFunc and Gee.UnfoldFunc as unowned in the appropriate VAPI file.
You can save a reference for them, just use (owned). Marking them unowned is not sane because the library has them owned.
Unowned delegates won't work (regardless of being sane) as the data might be freed just after exit of constructor disallowing the use afterwards. Besides some of the mentioned delegates are passed as unowned types (Gee.FoldFunc, Gee.ForallFunc, ...). The bigger problem is the memory leak then warnings and I hoped that bug #659619 would be fixed before it but if this is a problem. The quick'n'dirty solution would be reimplement GClosure in libgee internally - I can implement it over the weekend if needed - but I would prefer to just have GClosure as it would a) be correct solution and b) saved a lot of repetitive code.
(In reply to comment #3) > Unowned delegates won't work (regardless of being sane) as the data might be > freed just after exit of constructor disallowing the use afterwards. Besides > some of the mentioned delegates are passed as unowned types (Gee.FoldFunc, > Gee.ForallFunc, ...). > > The bigger problem is the memory leak then warnings and I hoped that bug > #659619 would be fixed before it but if this is a problem. The quick'n'dirty > solution would be reimplement GClosure in libgee internally - I can implement > it over the weekend if needed - but I would prefer to just have GClosure as it > would a) be correct solution and b) saved a lot of repetitive code. Oh. Sorry - I misunderstood the bug. It cannot be fixed to include external code without either polluting the external API with the GClosure reimplementation (I would _really_ like to avoid it). I'm moving bug to libgee as Vala doesn't ship the libgee bindings and mark bug #659619 as blocking this bug.
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/libgee/issues/15.