Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c++ > #67368
| 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> |
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
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