Am 05.12.2011 19:04, schrieb Manu:
>     Manu:
>
>      > Also, contrary to his claim, I find that wrapping is usually what I
>      > DO want in this case..
>      > It's super rare that I write any code that pushes the limits of
>     an int
>      > (unless we're talking 8-16 bit, see my range+saturation comment
>     before),
>      > and when I do write code that pushes the range of an int, I can't
>     think of
>      > a time when I've not wanted to wrap as expected.
>
>     The code you usually write seems rather unusual. I have kind of the
>     opposite situations.
>
>     But first of all, "trapping" ints are needed to avoid bugs in normal
>     code. Some bugs are shown here:
>     http://embed.cs.utah.edu/ioc/
>
>
> I write C/C++ systems/embedded/games code (not a small industry by any
> measure), and I'm looking to D as a successor.. I'm NOT interested in D
> as a replacement for C# (or Java/etc), those languages already exist,
> are well supported, and I'm happy with them for their purpose. I realise
> I seem to be one of the odd ones out on this forum currently, hence I
> like to throw my 2c in from time to time :) .. but I don't believe I'm
> alone.. the rest of the gamedev community will find D soon enough if the
> language gets it right...


Here in Europe the trend seems to be actually moving away to Java/C#, mostly C# actually, leaving C and C++ to the game engine core.

On 05-12-2011 20:34, Paulo Pinto wrote:
> Am 05.12.2011 19:04, schrieb Manu:
>> Manu:
>>
>> > Also, contrary to his claim, I find that wrapping is usually what I
>> > DO want in this case..
>> > It's super rare that I write any code that pushes the limits of
>> an int
>> > (unless we're talking 8-16 bit, see my range+saturation comment
>> before),
>> > and when I do write code that pushes the range of an int, I can't
>> think of
>> > a time when I've not wanted to wrap as expected.
>>
>> The code you usually write seems rather unusual. I have kind of the
>> opposite situations.
>>
>> But first of all, "trapping" ints are needed to avoid bugs in normal
>> code. Some bugs are shown here:
>> http://embed.cs.utah.edu/ioc/
>>
>>
>> I write C/C++ systems/embedded/games code (not a small industry by any
>> measure), and I'm looking to D as a successor.. I'm NOT interested in D
>> as a replacement for C# (or Java/etc), those languages already exist,
>> are well supported, and I'm happy with them for their purpose. I realise
>> I seem to be one of the odd ones out on this forum currently, hence I
>> like to throw my 2c in from time to time :) .. but I don't believe I'm
>> alone.. the rest of the gamedev community will find D soon enough if the
>> language gets it right...
>
>
> Here in Europe the trend seems to be actually moving away to Java/C#,
> mostly C# actually, leaving C and C++ to the game engine core.

Some people even write the games *in C#*. It's starting to become more and more practical with efficient GCs and various advancements in JIT/VM technology (for instance, Mono has an LLVM back end and VM-supported continuations).

- Alex

