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

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

Re: Constexpr evaluation of heavy stuff

Show all headers | View raw

On 20/05/2022 10:37, Juha Nieminen wrote:
> Malcolm McLean <malcolm.arthur.mclean@gmail.com> wrote:
>> The snag is that to use it, you have to be able to put the compiler into a
>> mode where it traps on overflow instead of silently wrapping. Most
>> compilers don't have such a mode.
> 
> I'm not entirely sure what the point of that would be. What exactly should
> happen in such a program if an unsigned arithmetic operation overflows or
> underflows? Should the program end? Should the code throw an exception?
> (What would you do if such an exception happens?) How should the program
> behave in such a situation?
> 

That's the big question in regard to overflow (signed or unsigned). 
/Sometimes/ you actually want wrapping behaviour, but it's rare.

Possible desirable behaviour include:

1. Halting the program with an error message.

2. Returning an error value or other special value (like a NaN or 
infinity in floating point).

3. Returning a default value.

4. Saturating.

5. Wrapping.

6. Logging the error in some way, and continuing (with the wrapped 
value, default, value, or whatever).

7. Setting errno and continuing.

8. Throwing a C++ exception.

9. Calling an error-handler function.

10. Returning an unspecified value.  (i.e., the result is a valid value 
of the type, but you have no idea what value it is).

11. Undefined behaviour, so the compiler can assume it won't happen if 
it aids optimisation.

12. Automatically growing the size of the types.


I'm sure there are more possibilities.  And you might want different 
behaviour for different types, or at different points in the code, or 
with different operations - such as having "x << 1" be defined as 
wrapping while "x * 2" be defined as trapping with an error message on 
overflow.

And then there is the question of how to combine this all with 
optimisation, re-arrangements, and intermediary calculations.


Usually, but not always, an overflow (signed or unsigned) is a bug in 
the code.  So having compiler tools that help catch that bug is useful 
during debugging and testing.  (And it doesn't matter whether "most 
compilers don't have such a mode" - it only matters that the compiler 
and tools you use during development have such a mode.)

Having options aimed at minimising the impact of run-time errors can be 
useful for deployed code - though the compiler needs guidance for how to 
do that.  (Halting with an error is perhaps the safest choice for a 
desktop program, avoiding the risk of security holes - but it's not a 
great choice for an aeroplane engine controller.)


I guess the only answer is to make your own C++ integer classes that 
have the overflow behaviour /you/ want in the code at the time.  The 
only thing you can be really sure of, is that there is /no/ single 
"correct" answer.


> Also, should bit-shifting to the left trap if a 1-bit gets shifted out?
> Ostensibly multiplying by a power of 2 should trap if it overflows.
> Should bit-shifting to the left also do so (given that it's effectively
> the exact same thing)?
> 
> Maybe it should behave like a few other programming languages which switch
> from hardware-register-sized integers to software multiprecision integers
> on any overflow? (But even then, what about underflow?)
> 
> If you want integers that grow as needed, just use GMP?

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

Thread

