Path: csiph.com!news.swapon.de!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail From: Keith Thompson Newsgroups: comp.lang.c++ Subject: Re: recovering from std::bad_alloc in std::string reserve Date: Fri, 28 May 2021 12:09:52 -0700 Organization: None to speak of Lines: 57 Message-ID: <87bl8uzncv.fsf@nosuchdomain.example.com> References: <_CUrI.452334$ST2.205157@fx47.iad> <87sg27zu0i.fsf@nosuchdomain.example.com> <87o8cvzsux.fsf@nosuchdomain.example.com> <87k0njzq45.fsf@nosuchdomain.example.com> <664dd958-6042-4d5d-951c-191b0e26421dn@googlegroups.com> <87fsy7zhxd.fsf@nosuchdomain.example.com> <2b396397-2ee8-4900-8969-8e59162f4c20n@googlegroups.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: reader02.eternal-september.org; posting-host="1458d77179aa98232e45e826606b1dc8"; logging-data="3729"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18vPm0fd4QQl9GwlOzW0u4K" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux) Cancel-Lock: sha1:kAWMrcs04ih5ReuOQ6BKOtwSdcQ= sha1:BnTmiK8ZD2zP4fU4zGe9tnykLx4= Xref: csiph.com comp.lang.c++:79919 Öö Tiib writes: > On Friday, 28 May 2021 at 05:55:11 UTC+3, Keith Thompson wrote: >> Öö Tiib writes: >> > On Friday, 28 May 2021 at 02:58:18 UTC+3, Keith Thompson wrote: >> >> In fact C doesn't define a type for representing file sizes. >> >> (It might be nice if it did.) >> > >> > Or may be it might be nice if it did take it back from C++ where >> > std::filesystem::file_size() is of type std::uintmax_t. >> >> Quite right. I post in comp.lang.c more than in comp.lang.c++ and I >> forgot where I was. Apologies for any confusion. > > No problems, all that pandemic and growing pile of communication > channels blinking make me also often confused where I am. > >> > Also standard should end the woo allowing implementations to >> > have integers that are not integers. It is awful. >> Not sure what you're referring to here. > > I meant "In addition to the standard integer types, the C99 standard > allows implementation-defined extended integer types, both signed > and unsigned. For example, a compiler might be provide signed > and unsigned 128-bit integer types." Right. Extended integer types are a nice idea, but I've never seen a compiler that actually implements them. > That is good. But it misses the opportunity to tell that standard forbids > implementations from making their custom integer types that are not > extended integer types. And lack of that turns the above into useless > woo, as it says nothing as result. Not a thing. Waste of space. gcc has __int128 *as an extension* (not supported for 32-bit targets). The standard permits extensions: A conforming implementation may have extensions (including additional library functions), provided they do not alter the behavior of any strictly conforming program. I'm not sure how (or why!) you'd forbid extensions that happen to act almost like integer types. gcc doesn't support 128-bit integer constants. Also, making __int128 an extended integer type would require intmax_t to be 128 bits, which would cause serious problems with ABIs (there are standard library functions that take arguments of type intmax_t). The alternative would have been not to support 128-bit integers at all. I'd like to see full support for 128-bit integers, but gcc's __int128 is IMHO better than nothing (though to be honest I've never used it except in small test programs). -- 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 */