size_t + ptrdiff_t

[Manu]

On 22 February 2012 17:16, Stewart Gordon <smjg_1998 at yahoo.com> wrote:

> On 22/02/2012 07:24, Jacob Carlborg wrote:
>
>> On 2012-02-22 06:24, Walter Bright wrote:
>>
>>> On 2/21/2012 2:11 PM, Stewart Gordon wrote:
>>>
>> <snip>
>
>  Are we going to have c_long_long as well?
>>>>
>>>
>>> Probably.
>>>
>>
>> Wouldn't that always be a "long" in D? Or is it the same as with "long"
>> in C.
>>
>
> long in D is 64 bits.
> long in C is 32 bits (on Win16/32 at least).
>
> If the C standard sets in stone the size of a long long, then we can do
> away with a c_long_long and just use long.  Otherwise, if we're going to
> have c_int and c_long, it only makes sense to have c_long_long as well.


The C standard is completely irrelevant to D, and should not be considered.
The C 'standard' is a guideline at best. I've worked with so many compilers
over the years that fail, or ignore the standard in all kinds of ways.
Their decisions towards the declaration of these fundamental types is a
classic fuck up on lots of compilers.
I can't trust anything in D defined to be "what c says".. if it's not
defined and guaranteed by D, consider it as not-portable, and you'll
probably need to start aliasing your own types inside super-portable
libraries; version the hell out of it for every compiler you can find, just
like C libs do. (Hello GLint (OpenGL), hkFloat(Havok), DWORD (windows),
etc... can you think of a single super-portable library that DOESN'T
redefine its primitive types?).
As D cross compilers become more and more common, or other D compiler
implementations begin to appear, the magnitude of the error will get more
and more obvious, and also the longer it's left, the more impossible it
will be to change.
GDC takes its types from GCC verbatim, and they'll be every bit as broken
as they would be in the corresponding C compiler.

I just want D to define its types (including pointer (u)int, and native
(u)int) explicitly in the D standard, and try and enforce it somehow to the
tragedy never appears in D.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20120222/1fdca520/attachment.html>