On Mon, Jan 19, 2004 at 09:15:54AM +0000 Nick Ing-Simmons wrote:
> Tels <[EMAIL PROTECTED]> writes:
> >
> >Now, instead of malloc() a struct like:
> >
> > struct BigInt {
> > int flags;
> > int sign;
> > double P;
> > double A;
> > SV* CALC;
> > };
> >
> >and then putting a ptr to it into the PV slot, I thought I could:
>
> As I have said (at least twice recently) you can naturally do one of two things:
>
> 1. Get perl to Newz() you a struct in the PV
> e.g.
> SV *thing = newSV(sizeof(struct BigInt));
> struct BigInt *p = (struct BigInt *) SvPVX(sv);
>
> I usually add:
> SvPOK_only(sv);
> SvREADONLY_on(sv);
>
> OR
>
> 2. malloc() struct and put it in the IV
> e.g.
> struct BigInt *p = (struct BigInt *) malloc(sizeof(struct BitInt));
> SV *thing = newSViv(PTR2IV(p));
But I think the above two are the things that Tels explicitly wanted to
avoid. At first I thought this was due to size-considerations. However,
storing a pointer to the BigInt structure in the IV slot will not need
more memory than putting the ints into the IV and the doubles into the
NV slot.
But when using all three slots in a clever way it has the advantage that
at least the IV slot can be accessed from a Perl script, namely in
numeric context.
> DO NOT malloc() and put in PV slot.
Hmmh, why not? For me, PV has never really been for strings only. It's a
pointer value so storing pointers in it seems natural to me.
Tassilo
--
$_=q#",}])!JAPH!qq(tsuJ[{@"tnirp}3..0}_$;//::niam/s~=)]3[))_$-3(rellac(=_$({
pam{rekcahbus})(rekcah{lrePbus})(lreP{rehtonabus})!JAPH!qq(rehtona{tsuJbus#;
$_=reverse,s+(?<=sub).+q#q!'"qq.\t$&."'!#+sexisexiixesixeseg;y~\n~~dddd;eval