Constexpr evaluation of heavy stuff Andrey Tarasevich <andreytarasevich@hotmail.com> - 2022-05-18 16:17 -0700
  Re: Constexpr evaluation of heavy stuff "Alf P. Steinbach" <alf.p.steinbach@gmail.com> - 2022-05-19 09:19 +0200
    Re: Constexpr evaluation of heavy stuff David Brown <david.brown@hesbynett.no> - 2022-05-19 11:59 +0200
      Re: Constexpr evaluation of heavy stuff "Alf P. Steinbach" <alf.p.steinbach@gmail.com> - 2022-05-19 12:37 +0200
        Re: Constexpr evaluation of heavy stuff David Brown <david.brown@hesbynett.no> - 2022-05-19 14:49 +0200
          Re: Constexpr evaluation of heavy stuff Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2022-05-19 06:19 -0700
            Re: Constexpr evaluation of heavy stuff Paavo Helde <eesnimi@osa.pri.ee> - 2022-05-19 20:32 +0300
              Re: Constexpr evaluation of heavy stuff Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2022-05-20 01:12 -0700
                Re: Constexpr evaluation of heavy stuff Juha Nieminen <nospam@thanks.invalid> - 2022-05-20 08:37 +0000
                Re: Constexpr evaluation of heavy stuff Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2022-05-20 02:21 -0700
                Re: Constexpr evaluation of heavy stuff Ben <ben.usenet@bsb.me.uk> - 2022-05-20 11:25 +0100
                Re: Constexpr evaluation of heavy stuff David Brown <david.brown@hesbynett.no> - 2022-05-20 12:47 +0200
                Re: Constexpr evaluation of heavy stuff Ben <ben.usenet@bsb.me.uk> - 2022-05-20 12:13 +0100
                Re: Constexpr evaluation of heavy stuff David Brown <david.brown@hesbynett.no> - 2022-05-20 14:27 +0200
                Re: Constexpr evaluation of heavy stuff Öö Tiib <ootiib@hot.ee> - 2022-05-20 06:33 -0700
                Re: Constexpr evaluation of heavy stuff Paavo Helde <eesnimi@osa.pri.ee> - 2022-05-20 17:15 +0300
                Re: Constexpr evaluation of heavy stuff Christian Gollwitzer <auriocus@gmx.de> - 2022-05-20 18:57 +0200
                Re: Constexpr evaluation of heavy stuff Paavo Helde <eesnimi@osa.pri.ee> - 2022-05-20 22:31 +0300
                Re: Constexpr evaluation of heavy stuff Manfred <noname@add.invalid> - 2022-05-21 21:56 +0200
                Re: Constexpr evaluation of heavy stuff Öö Tiib <ootiib@hot.ee> - 2022-05-21 23:24 -0700
                Re: Constexpr evaluation of heavy stuff Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2022-05-22 04:56 -0700
                Re: Constexpr evaluation of heavy stuff Öö Tiib <ootiib@hot.ee> - 2022-05-22 06:15 -0700
                Re: Constexpr evaluation of heavy stuff Manfred <noname@add.invalid> - 2022-05-22 21:46 +0200
                Re: Constexpr evaluation of heavy stuff "Alf P. Steinbach" <alf.p.steinbach@gmail.com> - 2022-05-22 23:23 +0200
                Re: Constexpr evaluation of heavy stuff Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2022-05-22 16:26 -0700
                Re: Constexpr evaluation of heavy stuff Manfred <noname@add.invalid> - 2022-05-23 17:24 +0200
                Re: Constexpr evaluation of heavy stuff Richard Damon <Richard@Damon-Family.org> - 2022-05-23 19:41 -0400
                Re: Constexpr evaluation of heavy stuff scott@slp53.sl.home (Scott Lurndal) - 2022-05-24 16:15 +0000
                Re: Constexpr evaluation of heavy stuff Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-05-24 05:37 -0700
                Re: Constexpr evaluation of heavy stuff Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2022-05-20 04:19 -0700
                Re: Constexpr evaluation of heavy stuff Ben <ben.usenet@bsb.me.uk> - 2022-05-20 12:32 +0100
                Re: Constexpr evaluation of heavy stuff Juha Nieminen <nospam@thanks.invalid> - 2022-05-20 10:40 +0000
                Re: Constexpr evaluation of heavy stuff David Brown <david.brown@hesbynett.no> - 2022-05-20 12:31 +0200
                Re: Constexpr evaluation of heavy stuff Juha Nieminen <nospam@thanks.invalid> - 2022-05-20 10:43 +0000
                Re: Constexpr evaluation of heavy stuff David Brown <david.brown@hesbynett.no> - 2022-05-20 14:52 +0200
          Re: Constexpr evaluation of heavy stuff "Alf P. Steinbach" <alf.p.steinbach@gmail.com> - 2022-05-19 15:34 +0200
    Re: Constexpr evaluation of heavy stuff "Alf P. Steinbach" <alf.p.steinbach@gmail.com> - 2022-05-19 17:03 +0200
  Re: Constexpr evaluation of heavy stuff Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-05-19 08:53 -0700
    Re: Constexpr evaluation of heavy stuff Marcel Mueller <news.5.maazl@spamgourmet.org> - 2022-05-19 18:33 +0200

csiph-web