<div class="gmail_quote">On 22 February 2012 17:16, Stewart Gordon <span dir="ltr"><<a href="mailto:smjg_1998@yahoo.com">smjg_1998@yahoo.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">On 22/02/2012 07:24, Jacob Carlborg wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On 2012-02-22 06:24, Walter Bright wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On 2/21/2012 2:11 PM, Stewart Gordon wrote:<br>
</blockquote></blockquote></div>
<snip><div class="im"><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

Are we going to have c_long_long as well?<br>
</blockquote>
<br>
Probably.<br>
</blockquote>
<br>
Wouldn't that always be a "long" in D? Or is it the same as with "long" in C.<br>
</blockquote>
<br></div>
long in D is 64 bits.<br>
long in C is 32 bits (on Win16/32 at least).<br>
<br>
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.</blockquote>
<div><br></div><div>The C standard is completely irrelevant to D, and should not be considered.</div><div>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.</div>
<div>Their decisions towards the declaration of these fundamental types is a classic fuck up on lots of compilers.</div><div>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?).</div>
<div>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.</div>
<div>GDC takes its types from GCC verbatim, and they'll be every bit as broken as they would be in the corresponding C compiler.</div><div><br></div><div>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.</div>
</div>