I know this is a more general questions as it applies to C and C++ as well, but somewhere I have to ask and actually D is what Im coding in:

Should one try to use uint in favor of int whenever one knows for sure the value
wont be negative? That whould be a bit more expressive but on the other hand
sometimes leads to type problems.
For example, when having things like this:

T min(T)(T a, T b) {
  return a < b ? a : b;
}

Here you whould need to ensure to cast values so they share a common type.

How do you code? Do you use uint whenever it suitable reflects the data to store (eg a x-y-position on the screen) or only when necessary?

TIA for your tips,
Henning

Henning Hasemann a écrit :
> I know this is a more general questions as it applies to C and C++ as well,
> but somewhere I have to ask and actually D is what Im coding in:
> 
> Should one try to use uint in favor of int whenever one knows for sure the value
> wont be negative? That whould be a bit more expressive but on the other hand
> sometimes leads to type problems.
> For example, when having things like this:
> 
> T min(T)(T a, T b) {
>   return a < b ? a : b;
> }
> 
> Here you whould need to ensure to cast values so they share a common type.
> 
> How do you code? Do you use uint whenever it suitable reflects the data to
> store (eg a x-y-position on the screen) or only when necessary?

I don't know the generic answer, but for an x-y position, using unsigned would be a bad idea: if you had a rectangle only partially visible on the screen for example, you wouldn't be able to represent it.

Regards,
renoX


> 
> TIA for your tips,
> Henning

I always use unsigned variables when their values don't go below 0. I also always use the smallest variable possible.

More often than not, I use "ubyte" instead of "int" in "for" loops. Signed variables use the most significant bit to represent sign. I don't know if there's any performance gain (even if marginal) when using mathematical operations on unsigned variables.

About conditions, you can always force a variable to be unsigned by masking away it's most significant bit:

short var2;
(...)
unsigned=var2 && 0x3FFF; (0x3FFF is hexadecimal for 0111_1111_1111_1111)

but it would be simpler just to use "abs()" function to obtain the absolute value.

orgoton wrote:
> I always use unsigned variables when their values don't go below 0. I also always use the smallest variable possible.
> 
> More often than not, I use "ubyte" instead of "int" in "for" loops. Signed variables use the most significant bit to represent sign. I don't know if there's any performance gain (even if marginal) when using mathematical operations on unsigned variables.

Using the smallest variable type possible doesn't gain you anything. It's common to use int in most cases, or size_t for indices.  Smaller types are generally used to save space for strings, structs that you have large arrays of, etc.

int and other 32-bit types are generally the fastest type for a 32-bit cpu to work with.  Except when copying arrays of data around, that's when it can be faster to use smaller types. Not for individual variables.

> About conditions, you can always force a variable to be unsigned by masking away it's most significant bit:
> 
> short var2;
> (...)
> unsigned=var2 && 0x3FFF; (0x3FFF is hexadecimal for 0111_1111_1111_1111)
>

I think this is what you mean:
ushort var3 = var2 & 0x7FFF;

But this doesn't make the variable unsigned.  Signed or unsigned is not a quality of the value, it's a matter of how a value is interpreted and treated by the compiler/cpu/library.

Look at this:

uint x = -1;

If you print x, you will se that it's 4294967295, since -1 is 0xFFFFFFFF.

Henning Hasemann wrote:
> I know this is a more general questions as it applies to C and C++ as well,
> but somewhere I have to ask and actually D is what Im coding in:
> 
> Should one try to use uint in favor of int whenever one knows for sure the value
> wont be negative? That whould be a bit more expressive but on the other hand
> sometimes leads to type problems.
> For example, when having things like this:
> 
> T min(T)(T a, T b) {
>   return a < b ? a : b;
> }
> 
> Here you whould need to ensure to cast values so they share a common type.
> 
> How do you code? Do you use uint whenever it suitable reflects the data to
> store (eg a x-y-position on the screen) or only when necessary?

Current D botches quite a few of the arithmetic conversions. Basically all conversions that may lose value, meaning, or precision should not be allowed implicitly. Walter is willing to fix D in accordance to that rule, which would yield an implicit conversion graph as shown in:

http://erdani.org/d-implicit-conversions.pdf

Notice that there is no arrow e.g. between int and uint (loss of meaning), or between int and float (loss of precision). But there is an arrow from int and uint to double, because double is able to represent them faithfully.

If we are nice, we may convince Walter to implement that soon (maybe in 1.006?) but it must be understood that the tighter rules will prompt changes in existing code.

To answer your question, with the new rules in hand, using unsigned types will considerably increase your expressiveness and your ability to detect bugs statically. Also, by the new rules ordering comparisons between mixed-sign types will be disallowed.


Andrei

On Wed, 07 Feb 2007 15:29:22 -0800, Andrei Alexandrescu (See Website For
Email) wrote:

> Current D botches quite a few of the arithmetic conversions. Basically all conversions that may lose value, meaning, or precision should not be allowed implicitly.

Yes, please! This has been a wart for far too long.

Can we please slow down featuritis and return to cleaning up the product as a priority.

-- 
Derek
(skype: derek.j.parnell)
Melbourne, Australia
"Down with mediocrity!"
8/02/2007 10:38:39 AM

Andrei Alexandrescu (See Website For Email) wrote:

> Current D botches quite a few of the arithmetic conversions. Basically all conversions that may lose value, meaning, or precision should not be allowed implicitly. Walter is willing to fix D in accordance to that rule, which would yield an implicit conversion graph as shown in:
> 
> http://erdani.org/d-implicit-conversions.pdf
> 

I notice the graph doesn't include complex types.
Is there any reason why float shouldn't be automatically converted to cfloat?

--bb

On Thu, 08 Feb 2007 08:59:56 +0900, Bill Baxter wrote:

> Andrei Alexandrescu (See Website For Email) wrote:
>> http://erdani.org/d-implicit-conversions.pdf

What is the justification for character types to be implicitly converted to integer types? For the same reason that arithmetic with booleans is meaningless, so is such operations on characters.

  int x = 'a' + 'z'; // Is meaningless.
  int y = cast(int)'a' + cast(int)'z'; // Is now purposeful.

-- 
Derek
(skype: derek.j.parnell)
Melbourne, Australia
"Justice for David Hicks!"
8/02/2007 11:09:42 AM

Bill Baxter wrote:
> Andrei Alexandrescu (See Website For Email) wrote:
> 
>> Current D botches quite a few of the arithmetic conversions. Basically all conversions that may lose value, meaning, or precision should not be allowed implicitly. Walter is willing to fix D in accordance to that rule, which would yield an implicit conversion graph as shown in:
>>
>> http://erdani.org/d-implicit-conversions.pdf
>>
> 
> I notice the graph doesn't include complex types.
> Is there any reason why float shouldn't be automatically converted to cfloat?

Sharp eyes :o). I was simply too lazy to include complex types. Probably real-to-complex conversion should be allowed implicitly, too, as long as the basic principle of preserving value is respected.

Andrei

Derek Parnell wrote:
> On Thu, 08 Feb 2007 08:59:56 +0900, Bill Baxter wrote:
> 
>> Andrei Alexandrescu (See Website For Email) wrote:
>>> http://erdani.org/d-implicit-conversions.pdf
> 
> What is the justification for character types to be implicitly converted to
> integer types? For the same reason that arithmetic with booleans is
> meaningless, so is such operations on characters. 
> 
>   int x = 'a' + 'z'; // Is meaningless.
>   int y = cast(int)'a' + cast(int)'z'; // Is now purposeful.

I agree. Those conversions are in there mostly for historical reasons.

Andrei