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.