On 05.12.2011 18:36, bearophile wrote:
> Manu:
>
>> Also, contrary to his claim, I find that wrapping is usually what I
>> DO want in this case..
>> It's super rare that I write any code that pushes the limits of an int
>> (unless we're talking 8-16 bit, see my range+saturation comment before),
>> and when I do write code that pushes the range of an int, I can't think of
>> a time when I've not wanted to wrap as expected.
>
> The code you usually write seems rather unusual. I have kind of the opposite situations.
>
> But first of all, "trapping" ints are needed to avoid bugs in normal code. Some bugs are shown here:
> http://embed.cs.utah.edu/ioc/

Those mostly aren't relevant for D. C has many cases of undefined behaviour because it doesn't require twos-complement arithmetic. D doesn't have that problem.
We still need to tidy up the semantics of << and >> to remove undefined behaviour. But it's hard to do much more than that.

The "overflow12.pdf" paper on that site shows statistics that overflow is very often intentional. It's strong evidence that you *cannot* make signed overflow an error. Even if you could do it with zero complexity and zero performance impact, it would be wrong.

Don:

> The "overflow12.pdf" paper on that site shows statistics that overflow is very often intentional.

In C/C++ code, but we are developing D, a new language that hopes to fix some of the mistakes of languages invented lot of time ago.


> It's strong evidence that you *cannot* make signed overflow an error.

In C/C++ code, maybe, yet they suggest to invent better tools to find overflow in C/C++ programs too.

In better/modern languages signed overflow is correct only in the precise points where it is required. The overflow (for signed) or wraparound (for unsigned) has not to be the default behaviour, because it's crappy and often leads to bugs.


>  Even if you could do it with zero complexity
> and zero performance impact, it would be wrong.

In C/C++, maybe. But not in D/Ada/Delphi/Haskell/etc.

Bye,
bearophile

Don:

> The "overflow12.pdf" paper on that site shows statistics that overflow is very often intentional.

This is expected, the C/C++ programmers are using the semantics of their language. But it's just because they are using a language with a bad integer semantics.
A better designed language gives you a way to tell the compiler where you want overflow (or the default behaviour of the ALU you are using), where you want wraparound, and where you want some overflow errors. I have seen enough overflow-related bugs in supposed higher-quality C code written by experts.

Bye,
bearophile

On 12/5/2011 1:37 PM, Don wrote:
> The "overflow12.pdf" paper on that site shows statistics that overflow is very
> often intentional. It's strong evidence that you *cannot* make signed overflow
> an error. Even if you could do it with zero complexity and zero performance
> impact, it would be wrong.

Here's an email from Andy Koenig from the C++ mailing list that I think is very relevant (there are a lot of very experienced people on that list, lots of mistakes we can avoid by listening to them):
-----------------------------------------
Subject: [c++std-ext-11967] Re: Two's-Complement Arithmetic
From: "Andrew Koenig" <ark@acm.org>
To: <c++std-ext@accu.org>
Date: Mon, 5 Dec 2011 22:08:29 -0500

>> With respect to overflow, I wonder how many of these issues would
>> not be better addressed with a Scheme-like bignum type that is cheap
>> for (31- or) 63-bit integers, and involves memory allocation only on
>> overflow.

> +1, would love to have had this years ago.

Sounds a little like Python 3 integers.

And while I'm thinking about Python 3 arithmetic, there's something else in
Python 3
That I'd love to have in C++, namely a guarantee that:

1) Converting a string to a floating-point number, whether through
input
at run time or writing a floating-point literal as part of a
program,
always yields the correctly rounded closest floating-point value to
the infinite-precision value of the literal.

2) Converting a floating-point number to a string without a
specified
number of significant digits yields the string with the smallest
number of
significant digits that, when converted back to floating point
according
to (1), yields exactly the same value as the one we are converting.

Techniques for solving these problems were published more than 20 years ago,
so it's hard to argue against them on the basis of novelty.  Moreover, these
rules
would have some nice properties, among them:

Printing a floating-point number without specifying accuracy and
reading
it back again into a variable with the same precision gives you the
same value.

Printing a floating-point literal with default precision gives you
the same value as the literal unless the literal has too many
significant digits to represent accurately.

References here:

http://www.cs.washington.edu/education/courses/cse590p/590k_02au/print-fp.pdf
http://www.cs.washington.edu/education/courses/cse590p/590k_02au/read-fp.pdf

Walter:

> there's something else in Python 3
> That I'd love to have in C++, namely a guarantee that:

This is not about integers but yeah, I'd like the better str <-> float conversions of Python in D too.

Bye,
bearophile

On 12/05/2011 05:31 AM, bearophile wrote:
> Found through Reddit, two blog posts about how integers should behave in system languages (with hardware support):
>
> http://blog.regehr.org/archives/641
> http://blog.regehr.org/archives/642

I've been following that guy for a while now. He's doing some REALLY nifty work with regards to automating processing regarding bugs.

>
> Bye,
> bearophile

On 12/5/2011 8:10 PM, bearophile wrote:
> This is not about integers but yeah, I'd like the better str<->  float conversions of Python in D too.

Do you have any test data that they actually are better in Python (apart from just being better specified)?

On 12/05/2011 08:37 AM, Don wrote:
> On 05.12.2011 14:31, bearophile wrote:
>> Found through Reddit, two blog posts about how integers should behave
>> in system languages (with hardware support):
>>
>> http://blog.regehr.org/archives/641
>> http://blog.regehr.org/archives/642
>>
>> Bye,
>> bearophile
>
> Not very convincing, since he proposes a change to existing
> architectures, and seems completely unaware of the overflow flag.

I think he's looking at it form the language theory standpoint. As such, architectures has nothing to do with it (the architectures to be targeted has yet to be defined at that point) and getting access to the overflow flag would require exposing it natively in the language.

> If you can change existing architectures, why not simply allow an
> exception to be generated if an overflow occurs?
>
> Doesn't seem at all helpful to D.