On Tuesday, 22 January 2013 at 16:31:20 UTC, Era Scarecrow wrote:
> I really wouldn't want to have to use BigInt for everything that can't overflow and then check to make sure I can fit it in my smaller variables afterwards along with the extra move. I wouldn't want to use BigInts everywhere, and long's aren't needed everywhere either.

Since D aims to emulate C in this aspect, overflow with uints is probably defined as a wrap-around (like C). In this case it seems to me the check for overflow would simply be '(a+b)<a', no need to cast to longs and BigInts and all that. Of course this may not apply to signed ints...

On Tuesday, 22 January 2013 at 17:10:35 UTC, Thiez wrote:
> On Tuesday, 22 January 2013 at 16:31:20 UTC, Era Scarecrow wrote:
>> I really wouldn't want to have to use BigInt for everything that can't overflow and then check to make sure I can fit it in my smaller variables afterwards along with the extra move. I wouldn't want to use BigInts everywhere, and long's aren't needed everywhere either.
>
> Since D aims to emulate C in this aspect, overflow with uints is probably defined as a wrap-around (like C). In this case it seems to me the check for overflow would simply be '(a+b)<a', no need to cast to longs and BigInts and all that. Of course this may not apply to signed ints...

 That merely shortens the size of the check, not where you need to place the checks or how often. Truthfully, in almost all cases the wrap-around or overflow/underflow is an error, usually unchecked. If 1 million were the max, then 1,000,000 + 1 should equal 1,000,001 and not <=0, and if 0 is the minimum, 0 - 1 should not equal >=0.

 The only real time I can find overflow wanted is while making something that watches for it explicitly to make use of it. Say we emulate or write the 'ucent' types. That could be done as:

  //addition example obviously
  void add(const uint[4] lhs, const uint[4] rhs) {
    uint[4] val;
    bool carry = false;
    foreach(i, ref v; val) {
      uint tmp = lhs[i];

      v = lhs[i] + rhs[i] + (carry ? 1 : 0);
      carry = v < tmp;
    }

    assert(!carry); //could fail. How to handle this? Ignore?
 }

 Now let's say there's a for loop which someone decides they would be clever and use a ubyte (unsigned char) as an index or counter.

 for(ubyte i = 0; i < 1000; i++) {
   writeln(i);
 }

 The overflow is an error because the wrong type was selected but doesn't change the obvious logic behind it. You can hide the type behind an alias or similar but that doesn't change the fact it's a bug, and can be easier to detect if we are aware the overflow is happening at all rather than it getting stuck and having to manually kill the process or step through it in a debugger. If it wasn't outputting in some way you could identify it's much harder to find.

 Encryption may make use of the overflow/wrap around, but far more likely they use xor or binary operations which don't have those problems.

On 1/22/2013 6:44 AM, Era Scarecrow wrote:
>   It's been quoted that for every 10 lines of code there's a bug.

I've been doing some refactoring in dmd now and then. Every time I do, the process exposes latent bugs. On the one hand, that's discouraging, on the other hand, I think it shows the value in refactoring into a better design.

On Tuesday, 22 January 2013 at 14:44:26 UTC, Era Scarecrow wrote:
>  It's been quoted that for every 10 lines of code there's a bug.

It is said a lot. I'd like to see hard data on that one. I'd bet that it greatly vary from one programmer to another, and probably from one language to another.

On Wed, Jan 23, 2013 at 5:56 AM, deadalnix <deadalnix@gmail.com> wrote:
> On Tuesday, 22 January 2013 at 14:44:26 UTC, Era Scarecrow wrote:
>>
>>  It's been quoted that for every 10 lines of code there's a bug.
>
>
> It is said a lot. I'd like to see hard data on that one. I'd bet that it greatly vary from one programmer to another, and probably from one language to another.

With D, we aim for one bug every 14 lines of code :)

On Wednesday, 23 January 2013 at 06:22:55 UTC, Philippe Sigaud wrote:
> On Wed, Jan 23, 2013 at 5:56 AM, deadalnix <deadalnix@gmail.com> wrote:
>> On Tuesday, 22 January 2013 at 14:44:26 UTC, Era Scarecrow
> With D, we aim for one bug every 14 lines of code :)

Add to that the fact that programs in D tend to be shorter than their C or even C++ equivalents!

On 2013-16-23 07:01, Philippe Sigaud <philippe.sigaud@gmail.com> wrote:

> On Wed, Jan 23, 2013 at 5:56 AM, deadalnix <deadalnix@gmail.com> wrote:
>> On Tuesday, 22 January 2013 at 14:44:26 UTC, Era Scarecrow wrote:
>>>
>>>  It's been quoted that for every 10 lines of code there's a bug.
>>
>>
>> It is said a lot. I'd like to see hard data on that one. I'd bet that it
>> greatly vary from one programmer to another, and probably from one language
>> to another.
>
> With D, we aim for one bug every 14 lines of code :)

Can do. Who wants to patch the compiler to automaically insert those bugs? :p

-- 
Simen

On Wednesday, 23 January 2013 at 07:33:22 UTC, eles wrote:
> On Wednesday, 23 January 2013 at 06:22:55 UTC, Philippe Sigaud wrote:
>> With D, we aim for one bug every 14 lines of code :)
>
> Add to that the fact that programs in D tend to be shorter than their C or even C++ equivalents!

 Less boiler plate code, fewer direct pointers, no preprocessor macros. Code that might have ambiguities based on order of priority force (or sternly warn) you to use parentheses for what you intend rather than a set of long complex rules. Templates easier to make and use (needing fewer of them). No header file(s) (and all the duplication or annoying separation that comes with it). Assignment in certain locations are illegal. Oh yes, no ugly STL, and a lot more.

 Plenty of stuff that simplifies a whole lot of stuff. D is indeed the language I always wanted :)

On Wednesday, 23 January 2013 at 07:57:38 UTC, Era Scarecrow wrote:
> On Wednesday, 23 January 2013 at 07:33:22 UTC, eles wrote:
>> On Wednesday, 23 January 2013 at 06:22:55 UTC, Philippe Sigaud wrote:
>  Plenty of stuff that simplifies a whole lot of stuff. D is indeed the language I always wanted :)

Sigh... Only if it would go into that gcc suite... faster.

On Wednesday, 23 January 2013 at 04:56:11 UTC, deadalnix wrote:
> On Tuesday, 22 January 2013 at 14:44:26 UTC, Era Scarecrow wrote:
>> It's been quoted that for every 10 lines of code there's a bug.
>
> It is said a lot. I'd like to see hard data on that one. I'd bet that it greatly vary from one programmer to another, and probably from one language to another.


It definitely does.

"There has been no error reported in TeX since 1994 or 1995"  -- Knuth, 2002.
There were 7 bugs in TeX reported between 1982 and 1995.
Tex has a lot more than 70 lines of code :-)