Greetings

The following code prints FFFF0000. Similar thing happens when a and b are
bytes.
Is this intended?

Regards
- Puneet

void main()
{
  import std.stdio;
  ushort a = 0x55AA;
  ushort b = 0xAA55;
  writefln("%X", ~(a | b));
}

On Tuesday, 11 December 2012 at 12:24:14 UTC, d coder wrote:
> Greetings
>
> The following code prints FFFF0000. Similar thing happens when a and b are
> bytes.
> Is this intended?
>
> Regards
> - Puneet
>
> void main()
> {
>   import std.stdio;
>   ushort a = 0x55AA;
>   ushort b = 0xAA55;
>   writefln("%X", ~(a | b));
> }

integer operations are always promoted to at least int. That's standard fare since C. I think it is a performance thing: Unpack into ints, oeprate, repack into ints.

D's stance regarding integer operations is "if it compiles, it creates the same output as in C".

It's kind of a gotcha, but not that big a deal.

On Tue, Dec 11, 2012 at 6:23 PM, monarch_dodra <monarchdodra@gmail.com>wrote:

> D's stance regarding integer operations is "if it compiles, it creates the same output as in C".
>

Thanks Monarch. So it is a gotcha we inherit from C. :-)

Regards
- Puneet

On 12/11/12 8:03 AM, d coder wrote:
>
>
> On Tue, Dec 11, 2012 at 6:23 PM, monarch_dodra <monarchdodra@gmail.com
> <mailto:monarchdodra@gmail.com>> wrote:
>
>     D's stance regarding integer operations is "if it compiles, it
>     creates the same output as in C".
>
>
> Thanks Monarch. So it is a gotcha we inherit from C. :-)

No, it's a fix of a gotcha from C. The C code would just allow the assignment.

Andrei

> No, it's a fix of a gotcha from C. The C code would just allow the assignment.


Yes Andrei.

But it does not look clean if you have to write:

byte a, b, c;
a = cast(byte) (b + c);

Well I know the advantages (safety). But imagine having to write all that when working with bytes and shorts. Makes it really difficult to work with shorts and bytes in D. Would I be asking for too much if I ask DMD to provide a compiler flag that makes it return bytes and shorts for operations on them? So the deal would be, if you use this compiler flag, code behavior would be different from that of C/C++.

What we get would be more practical short and byte behavior.

Regards
- Puneet

On Tuesday, 11 December 2012 at 13:24:59 UTC, d coder wrote:

> But it does not look clean if you have to write:
>
> byte a, b, c;
> a = cast(byte) (b + c);

That's the whole point. What you are doing is dangerous, so it requires the cast.

Adding a compiler flag to change the semantics of the language sounds like a recipe for disaster.

On Tue, Dec 11, 2012 at 7:05 PM, Peter Alexander < peter.alexander.au@gmail.com> wrote:

> That's the whole point. What you are doing is dangerous, so it requires the cast.
>


What I am doing is not dangerous. I am operating at byte/short level. Tell me, if what I am doing is dangerous, how come doing the following is not dangerous. It is allowed by D.

int a, b, c;
a = b + c;

Also the sense of safety that you get for short and byte too is not complete. Consider:

void main() {
  import std.stdio;
  ushort a = ushort.max;
  ushort b = ushort.max;
  a += b;
  writeln(a);
}


Is it too much to ask for consistent behavior across the built-in types?

Regards
- Puneet

d coder:

> Tell me, if what I am doing is dangerous, how come doing the following is not dangerous. It is allowed by D.
>
> int a, b, c;
> a = b + c;

I think this dis-uniformity was added because:
- Statistically it's more common to have an overflow when you sum two bytes compared to summing two ints.
- If the sum of two ints/uints requires a cast, you need to fill your code with casts. And casts are not safe at all, they are sharp powertools.

(I have asked many times for runtime integral overflows in D (as in C#/Delphi), that can be disabled with a compilation switch. But D designers come from the great unsafety of C-like languages and do not agree with me on the dangers/bugs of fixnum operations).

Bye,
bearophile

On Tuesday, 11 December 2012 at 13:24:59 UTC, d coder wrote:
>> No, it's a fix of a gotcha from C. The C code would just allow the
>> assignment.
>
>
> Yes Andrei.
>
> But it does not look clean if you have to write:
>
> byte a, b, c;
> a = cast(byte) (b + c);
>
> Well I know the advantages (safety). But imagine having to write all that
> when working with bytes and shorts. Makes it really difficult to work with
> shorts and bytes in D. Would I be asking for too much if I ask DMD to
> provide a compiler flag that makes it return bytes and shorts for
> operations on them? So the deal would be, if you use this compiler flag,
> code behavior would be different from that of C/C++.
>
> What we get would be more practical short and byte behavior.
>
> Regards
> - Puneet

If the compiler can statically verify that some integer value fits in a byte or short, you don't need the cast. So to rewrite your example:

byte a, b, c;
a = (b + c) & 0xFF;

Also:
short a;
byte b, c;
a = b + c;

Still not exactly what you're looking for, but the mask looks nicer than a cast IMO. It's also safer.

On 12/11/12 8:24 AM, d coder wrote:
>
>     No, it's a fix of a gotcha from C. The C code would just allow the
>     assignment.
>
>
> Yes Andrei.
>
> But it does not look clean if you have to write:
>
> byte a, b, c;
> a = cast(byte) (b + c);
>
> Well I know the advantages (safety). But imagine having to write all
> that when working with bytes and shorts. Makes it really difficult to
> work with shorts and bytes in D.

Value range propagation automatically avoids the need for a lot of those casts. http://www.drdobbs.com/tools/value-range-propagation/229300211

> Would I be asking for too much if I ask
> DMD to provide a compiler flag that makes it return bytes and shorts for
> operations on them?

That won't happen.


Andrei