Constructor taking 64-bit integer missing on (some) Windows C++ compilers
Vincent Lefevre
vincent at vinc17.net
Tue Jun 9 19:52:52 UTC 2020
On 2020-06-09 10:21:31 +0200, Marc Glisse wrote:
> On Tue, 9 Jun 2020, Niels Möller wrote:
>
> > Marc Glisse <marc.glisse at inria.fr> writes:
> >
> > > On Sat, 6 Jun 2020, Mihai Preda wrote:
> > >
> > > > I would rather suggest to support intmax_t and uintmax_t.
> > >
> > > That's one possibility for C (and C++, although it is a bit more
> > > painful there), but not one that everyone agrees with. I think the
> > > majority in standard committees believes that those 2 types were a
> > > mistake,
> >
> > Any reference for such discussions?
>
> No, I didn't take notes, and not all discussions are public. A quick search
> gives one paper presented to the C committee on the topic
> http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2303.pdf
The proposed change is worse. For instance, this would mean that
mp_limb_t could be larger than uintmax_t. This is an issue when
doing computations mixing various integer types from libraries, for
which one does not know their sizes. Or perhaps typeof could be the
solution, together with the ability to select the signedness of an
arbitrary integer type.
--
Vincent Lefèvre <vincent at vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
More information about the gmp-bugs
mailing list