On Jun 18, 7:33 am, degski <deg...@gmail.com> wrote:
Hi Degski,
> As I ran into trouble with the static c++ lib, I concluded that I
> needed a dynamic lib, hence my problem was created.
The fact that the DLL libraries include the C++ functions is
mentioned at one point in the VC++ readme.txt file but I will
add another mention of this in the C++ section.
Changing this in the manual is 'above my pay grade' as this is built
on *nix systems.
> There is one maybe worthwhile warning to mention (using the Intel
> 11.1.060 compiler):
>
> 6>randlc2x.c
> 6>..\..\randlc2x.c(285): warning #147: declaration is incompatible
> with "void __gmp_randinit_lc_2exp(__gmp_randstate_struct *,
> mpz_srcptr, unsigned long, mp_bitcnt_t={unsigned __int64})" (declared
> at line 579 of "..\..\mpir.h")
> 6> gmp_randinit_lc_2exp (gmp_randstate_t rstate,
> 6>
>
> I presume that doesn't effect the functioning (gmp_randstate_t rstate
> versus __gmp_randstate_struct *).
I'll look at this but I suspect it is not a problem.
> Testing the availabilty of the C++ interface through the mpirxxx.h +
> linking to mpir.lib (dynamic), revealed though that something like
> mpz_class x = 9834670453454353; does not work.
>
> 1>MontgomeryMultiplication.cpp
> 1>..\MontgomeryMultiplication.cpp(129): error: more than one operator
> "=" matches these operands:
> 1> function "__gmp_expr<mpz_t, mpz_t>::operator=(signed char)"
> 1> function "__gmp_expr<mpz_t, mpz_t>::operator=(unsigned char)"
> 1> function "__gmp_expr<mpz_t, mpz_t>::operator=(signed int)"
> 1> function "__gmp_expr<mpz_t, mpz_t>::operator=(unsigned int)"
> 1> function "__gmp_expr<mpz_t, mpz_t>::operator=(signed short)"
> 1> function "__gmp_expr<mpz_t, mpz_t>::operator=(unsigned short)"
> 1> function "__gmp_expr<mpz_t, mpz_t>::operator=(signed long)"
> 1> function "__gmp_expr<mpz_t, mpz_t>::operator=(unsigned long)"
> 1> function "__gmp_expr<mpz_t, mpz_t>::operator=(float)"
> 1> function "__gmp_expr<mpz_t, mpz_t>::operator=(double)"
> 1> operand types are: mpz_class = __int64
> 1> b = 9834670453454353;
> 1> ^
>
> I guess it's like that in GMP, I remember writing quite a bit of
> 64-bit input/output functions in the past, like mpz_set_ui64 etc
> etc... The workaround is easy, I understand, but shouldn't the __int64
> type be added to the interface?
The short answer is YES - we have repeatedly discussed how to handle
the Windows specific issue of how to handle 64-bit integers on this
platform. It typically doesn't happen on Linux because ints on 64-bit
Linux systems are 64-bits so the existing functions work here.
But it's a lot of work because there are a lot of get/set ui/si
functions that need to be duplicated for 'long long/unsigned long
long' inputs and outputs.
Are there any volunteers who would be willing to help in doing this?
I'm glad that it is now working for you.
Brian
--
You received this message because you are subscribed to the Google Groups
"mpir-devel" group.
To post to this group, send email to mpir-de...@googlegroups.com.
To unsubscribe from this group, send email to
mpir-devel+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/mpir-devel?hl=en.
