OK, I see that the refcount is not per scalar but per glist (in t_gstub) so if I understand correctly it's not possible to selectively invalidate gpointers only for the deleted scalars.
also I have to correct myself: adding scalars doesn't invalidate pointers. so the remaining problem is adding/deleting non-scalar objects. do you consider this a bug or is this by design? if it's a bug I'll make a PR to fix it. I attached a simple test case to illustrate the problem. Christof > Gesendet: Mittwoch, 28. Februar 2018 um 13:54 Uhr > Von: "Christof Ressi" <christof.re...@gmx.at> > An: pd-list <pd-l...@iem.at> > Cc: "Miller Puckette" <m...@ucsd.edu> > Betreff: Re: [PD] stale pointers after object creation (was Re: pix_data > issue) > > I noticed this issue ca. one year ago when I started working on a complex > project with data structures which involved dynamically adding/deleting > objects to/from a canvas. I even submitted a bug report: > https://sourceforge.net/p/pure-data/bugs/1282/ > > since I've recently started doing a couple a PRs, this is something I want to > investigate too. > > to explain the problem quickly: > > a glist (list of graphical objects) is internally implemented as a linked > list. usually, a big advantage of a linked lists is that adding/deleting > elements won't touch other elements (especially doesn't move them in memory, > like it can happen with dynamically sized arrays). I don't see why > adding/deleting graphical objects should invalidate any gpointers - apart > from those which pointed to the deleted element(s). > > I guess it's meant as a means to keep Pd pointers safe - but what situation > does it try it prevent? > and why are gpointers also invalidated if you add/delete "normal" text > objects which are not scalars (and so no gpointer could possibly point to it)? > > any pointers (no pun intended) to the reasons behind this desigin decision > are highly appreciated :-) > > > > > Gesendet: Mittwoch, 28. Februar 2018 um 12:17 Uhr > > Von: Fede <camaraf...@gmail.com> > > An: pd-list@lists.iem.at > > Betreff: [PD] stale pointers after object creation (was Re: pix_data issue) > > > > Ok, so it is a combination of editing the canvas and pointer memory > > > > i don’t think it has to do with saving. > > also, i don’t think it would relate to the previous pix_data pointer issue > > > > Here’s a patch > > > > > > > > On Feb 28, 2018, at 11:24 AM, IOhannes m zmölnig <zmoel...@iem.at> wrote: > > > > > On 02/28/2018 10:53 AM, Fede Camara Halac wrote: > > >> Would saving (cmd+s) make pix_data forget a pointer, as in [text] or > > >> [array] objects when using pointers? > > > > > > that sounds very fishy to. > > > do you have a patch that exposes the forget-on-save behaviour of [array] > > > or [text]? > > > > > > gfmdasr > > > IOhannes > > > > > > _______________________________________________ > > > Pd-list@lists.iem.at mailing list > > > UNSUBSCRIBE and account-management -> > > > https://lists.puredata.info/listinfo/pd-list > > > > _______________________________________________ > > Pd-list@lists.iem.at mailing list > > UNSUBSCRIBE and account-management -> > > https://lists.puredata.info/listinfo/pd-list > > > > _______________________________________________ > Pd-list@lists.iem.at mailing list > UNSUBSCRIBE and account-management -> > https://lists.puredata.info/listinfo/pd-list >
gpointer-issue.pd
Description: Binary data
_______________________________________________ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
