64Bit compatibility warnings

[Marco Leise]

Am 21.01.2012, 02:16 Uhr, schrieb Timon Gehr <timon.gehr at gmx.ch>:

> On 01/21/2012 01:48 AM, Stewart Gordon wrote:
>> On 20/01/2012 00:46, Peter Alexander wrote:
>>> On 20/01/12 12:25 AM, Trass3r wrote:
>>>> Could we please have at least a warning if code isn't compatible with
>>>> 64Bit?
>>>> It's really annoying to test out some code and having to fix a bunch  
>>>> of
>>>> stupid uint->size_t bugs just because the author is still on a 32 bit
>>>> machine.
>>>>
>>>> Is that feasible?
>>>
>>> In general, no. What you're asking is for the compiler to compile your
>>> code twice, once
>>> for 32-bit and once for 64-bit.
>>
>> No it isn't. It's basically asking to make size_t/ptrdiff_t not
>> implicitly convertible to uint/int, or at least issue a warning if you
>> implicitly convert between them.
>>
>> At least some Microsoft C++ complier versions have this warning.
>>
>> Stewart.
>
> I generally like the idea of making size_t strongly typed, but
> that would necessitate X!size_t to become a distinct instantiation from  
> X!uint or X!ulong. Furthermore, it would break all existing D programs  
> that are deliberately not 64 bit aware =).

I like the idea, too. Memory sizes and collection lengths are numbers of  
machine word size. This is a logically distinct type. I want to support my  
claim with this article:  
http://en.wikipedia.org/wiki/Integer_(computer_science)#Words
Although past systems had 24-bit architectures, in practice today a  
machine word maps to either uint or ulong. So what I have in mind is a  
machine word "typedef": It is logically different from both uint and  
ulong, but template instances using it are mapped to either uint or ulong  
(the semantically equivalent). As a new keyword, it would also look ok  
with syntax highlighting editors and remove size_t, which does look so so.

	void* allocate(word size);