Re: mixed-sign arithmetic and auto
James Dennett wrote:
Andrei Alexandrescu (See Website For Email) wrote:
James Dennett wrote:
Walter Bright wrote:
James Dennett wrote:
Walter Bright wrote:
Jerry Coffin wrote:
A design like you're advocating
that makes it easy for a bug to exist for years before it's even
noticed
almost inevitably _increases_ engineering costs by a huge margin.
You're the first I've ever heard claim that undefined behavior
reduces
bugs, even by a "huge margin". I think it's an extraordinary claim.
It's likely true.
Sorry, I'm not buying it. How many bugs have you found in your code
that
were exposed by UB that would still have been bugs without UB?
Hundreds, at a guess. Bugs that have been hidden when porting
between similar compilers/platforms but were exposed by others.
If the defined behavior had been that of the common platforms,
the bugs would have stayed hidden. Running tests across a wide
variety of platforms has brought to light many, many latent bugs.
As you yourself acknowledge, no test suite for a complex system
is complete; running it in different configurations across
platforms which have different behaviours helps to fill in some
of the gaps.
Sorry, I'm not buying it either.
I'll sell harder.
This is circular logic as it only works
for a self-serving definition of a bug ("forgetting to code around an UB
properly").
No it's not, as no, it doesn't :)
Unless you use useless definitions, and I prefer not to do so.
Defined integral sizes and wraparound behaviour can mask bugs.
Those bugs aren't just there because you need to "code around
an UB" -- they're there because you need to code so that your
code works, and respect limitations of finite arithmetic.
I agree with that, and also with the fact that a bad defined behavior
can be worse than a usually-reasonable UB/IDB.
The takeaway I got from this thread is actually the centuries-old adage:
"when you need multiple behaviors, encode them as distinct types". Bad
as it is, wraparound is fastest on most machines so I guess it should be
the default choice. That's a compromise for the sake of the real world
and I'm comfortable with it. Then the standard library should provide
distinct types for no-overflow integrals (with exception throwing) and
for integrals with saturation semantics.
On some machines some types will be faster, but on all machines, the
behavior of all types will be identical. Then it's easy to provide a
special typedef du jour, "fast-int-with-unspecified-overflow-behavior".
People who want speed and don't care for overflow can choose to use
that. I guess that's a sensible route for a less stable language such as
D to take.
Andrei
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]