That's a good point.

The answer, I suspect, is cosmetic appeal to C-family programmers.

"imr1984" <imr1984_member@pathlink.com> wrote in message news:c6ds7c$la7$1@digitaldaemon.com...
> well if all sizes will stay the same, id like to know why D actually calls its integers by non exact names (int, long, short etc). Why arent they called
int32,
> int64, int16 etc ?
>
> In article <c6boe1$1ilt$2@digitaldaemon.com>, Walter says...
> >
> >
> >"imr1984" <imr1984_member@pathlink.com> wrote in message news:c6b398$f01$1@digitaldaemon.com...
> >> im curious - when a D compiler is made for 64bit processors (in the near
> >future
> >> lets hope :) what will the size of an int be? I assume it will be 8, and
> >long
> >> will be 16. So then what will a 2 byte integer be? It cant be a short
> >because
> >> that will be a 4 byte integer.
> >>
> >> I assume that floating point names will stay the same, as they are defined
> >by
> >> the IEEE.
> >
> >All sizes will stay the same when moving to 64 bits, with the following exceptions:
> >
> >1) pointers will be 64 bits
> >2) object references will be 64 bits
> >3) dynamic array references will be 128 bits
> >4) pointer differences will be 64 bits
> >5) pointer offsets will be 64 bits
> >6) sizeof will be 64 bits
> >7) Whether real.size will stay 10 or be forced to 8 is still up in the air.
> >
> >To this end, and to ensure portability of D source code to 64 bits, follow the following rules:
> >
> >1) Use the .sizeof property whenever depending on the size of a type.
> >2) Use ptrdiff_t (an alias in object.d) for signed pointer differences.
> >3) Use size_t (an alias in object.d) for type sizes, unsigned pointer
> >offsets and array indices.
> >
> >Note that 1, 2, and 3 correspond to C's portable uses of sizeof, ptrdiff_t, and size_t.
> >
> >In particular, int's and long's will remain the same size as for 32 bit computing.
> >
> >
>
>

Dave Sieber schrieb:

> Ilya Minkov <minkov@cs.tum.edu> wrote:
> 
>>According to specification, all bit-widths are to be understood as minimal. The types *might* be upscaled in the (probably far) future.
>>For the sake of portability of algorithms, one should keep on the mind
>>that the types might be larger someday, and such bit with names would
>>become very unfortunate then.
> 
> Oh no, I certainly hope that's not true. Where is this mentioned in the spec?

http://www.digitalmars.com/d/portability.html

Right above your nose.

-eye

"Matthew" <matthew.hat@stlsoft.dot.org> wrote in message
news:c6b5ta$j67$1@digitaldaemon.com
| Well, the point is that using an inappropriately sized integer for a given
| architecture will have a performance cost. Therefore, anyone using an
integer for
| "normal" counting and such will be at a disadvantage when porting between
| different sized architectures. To avoid this *every* programmer who is
aware of
| the issue will end up creating their own versioned alias. Therefore, I
think it
| should be part of the language, or at least part of Phobos. Does this not
seem
| sensible?

There is std.stdint

-----------------------
Carlos Santander Bernal

"imr1984" <imr1984_member@pathlink.com> wrote in message
news:c6ds7c$la7$1@digitaldaemon.com
| well if all sizes will stay the same, id like to know why D actually calls
its
| integers by non exact names (int, long, short etc). Why arent they called
int32,
| int64, int16 etc ?
|

You can use the aliases from std.stdint

-----------------------
Carlos Santander Bernal

"imr1984" <imr1984_member@pathlink.com> wrote in message news:c6ds7c$la7$1@digitaldaemon.com...
> well if all sizes will stay the same, id like to know why D actually calls
its
> integers by non exact names (int, long, short etc). Why arent they called
int32,
> int64, int16 etc ?

It's just aesthetically unappealing. But if you prefer them, there are aliases for them in std.stdint.

<snip>
>> integers by non exact names (int, long, short etc). Why arent they called
>int32,
>> int64, int16 etc ?
>
>It's just aesthetically unappealing. But if you prefer them, there are aliases for them in std.stdint.
</snip>

Ah, but they aid in making the code self-documenting -- isn't that one of your goals?

"Juan C" <Juan_member@pathlink.com> wrote in message news:c6evnk$2kv2$1@digitaldaemon.com...
> <snip>
> >> integers by non exact names (int, long, short etc). Why arent they
called
> >int32,
> >> int64, int16 etc ?
> >
> >It's just aesthetically unappealing. But if you prefer them, there are aliases for them in std.stdint.
> </snip>
>
> Ah, but they aid in making the code self-documenting -- isn't that one of
your
> goals?

Yes, it is. I feel that goal is achieved, however, by specifying what the sizes of the types are in the spec, rather than leaving them unspecified as in C.

In article <c6c6kv$2afq$1@digitaldaemon.com>, Matthew says...
>
>and it's unsigned
>
>"Ilya Minkov" <minkov@cs.tum.edu> wrote in message news:c6bki6$1auk$1@digitaldaemon.com...
>> Matthew schrieb:
>>
>> > It does seem to me that we should have an additional integral type, say pint, that is an integer of the natural size of the architecture, for maximal efficiency.
>>
>> There is one, size_t -- but its name is ugly as hell!
>>
>> -eye
>

The docs claim that there is a second, equally ugly-named alias, ptrdiff_t, which is signed and has the natural size.

More specifically, it says that these "span the address space", i.e. they are the size of a pointer.  Usually this is equivalent to "register size"; is it always?  It seems like only a complete <unflattering> would make an architecture where it takes extra work to copy a pointer because they don't fit in a register, but...

Kevin

Processing costs internally the same. But data storage would be bigger as 64 bit. Additionally, when using the SSE3 multimedia instruction set, you can process 4 32-bit integers at the same time instead of only two 64 bit. Additionally, almost all 64 bit instruction needs an extra byte to specify that, and so the instruction cache would be to transfer more code. So, use 32 bit where appropriate!

(I know, this forum is dead, but this is a test.)

Matthew wrote:
> I'm not a hardware-Johny, but it's my understanding that using 32-bit integers on
> 64-bit architectures will be less efficient than using 64-bit integers.
> 
> "J Anderson" <REMOVEanderson@badmama.com.au> wrote in message
> news:c6b8uq$okp$1@digitaldaemon.com...
> 
>>Matthew wrote:
>>
>>
>>>Well, the point is that using an inappropriately sized integer for a given
>>>architecture will have a performance cost. Therefore, anyone using an integer
> 
> for
> 
>>>"normal" counting and such will be at a disadvantage when porting between
>>>different sized architectures. To avoid this *every* programmer who is aware
> 
> of
> 
>>>the issue will end up creating their own versioned alias. Therefore, I think
> 
> it
> 
>>>should be part of the language, or at least part of Phobos. Does this not seem
>>>sensible?
>>>
>>>
>>
>>It does.  However on 64 bit machines won't 32 bit integers still be
>>faster because they can be sent two at a time (under certain
>>conditions)?  The same can be said for 16-bit at the moment.
>>
>>-- 
>>-Anderson: http://badmama.com.au/~anderson/
> 
> 
>