| Keith Thompson <kst-u@mib.org>: Jul 31 04:32PM -0700 > 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 */ |
| "Öö Tiib" <ootiib@hot.ee>: Jul 31 07:21PM -0700 On Thursday, 1 August 2019 02:32:14 UTC+3, Keith Thompson wrote: > 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. > 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. ;) |
| David Brown <david.brown@hesbynett.no>: Aug 01 11:25PM +0200 On 31/07/2019 23:22, Öö Tiib wrote: > assume that integer arithmetic does not overflow and it will be > tricky to indicate to compiler that it may do such optimizations > in conforming mode. Such optimisations won't be tricky - they will be completely impossible. > But so ... solution is same as with your #2. Of course. Any defined behaviour on overflow restricts optimisations. It's good to be able to choose what you want in different circumstances - if you want traps on overflow to aid debugging, you don't mind the cost in optimisations. > their compiler is not conforming. Quite popular is to let to turn > off exceptions, to turn off RTTI and so on. I do not think that turning > off wrapping signed integers will be different in any way. It will be a completely different thing. And I think that is so obvious it doesn't need more explanation. > I like that neither of those settings turns on. No non-conforming > modes are needed. So why should warning about potentially wrapping > integer suddenly cause different situation? It is conceivable that compilers will have warnings for overflows on signed arithmetic, even when it is fully defined - but I think it is unlikely except with a view to compatibility for current standards. Compilers don't warn when unsigned arithmetic overflows, because it is fully defined. The difference is that when someone writes, for example, "if (a = 1)", they have almost certainly made a mistake. So it is not unreasonable for compilers to warn about it (and not unreasonable that it requires a non-default flag to get the warning, since it is valid C or C++ code). But if and when signed integer overflow becomes fully defined with wrapping behaviour, it is no longer a mistake. How is the compiler supposed to guess what was intentional behaviour and what was likely to be a programmer error? >> give. Raising an error or saturating would be far more likely to be >> correct. > That option I would also love like I said above. That cannot be an option if wrapping is the defined behaviour. It is fine to have flags that add semantics to the language in place of undefined behaviour. It is not fine to have flags that give completely different semantics to something the language defines. This is not like enabling or disabling particular features, such as exceptions or RTTI (features which are typically only disabled for niche uses, such as resource limited embedded systems). >> carpet where they are harder to find. > It is frequently same with unsigned integers. On lot of cases when > these overflow then it is defect. Agreed. I would be happy for unsigned arithmetic to be undefined on overflow in most cases. However, there are occasional situations where wrapping behaviour is clearly useful and correct, so it is important that there is /some/ way to get it. If unsigned arithmetic were not defined with wrapping in C and C++, there would have to be another way to do it for these occasional uses. >> primarily for code safety and correctness reasons, and secondarily for >> performance reasons. > But you put performance reason as #1 in above list. ;) 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. |
| Jorgen Grahn <grahn+nntp@snipabacken.se>: Aug 01 01:19PM On Mon, 2019-07-22, Keith Thompson wrote: > I wouldn't be too sure that *everyone* would read 2019/04/07 the same way. > The international standard format, ISO 8601, is 2019-04-07 (April 7, 2019). > I strongly suggest using that if at all possible. Yes, please. As a non-US person, I have to stop and think about 2019/04/07, although I'll soon conclude it's unambiguous. ISO dates OTOH are immediately familiar to me. /Jorgen -- // Jorgen Grahn <grahn@ Oo o. . . \X/ snipabacken.se> O o . |
| scott@slp53.sl.home (Scott Lurndal): Aug 01 02:10PM >> I strongly suggest using that if at all possible. >Yes, please. As a non-US person, I have to stop and think about >2019/04/07, although I'll soon conclude it's unambiguous. Moreover, it's trivially sortable. |
| Daniel <danielaparker@gmail.com>: Jul 31 08:29PM -0700 On Wednesday, July 31, 2019 at 12:12:54 PM UTC-4, Bo Persson wrote: > The function itself is perhaps unlikely to throw any exceptions, but any > comparisons would use the Compare template parameter which is not > limited to noexcept operations. Thanks, Daniel |
| Jorgen Grahn <grahn+nntp@snipabacken.se>: Aug 01 05:44AM On Wed, 2019-07-31, Öö Tiib wrote: ... > Note that contains() is C++2020 map feature and C++2020 standard does > not exist yet. I don't even understand why to add it since it does > exactly same thing that std::map::count() already does. Probably to help us write more readable code: if (employees.count(someone)) fire(someone); if (employees.contains(someone)) fire(someone); The latter reads better IMO. On the other hand, I think in 90% of cases you want to find() the element so you can access it if it exists. /Jorgen -- // Jorgen Grahn <grahn@ Oo o. . . \X/ snipabacken.se> O o . |
| Fraser Ross <fraser.ross8ATbtinternet.com@com>: Aug 01 09:18AM +0100 On 01/08/2019 06:44, Jorgen Grahn wrote: > cases you want to find() the element so you can access it if it > exists. > /Jorgen contains can stop after finding an equivalent element in a multimap or multiset. Fraser. |
| "Öö Tiib" <ootiib@hot.ee>: Aug 01 03:04AM -0700 On Thursday, 1 August 2019 11:18:33 UTC+3, Fraser Ross wrote: > >> exactly same thing that std::map::count() already does. > > Probably to help us write more readable code: > > if (employees.count(someone)) fire(someone); Note that in actual code it can have non-confusing form like: if (employees.count(someone)!=0) fire(someone); > > /Jorgen > contains can stop after finding an equivalent element in a multimap or > multiset. Good catch! Even there it can have same issue that empty() versus size()!=0 had. The empty() is shorter and was cheaper for some containers but programmers kept massively using size()!=0 (and its equivalents) so committee had to require size() to be O(1) for all containers. It is hard to figure why human brain works like that but programming language has to support it to write efficient programs. |
| 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. |
No comments:
Post a Comment