Integer conversions too pedantic in 64-bit

Steven Schveighoffer schveiguy at yahoo.com
Wed Feb 16 06:03:56 PST 2011


On Tue, 15 Feb 2011 18:18:22 -0500, Rainer Schuetze <r.sagitario at gmx.de>  
wrote:

>
> Steven Schveighoffer wrote:
>>  In addition size_t isn't actually defined by the compiler.  So the  
>> library controls the size of size_t, not the compiler.  This should  
>> make it extremely portable.
>>
>
> I do not consider the language and the runtime as completely seperate  
> when it comes to writing code.

You are right, in some cases the runtime just extends the compiler  
features.  However, I believe the runtime is meant to be used in multiple  
compilers.  I would expect object.di to remain the same.  Probably core  
too.  This should be easily checkable with the newer gdc, which I believe  
uses a port of druntime.

> BTW, though defined in object.di, size_t is tied to some compiler  
> internals:
>
> 	alias typeof(int.sizeof) size_t;
>
> and the compiler will make assumptions about this when creating array  
> literals.

This is true.  This makes it depend on the compiler.  However, I believe  
the spec is concrete about what the sizeof type should be (if not, it  
should be made concrete).

>>> I don't have a perfect solution, but maybe builtin arrays could be  
>>> limited to 2^^32-1 elements (or maybe 2^^31-1 to get rid of endless  
>>> signed/unsigned conversions), so the normal type to be used is still  
>>> "int". Ranges should adopt the type sizes of the underlying objects.
>>  No, this is too limiting.  If I have 64GB of memory (not out of the  
>> question), and I want to have a 5GB array, I think I should be allowed  
>> to.  This is one of the main reasons to go to 64-bit in the first place.
>
> Yes, that's the imperfect part of the proposal. An array of ints could  
> still use up to 16 GB, though.

Unless you cast it to void[].  What would exactly happen there, a runtime  
error?  Which means a runtime check for an implicit cast? I don't think  
it's really an option to make array length always be uint (or int).

I wouldn't have a problem with using signed words for length.  using more  
than 2GB for one array in 32-bit land would be so rare that having to jump  
through special hoops would be fine by me.  Obviously for now, 2^63-1  
sized arrays is plenty room for todays machines in 64-bit land.

> What bothers me is that you have to deal with these "portability issues"  
> from the very moment you store the length of an array elsewhere. Not a  
> really big deal, and I don't think it will change, but still feels a bit  
> awkward.

Java defines everything to be the same regardless of architecture, and the  
result is you just can't do certain things (like have a 5GB array).  A  
system-level language should support the full range of architecture  
capabilities, so you necessarily have to deal with portability issues.

If you want a super-portable language that runs the same everywhere, use  
an interpreted/bytecode language like Java, .Net or Python.  D is for  
getting close to the metal.

I see size_t as a way to *mostly* make things portable.  It is not  
perfect, and really cannot be.  It's necessary to expose the architecture  
so you can adapt to it, there's no getting around taht.

Really, it's rare that you have to use it anyways, most should use auto.

-Steve


More information about the Digitalmars-d mailing list