View mode: basic / threaded / horizontal-split · Log in · Help
December 11, 2012
Re: Is there any reason why arithmetic operation on shorts and bytes return int?
Thanks Everybody for responding. I have another query which is off-topic
but related.

Why is the following allowed in D?

long a;
int b;

b += a; // Allowed -- no explicit cast
b = a + b; // Not allowed
b = a;      // Not allowed
December 11, 2012
Re: Is there any reason why arithmetic operation on shorts and bytes return int?
d coder:

> Why is the following allowed in D?
>
> long a;
> int b;
>
> b += a; // Allowed -- no explicit cast
> b = a + b; // Not allowed
> b = a;      // Not allowed

Seems a bug of range analysis.

Bye,
bearophile
December 11, 2012
Re: Is there any reason why arithmetic operation on shorts and bytes return int?
On 12/11/12 11:36 AM, d coder wrote:
> Thanks Everybody for responding. I have another query which is off-topic
> but related.
>
> Why is the following allowed in D?
>
> long a;
> int b;
>
> b += a; // Allowed -- no explicit cast

RMW operations are allowed without a cast.

Andrei
December 11, 2012
Re: Is there any reason why arithmetic operation on shorts and bytes return int?
On 12/11/2012 5:24 AM, d coder wrote:
> 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++.

Having compiler flags that fundamentally change the behavior of the language are 
a disaster from about every point of view.
December 11, 2012
Re: Is there any reason why arithmetic operation on shorts and bytes return int?
On Tue, 11 Dec 2012 09:47:33 -0800
Walter Bright <newshound2@digitalmars.com> wrote:

> On 12/11/2012 5:24 AM, d coder wrote:
> > 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++.
> 
> Having compiler flags that fundamentally change the behavior of the
> language are a disaster from about every point of view.
> 

Yea, I'd hate to see D turn into PHP. That's one of the biggest
reasons I despise PHP - code can't rely on fucking *anything* in it to
ever work in any particular way. Pick any random line of PHP code,
and there's about 20 different things it might do, even on the exact
same version of PHP, all depending on a billion different configuration
settings. Any library written in PHP is *inherently* broken simply by
being one codebase intending to be "usable" on different servers.

Let's not entertain any thoughts of allowing D to venture down that
path.
December 11, 2012
Re: Is there any reason why arithmetic operation on shorts and bytes return int?
On Tuesday, 11 December 2012 at 16:09:14 UTC, Andrei Alexandrescu 
wrote:
> 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

But than we have a bug in the value range propagation algorithm.
E.g in the original program:
void main()
{
 import std.stdio;
 ushort a = 0x55AA;
 ushort b = 0xAA55;
 writefln("%X", ~(a | b));
}

(a | b) will be in the range of ushort values and ~ of that also 
remains in the same value range. In other words, it makes no 
sense that boolean ops (and, or, xor, 1's compliment, 2's 
compliment) will require type promotion as they cannot exceed the 
original width of the values. This is unlike arithmetic which can 
require promotion.
December 11, 2012
Re: Is there any reason why arithmetic operation on shorts and bytes return int?
On 12/11/2012 10:12 AM, Nick Sabalausky wrote:
> Let's not entertain any thoughts of allowing D to venture down that
> path.

No worries there :-) I feel pretty dang strongly about this issue, from bad 
experience.

Even if a language behaves "wrong", it is still usable if it is predictable.
December 11, 2012
Re: Is there any reason why arithmetic operation on shorts and bytes return int?
On Tuesday, 11 December 2012 at 14:02:52 UTC, d coder wrote:
> 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

What if you create a new type that creates the proper 
functionality and does the implicit casting and such? This would 
hide away the details but maybe at a cost of efficiency.

e.g.,

struct bbyte {
byte value;
...
}

bbyte a; bbyte b;

b = a + b; // uses bbyte's operators and casts to do the 
computation and assignment but then returns a bbyte instead of an 
int.

You should have no problems implicitly converting bbyte to built 
in types or built in types to bbyte.
December 12, 2012
Re: Is there any reason why arithmetic operation on shorts and bytes return int?
On Wed, Dec 12, 2012 at 3:40 AM, Walter Bright
<newshound2@digitalmars.com>wrote:

> No worries there :-) I feel pretty dang strongly about this issue, from
> bad experience.
>
> Even if a language behaves "wrong", it is still usable if it is
> predictable.
>

Agreed.

How about this.

1. Let "char" and "short" behave the C/C++ way. These can return integers.
This will make C/C++ code work in D.
2. Make D "byte" operations return bytes. And create another type (named
say dbyte or shortint) and make operations on the new type return
shortints. This will make these types more usable in D code. Well we end up
adding another keyword, but we shall get workable and safe 8-bit and 16-bit
integrals.

Regards
- Puneet
December 12, 2012
Re: Is there any reason why arithmetic operation on shorts and bytes return int?
On Wednesday, 12 December 2012 at 03:10:15 UTC, d coder wrote:
> On Wed, Dec 12, 2012 at 3:40 AM, Walter Bright
> <newshound2@digitalmars.com>wrote:
>
>> No worries there :-) I feel pretty dang strongly about this 
>> issue, from
>> bad experience.
>>
>> Even if a language behaves "wrong", it is still usable if it is
>> predictable.
>>
>
> Agreed.
>
> How about this.
>
> 1. Let "char" and "short" behave the C/C++ way. These can 
> return integers.
> This will make C/C++ code work in D.
> 2. Make D "byte" operations return bytes. And create another 
> type (named
> say dbyte or shortint) and make operations on the new type 
> return
> shortints. This will make these types more usable in D code. 
> Well we end up
> adding another keyword, but we shall get workable and safe 
> 8-bit and 16-bit
> integrals.
>
> Regards
> - Puneet

What's now is safer than what you propose. You can always create 
your own data type that would automatically truncate result if 
you wish so.
1 2 3 4
Top | Discussion index | About this forum | D home