I assume I'm in the minority here, but I don't see a need for such a
function.
Andrei
On 2/17/11 1:40 PM, David Simcha wrote:
Fair points. You've convinced me (since I didn't have a very strong
opinion before). Let's go with int. I've also come to believe that
ilength is the best name because it's negligible extra typing compared
to .length, so people will actually use it. Proposed function for
inclusion in object:
/**
Returns the length of an array as a 32-bit signed integer. Verifies
with an assert that arr.length <= int.max unless this can be proven
at compile time. This is a useful shortcut for getting the
length of a arrays that cannot plausibly have length longer than
int.max (about 2 billion) as a 32-bit integer even if building
for a 64-bit target. It's also useful for converting an array length
to a signed integer while verifying the safety of this
conversion if asserts are enabled.
*/
@property int ilength(T)(const T[] arr) pure nothrow @safe {
static if(size_t.sizeof > uint.sizeof || T.sizeof == 1) {
assert(arr.length <= int.max,
"Cannot get integer length of array with >int.max elements."
);
}
return cast(int) arr.length;
}
On Thu, Feb 17, 2011 at 2:24 PM, Don Clugston <[email protected]
<mailto:[email protected]>> wrote:
On 17 February 2011 17:10, David Simcha <[email protected]
<mailto:[email protected]>> wrote:
> Can you elaborate on why? Unsigned seems like the perfect type
for an array
> length.
An array length is a positive integer, you want to treat it as an
integer, not as a bag of bits.
Using an unsigned types is like using a cast, to be avoided whenever
possible. They're a breeding ground for bugs,
and a disturbingly large fraction of programmers don't understand them.
On 17 February 2011 18:02, David Simcha <[email protected]
<mailto:[email protected]>> wrote:
> My main gripe with going with int is that it eliminates the
possibility of
> making ilength() a noop that just returns .length on 32. The
assert would
> still be necessary.
But the assert adds value.
Note that an assert is only required on arrays of size 1 -- ubyte,
byte, char.
On everything else, it's still a no-op.
> On Thu, Feb 17, 2011 at 9:48 AM, Don Clugston
<[email protected] <mailto:[email protected]>>
> wrote:
>>
>> On 17 February 2011 14:59, David Simcha <[email protected]
<mailto:[email protected]>> wrote:
>> > Hey guys,
>> >
>> > Kagamin just came up with a simple but great idea to mitigate the
>> > pedantic
>> > nature of 64-bit to 32-bit integer conversions in cases where
using
>> > size_t
>> > doesn't cut it. Examples are storing arrays of indices into other
>> > arrays,
>> > where using size_t would be a colossal waste of space if it's
safe to
>> > assume
>> > none of the arrays will be billions of elements long.
>> > int or uint? I used int only b/c that was the example on the
>> > newsgroup,
>> > but I think uint makes more sense.
>>
>> I *strongly* oppose uint. We should take every possible
opportunity to
>> reduce usage of unsigned numbers.
>> 'i' implies immutable.
>> How about intlength (or intLength ?)
_______________________________________________
phobos mailing list
[email protected] <mailto:[email protected]>
http://lists.puremagic.com/mailman/listinfo/phobos
_______________________________________________
phobos mailing list
[email protected]
http://lists.puremagic.com/mailman/listinfo/phobos
_______________________________________________
phobos mailing list
[email protected]
http://lists.puremagic.com/mailman/listinfo/phobos
