in reply to Re^4: RFC: Win32::API API (names)
in thread RFC: Win32::API API

Can't you just inspect the argument passed to you, check if it's a string, a native 64-bit, a native double, or an Math::Int64 object, and process it accordingly?

With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
"Science is about questioning the status quo. Questioning authority".
In the absence of evidence, opinion is indistinguishable from prejudice.

The start of some sanity?

Replies are listed 'Best First'.
Re^6: RFC: Win32::API API (names)
by bulk88 (Priest) on Aug 19, 2012 at 07:01 UTC
    I've decided to do that where possible based on your suggestion. But it can't work if the data direction is from C to Perl (return value of a C function, @_ value coming into a Perl callback from C). If a programmer is very lazy, and very smart, he can avoid turning on Math::Int64 support explicitly and just pass MI64 Objs and get away with it in some careful places.

    The other idea in this thread some people said, I think was to totally remove Quads on 32 bit Perls as 8 byte SV PV string support and if you say Quad on 32 bit Perl, you've said Math::Int64, no exceptions. 8 byte SV PV string support is not portable at all currently. On x64 the 8 byte packed int64 as a scalar string will become garbage to the C function. If you really want 64 bit ints as 8 byte strings, you can type pun it to a "char *" and remember to pad it out at your own risk. Any opinions on removing int 64s as 8 byte strings on 32 bit Perl feature and tell the user to C type pun to char * if they dont want to use Math::Int64?
[reply]
      But it can't work if the data direction is from C to Perl (return value of a C function, @_ value coming into a Perl callback from C).

      I'd just always return quads to perl as strings. As soon as the programmer attempts to use it in a numeric context it'll get converted to whatever makes sense for the platform he is running on, or return an appropriate error message.

      Just note in the pod that is what will happen and suggest that if the user needs ints that will range outside +-2**52 on platforms that does support them natively, then they should consider creating Math::Int64 objects from the strings returned.

      Most of the time, they'll get converted to NVs and just work.

      With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
      Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
      "Science is about questioning the status quo. Questioning authority".
      In the absence of evidence, opinion is indistinguishable from prejudice.

      The start of some sanity?
[reply]

In Section Seekers of Perl Wisdom