Strictly speaking 'byte' is a name of data storage unit  and
not a name of numeric type. And by definition it is smallest addressable
unit by particular processor. ( Some DSP can address only 32bit bytes  for
example )

So word combinations "signed byte" and "unsigned byte" are technically incorrect.

Ideally (mathematically correct) it should be something like
int8, int16, int32, int64 and
nat8, nat16, nat32, nat64 for "unsigned"
real16, real32, real64, etc.

At least 'byte' should be unsigned numeric type ("what is max number stored
in byte?")
as 'word' and 'dword'.

Andrew Fedoniouk.
http://terrainformatica.com

Since a definition is something that most people agree on, there isn't a right and a wrong in these discussions. There is just consistent and inconsistent. For our purposes, a 'byte' and a 'ubyte' make sense because most people understand what those tokens mean; therefore they are consistent.

Andrew Fedoniouk wrote:
> Strictly speaking 'byte' is a name of data storage unit  and not a name of numeric type.
True, but D is meant to be a systems language as well, in which case it needs to support low level access to data storage units present in hardware.

> And by definition it is smallest addressable
> unit by particular processor.( Some DSP can address only 32bit bytes  for
> example )
That's a less commonly accepted meaning of the word 'byte' and it usually used in more specific contexts. Generally people would say that a byte is 8 bits.

> So word combinations "signed byte" and "unsigned byte" are technically incorrect.
I don't see why. Signed means the byte is treated as 2's complement and unsigned means it's not.

I would be totally cool with the concept of a 'byte' being just 8 bits. However, I start getting crazy ideas like disallowing any arithmetic on bytes, since they are just collections of bits.

> Ideally (mathematically correct) it should be something like
> int8, int16, int32, int64 and
> nat8, nat16, nat32, nat64 for "unsigned"
> real16, real32, real64, etc.
But computers != maths. A float is an IEEE754-compliant representation of a number; it's not really a 'real'. If it was a real it wouldn't have rounding errors and such.



Below, I am just trying to illustrate that there is no end to being picky with definitions...

> At least 'byte' should be unsigned numeric type ("what is max number stored
> in byte?")
> as 'word' and 'dword'.
The notion of a byte being a "data storage unit" means that technically there is no maximum number stored in a byte. Instead, we assign meaning to different configurations that a byte can take on (of which there are 256). For example, you could say 0xFF means 'infinity' or it can mean '42', or it can mean 'I <3 PONIES'.

> Andrew Fedoniouk.
> http://terrainformatica.com

Andrew Fedoniouk wrote:
> Strictly speaking 'byte' is a name of data storage unit  and
> not a name of numeric type.

True.

> And by definition it is smallest addressable
> unit by particular processor. ( Some DSP can address only 32bit bytes  for example )

This ("smallest addressable unit") is not the definition of byte (e.g. certain architectures do not allow loads which are not 32-bit aligned and always load a 32-bit quantity but still have byte == 8 bits).

Historically, it just meant tuple (or array if you want) of bits with an architecture dependent length (e.g. 6-bit bytes were the first used byte-size as the machines of long ago used 6-bit character sets). Well then was then and now is now, and nowadays everyone usually means "8 bits" when they say "byte".

> So word combinations "signed byte" and "unsigned byte" are
> technically incorrect.
> Ideally (mathematically correct) it should be something like
> int8, int16, int32, int64 and
> nat8, nat16, nat32, nat64 for "unsigned"
> real16, real32, real64, etc.

I like your idea, here is my variation on it:

int8,  int16,  int32,  int64,  int128
uint8, uint16, uint32, uint64, uint128
float32,  float64,  float80,  float128
ifloat32, ifloat64, ifloat80, ifloat128
cfloat32, cfloat64, cfloat80, cfloat128

But you'd actually have to look at code containing lots of this -- perhaps it just turns out too ugly.

Marco

In article <dt5ba1$h5n$1@digitaldaemon.com>, Marco Matthies says...

>I like your idea, here is my variation on it:
>
>int8,  int16,  int32,  int64,  int128
>uint8, uint16, uint32, uint64, uint128
>float32,  float64,  float80,  float128
>ifloat32, ifloat64, ifloat80, ifloat128
>cfloat32, cfloat64, cfloat80, cfloat128
>
>But you'd actually have to look at code containing lots of this -- perhaps it just turns out too ugly.
>
>Marco

This is very common in cross platform C applications.  Typdefs from the types of a specific artitecture to these size style types so they don't have to remember what arch they're on everywhere.  It doesn't look bad to me at all.

-S.

"S. Chancellor" <S._member@pathlink.com> wrote in message news:dt5do3$jh1$1@digitaldaemon.com...
> In article <dt5ba1$h5n$1@digitaldaemon.com>, Marco Matthies says...
>
>>I like your idea, here is my variation on it:
>>
>>int8,  int16,  int32,  int64,  int128
>>uint8, uint16, uint32, uint64, uint128
>>float32,  float64,  float80,  float128
>>ifloat32, ifloat64, ifloat80, ifloat128
>>cfloat32, cfloat64, cfloat80, cfloat128
>>
>>But you'd actually have to look at code containing lots of this -- perhaps it just turns out too ugly.
>>
>>Marco
>
> This is very common in cross platform C applications.  Typdefs from the
> types of
> a specific artitecture to these size style types so they don't have to
> remember
> what arch they're on everywhere.  It doesn't look bad to me at all.

This is unnecessary in D, as ints are 32 bits everywhere. A typedef or other reminder isn't necessary.

Walter Bright wrote:
> "S. Chancellor" <S._member@pathlink.com> wrote in message news:dt5do3$jh1$1@digitaldaemon.com...
>> In article <dt5ba1$h5n$1@digitaldaemon.com>, Marco Matthies says...
>>
>>> I like your idea, here is my variation on it:
>>>
>>> int8,  int16,  int32,  int64,  int128
>>> uint8, uint16, uint32, uint64, uint128
>>> float32,  float64,  float80,  float128
>>> ifloat32, ifloat64, ifloat80, ifloat128
>>> cfloat32, cfloat64, cfloat80, cfloat128
>>>
>>> But you'd actually have to look at code containing lots of this -- perhaps it just turns out too ugly.
>>>
>>> Marco
>> This is very common in cross platform C applications.  Typdefs from the types of
>> a specific artitecture to these size style types so they don't have to remember
>> what arch they're on everywhere.  It doesn't look bad to me at all.
> 
> This is unnecessary in D, as ints are 32 bits everywhere. A typedef or other reminder isn't necessary. 
> 
> 

Still, it might be nice to have those types in the language, as aliases. It could be a good name alternative, in some situations, to using the new names(like real or cent) for every new size that has come up.


-- 
Bruno Medeiros - CS/E student
"Certain aspects of D are a pathway to many abilities some consider to be... unnatural."

"Bruno Medeiros" <daiphoenixNO@SPAMlycos.com> wrote in message news:dt705s$1vkh$1@digitaldaemon.com...
> Still, it might be nice to have those types in the language, as aliases. It could be a good name alternative, in some situations, to using the new names(like real or cent) for every new size that has come up.

import std.stdint;

"Walter Bright" <newshound@digitalmars.com> wrote in message news:dt7mur$2hvs$2@digitaldaemon.com...
>
> "Bruno Medeiros" <daiphoenixNO@SPAMlycos.com> wrote in message news:dt705s$1vkh$1@digitaldaemon.com...
>> Still, it might be nice to have those types in the language, as aliases. It could be a good name alternative, in some situations, to using the new names(like real or cent) for every new size that has come up.
>
> import std.stdint;

Could the _t suffix at least be taken off those aliases (alii?) ?  int8_t has got to be one of the ugliest things I've seen since CLK_TCK.

"Jarrett Billingsley" <kb3ctd2@yahoo.com> wrote in message news:dt7q7f$2kfm$1@digitaldaemon.com...
> "Walter Bright" <newshound@digitalmars.com> wrote in message news:dt7mur$2hvs$2@digitaldaemon.com...
>>
>> "Bruno Medeiros" <daiphoenixNO@SPAMlycos.com> wrote in message news:dt705s$1vkh$1@digitaldaemon.com...
>>> Still, it might be nice to have those types in the language, as aliases. It could be a good name alternative, in some situations, to using the new names(like real or cent) for every new size that has come up.
>>
>> import std.stdint;
>
> Could the _t suffix at least be taken off those aliases (alii?) ?  int8_t has got to be one of the ugliest things I've seen since CLK_TCK.

I agree it's ugly, but the names were taken from C's <stdint>. That makes it convenient for porting from C, and for those who like the C stuff. Having yet a third set of names would be a bit too redundant.

"Walter Bright" <newshound@digitalmars.com> wrote in message news:dt7uv8$2p0l$2@digitaldaemon.com...
> I agree it's ugly, but the names were taken from C's <stdint>. That makes it convenient for porting from C, and for those who like the C stuff. Having yet a third set of names would be a bit too redundant.

You could just change it altogether, since it's easy to globally search and replace for intxx_t.  Besides, how many C programs have you seen that _actually use the stdints_?  It seems every open-source project out there has its own set of defines or typedefs to rename the types whatever they want, be it int8, byte, i8 or something else altogether.

Of course, this is never going to change, so I'm not sure why I even bother.