Tuesday, June 1, 2021

Digest for comp.lang.c++@googlegroups.com - 7 updates in 3 topics

Michael S <already5chosen@yahoo.com>: Jun 01 01:23PM -0700

On Tuesday, June 1, 2021 at 12:54:30 PM UTC+3, David Brown wrote:
> all tests".
 
> (That said, MSVC can be quite efficient for some kinds of code - it's
> entirely possible that it is simply better for the examples you were using.)
 
I was under impression that in clang -O3 is the same as -O2. A flag that exists for compatibility with gcc and nothing else.
Real Troll <real.troll@trolls.com>: Jun 01 10:47PM +0100

On 01/06/2021 21:23, Michael S wrote:
> I was under impression that in clang -O3 is the same as -O2. A flag that exists for compatibility with gcc and nothing else.
 
 
Just checked in clang, latest version 12.0.0-win64, and nothing in it -O3. Not sure what are they talking about.
MrSpook_x510g@6uikovuenojv.gov.uk: Jun 01 06:27PM

On Tue, 1 Jun 2021 07:10:19 +0000 (UTC)
 
>"An attack to the person" does not mean "being aggressive towards the
>person (eg. with insults or swearwords)". It means "trying to discredit
>what the person is saying by discrediting the reputation of the person".
 
Calling someone stupid fits that description nicely.
Keith Thompson <Keith.S.Thompson+u@gmail.com>: Jun 01 11:17AM -0700

> On 01/06/2021 18:00, Manfred wrote:
[...]
> 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.)
 
> 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.
 
> 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.
 
 
> 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 */
Manfred <noname@add.invalid>: Jun 01 08:21PM +0200

On 6/1/2021 7:15 PM, David Brown wrote:
> 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.
The use I see is with imaxdiv and friends as I wrote below, at least
this is my understanding.
 
When would you want an integer type whose sole
> 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".
 
When I wrote "use" I didn't mean "make". I meant imaxdiv may be a 128
bit division routine provided by the implementation that the programmer
can to use without the need to write one, possible a less efficient one.
 
 
> 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.
 
The way I see it this is a problem with gcc, not with the standard.
Unless the committee managed to produce some wording that is too
problematic for __int128 to fit as extended integer type.
 
Note that I am not talking about plain integer division (the '/'
operator) I am talking about 128 bit ldiv.
Now we have div, ldiv and lldiv too (supposedly for 64 bit), but instead
of going on with llldiv, and then llllllllldiv, they decided to stop
with imaxdiv. It makes sense.
 
Manfred <noname@add.invalid>: Jun 01 08:25PM +0200

On 6/1/2021 8:17 PM, Keith Thompson wrote:
> 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?
 
 
> 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
Lynn McGuire <lynnmcguire5@gmail.com>: Jun 01 01:26PM -0500

On 6/1/2021 6:59 AM, Bo Persson wrote:
> time when intmax_t was introduced, at least in C there were
> implementations with 36 bit ints and 72-bit longs. So just using int64_t
> would not be portable.
 
Don't forget the 60 bit int / 120 bit long CDC 7600 machines. The only
36 bit machine that I knew was the Univac 1108 that the IRS reputedly
used until 2010 or so.
 
Lynn
You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page.
To unsubscribe from this group and stop receiving emails from it send an email to comp.lang.c+++unsubscribe@googlegroups.com.
Posted by at

No comments:

Post a Comment

Subscribe to: Post Comments (Atom)