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


Groups > comp.lang.c++ > #67368

Re: In the end, rason will come

From Manfred <noname@add.invalid>
Newsgroups comp.lang.c++
Subject Re: In the end, rason will come
Date 2019-08-07 16:05 +0200
Organization Aioe.org NNTP Server
Message-ID <qielrn$1nkt$1@gioia.aioe.org> (permalink)
References (4 earlier) <qhvld8$d5a$1@dont-email.me> <8b28fb67-d7d6-4b17-a65b-7c020d5e5aa8@googlegroups.com> <qi20dn$9g$1@dont-email.me> <a98bf6e0-96b8-4191-ba17-2d035b30ab0c@googlegroups.com> <qibs1f$j0c$1@dont-email.me>

Show all headers | View raw


Premise: I agree with you on most of your arguments about overflow.

I also note that the authors do explicitly define wrapping for signed 
integers (section 2, [basic.fundamental]), but also explicitly leave out 
of scope (section 3) /compiler/ behaviour with wrapping on signed 
integers, which makes the proposal inherently flawed, I believe.
It sounds like they know there is a problem with the matter, yet they 
want signed integer wrapping as defined behaviour, but do not want to 
address the consequences of this decision.


On 8/6/2019 2:32 PM, David Brown wrote:
> A big issue I have with the whole concept is that currently we have
> /types/  for which overflow is defined (unsigned types) and types for
> which it is not defined.  But overflow behaviour should be part of the
> operations, not the types.

Here I tend to disagree, or at least I am fine with the behaviour being 
attached to the types.
You are probably recalling that in ASM overflow is part of the 
instruction, but I think this is because the ASM type system is 
obviously much more rudimentary than in higher level languages.
Programming languages are meant to translate human logic into machine 
instructions, and we are used to operations that behave differently 
depending on the type they are performed on - see e.g. addition on real 
and complex numbers.
 From this perspective, in binary arithmetic it does make sense that 
addition behaves differently for signed and unsigned integers.
On the other hand, having some sort of "+" and "ǂ" would complicate the 
syntax, and be overly redundant too: you would have to specify the 
behavior of non-wrapping addition on unsigned integers, and wrapping 
addition on signed integers as well - this would bring more confusion 
than help, IMHO.

Back to comp.lang.c++ | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread


Thread

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

csiph-web