Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c++ > #79727 > unrolled thread
| Started by | Lynn McGuire <lynnmcguire5@gmail.com> |
|---|---|
| First post | 2021-05-24 20:46 -0500 |
| Last post | 2021-06-01 17:35 -0700 |
| Articles | 20 on this page of 112 — 21 participants |
Back to article view | Back to comp.lang.c++
recovering from std::bad_alloc in std::string reserve Lynn McGuire <lynnmcguire5@gmail.com> - 2021-05-24 20:46 -0500
Re: recovering from std::bad_alloc in std::string reserve Lynn McGuire <lynnmcguire5@gmail.com> - 2021-05-24 20:50 -0500
Re: recovering from std::bad_alloc in std::string reserve Lynn McGuire <lynnmcguire5@gmail.com> - 2021-05-24 20:52 -0500
Re: recovering from std::bad_alloc in std::string reserve Paavo Helde <myfirstname@osa.pri.ee> - 2021-05-25 07:47 +0300
Re: recovering from std::bad_alloc in std::string reserve Lynn McGuire <lynnmcguire5@gmail.com> - 2021-05-25 12:20 -0500
Re: recovering from std::bad_alloc in std::string reserve Christian Gollwitzer <auriocus@gmx.de> - 2021-05-26 08:36 +0200
Re: recovering from std::bad_alloc in std::string reserve Lynn McGuire <lynnmcguire5@gmail.com> - 2021-05-26 13:28 -0500
Re: recovering from std::bad_alloc in std::string reserve Bonita Montero <Bonita.Montero@gmail.com> - 2021-05-25 12:56 +0200
Re: recovering from std::bad_alloc in std::string reserve scott@slp53.sl.home (Scott Lurndal) - 2021-05-25 14:55 +0000
Re: recovering from std::bad_alloc in std::string reserve Paavo Helde <myfirstname@osa.pri.ee> - 2021-05-25 18:42 +0300
Re: recovering from std::bad_alloc in std::string reserve MrSpook_Ann1u@d0v_5eh1bqgd.com - 2021-05-25 16:10 +0000
Re: recovering from std::bad_alloc in std::string reserve Bonita Montero <Bonita.Montero@gmail.com> - 2021-05-25 18:23 +0200
Re: recovering from std::bad_alloc in std::string reserve Paavo Helde <myfirstname@osa.pri.ee> - 2021-05-25 19:57 +0300
Re: recovering from std::bad_alloc in std::string reserve MrSpook_ddZgr4t4@okc9_pd48oig5.info - 2021-05-26 07:15 +0000
Re: recovering from std::bad_alloc in std::string reserve Bonita Montero <Bonita.Montero@gmail.com> - 2021-05-26 09:22 +0200
Re: recovering from std::bad_alloc in std::string reserve Paavo Helde <myfirstname@osa.pri.ee> - 2021-05-26 10:54 +0300
Re: recovering from std::bad_alloc in std::string reserve MrSpook_dw5lvA4g@kak0_42x.edu - 2021-05-26 08:29 +0000
Re: recovering from std::bad_alloc in std::string reserve Nikolaj Lazic <nlazicBEZ_OVOGA@mudrac.ffzg.hr> - 2021-05-25 16:21 +0000
Re: recovering from std::bad_alloc in std::string reserve Paavo Helde <myfirstname@osa.pri.ee> - 2021-05-25 20:04 +0300
Re: recovering from std::bad_alloc in std::string reserve Lynn McGuire <lynnmcguire5@gmail.com> - 2021-05-25 12:46 -0500
Re: recovering from std::bad_alloc in std::string reserve Paavo Helde <myfirstname@osa.pri.ee> - 2021-05-25 20:58 +0300
Re: recovering from std::bad_alloc in std::string reserve Lynn McGuire <lynnmcguire5@gmail.com> - 2021-05-25 13:48 -0500
Re: recovering from std::bad_alloc in std::string reserve Nikolaj Lazic <nlazicBEZ_OVOGA@mudrac.ffzg.hr> - 2021-05-25 18:23 +0000
Re: recovering from std::bad_alloc in std::string reserve Lynn McGuire <lynnmcguire5@gmail.com> - 2021-05-25 13:49 -0500
Re: recovering from std::bad_alloc in std::string reserve Lynn McGuire <lynnmcguire5@gmail.com> - 2021-05-26 21:07 -0500
Re: recovering from std::bad_alloc in std::string reserve Bonita Montero <Bonita.Montero@gmail.com> - 2021-05-25 18:23 +0200
Re: recovering from std::bad_alloc in std::string reserve Lynn McGuire <lynnmcguire5@gmail.com> - 2021-05-24 22:33 -0500
Re: recovering from std::bad_alloc in std::string reserve Lynn McGuire <lynnmcguire5@gmail.com> - 2021-05-24 22:35 -0500
Re: recovering from std::bad_alloc in std::string reserve Juha Nieminen <nospam@thanks.invalid> - 2021-05-25 05:16 +0000
Re: recovering from std::bad_alloc in std::string reserve Bonita Montero <Bonita.Montero@gmail.com> - 2021-05-25 13:00 +0200
Re: recovering from std::bad_alloc in std::string reserve Lynn McGuire <lynnmcguire5@gmail.com> - 2021-05-25 12:49 -0500
Re: recovering from std::bad_alloc in std::string reserve Lynn McGuire <lynnmcguire5@gmail.com> - 2021-05-27 14:08 -0500
Re: recovering from std::bad_alloc in std::string reserve scott@slp53.sl.home (Scott Lurndal) - 2021-05-27 21:59 +0000
Re: recovering from std::bad_alloc in std::string reserve Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-05-27 15:33 -0700
Re: recovering from std::bad_alloc in std::string reserve Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-05-27 15:58 -0700
Re: recovering from std::bad_alloc in std::string reserve Lynn McGuire <lynnmcguire5@gmail.com> - 2021-05-27 18:17 -0500
Re: recovering from std::bad_alloc in std::string reserve Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-05-27 16:58 -0700
Re: recovering from std::bad_alloc in std::string reserve Öö Tiib <ootiib@hot.ee> - 2021-05-27 18:36 -0700
Re: recovering from std::bad_alloc in std::string reserve Lynn McGuire <lynnmcguire5@gmail.com> - 2021-05-27 21:38 -0500
Re: recovering from std::bad_alloc in std::string reserve Paavo Helde <myfirstname@osa.pri.ee> - 2021-05-28 08:53 +0300
Re: recovering from std::bad_alloc in std::string reserve Bo Persson <bo@bo-persson.se> - 2021-05-28 09:47 +0200
Re: recovering from std::bad_alloc in std::string reserve Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-05-27 19:54 -0700
Re: recovering from std::bad_alloc in std::string reserve Öö Tiib <ootiib@hot.ee> - 2021-05-27 21:02 -0700
Re: recovering from std::bad_alloc in std::string reserve Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-05-28 12:09 -0700
Re: recovering from std::bad_alloc in std::string reserve scott@slp53.sl.home (Scott Lurndal) - 2021-05-28 20:26 +0000
Re: recovering from std::bad_alloc in std::string reserve Öö Tiib <ootiib@hot.ee> - 2021-05-28 17:10 -0700
Re: recovering from std::bad_alloc in std::string reserve David Brown <david.brown@hesbynett.no> - 2021-05-29 11:47 +0200
Re: recovering from std::bad_alloc in std::string reserve "daniel...@gmail.com" <danielaparker@gmail.com> - 2021-05-30 15:15 -0700
Re: recovering from std::bad_alloc in std::string reserve David Brown <david.brown@hesbynett.no> - 2021-05-31 08:33 +0200
Re: recovering from std::bad_alloc in std::string reserve "daniel...@gmail.com" <danielaparker@gmail.com> - 2021-05-31 08:21 -0700
Re: recovering from std::bad_alloc in std::string reserve David Brown <david.brown@hesbynett.no> - 2021-05-31 18:13 +0200
Re: recovering from std::bad_alloc in std::string reserve Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-05-31 14:43 -0700
Re: recovering from std::bad_alloc in std::string reserve Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-05-31 14:44 -0700
Re: recovering from std::bad_alloc in std::string reserve "daniel...@gmail.com" <danielaparker@gmail.com> - 2021-05-31 15:20 -0700
Re: recovering from std::bad_alloc in std::string reserve Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-06-01 11:17 -0700
Re: recovering from std::bad_alloc in std::string reserve Manfred <noname@add.invalid> - 2021-06-01 20:25 +0200
Re: recovering from std::bad_alloc in std::string reserve Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-06-01 16:55 -0700
Re: recovering from std::bad_alloc in std::string reserve David Brown <david.brown@hesbynett.no> - 2021-06-02 09:06 +0200
Re: recovering from std::bad_alloc in std::string reserve Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-06-05 17:50 -0700
Re: recovering from std::bad_alloc in std::string reserve David Brown <david.brown@hesbynett.no> - 2021-06-06 11:10 +0200
Re: recovering from std::bad_alloc in std::string reserve Öö Tiib <ootiib@hot.ee> - 2021-06-06 04:07 -0700
Re: recovering from std::bad_alloc in std::string reserve Richard Damon <Richard@Damon-Family.org> - 2021-06-06 07:49 -0400
Re: recovering from std::bad_alloc in std::string reserve Manfred <noname@add.invalid> - 2021-06-01 20:21 +0200
Re: recovering from std::bad_alloc in std::string reserve David Brown <david.brown@hesbynett.no> - 2021-06-02 09:29 +0200
Re: recovering from std::bad_alloc in std::string reserve Manfred <noname@add.invalid> - 2021-06-02 18:43 +0200
Re: recovering from std::bad_alloc in std::string reserve David Brown <david.brown@hesbynett.no> - 2021-06-02 23:32 +0200
Re: recovering from std::bad_alloc in std::string reserve Manfred <noname@add.invalid> - 2021-06-03 00:49 +0200
Re: recovering from std::bad_alloc in std::string reserve David Brown <david.brown@hesbynett.no> - 2021-06-03 09:08 +0200
Re: recovering from std::bad_alloc in std::string reserve David Brown <david.brown@hesbynett.no> - 2021-06-03 10:53 +0200
Re: recovering from std::bad_alloc in std::string reserve Manfred <noname@add.invalid> - 2021-06-03 16:20 +0200
Re: recovering from std::bad_alloc in std::string reserve James Kuyper <jameskuyper@alumni.caltech.edu> - 2021-06-03 11:20 -0400
Re: recovering from std::bad_alloc in std::string reserve David Brown <david.brown@hesbynett.no> - 2021-06-03 19:04 +0200
Re: recovering from std::bad_alloc in std::string reserve scott@slp53.sl.home (Scott Lurndal) - 2021-06-03 22:24 +0000
Re: recovering from std::bad_alloc in std::string reserve Öö Tiib <ootiib@hot.ee> - 2021-06-03 16:27 -0700
Re: recovering from std::bad_alloc in std::string reserve scott@slp53.sl.home (Scott Lurndal) - 2021-06-04 00:36 +0000
Re: recovering from std::bad_alloc in std::string reserve David Brown <david.brown@hesbynett.no> - 2021-06-04 08:46 +0200
Re: recovering from std::bad_alloc in std::string reserve Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-06-05 22:02 -0700
Re: recovering from std::bad_alloc in std::string reserve David Brown <david.brown@hesbynett.no> - 2021-06-06 11:17 +0200
Re: recovering from std::bad_alloc in std::string reserve Manfred <noname@add.invalid> - 2021-06-06 18:39 +0200
Re: recovering from std::bad_alloc in std::string reserve Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-06-06 16:33 -0700
Re: recovering from std::bad_alloc in std::string reserve David Brown <david.brown@hesbynett.no> - 2021-06-07 08:41 +0200
Re: recovering from std::bad_alloc in std::string reserve David Brown <david.brown@hesbynett.no> - 2021-06-06 17:46 +0200
Re: recovering from std::bad_alloc in std::string reserve MrSpook_Qfmtjdmi@nc6.com - 2021-06-06 14:11 +0000
Re: recovering from std::bad_alloc in std::string reserve Manfred <noname@add.invalid> - 2021-06-03 16:43 +0200
Re: recovering from std::bad_alloc in std::string reserve Manfred <noname@add.invalid> - 2021-06-01 18:00 +0200
Re: recovering from std::bad_alloc in std::string reserve David Brown <david.brown@hesbynett.no> - 2021-06-01 19:15 +0200
Re: recovering from std::bad_alloc in std::string reserve David Brown <david.brown@hesbynett.no> - 2021-06-01 15:55 +0200
Re: recovering from std::bad_alloc in std::string reserve Bo Persson <bo@bo-persson.se> - 2021-06-01 13:59 +0200
Re: recovering from std::bad_alloc in std::string reserve Lynn McGuire <lynnmcguire5@gmail.com> - 2021-06-01 13:26 -0500
Re: recovering from std::bad_alloc in std::string reserve David Brown <david.brown@hesbynett.no> - 2021-06-01 08:29 +0200
Re: recovering from std::bad_alloc in std::string reserve Bo Persson <bo@bo-persson.se> - 2021-06-01 14:05 +0200
Re: recovering from std::bad_alloc in std::string reserve David Brown <david.brown@hesbynett.no> - 2021-06-01 15:58 +0200
Re: recovering from std::bad_alloc in std::string reserve James Kuyper <jameskuyper@alumni.caltech.edu> - 2021-06-01 11:33 -0400
Re: recovering from std::bad_alloc in std::string reserve Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-06-01 10:52 -0700
Re: recovering from std::bad_alloc in std::string reserve James Kuyper <jameskuyper@alumni.caltech.edu> - 2021-05-27 23:16 -0400
Re: recovering from std::bad_alloc in std::string reserve scott@slp53.sl.home (Scott Lurndal) - 2021-05-28 14:34 +0000
Re: recovering from std::bad_alloc in std::string reserve Lynn McGuire <lynnmcguire5@gmail.com> - 2021-05-27 18:19 -0500
Re: recovering from std::bad_alloc in std::string reserve Bonita Montero <Bonita.Montero@gmail.com> - 2021-05-28 03:47 +0200
Re: recovering from std::bad_alloc in std::string reserve Lynn McGuire <lynnmcguire5@gmail.com> - 2021-05-27 17:45 -0500
Re: recovering from std::bad_alloc in std::string reserve scott@slp53.sl.home (Scott Lurndal) - 2021-05-28 14:38 +0000
Re: recovering from std::bad_alloc in std::string reserve Bonita Montero <Bonita.Montero@gmail.com> - 2021-05-28 16:44 +0200
Re: recovering from std::bad_alloc in std::string reserve Bonita Montero <Bonita.Montero@gmail.com> - 2021-05-28 16:42 +0200
Re: recovering from std::bad_alloc in std::string reserve Paavo Helde <myfirstname@osa.pri.ee> - 2021-05-28 18:22 +0300
Re: recovering from std::bad_alloc in std::string reserve Paavo Helde <myfirstname@osa.pri.ee> - 2021-05-28 08:47 +0300
Re: recovering from std::bad_alloc in std::string reserve Bonita Montero <Bonita.Montero@gmail.com> - 2021-05-26 06:16 +0200
Re: recovering from std::bad_alloc in std::string reserve Lynn McGuire <lynnmcguire5@gmail.com> - 2021-05-26 13:30 -0500
Re: recovering from std::bad_alloc in std::string reserve Bonita Montero <Bonita.Montero@gmail.com> - 2021-05-26 20:37 +0200
Re: recovering from std::bad_alloc in std::string reserve Lynn McGuire <lynnmcguire5@gmail.com> - 2021-05-26 14:09 -0500
Re: recovering from std::bad_alloc in std::string reserve "Alf P. Steinbach" <alf.p.steinbach@gmail.com> - 2021-05-26 18:33 +0200
Re: recovering from std::bad_alloc in std::string reserve Lynn McGuire <lynnmcguire5@gmail.com> - 2021-05-26 13:32 -0500
Re: recovering from std::bad_alloc in std::string reserve Christian Gollwitzer <auriocus@gmx.de> - 2021-05-27 07:50 +0200
Re: recovering from std::bad_alloc in std::string reserve "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2021-06-01 17:35 -0700
Page 3 of 6 — ← Prev page 1 2 [3] 4 5 6 Next page →
| From | Bo Persson <bo@bo-persson.se> |
|---|---|
| Date | 2021-05-28 09:47 +0200 |
| Message-ID | <ihblgiFckfU1@mid.individual.net> |
| In reply to | #79831 |
On 2021-05-28 at 04:38, Lynn McGuire wrote: > On 5/27/2021 8:36 PM, Öö Tiib wrote: >> 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. >> Also standard should end the woo allowing implementations to >> have integers that are not integers. It is awful. > > For some reason, Microsoft is using __int64. Not my favorite variable > type. The reason being that they invented this type at a time when there was no long long. > Even "long long" is better (and the same) imho. Yes, *now* it is. :-) > __int64 _ftelli64 (FILE *stream); > > https://docs.microsoft.com/en-us/cpp/c-runtime-library/reference/ftell-ftelli64?view=msvc-160 > > > Apparently no one else is using _ftelli64. This sucks. > https://www.vogons.org/viewtopic.php?t=65070 > > Lynn > > >
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2021-05-27 19:54 -0700 |
| Message-ID | <87fsy7zhxd.fsf@nosuchdomain.example.com> |
| In reply to | #79823 |
Öö Tiib <ootiib@hot.ee> 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.
> 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.
--
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 */
[toc] | [prev] | [next] | [standalone]
| From | Öö Tiib <ootiib@hot.ee> |
|---|---|
| Date | 2021-05-27 21:02 -0700 |
| Message-ID | <2b396397-2ee8-4900-8969-8e59162f4c20n@googlegroups.com> |
| In reply to | #79832 |
On Friday, 28 May 2021 at 05:55:11 UTC+3, Keith Thompson wrote: > Öö Tiib <oot...@hot.ee> 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." 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.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2021-05-28 12:09 -0700 |
| Message-ID | <87bl8uzncv.fsf@nosuchdomain.example.com> |
| In reply to | #79840 |
Öö Tiib <ootiib@hot.ee> writes:
> On Friday, 28 May 2021 at 05:55:11 UTC+3, Keith Thompson wrote:
>> Öö Tiib <oot...@hot.ee> 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 */
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2021-05-28 20:26 +0000 |
| Message-ID | <8mcsI.1203$8m1.749@fx12.iad> |
| In reply to | #79919 |
Keith Thompson <Keith.S.Thompson+u@gmail.com> writes: >gcc has __int128 *as an extension* (not supported for 32-bit targets). >The standard permits extensions: > >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). We use it when modeling 128-bit bus structures. We don't use arithmetic operations on 128-bit data but do use masking and shifting.
[toc] | [prev] | [next] | [standalone]
| From | Öö Tiib <ootiib@hot.ee> |
|---|---|
| Date | 2021-05-28 17:10 -0700 |
| Message-ID | <7bca12bc-3b61-4e82-abd3-44835679245dn@googlegroups.com> |
| In reply to | #79919 |
On Friday, 28 May 2021 at 22:10:07 UTC+3, Keith Thompson wrote: > 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. I hoped to managed to express it. Technically the integer types are causing some of trouble as the rules of promotion and implicit conversion especially with implementation defined features in mix seem not to be intuitive to many programmers. Therefore desire to regulate it is welcome and appearance of regulating something without actually regulating anything is double unwelcome. > > 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 think of it as nonsense. The monsters are just thinking they are clever and fooling each other and so there is illusion of consensus. Actual desire is to have support to 128 bit (or perhaps arbitrary amount of bit) integers in their Golangs, Swifts, Javas or C#s before C and C++ and so hopefully others. But their proprieritary language infrastructures are mostly written in C or C++ so I see no point in pretending that we don't see it through.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2021-05-29 11:47 +0200 |
| Message-ID | <s8t2jn$ll2$1@dont-email.me> |
| In reply to | #79919 |
On 28/05/2021 21:09, Keith Thompson wrote: > 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. The definition of intmax_t is a problem - it is a limitation for integer types in C and C++. I'd have preferred to see functions like "abs" be type-generic macros in C and template functions in C++. From C90 there was "abs" and "labs" - C99 could have skipped "llabs" and "imaxabs", and similar functions. The "div" functions wouldn't need extended for bigger types - they are a hangover from an era of weaker compilers. No doubt there would be complications with some other functions that today use intmax_t types - no doubt there would be alternative ways of handling them, given a bit of thought. But of course it is too late to change all that now. The gcc solution of __int128 covers most purposes without affecting backwards compatibility. > > 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). > There is nothing stopping the C++ standard library introducing types std::int<N> and std::uint<N> types, where implementations can choose which sizes of N they support (but requiring support for any N for which std::intN_t exists). These would work just like integer types for most purposes, but not be /called/ integer types. So in gcc, std::int<128> would be the same as __int128_t. Constants would be handled by user-defined literals. (I also don't see much need for 128-bit or bigger types - until you get to cryptography-sized integers - but I guess some people do.)
[toc] | [prev] | [next] | [standalone]
| From | "daniel...@gmail.com" <danielaparker@gmail.com> |
|---|---|
| Date | 2021-05-30 15:15 -0700 |
| Message-ID | <ebbd50a2-ddbb-4344-9450-d2b77967621dn@googlegroups.com> |
| In reply to | #79944 |
On Saturday, May 29, 2021 at 5:47:50 AM UTC-4, David Brown wrote: > The definition of intmax_t is a problem - it is a limitation for integer > types in C and C++. Hopefully eventually deprecate intmax_t. One proposal is to make intmax_t mean int64_t, and leave it at that. Have no requirement that integer types can't be larger. No more ABI problem. > I'd have preferred to see functions like "abs" be > type-generic macros in C and template functions in C++. From C90 there > was "abs" and "labs" - C99 could have skipped "llabs" and "imaxabs", and > similar functions. Yes, of course, and to_integer<T> and from_integer<T>, and others. Many libraries have to reinvent their own version of these things. > > The gcc solution of __int128 covers most purposes without affecting > backwards compatibility. > > Hardly "most purposes", far from it. Without compiling with "-std=gnu++11", you don't even have std::numeric_limits<__int128>. The absence of standard support for int128_t makes genericity much harder. While other languages such as rust with better type support see rapid growth of open source libraries that cover all manner of data interchange standards, C++ is comparatively stagnant. Daniel
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2021-05-31 08:33 +0200 |
| Message-ID | <s92001$iei$1@dont-email.me> |
| In reply to | #80002 |
On 31/05/2021 00:15, daniel...@gmail.com wrote: > On Saturday, May 29, 2021 at 5:47:50 AM UTC-4, David Brown wrote: >> The definition of intmax_t is a problem - it is a limitation for integer >> types in C and C++. Hopefully eventually deprecate intmax_t. > > One proposal is to make intmax_t mean int64_t, and leave it at that. > Have no requirement that integer types can't be larger. No more ABI > problem. > It might make more sense to tie it to "long long int" rather than "int64_t", but someone would first have to check if it affected any real implementations before making such a change. But yes, that might be a way out and a way forward. >> I'd have preferred to see functions like "abs" be >> type-generic macros in C and template functions in C++. From C90 there >> was "abs" and "labs" - C99 could have skipped "llabs" and "imaxabs", and >> similar functions. > > Yes, of course, and to_integer<T> and from_integer<T>, and others. Many libraries > have to reinvent their own version of these things. >> >> The gcc solution of __int128 covers most purposes without affecting >> backwards compatibility. >>> > Hardly "most purposes", far from it. Without compiling with "-std=gnu++11", > you don't even have std::numeric_limits<__int128>. Well, it /is/ a gcc extension - choosing to enable it on the command line makes sense to me. But I was thinking of the core language, rather than the library, which can be somewhat independent of the compiler itself. > The absence of > standard support for int128_t makes genericity much harder. While other > languages such as rust with better type support see rapid growth > of open source libraries that cover all manner of data interchange > standards, C++ is comparatively stagnant. > Those relatively few programs that have need of int128_t can simply do a typedef. It won't magically allow literals of the type, but it will cover most cases.
[toc] | [prev] | [next] | [standalone]
| From | "daniel...@gmail.com" <danielaparker@gmail.com> |
|---|---|
| Date | 2021-05-31 08:21 -0700 |
| Message-ID | <631d7c79-32cc-4af0-8f64-86263552fff9n@googlegroups.com> |
| In reply to | #80017 |
On Monday, May 31, 2021 at 2:33:52 AM UTC-4, David Brown wrote: > On 31/05/2021 00:15, daniel...@gmail.com wrote: > > The absence of > > standard support for int128_t makes genericity much harder. While other > > languages such as rust with better type support see rapid growth > > of open source libraries that cover all manner of data interchange > > standards, C++ is comparatively stagnant. > > > Those relatively few programs that have need of int128_t can simply do a > typedef. It won't magically allow literals of the type, but it will > cover most cases. A typedef? You've lost me. Daniel
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2021-05-31 18:13 +0200 |
| Message-ID | <s931ur$f0b$1@dont-email.me> |
| In reply to | #80022 |
On 31/05/2021 17:21, daniel...@gmail.com wrote: > On Monday, May 31, 2021 at 2:33:52 AM UTC-4, David Brown wrote: >> On 31/05/2021 00:15, daniel...@gmail.com wrote: >>> The absence of >>> standard support for int128_t makes genericity much harder. While other >>> languages such as rust with better type support see rapid growth >>> of open source libraries that cover all manner of data interchange >>> standards, C++ is comparatively stagnant. >>> >> Those relatively few programs that have need of int128_t can simply do a >> typedef. It won't magically allow literals of the type, but it will >> cover most cases. > > A typedef? You've lost me. > > Daniel > typedef signed __int128 int128_t; typedef unsigned __int128 uint128_t; You can wrap them in #ifdef's to check for gcc and support for the 128 bit almost integer types (and perhaps to check that your target doesn't support standard int128_t types, as it will if "long long" is 128 bits).
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2021-05-31 14:43 -0700 |
| Message-ID | <87v96yy3yr.fsf@nosuchdomain.example.com> |
| In reply to | #80017 |
David Brown <david.brown@hesbynett.no> writes:
> On 31/05/2021 00:15, daniel...@gmail.com wrote:
>> On Saturday, May 29, 2021 at 5:47:50 AM UTC-4, David Brown wrote:
>>> The definition of intmax_t is a problem - it is a limitation for integer
>>> types in C and C++. Hopefully eventually deprecate intmax_t.
>>
>> One proposal is to make intmax_t mean int64_t, and leave it at that.
>> Have no requirement that integer types can't be larger. No more ABI
>> problem.
>
> It might make more sense to tie it to "long long int" rather than
> "int64_t", but someone would first have to check if it affected any real
> implementations before making such a change. But yes, that might be a
> way out and a way forward.
[...]
That would allow intmax_t to be 128 bits on implementations with
128-bit long long (are there any?), which seems like a good idea.
I think the point of both these proposals is purely for backward
compatibility, avoiding breaking code that already uses [u]intmax_t.
Both of them destroy the point of intmax_t, providing a type that's
guaranteed to be the longest integer type. Should intmax_t be
deprecated?
Perhaps some future version of C might have enough capabilities to
allow defining a longest integer type without causing ABI issues
the way intmax_t did.
And since, as far as I've been able to tell, no implementation
supports extended integer types, I wonder if they should be
reconsidered.
--
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 */
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2021-05-31 14:44 -0700 |
| Message-ID | <87r1hmy3vx.fsf@nosuchdomain.example.com> |
| In reply to | #80028 |
Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
[...]
> Perhaps some future version of C might have enough capabilities to
> allow defining a longest integer type without causing ABI issues
> the way intmax_t did.
And I did it again. s/C/C++/, or s/comp.lang.c++/comp.lang.c/.
[...]
--
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 */
[toc] | [prev] | [next] | [standalone]
| From | "daniel...@gmail.com" <danielaparker@gmail.com> |
|---|---|
| Date | 2021-05-31 15:20 -0700 |
| Message-ID | <d0fabaf2-7bc4-4297-9989-bfbeb376b8f0n@googlegroups.com> |
| In reply to | #80028 |
On Monday, May 31, 2021 at 5:43:23 PM UTC-4, Keith Thompson wrote: > David Brown <david...@hesbynett.no> writes: > > On 31/05/2021 00:15, daniel...@gmail.com wrote: > >> On Saturday, May 29, 2021 at 5:47:50 AM UTC-4, David Brown wrote: > >>> The definition of intmax_t is a problem - it is a limitation for integer > >>> types in C and C++. Hopefully eventually deprecate intmax_t. > >> > >> One proposal is to make intmax_t mean int64_t, and leave it at that. > >> Have no requirement that integer types can't be larger. No more ABI > >> problem. > > > > It might make more sense to tie it to "long long int" rather than > > "int64_t", but someone would first have to check if it affected any real > > implementations before making such a change. But yes, that might be a > > way out and a way forward. > [...] > > That would allow intmax_t to be 128 bits on implementations with > 128-bit long long (are there any?), which seems like a good idea. > > I think the point of both these proposals is purely for backward > compatibility, avoiding breaking code that already uses [u]intmax_t. > Both of them destroy the point of intmax_t, providing a type that's > guaranteed to be the longest integer type. Should intmax_t be > deprecated? > Yes. "Give me the biggest integer type there is" is not a reasonable thing to ask for, in any code that is intended to be portable across platforms or over time on the same platform. You may as well have intwhatever_t. Daniel
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2021-06-01 11:17 -0700 |
| Message-ID | <87im2xxxer.fsf@nosuchdomain.example.com> |
| In reply to | #80030 |
David Brown <david.brown@hesbynett.no> writes:
> On 01/06/2021 18:00, Manfred wrote:
[...]
>> I think this would be problematic as well, or at least useless and
>> confusing.
>> The idea for intmax_t is to give a standard name to the widest integer
>> type that is available, which is by definition implementation defined.
>> Having intmax_t an alias for "long long" would change its meaning to the
>> widest /standard/ integer type defined by the standard itself - a
>> useless repetition (we have "long long" for that), and confusing too,
>> given its change in meaning.
>
> Yes, that is all true. The point is not to find another useful purpose
> for intmax_t - the point is to get rid of it, marking it as deprecated,
> but to do so in a way that won't break existing code.
>
> I am at a loss to understand why anyone would have a use for intmax_t in
> the first place. When would you want an integer type whose sole
> characteristic is "big" ? To me, it is logical to want a type that is
> at least N bits, or exactly N bits. These requirements are covered by
> the normal "short", "int", "long" and "long long" types, or - better for
> my use, but not necessarily other people's - the <stdint.h> fixed size
> types. "intmax_t" gives you absolutely /nothing/ that "long long" does not.
Suppose you have a type foo_t, and all you know is that it's a signed
integer type. You can print it using printf("%ju", (intmax_t)n).
(Or in C++ you can use std::cout << n, but intmax_t is inherited from
C's standard library.)
Or suppose you're implementing an arbitrary-width integer type as
an array of fixed-width integers. You might want each element to
be as wide as possible, because arithmetic on a 2*N-bit integer is
likely to be faster than synthesizing it from two N-bit integers.
(That's assuming that, for example, 128-bit integer arithmetic
isn't drastically less efficient than 64-bit integer arithmetic.)
> Given that there are, as far as we know, no implementations where
> intmax_t does not correspond directly to "long long", I would like to
> see "intmax_t" be dropped to the maximum extent allowable by backwards
> compatibility.
I'd *like* to keep intmax_t and make it work the way it was intended,
but ABI issues made that impractical. (I'm guessing those issues
weren't anticipated when intmax_t was added in C99.) Deprecating it
might be the least bad solution.
>> As far as I understand the purpose for intmax_t is to allow for (sort
>> of) 'standard' prototypes of functions like imaxabs, imaxdiv, strtoimax,
>> etc that are supposed to operate on larger integer types - these are the
>> only functions that take this kind of arguments.
>> The confusing part is that all of these facilities are implementation
>> dependent, so even if they are part of the standard they are /not/
>> portable, meaning that the programmer is supposed (the way I see it) to
>> use them under the guard of appropriate preprocessor directives.
>>
>> The use for them is to allow the programmer to use some optimized
>> routines for larger types, if available.
>
> But they don't allow that. If you are trying to make optimised routines
> for larger types, you need to know your sizes - you either use
> implementation extensions (like __int128), or fixed size types, or if
> you need maximal portability, you use "int_fast64_t".
And my impression (which could be mistaken) is that __int128 is not an
extended integer type partly *because* it would require making intmax_t
128 bits, which would cause ABI problems. That, and __int128 is
unfinished (some features are missing), but if it could have been made
an extended integer type perhaps more effort would have been spent
making it fully functional.
>> For example, in case operations like ldiv are needed on 128 bit
>> integers, then IF the implementation supports 128 bit intmax_t then
>> imaxdiv can be a better choice rather than implementing your own routine
>> - note that /IF/ is the keyword here, that should map directly to
>> appropriate #if directives.
>
> The situation we have now is that on a compiler like gcc you can get
> 128-bit division using __int128, but /not/ using intmax_t. It is a
> useless type.
I suspect it's useful enough for some purposes. There's probably code
out there that uses __int128 that doesn't need 128-bit division.
[...]
--
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 */
[toc] | [prev] | [next] | [standalone]
| From | Manfred <noname@add.invalid> |
|---|---|
| Date | 2021-06-01 20:25 +0200 |
| Message-ID | <s95u2v$1et0$1@gioia.aioe.org> |
| In reply to | #80043 |
On 6/1/2021 8:17 PM, Keith Thompson wrote:
> David Brown <david.brown@hesbynett.no> writes:
>> On 01/06/2021 18:00, Manfred wrote:
> [...]
>>> I think this would be problematic as well, or at least useless and
>>> confusing.
>>> The idea for intmax_t is to give a standard name to the widest integer
>>> type that is available, which is by definition implementation defined.
>>> Having intmax_t an alias for "long long" would change its meaning to the
>>> widest /standard/ integer type defined by the standard itself - a
>>> useless repetition (we have "long long" for that), and confusing too,
>>> given its change in meaning.
>>
>> Yes, that is all true. The point is not to find another useful purpose
>> for intmax_t - the point is to get rid of it, marking it as deprecated,
>> but to do so in a way that won't break existing code.
>>
>> I am at a loss to understand why anyone would have a use for intmax_t in
>> the first place. When would you want an integer type whose sole
>> characteristic is "big" ? To me, it is logical to want a type that is
>> at least N bits, or exactly N bits. These requirements are covered by
>> the normal "short", "int", "long" and "long long" types, or - better for
>> my use, but not necessarily other people's - the <stdint.h> fixed size
>> types. "intmax_t" gives you absolutely /nothing/ that "long long" does not.
>
> Suppose you have a type foo_t, and all you know is that it's a signed
> integer type. You can print it using printf("%ju", (intmax_t)n).
> (Or in C++ you can use std::cout << n, but intmax_t is inherited from
> C's standard library.)
>
> Or suppose you're implementing an arbitrary-width integer type as
> an array of fixed-width integers. You might want each element to
> be as wide as possible, because arithmetic on a 2*N-bit integer is
> likely to be faster than synthesizing it from two N-bit integers.
> (That's assuming that, for example, 128-bit integer arithmetic
> isn't drastically less efficient than 64-bit integer arithmetic.)
>
>> Given that there are, as far as we know, no implementations where
>> intmax_t does not correspond directly to "long long", I would like to
>> see "intmax_t" be dropped to the maximum extent allowable by backwards
>> compatibility.
>
> I'd *like* to keep intmax_t and make it work the way it was intended,
> but ABI issues made that impractical. (I'm guessing those issues
> weren't anticipated when intmax_t was added in C99.) Deprecating it
> might be the least bad solution.
Can you be more specific about which ABI issues?
>
>>> As far as I understand the purpose for intmax_t is to allow for (sort
>>> of) 'standard' prototypes of functions like imaxabs, imaxdiv, strtoimax,
>>> etc that are supposed to operate on larger integer types - these are the
>>> only functions that take this kind of arguments.
>>> The confusing part is that all of these facilities are implementation
>>> dependent, so even if they are part of the standard they are /not/
>>> portable, meaning that the programmer is supposed (the way I see it) to
>>> use them under the guard of appropriate preprocessor directives.
>>>
>>> The use for them is to allow the programmer to use some optimized
>>> routines for larger types, if available.
>>
>> But they don't allow that. If you are trying to make optimised routines
>> for larger types, you need to know your sizes - you either use
>> implementation extensions (like __int128), or fixed size types, or if
>> you need maximal portability, you use "int_fast64_t".
>
> And my impression (which could be mistaken) is that __int128 is not an
> extended integer type partly *because* it would require making intmax_t
> 128 bits, which would cause ABI problems.
That sounds like a possible explanation, but again I'd need to know more
about such ABI issues.
That, and __int128 is
> unfinished (some features are missing), but if it could have been made
> an extended integer type perhaps more effort would have been spent
> making it fully functional.
>
>>> For example, in case operations like ldiv are needed on 128 bit
>>> integers, then IF the implementation supports 128 bit intmax_t then
>>> imaxdiv can be a better choice rather than implementing your own routine
>>> - note that /IF/ is the keyword here, that should map directly to
>>> appropriate #if directives.
>>
>> The situation we have now is that on a compiler like gcc you can get
>> 128-bit division using __int128, but /not/ using intmax_t. It is a
>> useless type.
>
> I suspect it's useful enough for some purposes. There's probably code
> out there that uses __int128 that doesn't need 128-bit division.
>
> [...]
>
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2021-06-01 16:55 -0700 |
| Message-ID | <87eedlxhqa.fsf@nosuchdomain.example.com> |
| In reply to | #80053 |
Manfred <noname@add.invalid> writes:
> On 6/1/2021 8:17 PM, Keith Thompson wrote:
[...]
>> I'd *like* to keep intmax_t and make it work the way it was intended,
>> but ABI issues made that impractical. (I'm guessing those issues
>> weren't anticipated when intmax_t was added in C99.) Deprecating it
>> might be the least bad solution.
>
> Can you be more specific about which ABI issues?
It's discussed, and a solution proposed, here:
http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2465.pdf
Quoting the problem description section:
The interaction between the definition of extended integer types and
[u]intmax_t has resulted in a lack of extensibility for existing
ABI. Platforms that have anchored their specifications for the basic
integer types and for [u]intmax_t cannot add an extended integer type
that is wider than their current [u]intmax_t to their specification. As
the current text of the C standard stands, such an addition would
force a redefinition of [u]intmax_t to the wider types. This would
have the following consequences
- The parts of the C library that use [u]intmax_t (specific
functions but also printf and related functions) must be
rewritten or recompiled with the new ABI and become binary
incompatible with existing programs.
- Programs compiled with the new ABI would be binary incompatible
on platforms that have not been upgraded.
- The preprocessor of the implementation must be re-engineered
to comply with the standard. In particular, there would be
severe specification problems for preprocessor numbers and
their evaluation. E.g., the value of ULLONG_MAX+1 is not
expressible as a literal in the language proper but would
be for the preprocessor. The expression ULLONG_MAX+1 would
evaluate to true in a preprocessor conditional but to 0
(false) in later compilation phases.
See also http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2425.pdf
--
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 */
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2021-06-02 09:06 +0200 |
| Message-ID | <s97alu$v8t$1@dont-email.me> |
| In reply to | #80043 |
On 01/06/2021 20:17, Keith Thompson wrote:
> David Brown <david.brown@hesbynett.no> writes:
>> On 01/06/2021 18:00, Manfred wrote:
> [...]
>>> I think this would be problematic as well, or at least useless and
>>> confusing.
>>> The idea for intmax_t is to give a standard name to the widest integer
>>> type that is available, which is by definition implementation defined.
>>> Having intmax_t an alias for "long long" would change its meaning to the
>>> widest /standard/ integer type defined by the standard itself - a
>>> useless repetition (we have "long long" for that), and confusing too,
>>> given its change in meaning.
>>
>> Yes, that is all true. The point is not to find another useful purpose
>> for intmax_t - the point is to get rid of it, marking it as deprecated,
>> but to do so in a way that won't break existing code.
>>
>> I am at a loss to understand why anyone would have a use for intmax_t in
>> the first place. When would you want an integer type whose sole
>> characteristic is "big" ? To me, it is logical to want a type that is
>> at least N bits, or exactly N bits. These requirements are covered by
>> the normal "short", "int", "long" and "long long" types, or - better for
>> my use, but not necessarily other people's - the <stdint.h> fixed size
>> types. "intmax_t" gives you absolutely /nothing/ that "long long" does not.
>
> Suppose you have a type foo_t, and all you know is that it's a signed
> integer type. You can print it using printf("%ju", (intmax_t)n).
And if you know "long long" is the largest standard type, you can print
it with "%llu". The reality is that it is currently exactly the same.
intmax_t doesn't let you print anything that you can't print with "long
long" in any existing implementations, and is seems unlikely to do so in
the future.
If implementations regularly had integer types that were bigger than
"long long" then "intmax_t" could have been useful in such cases. It
could be seen as a good reason for introducing intmax_t in the first
place. The reality, however, is different.
I suspect an issue here is that compilers and standard libraries are
often developed somewhat independently - but the introduction of a
larger integer type in a compiler would require changes to the libraries
used, possibly also the ABI for the platform. It's one thing to accept
such chicken-and-egg challenges for a major new C revision, such as the
introduction of "long long" in C99, but quite another to have it for
compiler-specific extensions along the way.
> (Or in C++ you can use std::cout << n, but intmax_t is inherited from
> C's standard library.)
>
C++ does not have the problems or excuses of C here. printf is a pain
because it is a variadic function with types unknown at declaration and
compile time (of the printf implementation). For C++, an implementation
can easily add an overload for << with whatever types the compiler supports.
> Or suppose you're implementing an arbitrary-width integer type as
> an array of fixed-width integers. You might want each element to
> be as wide as possible, because arithmetic on a 2*N-bit integer is
> likely to be faster than synthesizing it from two N-bit integers.
> (That's assuming that, for example, 128-bit integer arithmetic
> isn't drastically less efficient than 64-bit integer arithmetic.)
>
You need to know the sizes of your integers here. intmax_t, specified
merely as "at least as big as long long", is useless. For such tasks,
you use the <stdint.h> types in general, and possibly compiler-specific
extensions like __int128. You don't use intmax_t. (At least, /I/ can't
see how it would be helpful here.)
>> Given that there are, as far as we know, no implementations where
>> intmax_t does not correspond directly to "long long", I would like to
>> see "intmax_t" be dropped to the maximum extent allowable by backwards
>> compatibility.
>
> I'd *like* to keep intmax_t and make it work the way it was intended,
> but ABI issues made that impractical. (I'm guessing those issues
> weren't anticipated when intmax_t was added in C99.) Deprecating it
> might be the least bad solution.
Fair enough.
>
>>> As far as I understand the purpose for intmax_t is to allow for (sort
>>> of) 'standard' prototypes of functions like imaxabs, imaxdiv, strtoimax,
>>> etc that are supposed to operate on larger integer types - these are the
>>> only functions that take this kind of arguments.
>>> The confusing part is that all of these facilities are implementation
>>> dependent, so even if they are part of the standard they are /not/
>>> portable, meaning that the programmer is supposed (the way I see it) to
>>> use them under the guard of appropriate preprocessor directives.
>>>
>>> The use for them is to allow the programmer to use some optimized
>>> routines for larger types, if available.
>>
>> But they don't allow that. If you are trying to make optimised routines
>> for larger types, you need to know your sizes - you either use
>> implementation extensions (like __int128), or fixed size types, or if
>> you need maximal portability, you use "int_fast64_t".
>
> And my impression (which could be mistaken) is that __int128 is not an
> extended integer type partly *because* it would require making intmax_t
> 128 bits, which would cause ABI problems. That, and __int128 is
> unfinished (some features are missing), but if it could have been made
> an extended integer type perhaps more effort would have been spent
> making it fully functional.
>
Agreed.
>>> For example, in case operations like ldiv are needed on 128 bit
>>> integers, then IF the implementation supports 128 bit intmax_t then
>>> imaxdiv can be a better choice rather than implementing your own routine
>>> - note that /IF/ is the keyword here, that should map directly to
>>> appropriate #if directives.
>>
>> The situation we have now is that on a compiler like gcc you can get
>> 128-bit division using __int128, but /not/ using intmax_t. It is a
>> useless type.
>
> I suspect it's useful enough for some purposes. There's probably code
> out there that uses __int128 that doesn't need 128-bit division.
>
I might have been unclear there - I meant "intmax_t" is a useless type.
__int128 is useful as it is (albeit not often useful). Adding abs,
div, etc., support to __int128 would not make it any more useful.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2021-06-05 17:50 -0700 |
| Message-ID | <87h7ibx1ci.fsf@nosuchdomain.example.com> |
| In reply to | #80073 |
David Brown <david.brown@hesbynett.no> writes:
> On 01/06/2021 20:17, Keith Thompson wrote:
>> David Brown <david.brown@hesbynett.no> writes:
>>> On 01/06/2021 18:00, Manfred wrote:
>> [...]
>>>> I think this would be problematic as well, or at least useless and
>>>> confusing.
>>>> The idea for intmax_t is to give a standard name to the widest integer
>>>> type that is available, which is by definition implementation defined.
>>>> Having intmax_t an alias for "long long" would change its meaning to the
>>>> widest /standard/ integer type defined by the standard itself - a
>>>> useless repetition (we have "long long" for that), and confusing too,
>>>> given its change in meaning.
>>>
>>> Yes, that is all true. The point is not to find another useful purpose
>>> for intmax_t - the point is to get rid of it, marking it as deprecated,
>>> but to do so in a way that won't break existing code.
>>>
>>> I am at a loss to understand why anyone would have a use for intmax_t in
>>> the first place. When would you want an integer type whose sole
>>> characteristic is "big" ? To me, it is logical to want a type that is
>>> at least N bits, or exactly N bits. These requirements are covered by
>>> the normal "short", "int", "long" and "long long" types, or - better for
>>> my use, but not necessarily other people's - the <stdint.h> fixed size
>>> types. "intmax_t" gives you absolutely /nothing/ that "long long" does not.
>>
>> Suppose you have a type foo_t, and all you know is that it's a signed
>> integer type. You can print it using printf("%ju", (intmax_t)n).
>
> And if you know "long long" is the largest standard type, you can print
> it with "%llu". The reality is that it is currently exactly the same.
> intmax_t doesn't let you print anything that you can't print with "long
> long" in any existing implementations, and is seems unlikely to do so in
> the future.
long long is the widest *standard* signed integer type (though I can
imagine wanting to future-proof my code by not assuming that a future
standard won't add long long long). The whole point of intmax_t is that
long long might not be the widest signed integer type. The most likely
scenario is that a compiler makes long long 64 bits and provides a
128-bit extended integer type.
That hasn't happened, and we've already discussed the reasons for that.
I don't want to assume that a solution won't be found that allows for
extended integer types wider than long long. Maybe some new popular
platform won't have to conform to existing ABIs.
Using intmax_t rather than long long costs me nothing.
> If implementations regularly had integer types that were bigger than
> "long long" then "intmax_t" could have been useful in such cases. It
> could be seen as a good reason for introducing intmax_t in the first
> place. The reality, however, is different.
So far.
And I'm not predicting that that won't change. I'm just not assuming
that it won't.
> I suspect an issue here is that compilers and standard libraries are
> often developed somewhat independently - but the introduction of a
> larger integer type in a compiler would require changes to the libraries
> used, possibly also the ABI for the platform. It's one thing to accept
> such chicken-and-egg challenges for a major new C revision, such as the
> introduction of "long long" in C99, but quite another to have it for
> compiler-specific extensions along the way.
>
>> (Or in C++ you can use std::cout << n, but intmax_t is inherited from
>> C's standard library.)
>>
>
> C++ does not have the problems or excuses of C here. printf is a pain
> because it is a variadic function with types unknown at declaration and
> compile time (of the printf implementation). For C++, an implementation
> can easily add an overload for << with whatever types the compiler supports.
C++ has all of C's standard library (with a few tweaks here and there).
printf is a standard C++ function. So is imaxabs.
>> Or suppose you're implementing an arbitrary-width integer type as
>> an array of fixed-width integers. You might want each element to
>> be as wide as possible, because arithmetic on a 2*N-bit integer is
>> likely to be faster than synthesizing it from two N-bit integers.
>> (That's assuming that, for example, 128-bit integer arithmetic
>> isn't drastically less efficient than 64-bit integer arithmetic.)
>>
>
> You need to know the sizes of your integers here. intmax_t, specified
> merely as "at least as big as long long", is useless. For such tasks,
> you use the <stdint.h> types in general, and possibly compiler-specific
> extensions like __int128. You don't use intmax_t. (At least, /I/ can't
> see how it would be helpful here.)
Who says the code has to be compiler-specific?
You can use long long for compilers that don't have 128-bit integers, or
__int128 for compilers that do. Or you can use intmax_t.
And yes, the fact that gcc's __int128 is not an extended integer type is
a barrier, but you can still write portable future-proof C code that
will use the widest fully supported integer type. I can see that being
useful.
[...]
> I might have been unclear there - I meant "intmax_t" is a useless type.
> __int128 is useful as it is (albeit not often useful). Adding abs,
> div, etc., support to __int128 would not make it any more useful.
I disagree. intmax_t has not turned out to be a useful as it was
intended to be, but it's hardly useless.
--
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 */
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2021-06-06 11:10 +0200 |
| Message-ID | <s9i3el$i1e$1@dont-email.me> |
| In reply to | #80176 |
On 06/06/2021 02:50, Keith Thompson wrote: <snipping for brevity - as usual, you make good points, but I don't think I have much to add> > I disagree. intmax_t has not turned out to be a useful as it was > intended to be, but it's hardly useless. > Fair enough. You've convinced me that it has some future-proofing uses, even if such future-proofing may never be needed in practice. (Predictions about the future are always hard.) From my own viewpoint, it looks like the unintended consequences outweigh the usefulness, but my viewpoint is not the only one!
[toc] | [prev] | [next] | [standalone]
Page 3 of 6 — ← Prev page 1 2 [3] 4 5 6 Next page →
Back to top | Article view | comp.lang.c++
csiph-web