Community

Why not also include these variable types in D?
int1 - 1 byte
int2 - 2 bytes
int4 - 4 bytes
intN - N bytes (experimental)
It must be also guaranteed that these types will always, on every machine, have
the same size.

In article <dlss62$13b$1@digitaldaemon.com>, Shawn Liu says...
>
>I think int8, int16, int32, int64 is more comfortable.
In the interest of hearing this idea out, I'll play the devil's advocate on this
one. :)
What is wrong with the documented convetions laid out for the byte sizes of the
current values? Would it be enough to incorporate those definitions into the
(eventual) D ABI, to ensure that all D compiler vendors adhere to the same
sizes?
While I think there's value in having a standard that is easily grasped, I don't
think its necessary to clutter things up with more keywords for already
well-defined types.
- EricAnderton at yahoo

"pragma" <pragma_member@pathlink.com> wrote in message
news:dlstrd$2i4$1@digitaldaemon.com...
> What is wrong with the documented convetions laid out for the byte sizes
> of the
> current values?
Because although they're documented and strictly defined, they don't make
much sense. For example, long makes sense on a 32-bit machine, but on
64-bit machines (to which everything is moving relatively soon), 64 bits is
the default size. So "long" would be the "normal" size. Then there's
short, which I suppose makes sense on both platforms, and int, but neither
gives any indication of the size. The only type that does is "byte."
I'd personally like int8, int16, int32, etc. This also makes it easy to add
new, larger types. What comes after int64? int128, of course. But what
comes after "long?" Why, "cent." What?! Huh?
But of course, none of this will ever happen / even be considered, so it's
kind of an exercise in futility.

