www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - range.size() should be long, right?

reply "Mehrdad" <wfunction hotmail.com> writes:
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.
Jun 25 2012
next sibling parent reply Artur Skawina <art.08.09 gmail.com> writes:
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
Jun 25 2012
parent =?UTF-8?B?QWxleCBSw7hubmUgUGV0ZXJzZW4=?= <alex lycus.org> writes:
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
Jun 25 2012
prev sibling next sibling parent reply "Jonathan M Davis" <jmdavisProg gmx.com> writes:
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
Jun 25 2012
parent Walter Bright <newshound2 digitalmars.com> writes:
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'.
Jun 25 2012
prev sibling next sibling parent "Jonathan M Davis" <jmdavisProg gmx.com> writes:
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
Jun 25 2012
prev sibling next sibling parent "Mehrdad" <wfunction hotmail.com> writes:
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.)
Jun 25 2012
prev sibling next sibling parent Timon Gehr <timon.gehr gmx.ch> writes:
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)); })); }
Jun 25 2012
prev sibling parent "Mehrdad" <wfunction hotmail.com> writes:
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.
Jun 25 2012