in reply to How to keep C variables "alive" between invocations with Inline::C

You can set the buffer of a scalar to the C struct, and set SvLEN to zero so Perl doesn't try to free it. Doing almost anything to that scalar will replace the buffer, though, so you might want to have another reference to the C struct somewhere so you can properly free it. But if you're just trying to pass it to your own Perl code, it shouldn't be a problem. See Re: Writing to Pointer Values (PV) in XS.

If you want Perl to free it, allocate the struct using Perl's memory functions and set SvLEN appropriately.

In both cases, no destructor is going to be called. That's why I think you might want to use an object on the Perl side. It doesn't look like you want to provide direct access to the internal details of the struct to the Perl code, so I don't see why you'd want to avoid using an object.

Update: Added second and third paragraphs.

  • Comment on Re: How to keep C variables "alive" between invocations with Inline::C

Replies are listed 'Best First'.
Re^2: How to keep C variables "alive" between invocations with Inline::C
by Limbic~Region (Chancellor) on Sep 27, 2010 at 21:16 UTC
    ikegami,
    If you want Perl to free it, allocate the struct using Perl's memory functions and set SvLEN appropriately.

    I haven't had a chance to read your link yet (still at work) but if it doesn't cover doing that - would you mind providing an example? Ultimately the tree is going to turn into a real tree with branches and leaves so having it all magically get freed if someone does undef $tree would be great.

    It doesn't look like you want to provide direct access to the internal details of the struct to the Perl code, so I don't see why you'd want to avoid using an object.

    I have to beg forgiveness in advance. When I learn new things, I move in a lot of different directions at once. I ignore advice to not do X unless I understand why (usually it means finding out the hard way which I am ok with). My ultimate goal is to be able to write XS naturally. This means improving my mediocre C skills and getting intimately familiar with the perl API. Getting there though, I intend to start by doing some things in Inline::C that are just a little outside my comfort zone and expand from there. Oh, that's the long answer. The short answer is I don't want to have to write code that looks like the cookbook: 

    return ((Soldier*)SvIV(SvRV(obj)))->name;
vs
return soldier.name;

    [download]

    Cheers - L~R

[reply]
[d/l]

      Ultimately the tree is going to turn into a real tree with branches and leaves so having it all magically get freed if someone does undef $tree would be great.

      That will only happen if the whole tree is in that one scalar's memory block since no destructor is called.

      The short answer is I don't want to have to write code that looks like the cookbook:

      You should use the typemap to do that for you. I'm pretty sure Inline::C allows you to specify a typemap.

[reply]
      The short answer is I don't want to have to write code that looks like the cookbook

      If it helps, there's a typemap for the Soldier* type in the InlineX::C2XS Cookbook. (Perhaps it should be added to the Inline::C Cookbook as well.)

      Cheers,
      Rob
[reply]

In Section Seekers of Perl Wisdom