In article <dlsuq9$3d9$1@digitaldaemon.com>, Jarrett Billingsley says...
>
>"pragma" <pragma_member@pathlink.com> wrote in message
>news:dlstrd$2i4$1@digitaldaemon.com...
>> What is wrong with the documented convetions laid out for the byte sizes
>> of the
>> current values?
>
>Because although they're documented and strictly defined, they don't make
>much sense. For example, long makes sense on a 32-bit machine, but on
>64-bit machines (to which everything is moving relatively soon), 64 bits is
>the default size. So "long" would be the "normal" size.
Maybe if D bit-length specifications were relative (don't know the downsides of
this approach but I'm all ears).
For example:
____________________________________________________________________________,
TYPE | SIZE | LEN IN 32-BIT MACHINES | LEN IN 64-BIT MACHINES |
| (relative to 1 | (in bits) | (in bits) |
| CPU word) | | |
| (register size)| | |
---------+----------------+------------------------+------------------------+
(u)short | 1/2 | 16 | 32 |
(u)int | 1 | 32 | 64 |
(u)long | 2 | 64 (as VC++s __int64) | 128 |
After all, isn't it ugly and less abstract to code assuming a certain sizeof
for integral types (and also maybe with other types)? (sizeof brings that
information to the programmer and the programmer should code relative to the
'sizeof' of a type and not assuming that size with premeditation).
>Then there's
>short, which I suppose makes sense on both platforms, and int, but neither
>gives any indication of the size. The only type that does is "byte."
Don't know if a type should be THAT explicit with it's size.
>I'd personally like int8, int16, int32, etc. This also makes it easy to add
>new, larger types. What comes after int64? int128, of course. But what
>comes after "long?" Why, "cent." What?! Huh?
>
>But of course, none of this will ever happen / even be considered, so it's
>kind of an exercise in futility.
Hehe, I agree.
Tom

Tomás Rossi wrote:
> In article <dlsuq9$3d9$1@digitaldaemon.com>, Jarrett Billingsley says...
>
>>"pragma" <pragma_member@pathlink.com> wrote in message
>>news:dlstrd$2i4$1@digitaldaemon.com...
>>
>>>What is wrong with the documented convetions laid out for the byte sizes
>>>of the
>>>current values?
>>
>>Because although they're documented and strictly defined, they don't make
>>much sense. For example, long makes sense on a 32-bit machine, but on
>>64-bit machines (to which everything is moving relatively soon), 64 bits is
>>the default size. So "long" would be the "normal" size.
>
>
> Maybe if D bit-length specifications were relative (don't know the downsides of
> this approach but I'm all ears).
> For example:
> ____________________________________________________________________________,
> TYPE | SIZE | LEN IN 32-BIT MACHINES | LEN IN 64-BIT MACHINES |
> | (relative to 1 | (in bits) | (in bits) |
> | CPU word) | | |
> | (register size)| | |
> ---------+----------------+------------------------+------------------------+
> (u)short | 1/2 | 16 | 32 |
> (u)int | 1 | 32 | 64 |
> (u)long | 2 | 64 (as VC++s __int64) | 128 |
>
> After all, isn't it ugly and less abstract to code assuming a certain sizeof
> for integral types (and also maybe with other types)? (sizeof brings that
> information to the programmer and the programmer should code relative to the
> 'sizeof' of a type and not assuming that size with premeditation).
>
The problem is this: people need different guarantees about their
types' sizes for different purposes.
In one instance, you may need a set of types that are absolutely
fixed-size for use in reading/writing out binary data to files or
streams, etc. In another instance, you may need a set of types that
match the processor's supported native word sizes for fast processing.
>
>>Then there's
>>short, which I suppose makes sense on both platforms, and int, but neither
>>gives any indication of the size. The only type that does is "byte."
>
>
> Don't know if a type should be THAT explicit with it's size.
>
>
>>I'd personally like int8, int16, int32, etc. This also makes it easy to add
>>new, larger types. What comes after int64? int128, of course. But what
>>comes after "long?" Why, "cent." What?! Huh?
>>
>>But of course, none of this will ever happen / even be considered, so it's
>>kind of an exercise in futility.
>
...unless certain ones designing new languages happen to be listening...
I do like the int8, int16, int32, int64 names. It makes sense. Very
easy to scale up the language for 128-bit processing and 256-bit processing.
>
> Hehe, I agree.
>
> Tom

Oskar Linde wrote:
> In article <dlt3c9$87f$1@digitaldaemon.com>, Tomás Rossi says...
>
>>In article <dlsuq9$3d9$1@digitaldaemon.com>, Jarrett Billingsley says...
>>
>>>"pragma" <pragma_member@pathlink.com> wrote in message
>>>news:dlstrd$2i4$1@digitaldaemon.com...
>>>
>>>>What is wrong with the documented convetions laid out for the byte sizes
>>>>of the
>>>>current values?
>>>
>>>Because although they're documented and strictly defined, they don't make
>>>much sense. For example, long makes sense on a 32-bit machine, but on
>>>64-bit machines (to which everything is moving relatively soon), 64 bits is
>>>the default size. So "long" would be the "normal" size.
>>
>>Maybe if D bit-length specifications were relative (don't know the downsides of
>>this approach but I'm all ears).
>>For example:
>>____________________________________________________________________________,
>>TYPE | SIZE | LEN IN 32-BIT MACHINES | LEN IN 64-BIT MACHINES |
>>| (relative to 1 | (in bits) | (in bits) |
>>| CPU word) | | |
>>| (register size)| | |
>>---------+----------------+------------------------+------------------------+
>>(u)short | 1/2 | 16 | 32 |
>>(u)int | 1 | 32 | 64 |
>>(u)long | 2 | 64 (as VC++s __int64) | 128 |
>
>
> This is exactly one of the things D was designed to avoid.
> But it would be nice to have an official alias for the system native register
> sized type.
I don't believe it would be nice. The language already has the most
needed data types. It's really a pain in the ass to test these
variable-length types using different architectures. Maybe they would
result in a better c-interoperativity, but still it would make porting d
programs harder. Of course you might say that you don't have to use this
type, but I have a feeling that not all people ever get it right.

In article <dlss62$13b$1@digitaldaemon.com>, Shawn Liu says...
>
>I think int8, int16, int32, int64 is more comfortable.
>
>"John Smith" <John_member@pathlink.com>
>wrote:dlsq7f$30hv$1@digitaldaemon.com...
>> Why not also include these variable types in D?
>> int1 - 1 byte
>> int2 - 2 bytes
>> int4 - 4 bytes
>> intN - N bytes (experimental)
>>
>> It must be also guaranteed that these types will always, on every machine,
>> have
>> the same size.
>>
I think this is a nice idea. Most projects either have network data formats to
define and/or interface with hardware, both of which require you to once again
write a "prim_types.h" file (in C/C++) to yet again define what a
Uint8/Int8/Uint16/Int16 etc. are on the platform that you're using this time
round. It doesn't take that long to do, and it's an obvious thing to use "alias"
for... but it's another thing that it would be really nice to have builtin to
the language instead of having to do it by hand.
A key word for me in the suggestion is "also". We definitely need to be able to
specify "int" as the platform-native (i.e. fastest) integer type.
Just my tuppence!
Munch