Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c++ > #67214 > unrolled thread

In the end, rason will come

Back to article view | Back to comp.lang.c++

Contents

  In the end, rason will come Bonita Montero <Bonita.Montero@gmail.com> - 2019-07-31 10:14 +0200
    Re: In the end, rason will come "Chris M. Thomasson" <invalid_chris_thomasson_invalid@invalid.com> - 2019-07-31 01:25 -0700
      Re: In the end, rason will come James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-07-31 07:58 -0400
        Re: In the end, rason will come Siri Cruise <chine.bleu@yahoo.com> - 2019-07-31 05:14 -0700
        Re: In the end, rason will come Jorgen Grahn <grahn+nntp@snipabacken.se> - 2019-07-31 22:35 +0000
      Re: In the end, rason will come "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com> - 2019-07-31 14:59 +0200
    Re: In the end, rason will come Öö Tiib <ootiib@hot.ee> - 2019-07-31 03:48 -0700
      Re: In the end, rason will come David Brown <david.brown@hesbynett.no> - 2019-07-31 15:29 +0200
        Re: In the end, rason will come Öö Tiib <ootiib@hot.ee> - 2019-07-31 14:22 -0700
          Re: In the end, rason will come David Brown <david.brown@hesbynett.no> - 2019-08-01 23:25 +0200
            Re: In the end, rason will come Öö Tiib <ootiib@hot.ee> - 2019-08-01 19:53 -0700
              Re: In the end, rason will come David Brown <david.brown@hesbynett.no> - 2019-08-02 20:46 +0200
                Re: In the end, rason will come Öö Tiib <ootiib@hot.ee> - 2019-08-05 02:56 -0700
                  Re: In the end, rason will come David Brown <david.brown@hesbynett.no> - 2019-08-06 14:32 +0200
                    Re: In the end, rason will come Manfred <noname@add.invalid> - 2019-08-07 16:05 +0200
                      Re: In the end, rason will come David Brown <david.brown@hesbynett.no> - 2019-08-07 17:00 +0200
                        Re: In the end, rason will come "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com> - 2019-08-07 18:39 +0200
                          Re: In the end, rason will come David Brown <david.brown@hesbynett.no> - 2019-08-07 21:15 +0200
                          Re: In the end, rason will come David Brown <david.brown@hesbynett.no> - 2019-08-07 21:20 +0200
                            Re: In the end, rason will come Ralf Goertz <me@myprovider.invalid> - 2019-08-08 12:14 +0200
                            Re: In the end, rason will come Ralf Goertz <me@myprovider.invalid> - 2019-08-08 12:21 +0200
            Re: In the end, rason will come Christian Gollwitzer <auriocus@gmx.de> - 2019-08-02 07:41 +0200
      Re: In the end, rason will come Keith Thompson <kst-u@mib.org> - 2019-07-31 13:05 -0700
        Re: In the end, rason will come Öö Tiib <ootiib@hot.ee> - 2019-07-31 15:48 -0700
          Re: In the end, rason will come Keith Thompson <kst-u@mib.org> - 2019-07-31 16:32 -0700
            Re: In the end, rason will come Öö Tiib <ootiib@hot.ee> - 2019-07-31 19:21 -0700
        Re: In the end, rason will come Bonita Montero <Bonita.Montero@gmail.com> - 2019-08-02 08:10 +0200
    Re: In the end, rason will come David Brown <david.brown@hesbynett.no> - 2019-08-06 14:54 +0200

Page 2 of 2 — ← Prev page 1 [2]

#67437

Am Wed, 7 Aug 2019 21:20:36 +0200
schrieb David Brown <david.brown@hesbynett.no>:

> Backslash is used for set difference and a few other things in
> mathematics.  Quotient groups use forward slash in my experience as
> does integer division.  So I don't see any logic here at all.  

I have the same experience. Maybe apart from integer division. I haven't
seen the forward slash as indicator of *integer* division but then I am
usually more interested in the remainder than the quotient. :-)

> However, sometimes mathematical symbol conventions vary by language -
> I have no idea about conventions in German.  

The conventions in German don't differ from those in English in this
respect AFAIK.

[toc] | [prev] | [next] | [standalone]

#67245

Am 01.08.19 um 23:25 schrieb David Brown:
> It was not ordered by importance (or what I feel is most important). 
> Correctness always trumps efficiency, and aids to correctness are 
> therefore high on my list of important features.

