int always 32 bits on all platforms?

AJ aj at nospam.net
Wed Oct 21 16:10:09 PDT 2009


"BCS" <none at anon.com> wrote in message 
news:a6268ffbaf38cc207c6738826c at news.digitalmars.com...
> Hello aJ,
>
>> "BCS" <none at anon.com> wrote in message
>> news:a6268ffbadb8cc20772570e4f0 at news.digitalmars.com...
>>
>>> Hello aJ,
>>>
>>>> How can/does D guarantee that "int" will always be 32 bits on all
>>>> platforms? Does this mean that D won't work on some platforms?
>>>>
>>> D is not built for 8 or 16 bit systems. However 32 bit math can be
>>> done on a 16 bit CPU, it's just slow. In the other direction, 32 bit
>>> math (and 16 and 8 bit) can be done on a 64 bit CPU so that's not a
>>> problem.
>>>
>> I wasn't thinking about math issues,
>
> OK
>
>> but rather struct field
>> alignment/portability, and platform alignment requirements for basic
>> types, issues.
>
> Unless you say otherwise, the compiler is free to align struct however it 
> wants (this is true in C but there are conventions) and in general you 
> can't expect it to do the same for different system (again, ditto re C)
>
> OTOH I'm not sure how that links into int being the same size all over. If 
> anything that should make these issue less of a problem.

I would think so. Anyway, what I find compelling about guaranteed widths is 
the potential to eliminate alignment and padding issues (that is, be able to 
control it with confidence across platforms as one already can on a single 
platform via compiler pragmas or cmdline switches).

>
>> I'm guessing that it is all worked out by the compiler,
>> so that makes the development of a compiler more difficult, if so, but
>> how much more difficult? A simple example or description of how this
>> is done would really be great. (BTW, this is definitely an area where
>> I would approve of more language implementation complexity for the
>> great strides in programming efficiency (and fun!) it gives).
>
> 





More information about the Digitalmars-d mailing list