On Friday 18 June 2010 08:18:03 Cactus wrote:
> 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.
>
I'll do it if you can send the text that you want inserted and where.
Then I suppose we can release 2.1.1 ?
Jason
> > 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.