Then the right thing to do would be mathematical signed integers, which 
can not overflow at all (like those in Python, short of memory 
exhaustion) for the type "int". Wrapping integers for int8_t, uint8_t 
etc. No general unsigned int, unless it throws an exception on negative 
numbers.

The only reason no one wants to suggest this, is performance.

	Christian

[toc] | [prev] | [next] | [standalone]

#67229

Öö Tiib <ootiib@hot.ee> writes:
> On Wednesday, 31 July 2019 11:14:17 UTC+3, Bonita Montero  wrote:
>> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0907r0.html

The link is to:
    p0907r0
    Signed Integers are Two’s Complement
    Published Proposal, 9 February 2018

> This feels like two major proposals. One is that all signed integers
> should be two's complement and other is that signed integer overflow
> should wrap. 
>
> Majority will be happy (or at least content) with both but about
> second  there will be likely a bit of opposition and controversy. 
>
> Most of such opposition will boil down to claim that signed
> arithmetic should not overflow anyway in sane code and therefore
> some optimizations where compiler did assume that it does not
> overflow will be lost without any gain.
>
> I agree that that signed arithmetic should not overflow
> in good code but it seems hard to find (or to teach) programmers
> who write good code in that respect. So there are often bugs with
> it and so I would often prefer crash (or have SIGFPE raised)
> instead of wrapping.

I have no particular objection to requiring two's complement for signed
integers.  I don't think this proposal addresses padding bits or the
possibility that the most negative representation is a trap
representation, so would still be some rare variations to worry about.

Specifying wrapping behavior for signed integers could be a *big*
problem.  In particular, this:

    int n = INT_MAX + 1;

would probably not produce a warning.  It's not required to do
so now, and compilers could produce warnings anyway, but making
INT_MAX + 1 well defined where it's currently almost certainly an
error would be confusing.  More concretely, this:

    constexpr int n = INT_MAX + 1;

is currently invalid and would become legal.

Requiring 2's-complement representation while leaving overflow
behavior alone would be a simpler and less controversial change.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Will write code for food.
void Void(void) { Void(); } /* The recursive call of the void */

[toc] | [prev] | [next] | [standalone]

#67233

On Wednesday, 31 July 2019 23:05:52 UTC+3, Keith Thompson  wrote:
> Specifying wrapping behavior for signed integers could be a *big*
> problem.  In particular, this:
> 
>     int n = INT_MAX + 1;
> 
> would probably not produce a warning.  It's not required to do
> so now, and compilers could produce warnings anyway, but making
> INT_MAX + 1 well defined where it's currently almost certainly an
> error would be confusing.  More concretely, this:
> 
>     constexpr int n = INT_MAX + 1;
> 
> is currently invalid and would become legal.

I feel confused, either I misunderstand the point you are making
or have misread standard.
Right now (as with C++17) the std::numeric_limits<int>::is_modulo
has implementation-defined constexpr value. Yes? 
That value can depend on compiler options if it is true
or false. Yes?
My reading of standard is that when it is true then INT_MAX + 1
is not undefined behavior. Do I misread?
Are you saying that it should be undefined behavior?
I read that the proposal was to make it true always and that I'm
also unsure if it is good idea.

[toc] | [prev] | [next] | [standalone]

#67234

Öö Tiib <ootiib@hot.ee> writes:
> On Wednesday, 31 July 2019 23:05:52 UTC+3, Keith Thompson  wrote:
>> Specifying wrapping behavior for signed integers could be a *big*
>> problem.  In particular, this:
>> 
>>     int n = INT_MAX + 1;
>> 
>> would probably not produce a warning.  It's not required to do
>> so now, and compilers could produce warnings anyway, but making
>> INT_MAX + 1 well defined where it's currently almost certainly an
>> error would be confusing.  More concretely, this:
>> 
>>     constexpr int n = INT_MAX + 1;
>> 
>> is currently invalid and would become legal.
>
> I feel confused, either I misunderstand the point you are making
> or have misread standard.
> Right now (as with C++17) the std::numeric_limits<int>::is_modulo
> has implementation-defined constexpr value. Yes? 
> That value can depend on compiler options if it is true
> or false. Yes?
> My reading of standard is that when it is true then INT_MAX + 1
> is not undefined behavior. Do I misread?
> Are you saying that it should be undefined behavior?
> I read that the proposal was to make it true always and that I'm
> also unsure if it is good idea.

