Re^10: odd line in windows

[ikegami]

I stand corrected. The code in the recipe is actually correct.

SV* obj_ref = newSViv(0);
SV* obj = newSVrv(obj_ref, class);

newSVrv doesn't create a reference as a I had guessed, it returns a new SV and makes obj_ref a reference to it. WTF? How odd is that!!!

So obj_ref holds a reference to the blessed scalar in obj, which in turn contains an integer which corresponds to the memory address of the C object.

set_iv is not being used on the reference, so there are no issues wrt to recent changes in scalar types.

[BrowserUk]

newSVrv doesn't create a reference as a I had guessed, it returns a new SV and makes obj_ref a reference to it. WTF? How odd is that!!!

Very odd!

There's nothing like consistency:

1. newSViv: Creates a new SV and copies an integer into it
2. newSVnv: Creates a new SV and copies a floating point value into it.
3. newSVpv: Creates a new SV and copies a string into it.
4. newSVrv: Creates a new SV for the RV, rv, to point to.

And that's nothing like consistent! newRVsv() would make more sense (IMO).

[ikegami]

Here's an alternative way of writing the function that might be clearer.

SV* new(const char * classname, const char * name, const char * rank, 
+long serial) {
    Soldier * soldier;
    SV      * obj;
    SV      * obj_ref;

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

    obj = newSViv((IV)soldier);
    obj_ref = newRV_noinc(obj);
    sv_bless(obj_ref, gv_stashpv(classname, GV_ADD));
    SvREADONLY_on(obj);

    return obj_ref;  // Inline will mortalize.
}

[BrowserUk]

Indeed. That is much clearer.

syphilis if you are following along, it would be worth updating the POD with that example