Have you actually tried porting any application code to 64? Phobos and
other similarly generic libraries don't count because code that's that
generic legitimately can't assume that no arrays are going to be
billions of elements long.
On 2/17/2011 6:00 PM, Andrei Alexandrescu wrote:
I don't see a problem with using size_t throughout. The machine will
be as good or better at operating on size_t (compared to int).
The size argument has been historically made about double and float.
Today people use double throughout and float on occasion when they
want to optimize storage.
@Don: Making it signed adds insult to injury. It means that we're
inconsistent about the way we handle nonnegative entities in the
language and its library.
Andrei
On 2/17/11 4:46 PM, David Simcha wrote:
On Thu, Feb 17, 2011 at 5:28 PM, Andrei Alexandrescu <[email protected]
<mailto:[email protected]>> wrote:
I assume I'm in the minority here, but I don't see a need for such a
function.
Andrei
The point you're missing is that arrays are a very commonly used thing
and give you no choice about integer widths. Most of the time, if you
don't need the extra width (most values in any program represent
quantities that can't plausibly be bigger than the maximum value of some
fixed-width integer) and want to avoid either the viral effects of using
wide integers or the need to insert casts all over the place, you just
use a narrower integer. For the vast majority of quantities people deal
with, 32-bit ints are more than enough, so they tend to be what's used
most in practice.
With arrays, you don't have that choice, even though the *vast* majority
of the time int is plenty and you tend to know when it isn't.
Therefore, you get stuck either dealing with the viralness of
array.length being a ulong on 64 or with the ugliness of manually
inserting casts everywhere. You gain virtually nothing in safety in
exchange because arrays are almost never (and when I say almost never I
mean I've never seen one in my life) over 2 billion elements long.
The point is that by adding this function you lose epsilon in safety,
where epsilon is some tiny but nonzero value, and gain a whole bunch in
usability. Realistically, using size_t everywhere is not a good idea
(though it admittedly is a good idea in a large portion of cases) for
*at least* two reasons, i.e. two that I've encountered already:
1. Storing arrays of indices into other arrays with size_t's is
incredibly wasteful unless there's a realistic chance that one of the
arrays you're indexing could be billions of elements long.
2. Some libraries written in other languages that interface with D
(GTK, BLAS and LAPACK come to mind) always assume, even on 64, that int
is enough for the length of an array. The ugliness and tediousness of
putting casts everywhere to accommodate this is slowly breeding insanity
in me.
--Dave
_______________________________________________
phobos mailing list
[email protected]
http://lists.puremagic.com/mailman/listinfo/phobos
_______________________________________________
phobos mailing list
[email protected]
http://lists.puremagic.com/mailman/listinfo/phobos
_______________________________________________
phobos mailing list
[email protected]
http://lists.puremagic.com/mailman/listinfo/phobos
