Thread overview | |||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|
|
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? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Mehrdad | 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? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Mehrdad | 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? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Mehrdad | 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? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Artur Skawina | 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? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Mehrdad | 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? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Mehrdad | 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? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Jonathan M Davis | 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? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Alex Rønne Petersen | 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.
|
Copyright © 1999-2021 by the D Language Foundation