Path: csiph.com!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: Sun, 06 Jun 2021 16:33:04 -0700 Organization: None to speak of Lines: 53 Message-ID: <87im2qvaa7.fsf@nosuchdomain.example.com> References:

<3ec77fe7-2c57-4ede-baf3-12b42f52b1afn@googlegroups.com>

<87czszwppd.fsf@nosuchdomain.example.com> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: reader02.eternal-september.org; posting-host="da0ef0006e1a2be3c584df7adb5e6866"; logging-data="24247"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18J3+e1bArSjp8FdWjxrwdt" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux) Cancel-Lock: sha1:pN8OKtqXsdRFjfSbS6+ZB4UW7gU= sha1:1dbIc/yOG4S5bj5AjNR6xpYwsWI= Xref: csiph.com comp.lang.c++:80204 David Brown writes: > On 06/06/2021 07:02, Keith Thompson wrote: >> David Brown writes: >>> On 04/06/2021 02:36, Scott Lurndal wrote: >> [...] >>>> Perhaps, but gcc generally documents all the functions that will >>>> be inlined in their texinfo documentation, and div is not included >>>> in the list of math functions that automatically get builtin status >>>> at least in GCC 4.8. Since they're up to GCC11 now, they may have >>>> added it to the list. >>> >>> It has not (because of the weakly specified "div_t" struct that is >>> determined by the library implementation and not the standards or the >>> compiler). >>> >>> >> >> This could be done if a future C standard specified the representation >> of type div_t (as it does for complex types). > > One of the suggested ways for handling this situation for gcc is, in > fact, to use a complex type as a container for the div_t results. It > would use the gcc extension of complex integer types (Gaussian integers, > I suppose), precisely because it is a suitable pair of numbers whose > structure is known to the compiler. This is just one of these odd > things in compilers that seems simple from the outside, but has subtle > complications in practice. Sure, but the type div_t is still defined in the or header, and gcc has to work with arbitrary library implementations. The C standard's requirements for the representation of complex types: Each complex type has the same representation and alignment requirements as an array type containing exactly two elements of the corresponding real type; the first element is equal to the real part, and the second element to the imaginary part, of the complex number. could easily be reworked to specify the representation of div_t (and ldiv_t, and lldvi_t, and intmaxdiv_t). I strongly suspect that all existing implementations already define the *div_t types consistently, with quot at offset 0 and rem following it. If the layout were specified, gcc could optimize calls to the *div() functions (assuming it knows that the library that will be used is conforming). [...] -- 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 */