Path: csiph.com!news.swapon.de!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: Keith Thompson <Keith.S.Thompson+u@gmail.com>
Newsgroups: comp.lang.c++
Subject: Re: recovering from std::bad_alloc in std::string reserve
Date: Tue, 01 Jun 2021 10:52:56 -0700
Organization: None to speak of
Lines: 35
Message-ID: <87mts9xyiv.fsf@nosuchdomain.example.com>
References: <s8hkt2$liv$1@dont-email.me> <s8m48i$g6f$3@dont-email.me> <s8nbvd$5ah$1@dont-email.me> <s8oqn6$fbj$1@dont-email.me> <_CUrI.452334$ST2.205157@fx47.iad> <87sg27zu0i.fsf@nosuchdomain.example.com> <87o8cvzsux.fsf@nosuchdomain.example.com> <s8p9ak$gun$1@dont-email.me> <87k0njzq45.fsf@nosuchdomain.example.com> <664dd958-6042-4d5d-951c-191b0e26421dn@googlegroups.com> <87fsy7zhxd.fsf@nosuchdomain.example.com> <2b396397-2ee8-4900-8969-8e59162f4c20n@googlegroups.com> <87bl8uzncv.fsf@nosuchdomain.example.com> <s8t2jn$ll2$1@dont-email.me> <ebbd50a2-ddbb-4344-9450-d2b77967621dn@googlegroups.com> <s92001$iei$1@dont-email.me> <87v96yy3yr.fsf@nosuchdomain.example.com> <s94k4t$s93$1@dont-email.me> <ihmm3pF4hgjU1@mid.individual.net> <s95edd$a8p$2@dont-email.me> <s95k0j$ipt$1@dont-email.me>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Injection-Info: reader02.eternal-september.org; posting-host="6d07d9ecbed4ca9b4b4af3cdc4f29c49"; logging-data="13189"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX18bmzlFTx1yUBDHBKHN6s49"
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux)
Cancel-Lock: sha1:sXycSxtdJbw4VXJ+/w6v1gJXyNY= sha1:wDjXCgIgexj5ba/SVGaUHk20e/g=
Xref: csiph.com comp.lang.c++:80052

James Kuyper <jameskuyper@alumni.caltech.edu> writes:
> On 6/1/21 9:58 AM, David Brown wrote:
>> On 01/06/2021 14:05, Bo Persson wrote:
>>> On 2021-06-01 at 08:29, David Brown wrote:
> ...
>>>> Maybe it would be worth reconsidering exactly what the definition of
>>>> "integer type" should be in the C and C++ standards (keeping both
>>>> languages in sync here is, I think, important).  I'd like to see
>>>> intmax_t removed and the definition of "integer type" modified such that
>>>> gcc's __int128 /is/ an extended integer type.  After all, people use it
>>>> as though it were, and assume it is.
>>>>
>>>
>>> And it really *is*, except for the documentation saying "integer type
>>> extension" (and not "extended integer type"), only to avoid the intmax_t
>>> problem.
>> 
>> There is also no way to make constant literals of __int128, nor is there
>> support for printf and a wide variety of the builtin functions, and
>> standard library functions, and other bits and pieces.  It's fine for
>> basic usage, but missing many features of int64_t and other sized
>> integer types.  (I'm not complaining, just noting.)
>
> If they changed their documentation to identify __int128_t as an
> extended integer type, then they would be required to support int128_t,
> along with all of the corresponding features of <cinttypes> and
> <cstdint>, which would address that issue.

*And* they'd have to make intmax_t 128 bits, which would cause more
problems.

-- 
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips Healthcare
void Void(void) { Void(); } /* The recursive call of the void */