'int' is enough for 'length' to migrate code from x86 to x64

Don via Digitalmars-d digitalmars-d at puremagic.com
Wed Nov 19 05:33:21 PST 2014


On Wednesday, 19 November 2014 at 11:43:38 UTC, John Colvin wrote:
> On Wednesday, 19 November 2014 at 11:04:05 UTC, Matthias 
> Bentrup wrote:
>> On Wednesday, 19 November 2014 at 10:03:35 UTC, Don wrote:
>>> On Tuesday, 18 November 2014 at 18:23:52 UTC, Marco Leise 
>>> wrote:
>>>> Am Tue, 18 Nov 2014 15:01:25 +0000
>>>> schrieb "Frank Like" <1150015857 at qq.com>:
>>>>
>>>>> > but now ,'int' is enough for use,not huge and not 
>>>>> > small,only enough.
>>>>> > 'int' is easy to write,and most people are used to it.
>>>>> > Most importantly easier to migrate code,if  'length''s 
>>>>> > return
>>>>> >value type is 'int'.
>>>>> 
>>>>> How about your idea?
>>>>
>>>> I get the idea of a broken record right now...
>>>> Clearly size_t (which I tend to alias with ℕ in my code for
>>>> brevity and coolness) can express more than 2^31-1 items, 
>>>> which
>>>> is appropriate to reflect the increase in usable memory per
>>>> application on 64-bit platforms. Yes, the 64-bit version of a
>>>> program or library can handle larger data sets. Just like it
>>>> was when people transitioned from 16-bit to 32-bit. I wont 
>>>> use
>>>> `int` just because the technically correct thing is `size_t`,
>>>> even it it is a little harder to type.
>>>
>>> This is difficult. Having arr.length return an unsigned type, 
>>> is a dreadful language mistake.
>>>
>>>> Aside from the size factor, I personally prefer unsigned 
>>>> types
>>>> for countable stuff like array lengths. Mixed arithmetics
>>>> decay to unsinged anyways and you don't need checks like
>>>> `assert(idx >= 0)`. It is a matter of taste though and others
>>>> prefer languages with no unsigned types at all.
>>>
>>>
>>> No! No! No!  This is completely wrong. Unsigned does not mean 
>>> "positive". It means "no sign", and therefore "wrapping 
>>> semantics".
>>> eg length - 4 > 0, if length is 2.
>>>
>>> Weird consequence: using subtraction with an unsigned type is 
>>> nearly always a bug.
>>>
>>> I wish D hadn't called unsigned integers 'uint'. They should 
>>> have been called '__uint' or something. They should look 
>>> ugly. You need a very, very good reason to use an unsigned 
>>> type.
>>>
>>> We have a builtin type that is deadly but seductive.
>>
>> int has wrapping the same semantics too, only it wraps to 
>> negative numbers instead of zero.

No. Signed types do not *wrap*. They *overflow* if their range is 
exceeded.
This is not the same thing. Overflow is always an error.
And the compiler could insert checks to detect this.

That's not possible for unsigned types. With an unsigned type, 
wrapping is part of the semantics.

Moreover, hitting an overflow with a signed type is an 
exceptional situation. Wrapping with an unsigned type is entirely 
normal, and happens with things like 2u - 1u.

>If you insist on
>> non-wrapping length, it should return double or long double.
>
> Which would be totally wrong for different reasons.
>
> Short of BigInts or overflow-checking, there is no perfect 
> option.
>
> An overflow-checked type that could be reasonably well 
> optimised would be nice, as mentioned by bearophile many times.

I don't think we need to worry about the pathological cases. The 
problem with unsigned size_t is that it introduces inappropriate 
semantics everywhere for the sake of the pathological cases.

IMHO the correct solution is to say that the length of a slice 
cannot exceed half of the memory space, otherwise a runtime error 
will occur. And then make size_t a positive integer.

Then let typeof(size_t - size_t) == int, instead of uint. All 
other operations stay as size_t.

Perhaps we can get most of the way, by improving range 
propagation.




More information about the Digitalmars-d mailing list