On 22 February 2012 17:16, Stewart Gordon <smjg_1998@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.