Re^13: Puzzled by value of $overload::ops{binary}

Thanks for the input.
There's some thoughts there that probably gel with a lot of people. They also gel with me to some extent.

The attraction for me of taking/returning SVs in the C function is that I don't always know precisely what is being taken/returned.
For example, with the overload routines, I know that the first arg will always be a Math::GMPz object (and I'll probably now get around to changing that first arg from SV* to mpz_t* in those routines), but the 2nd arg can be any one of an IV, NV, PV, or a number of different objects (Math::GMPz, Math::GMPq, Math::MPFR, etc.).
It's convenient to just call it an SV and then let the overload routine work out exactly what it is, and how to deal with it.

Similarly, not all of those overload routines always return a Math::GMPz object - sometimes some of them may return a Math::GMPq or Math::MPFR object.
Again, it's nice to just specify the return as an SV* and let the typemapping sort out exactly what it is.

Now, admittedly, I could do away with the C functions altogether, and have everything done inside the XS subs, but that's just putting the spaghetti into the meatballs.
There's nothing wrong with that, but I'm quite happy to have the spagehetti and the meatballs kept adjacent to each other. Changing that aspect of the current procedure strikes me as being more trouble than it's worth.
But having said that, I do see an opportunity to remove a lot of simple C functions - which I intend to do.

Having had a very quick look at https://github.com/sisyphus/math-gmpz/blob/master/typemap, is there a reason all those identical "types" aren't just the one?

I don't think their identical. I believe that all occurrences of "$type" and "$var" represent separate, unique values.
It's probably only mpz_t, mpq_t and gmp_randstate_t that need to be specified.
I guess the other ones are there just in case they're ever needed.

Thanks again, etj.

Cheers,
Rob

Comment on Re^13: Puzzled by value of $overload::ops{binary} Select or Download Code

Replies are listed 'Best First'.
Re^14: Puzzled by value of $overload::ops{binary} by etj (Priest) on Jun 30, 2024 at 11:00 UTC
(Re https://github.com/sisyphus/math-gmpz/blob/master/typemap) I don't think their(sic) identical. I believe that all occurrences of "$type" and "$var" represent separate, unique values. Well they do once ExtUtils::ParseXS expands them. There's a reason they're in there as `$variable`s. If you make that typemap read as just this: `mpq_t * GMP_PTR mpz_t * GMP_PTR mpf_t * GMP_PTR mpfr_t * GMP_PTR gmp_randstate_t * GMP_PTR INPUT GMP_PTR $var = INT2PTR($type, SvIVX(SvRV($arg)))` [download] It still works correctly. (Yes, I just tried it) As a matter of fact, the Perl-supplied typemap includes an entry already that does the above, but better because it also checks the SV is a ref first: `mpq_t * T_PTRREF mpz_t * T_PTRREF mpf_t * T_PTRREF mpfr_t * T_PTRREF gmp_randstate_t * T_PTRREF` [download]	[reply] [d/l] [select]
Re^15: Puzzled by value of $overload::ops{binary} by syphilis (Archbishop) on Jun 30, 2024 at 12:00 UTC
As a matter of fact, the Perl-supplied typemap includes an entry already that does the above, but better because it also checks the SV is a ref first Aaah ... yes, I can now see how that works. Thanks !! Cheers, Rob	[reply]