----- Original Message -----
From: "Eric Wilhelm" <[EMAIL PROTECTED]>
>
> I think that's your best bet. Why would you put them both in the same
> class if they don't have anything in common?
>
Heh ... in the "real life" situation they have everything in common ....
except that they have different cleanup requirements. I thought I was going
to get to the bottom of this by providing the simplistic examples so far
given - but it seems I was mistaken about that, too. (I often think it would
be useful if I knew what I was doing.) Thanks to one and all for the various
pieces of advice - which (apart from being informative) will also help me to
approach this correctly.
What follows is just fyi or bwoe ("by way of explanation").
I'm dealing with the GMP (big number) library's objects - let's call 'em
"GMP objects". If I bless them into a package (as I'm doing) perl will clean
them up for me whenever they go out of scope, and I can also use operator
overloading. If I don't bless them into a package then it's up to me to
clean them up whenever they go out of scope (which is not always obvious,
and easy to overlook even when it *is* obvious) - and I can't use operator
overloading (someone please let me know if that's not so).
Everything was fine and working nicely - and then I decided it would be
interesting to wrap a GMP function called 'mpz_array_init' - which creates
and returns to perl an array of these GMP objects. (Under certain
circumstances this can be fairly useful.)That pretty much also works fine. I
can use the Inline C functions, and even some, though perhaps not all, of
the overload functions, with these GMP objects created by 'mpz_array_init',
same as with the other GMP objects (and this, acording to the GMP
documentation, is to be expected). But the GMP objects created by
'mpz_array_init' differ in one significant aspect. Whereas the other GMP
objects will grow automatically (realloc) as required (to accommodate larger
numbers - eg when a number is squared), the GMP objects returned by
'mpz_array_init' are of fixed size and incapable of growing. I'm guessing
it's that difference that's instrumental in the "Free to wrong pool..."
error I get whenever one of the GMP objects created by 'mpz_array_init' goes
out of scope and Safefree() gets called on it. (Unlike the "normal" GMP
objects, the GMP objects created by 'mpz_array_init' were not created with
'New()', so it's hardly surprising that Safefree() produces an error.)
I was hoping there would be some simple way for DESTROY() to work out
whether it was being passed a GMP object created with 'mpz_array_init', or a
"normal" GMP object - and I expected there would be, but it now looks as
though that's not the case. Creating a separate class or a sub-class is
starting to look like the right way to go ... or maybe even just not
blessing them into a package at all.
I really wanted to do, for one "type" of GMP object:
sv_AD_HOC_FLAG_FOR_SUNDRY_PURPOSES_ON(obj_ref);
return obj_ref;
and for the other type of GMP object:
sv_AD_HOC_FLAG_FOR_SUNDRY_PURPOSES_OFF(obj_ref);
return obj_ref;
Then, when DESTROY() gets passsed obj_ref, it has something it can use to
determine the appropriate action.
(I toyed with the idea of leaving the READONLY flag unset for one of the
types .... but I don't think that's the correct thing to do, even if it has
a good chance of succeeding.)
Obviously I don't want to go altering/reading the GMP C structs. In fact I
don't really know what they look like - and the GMP documentation warns that
if you do need to know what they look like then your code is probably not
going to work with future releases.
Anyway - it doesn't have to be solved immediately (and I'm still open to
further suggestions). Thanks again to *everyone* for their efforts :-)
Cheers,
Rob
