On Mon, Feb 7, 2011 at 7:47 AM, Cactus <rieman...@gmail.com> wrote: > > On Feb 7, 3:09 pm, Case Vanhorsen <cas...@gmail.com> wrote: >> On Mon, Feb 7, 2011 at 7:00 AM, Cactus <rieman...@gmail.com> wrote: >> > >> > This would also be a significant task but it would solve this problem >> > once and for all. >> >> It does keep the API from growing. I can see it working with >> statically linked applications (like gmpy) but wouldn't there be DLL >> issues if two dynamically linked applications assumed different >> interfaces? > > Only the application that made the wrong assumption :-) > > 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-devel@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. > > What about following the API in MPFR and adding mpz_set_sj where j is defined to be intmax_t? IIUC, this should allow us to pass any integer type. (And _uj for uintmax_t, etc.)
This may be the most work, but it follows the precedent set in MPFR. casevh -- You received this message because you are subscribed to the Google Groups "mpir-devel" group. To post to this group, send email to mpir-devel@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.
