Path: csiph.com!eternal-september.org!feeder.eternal-september.org!reader01.eternal-september.org!.POSTED!not-for-mail From: Keith Thompson Newsgroups: comp.lang.c++ Subject: Re: Don't be fooled by cpp.sh Date: Mon, 16 Dec 2019 22:23:03 -0800 Organization: None to speak of Lines: 28 Message-ID: <87woavv5bs.fsf@nosuchdomain.example.com> References: <356f42b0-2919-4e72-a1a2-3813212973f1@googlegroups.com> <7f5255fa-f634-4dc7-9f33-409acc47356c@googlegroups.com> <2a6b4b2d-283f-4b5f-9f4c-025efaa087a8@googlegroups.com> <875zigw1iq.fsf@nosuchdomain.example.com> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: reader02.eternal-september.org; posting-host="f43f53019f1947236be6bf564cb59bdd"; logging-data="9188"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18+WXSd3enH+ZZ9ZWqEJTbR" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux) Cancel-Lock: sha1:NiMX8rZ0IS91lYTNZEwhH8ygg/U= sha1:bt6C/gQ1f+XYXqOx6FHm0xS49Yw= Xref: csiph.com comp.lang.c++:70533 David Brown writes: [...] > I'd like to see some standard way (with standard names) to have > 128-bit integer types without increasing intmax_t. I don't think > there would be a need to make them mandatory - compilers would support > them where they are practical and useful. I'd greatly prefer to see the *existing* standard way to have 128-bit integer types *along with* a redefinition of intmax_t as appropriate. Because **that's what intmax_t means**. I know that ABIs and existing libraries make that difficult, but understanding the reasons does not lessen my annoyance. On the other hand, 64 bits really are enough to count just about anything. For example, we're not going to see files bigger than 2**64 bytes any time soon. Some standardized way of handling huge integer-like entities without calling them "integer types" would probably give us most of the benefits of 128-bit integer types, and C++ has enough features that it's feasible to do that in the library rather than in the language. -- Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com [Note updated email address] Working, but not speaking, for Philips Healthcare void Void(void) { Void(); } /* The recursive call of the void */