yet it's not what I naively expected.

I have similar reservations about the Object Oriented Inline example in the cookbook:

SV* new(char* class, char* name, char* rank, long serial) {
    Soldier* soldier;
    SV*      obj_ref = newSViv(0);
    SV*      obj = newSVrv(obj_ref, class);
    
    New(42, soldier, 1, Soldier);
    soldier->name = savepv(name);
    soldier->rank = savepv(rank);
    soldier->serial = serial;
        
    sv_setiv(obj, (IV)soldier);
    SvREADONLY_on(obj);
    return obj_ref;
}
[download]

obj_ref is an IV (set to 0), pointed at by obj which is an RV, who's IV is set to the address of the struct and then set read only. But then it is obj_ref that is returned.

• Why is the RV called obj and the thing it points to call obj_ref?
• Why is obj_ref returned when it is an IV that has only ever been set to 0?
• How can we (now, since 5.14?), assign the address of the struct to the IV component of obj (which is constructed as an RV remember) without overwriting the pointer now that they are one and the same piece of memory?

Then again, I find almost nothing about XS intuitive and the documentation is shite. If you ask questions about it you either get no answers or an answer of "Do this", with no explanation of why that works. And that smacks of the passing on of rote learnt knowledge with no true understanding. If there is anyone left who really understands this stuff, they are keeping that knowledge firmly to themselves.

If I could get help in understanding this stuff I might have published a whole lot more of my half-finished, but dead-in-the-water projects.

I have similar reservations about the Object Oriented Inline example in the cookbook

I can't help much with those questions - your line about "rote learnt knowledge with no true understanding" pretty much sums me up (except that I don't have much of the "rote learnt knowledge" :-)

I *do* hope the basic construct being demonstrated in that cookbook example is not doing anything too dastardly, as it's one that I've been using extensively, and for quite a long time (in, eg, all of my Math::* modules). I've found it to be very serviceable and reliable - which hopefully stands it in good stead.

Cheers,
Rob

Looks like if you just swap the two variables names (just in the declaration lines), then it makes sense.

Firing up Acme::ESP, I suspect the author was thinking of the IV as an opaque thing that refers to the real object ("Soldier") and the RV was the Perl (proxy) object. So he called the IV "obj_ref" and the Perl object "obj" but then, when writing the rest of the code, he naturally used "obj_ref" to get the Perl reference and "obj" to get what would result from de-ref-ing "obj_ref".

So, if you have two different things that are "objects" and one refers to the other and one is also a Perl reference, then "obj" and "ref" are way too ambiguous to be enough to get good variable names.

SV* new( char* class, char* name, char* rank, long serial )
{
    Soldier* soldier;
    SV*      addr;
    SV*      perlObj;
    
    New( 42, soldier, 1, Soldier );
    soldier->name = savepv(name);
    soldier->rank = savepv(rank);
    soldier->serial = serial;

    addr = newSViv( (IV)soldier );
    SvREADONLY_on( addr );
    perlObj = newSVrv( addr, class );

    return perlObj;
}
[download]

But I'd avoid most of the "writing Perl code in C" of such an XS example and instead have the XS functions provide a C-like interface and use Perl wrappers to do the Perl stuff. You'll end up with more flexible code with fewer bugs that way, IME.

IV new( char* class, char* name, char* rank, long serial )
{
    Soldier* soldier;

    New( 42, soldier, 1, Soldier );
    soldier->name = savepv(name);
    soldier->rank = savepv(rank);
    soldier->serial = serial;

    return (IV)soldier;
}
[download]

- tye        

Update: This is wrong. should have looked at what newSVrv did.

---

Read more... (583 Bytes)