Am 21.01.2012, 02:16 Uhr, schrieb Timon Gehr <[email protected]>:
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);
