[PD] deleting data structures

[david golightly]

...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 at hotmail.com>
>To: fbar at footils.org, pd-list at 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 at footils.org>
>>To: pd-list at 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 at iem.at mailing list
>>UNSUBSCRIBE and account-management -> 
>>http://lists.puredata.info/listinfo/pd-list
>
>
>
>_______________________________________________
>PD-list at iem.at mailing list
>UNSUBSCRIBE and account-management -> 
>http://lists.puredata.info/listinfo/pd-list