...meaning, ultimately, that deleting a pointer simply shifts the previous reference to the next one. You still ultimately have the "null pointer" to deal with if you delete all the elements in the list. But this way you don't have to see it as much. It's having your pointer cake & eating it too.
Just downloaded 0.39 - the DS tutorial is brilliant - much clearer now, thanks Frank. Highly recommended for anyone scared away from DS in the past.
-David
From: "david golightly" davigoli@hotmail.com To: fbar@footils.org, pd-list@iem.at Subject: Re: [PD] deleting data structures Date: Tue, 04 Oct 2005 15:57:55 -0400
Hm, some good insights Frank. I'm not too familiar with how PD handles its own [pointer] objs internally but perhaps it might be a good approach for devel to remodel after the C/C++ technique I described. As you say, I don't see how deleting by messages would be fundametally different from deleting by mouse click, in terms of internal relations between pointers in a list. Again, in C++ terminology (and I don't have to tell this to any developer!), most instances in a linked list will contain a pointer to the next obj & a pointer to the previous obj. Upon deletion, the object will call a "deconstructor" routine that looks at the prev. obj and makes its "next" pointer point to the current obj's "next", and vice versa, like a circle of people holding hands, and you step out of the circle but join the hands of the two people next to you to keep the circle from breaking.
Therefore, no pointer references become "invalid" because no pointers have moved! If this is how things work in C/C++ (and most other mid-level languages), I don't see why this couldn't be applied to the internal pointer logic in PD as well...I don't think my C chops are up to the task of taking on a re-engineering of the internal [pointer] logic the DS, though again I'll have to take a look at it and see. I could be waaaay off base here, and there are doubtless other technicalities I'm not seeing. Any one in Devel who has any thoughts?
Thanks, David
From: Frank Barknecht fbar@footils.org To: pd-list@iem.at Subject: Re: [PD] deleting data structures Date: Tue, 4 Oct 2005 21:26:21 +0200
Hallo, david golightly hat gesagt: // david golightly wrote:
Well, I ended up abandoning attempts to delete the data structures and
have
just assigned one data structure to each voice in a polyphonic texture,
so
that the DS's get moved around in response to note-events within that
voice
rather than created & deleted. Seems to work fine for now, but nonetheless: it seems to me that creating an effective DS system would involve the use of doubly-linked lists, each atom having (in C++ terminology) a pointer to the next object and to the previous object,
which
are then updated each time anything gets added or deleted to the list, making it less of a list and more a 2-way ring (like the <deque>
template
in C++'s STL), as following successive pointers in any direction gets
you
back where you started. That way, deleting an atom from the list
causes
the list to close up around the gap, and the memory address of the
defunct
atom is returned to the heap and rendered irrelevant while all
remaining
pointer references remain valid.
This sounds like a sensible approach.
To add a third name, that is used in different contexts to mean different things: The problem with deleting a data structure is not only one of memory (de)allocation (that can be solved using C language features), but the fact, that there is a [pointer] Pd type, which can be passed around just like a float or a symbol can. A float can not become invalid, however a [pointer] can:
If you work a bit with DS, you will encounter messages like
error: ptrobj_bang: empty pointer error: ptrobj_next: stale pointer error: set: empty pointer
a lot, if you delete a DS, whose [pointer] is still in use in your patch. This doesn't crash Pd (most of the time) but it will do other strange things. For example in the Midi-Loop-Sequencer I posted (also in my PWD~ ("public working directory") at [1]) the sequencing will stop as soon as you delete a note in your pattern, probably because not only the deleted [pointer] became invalid, but also all other [pointer]s in the same list (i.e. subwindow).
So to allow clean deletion of DS-objects, some care has to be taken with dangling [pointer]s in a Pd patch's logic, too.
However as deletion of DS is possible by hand (and also by Pd's internal messages for mouse movement and editing) adding a "remove"-method to [pointer] would not create a fundamentaly new problem, as far as I can see.
[1] http://royalrabbit.goto10.org/svn/goto10/pd-patches/fbar/pipeseq/
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list