<html><body><div style="color:#000; background-color:#fff; font-family:times new roman, new york, times, serif;font-size:12pt"><div style="font-family: 'times new roman', 'new york', times, serif; font-size: 12pt; "><span><br></span></div><div style="font-family: 'times new roman', 'new york', times, serif; font-size: 12pt; "><span>Thanks for your answer; it covers everything I was curious about.</span></div><div style="font-family: 'times new roman', 'new york', times, serif; font-size: 12pt; "><span><br></span></div><div style="font-family: 'times new roman', 'new york', times, serif; font-size: 12pt; ">Let me elaborate on my use case a bit:</div><div style="font-family: 'times new roman', 'new york', times, serif; font-size: 12pt; "><span><br></span></div><div style="font-family: 'times new roman', 'new york', times, serif; font-size: 12pt; "><span>I'm interfacing to a native library (libSFML), and I admit to not being very good at NCI. So what I did
 was wrap each function call in the simplest way possible. An example of this is sfml::Sprite::GetColor(), which returns a Color&. I chose to duplicate the return value and wrap it in a pointer:</span></div><div><span><div><br></div><div>//My function</div><div>sf::Color* sprite_get_color(const sf::Sprite* item)</div><div>{</div><div>  sf::Color* res = new sf::Color(item->GetColor());</div><div>  return res;</div><div>}</div><div><br></div><div>...and let Pointer PMCs do the rest:</div><div><br></div><div><div>.sub 'SPR_GetColor'</div><div>  .param pmc item</div><div>  .local pmc lib, func</div><div>  lib = INT_GetDLL()   #Does what you think it does</div><div>  func = dlfunc lib, "sprite_get_color", "pp"</div><div>  $P0 = func(item)</div><div>  .return($P0)  #$P0 is now dangling</div><div>.end</div><div><br></div><div>There are several places in my PIR code where I, e.g., get the Color and check
 its blue component, which requires me to call "game_del_color()" (my own library function) to delete the dangling pointer. </div><div><br></div><div>I was thinking of making my own class "Color", and having it delete the library resource when it itself is collected:</div><div><br></div><div>.namespace ['Color']<br></div><div><div><div>.sub 'init' :vtable</div><div>  $P0 = #Get a pointer via SPR_GetColor()</div><div>  setattribute self, 'colorPtr', $P0</div><div>.end</div><div><div>.sub 'destroy' :vtable</div><div>  $P0 = getattribute self, 'colorPtr'<br></div><div>  game_del_color($P0)</div><div>.end</div><div><br></div><div>A bit convoluted, and perhaps there is already a better option? I was reading about "managed" structs (I think?), but there was a lot more glue code required in that article. In my case, library functions are simply loaded by name, and I prefer the
 simplicity. </div><div><br></div><div>In terms of liveliness, I really like the sound of that "<span class="Apple-style-span" style="font-size: 16px; ">timely destruction" that you referenced. It sounds sort of like what C# does, where newly-allocated objects are checked more frequently than long-lived ones. (As a side note, I really don't want to have to delete my objects manually, because the whole reason I'm working in PIR is to get decent automatic memory management.) </span></div><div><span class="Apple-style-span" style="font-size: 16px; "><br></span></div><div><span class="Apple-style-span" style="font-size: 16px; ">To use an example, the following should collect not long after the function ends:</span></div><div><span class="Apple-style-span" style="font-size: 16px; "><br></span></div><div><span class="Apple-style-span"><div>.sub 'do_nothing'</div><div>  .local pmc newColor</div><div>  newColor = new
 ['Color']</div><div>.end</div></span></div></div></div></div><div><br></div><div>Thanks again for your help. I would repeat that, for the most part, Parrot is absolutely lovely to work with, and I really appreciate all the effort that goes into its design.</div><div>-->Seth</div><div><br></div><div><br></div></div><div><br></div><div><br></div></span></div><div style="font-family: 'times new roman', 'new york', times, serif; font-size: 12pt; "><span><br></span></div><div style="font-family: 'times new roman', 'new york', times, serif; font-size: 12pt; "><br></div>  <div style="font-size: 12pt; font-family: 'times new roman', 'new york', times, serif; "> <div style="font-size: 12pt; font-family: 'times new roman', 'new york', times, serif; "> <font size="2" face="Arial"> <hr size="1">  <b><span style="font-weight:bold;">From:</span></b> Andrew Whitworth <wknight8111@gmail.com><br> <b><span style="font-weight: bold;">To:</span></b> S'orlok Reaves
 <sorlok_reaves@yahoo.com> <br><b><span style="font-weight: bold;">Cc:</span></b> "parrot-users@lists.parrot.org" <parrot-users@lists.parrot.org> <br> <b><span style="font-weight: bold;">Sent:</span></b> Thursday, December 29, 2011 9:11 PM<br> <b><span style="font-weight: bold;">Subject:</span></b> Re: [Parrot-users] Use of vtable "destroy"<br> </font> <br>
Great questions. This is the kind of thing we should have more<br>documentation on in the future.<br><br>The destroy vtable is called when the object is collected by the<br>garbage collector. Because it is called during a sensitive point in<br>the interpreter execution (in the GC, as the PMC is being destroyed) I<br>wouldn't try to do too much processing in that vtable, but that's more<br>of a hunch than an actual rule. Honestly, the destroy vtable is not<br>used very often.<br><br>We used to have a notion of "timely destruction", or PMCs which needed<br>to be collected as quickly as possible. That doesn't really work with<br>our newest GC algorithm.  We don't have a way to manually destroy a<br>PMC at the moment, but we could possibly add that in the future if<br>there was a demand for it. The programmer would be responsible to<br>guarantee that the PMC only had one surviving reference and that it<br>was never accessed again after being destroyed,
 of course.<br><br>What is your use-case? What are you trying to accomplish with this? If<br>we know a little bit more about what you need we can help find a good<br>solution for you.<br><br>--Andrew Whitworth<br><br><br><br>On Thu, Dec 29, 2011 at 5:04 AM, S'orlok Reaves <<a ymailto="mailto:sorlok_reaves@yahoo.com" href="mailto:sorlok_reaves@yahoo.com">sorlok_reaves@yahoo.com</a>> wrote:<br>> Good evening,<br>><br>>       I'm having a hard time finding information on this: is "destroy" the<br>> correct method to override if I want something to be performed whenever an<br>> object is deleted? I did some searching through src/pmc/object.c, and<br>> "destroy" was the only method that seemed relevant.<br>><br>>      If not, then what method should I use?<br>><br>>      If so, then I have a follow-up question: What are the guarantees of<br>> object deletion? Will outstanding
 objects be deleted when the VM exits<br>> normally? Is there any way to force an object to be collected/deleted at<br>> some arbitrary point in time (e.g., when a function exits)?<br>><br>>     I checked through the Parrot docs, but couldn't find anything on object<br>> deletion. If I missed an obvious source of information, I apologize.<br>><br>> Thanks,<br>> -->Seth<br>><br>> _______________________________________________<br>> Parrot-users mailing list<br>> <a ymailto="mailto:Parrot-users@lists.parrot.org" href="mailto:Parrot-users@lists.parrot.org">Parrot-users@lists.parrot.org</a><br>> http://lists.parrot.org/mailman/listinfo/parrot-users<br>><br><br><br> </div> </div>  </div></body></html>