As far as I know, that's all correct.

I hadn't known about is_modulo.

For g++ and clang++, is_modulo is false for signed integer types, which
makes the behavior of INT_MAX + 1 undefined.  I don't know whether
there's an option that makes it true, or what other implementations do.

Yes, that does affect the issue.  The proposal would effectively require
is_modulo to be true for signed types.

It would be nice to have a way for a programmer, not just an
implementation, to decide whether a given signed type has wraparound or
overflow semantics.  That's probably beyond the scope of this proposal.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Will write code for food.
void Void(void) { Void(); } /* The recursive call of the void */

[toc] | [prev] | [next] | [standalone]

#67235

On Thursday, 1 August 2019 02:32:14 UTC+3, Keith Thompson  wrote:
> Öö Tiib <ootiib@hot.ee> writes:
> > On Wednesday, 31 July 2019 23:05:52 UTC+3, Keith Thompson  wrote:
> >> Specifying wrapping behavior for signed integers could be a *big*
> >> problem.  In particular, this:
> >> 
> >>     int n = INT_MAX + 1;
> >> 
> >> would probably not produce a warning.  It's not required to do
> >> so now, and compilers could produce warnings anyway, but making
> >> INT_MAX + 1 well defined where it's currently almost certainly an
> >> error would be confusing.  More concretely, this:
> >> 
> >>     constexpr int n = INT_MAX + 1;
> >> 
> >> is currently invalid and would become legal.
> >
> > I feel confused, either I misunderstand the point you are making
> > or have misread standard.
> > Right now (as with C++17) the std::numeric_limits<int>::is_modulo
> > has implementation-defined constexpr value. Yes? 
> > That value can depend on compiler options if it is true
> > or false. Yes?
> > My reading of standard is that when it is true then INT_MAX + 1
> > is not undefined behavior. Do I misread?
> > Are you saying that it should be undefined behavior?
> > I read that the proposal was to make it true always and that I'm
> > also unsure if it is good idea.
> 
> As far as I know, that's all correct.
> 
> I hadn't known about is_modulo.
> 
> For g++ and clang++, is_modulo is false for signed integer types, which
> makes the behavior of INT_MAX + 1 undefined.  I don't know whether
> there's an option that makes it true, or what other implementations do.

About g++ I remember that it was true. However it did
behave in non-conforming and inconsistent manner. There was
perhaps too lot of work to fix it so it was put to false under
every set of options at 2012. That Bugzilla issue was about it:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=22200
Feels hostile discussion like as people had had some long and
nauseous flame wars in lists. About more recent developments or
other compilers I don't also know.

> Yes, that does affect the issue.  The proposal would effectively require
> is_modulo to be true for signed types.
> 
> It would be nice to have a way for a programmer, not just an
> implementation, to decide whether a given signed type has wraparound or
> overflow semantics.  That's probably beyond the scope of this proposal.

Hmm ... some want it to be UB, some want it to trap, some want it to
have saturating NaN, some want it to wrap and some want to pick
depending on circumstances.
To please everybody is behind any scope I can imagine. ;)

[toc] | [prev] | [next] | [standalone]

#67246

> Specifying wrapping behavior for signed integers could be a *big*
> problem.  In particular, this:
>      int n = INT_MAX + 1;

That's not the least problem because no one writes such code.

[toc] | [prev] | [next] | [standalone]

#67331

On 31/07/2019 10:14, Bonita Montero wrote:
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0907r0.html
> 

I've done a little digging, and there are several revisions to that
paper.  The latest (AFAICS) is:

<http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0907r4.html>


One change in later revisions that is relevant to some parts of this
thread is:

"""
*Status-quo* If a signed operation would naturally produce a value that
is not within the range of the result type, the behavior is undefined.
The author had hoped to make this well-defined as wrapping (the
operations produce the same value bits as for the corresponding unsigned
type), but WG21 had strong resistance against this.
"""

It seems I am not the only one who thinks this way.

I think this revision will be a lot less controversial - it mostly
documents the way current compilers work on current hardware, and
simplifies the wording in the standard to match.



I found another related paper:

<http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p1236r1.html>

I think the two papers cover the same ideas, but with different wording.
 I don't know what will actually end up in C++20.

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | comp.lang.c++

csiph-web