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.

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

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

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

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.)

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));
    }));
}

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

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'.

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.