View mode: basic / threaded / horizontal-split · Log in · Help
June 25, 2012
range.size() should be long, right?
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
Re: range.size() should be long, right?
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
Re: range.size() should be long, right?
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
Re: range.size() should be long, right?
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
Re: range.size() should be long, right?
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
Re: range.size() should be long, right?
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
Re: range.size() should be long, right?
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
Re: range.size() should be long, right?
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
Re: range.size() should be long, right?
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