June 25, 2012
Shouldn't the length of a range should be a long?

Otherwise there's no way we could possibly replace streams with ranges.
32-bit systems have LOTS of common streams that are over 2^32 bytes (e.g. DVD images, partition images, large movies, etc.).

And not just that -- if we use size_t instead of long, bit arrays will only have a maximum length of 512 MiB -- waay lower than what 32-bit systems can handle.
June 25, 2012
On 06/25/12 19:49, Mehrdad wrote:
> Shouldn't the length of a range should be a long?
> 
> Otherwise there's no way we could possibly replace streams with ranges.
> 32-bit systems have LOTS of common streams that are over 2^32 bytes (e.g. DVD images, partition images, large movies, etc.).
> 
> And not just that -- if we use size_t instead of long, bit arrays will only have a maximum length of 512 MiB -- waay lower than what 32-bit systems can handle.
> 

What makes you think 'length' should evaluate to a size_t? If it it's documented like that somewhere then that should be fixed.

It should be unsigned though, so if you need a type wider than 32-bit size_t, use ulong etc.

artur
June 25, 2012
On Monday, June 25, 2012 19:49:54 Mehrdad wrote:
> Shouldn't the length of a range should be a long?
> 
> Otherwise there's no way we could possibly replace streams with
> ranges.
> 32-bit systems have LOTS of common streams that are over 2^32
> bytes (e.g. DVD images, partition images, large movies, etc.).
> 
> And not just that -- if we use size_t instead of long, bit arrays will only have a maximum length of 512 MiB -- waay lower than what 32-bit systems can handle.

It depends entirely on the range. In most cases, it's size_t, but occasionally it's explicitly something else.



- Jonathan M Davis
June 25, 2012
On Monday, June 25, 2012 19:49:54 Mehrdad wrote:
> Shouldn't the length of a range should be a long?
> 
> Otherwise there's no way we could possibly replace streams with
> ranges.
> 32-bit systems have LOTS of common streams that are over 2^32
> bytes (e.g. DVD images, partition images, large movies, etc.).
> 
> And not just that -- if we use size_t instead of long, bit arrays will only have a maximum length of 512 MiB -- waay lower than what 32-bit systems can handle.

It depends on the range type. It's usually size_t, but sometimes it's explicitly something else. It just has to be implicitly convertible to ulong:

template hasLength(R)
{
 enum bool hasLength = !isNarrowString!R && is(typeof(
 (inout int _dummy=0)
 {
 R r = void;
 static assert(is(typeof(r.length) : ulong));
 }));
}

- Jonathan M Davis
June 25, 2012
On Monday, 25 June 2012 at 18:22:00 UTC, Artur Skawina wrote:
> What makes you think 'length' should evaluate to a size_t? If it it's documented like that somewhere then that should be fixed.

That is a VERY good question...

I guess it doesn't /have/ to... didn't quite realize this.

But the fact that it currently does for pretty much everything (even including std.bitmanip.BitArray.length) was what made me think this.

I guess that should be fixed then..


> It should be unsigned though, so if you need a type wider than 32-bit
> size_t, use ulong etc.
>
> artur

I mentioned signed in case we want to allow negatives just in case we want special values (e.g. "unknown length", etc.)
June 25, 2012
On 06/25/2012 07:49 PM, Mehrdad wrote:
> Shouldn't the length of a range should be a long?
>
> Otherwise there's no way we could possibly replace streams with ranges.
> 32-bit systems have LOTS of common streams that are over 2^32 bytes
> (e.g. DVD images, partition images, large movies, etc.).
>
> And not just that -- if we use size_t instead of long, bit arrays will
> only have a maximum length of 512 MiB -- waay lower than what 32-bit
> systems can handle.

template hasLength(R)
{
    enum bool hasLength = !isNarrowString!R && is(typeof(
    {
        R r = void;
        static assert(is(typeof(r.length) : ulong));
    }));
}

June 26, 2012
On 25-06-2012 20:28, Mehrdad wrote:
> On Monday, 25 June 2012 at 18:22:00 UTC, Artur Skawina wrote:
>> What makes you think 'length' should evaluate to a size_t? If it it's
>> documented like that somewhere then that should be fixed.
>
> That is a VERY good question...
>
> I guess it doesn't /have/ to... didn't quite realize this.
>
> But the fact that it currently does for pretty much everything (even
> including std.bitmanip.BitArray.length) was what made me think this.
>
> I guess that should be fixed then..
>
>
>> It should be unsigned though, so if you need a type wider than 32-bit
>> size_t, use ulong etc.
>>
>> artur
>
> I mentioned signed in case we want to allow negatives just in case we
> want special values (e.g. "unknown length", etc.)

IMHO unsigned is fine. I personally strongly dislike the .NET situation where the convention is to use signed ints for everything due to some stupid language interoperability guideline just for VB.NET (and J# previously).

-- 
Alex Rønne Petersen
alex@lycus.org
http://lycus.org


June 26, 2012
On 6/25/2012 11:24 AM, Jonathan M Davis wrote:
> It depends entirely on the range.

Exactly. The definition of a range that has a 'length' property is that it returns type 'auto'.
June 26, 2012
On Tuesday, 26 June 2012 at 00:31:01 UTC, Alex Rønne Petersen wrote:
> IMHO unsigned is fine. I personally strongly dislike the .NET situation where the convention is to use signed ints for everything due to some stupid language interoperability guideline just for VB.NET (and J# previously).

Yeah in general I hate .NET's stupid rule, it makes no sense.

The only reason I mentioned long was that it didn't seem to hurt to leave the negative numbers for some other purpose, but it doesn't really matter anyway if we wouldn't use it haha.
Top | Discussion index | About this forum | D home