digitalmars.D - range.size() should be long, right?
- Mehrdad (8/8) Jun 25 2012 Shouldn't the length of a range should be a long?
- Artur Skawina (6/13) Jun 25 2012 What makes you think 'length' should evaluate to a size_t? If it it's
- Mehrdad (9/16) Jun 25 2012 That is a VERY good question...
- =?UTF-8?B?QWxleCBSw7hubmUgUGV0ZXJzZW4=?= (9/23) Jun 25 2012 IMHO unsigned is fine. I personally strongly dislike the .NET situation
- Mehrdad (6/10) Jun 25 2012 Yeah in general I hate .NET's stupid rule, it makes no sense.
- Jonathan M Davis (4/14) Jun 25 2012 It depends entirely on the range. In most cases, it's size_t, but occasi...
- Walter Bright (3/4) Jun 25 2012 Exactly. The definition of a range that has a 'length' property is that ...
- Jonathan M Davis (13/23) Jun 25 2012 It depends on the range type. It's usually size_t, but sometimes it's
- Timon Gehr (9/16) Jun 25 2012 template hasLength(R)
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
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
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. arturI mentioned signed in case we want to allow negatives just in case we want special values (e.g. "unknown length", etc.)
Jun 25 2012
On 25-06-2012 20:28, Mehrdad wrote:On Monday, 25 June 2012 at 18:22:00 UTC, Artur Skawina 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 previously). -- Alex Rønne Petersen alex lycus.org http://lycus.orgWhat 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. arturI mentioned signed in case we want to allow negatives just in case we want special values (e.g. "unknown length", etc.)
Jun 25 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 interoperabilityYeah 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
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
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
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
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