www.digitalmars.com         C & C++   DMDScript  

D - Renaming of integer data types needed

reply Brian Bober <netdemonz yahoo.com> writes:
I believe integer data types (http://www.digitalmars.com/d/), such as long,
should be reconsidered. I brought this up a couple years ago and discussed
it with Pavel Minayev but had a different solution then. I now rehash
it with a new suggestion:

bit -- 1 bit
byte -- 8 bits signed
ubyte -- 8 bits unsigned
int16 -- 16 bits signed
uint16 -- 16 bits unsigned
int32, uint32,int64,uint64, etc

You can provide a temporary standard header that will provide the alternate 
names you provided on http://www.digitalmars.com/d/type.html until people 
have migrated to the new system I suggested here.

Reasons for my suggestion are that:
1) It is more logical because it shows the length of the variable.

2) It won't suffer from issues if there is an addition of more integer 
types, such as 256 and 512 bit integers. This is what caused the whole
mess with int and long in C/C++, so you are just dooming us to the same
mess. Pavel Minayev said that # of bits in processors increase
logarithmically. We cannot assume this to always be the case, especially
if processors ever develop serial internal buses to space components out
more. If that ever happens, and it will likely happen some day, then the
size of integers won't really matter in terms of processor size.
Scientific computers will likely have the capability for much larger
integers. 

3) It will cause less confusion between C and C++ and what people
remember from various systems (such as i386, long is 32 bits).

4) It will cause less issues for automatic conversions, especially using
tools like sed or awk.

5) It will cause people to think more about what names they use when
converting.

6) This method has proved effective for cross platform in Mozilla's 
prInt32, etc. 

7) It'll be easier for embedded system designers who want to make, 
say, 24-bit integers to implement it in a meaningful manner.
8) cent and ucent is not a good name for a 128-bit variable. First
of all, it might be too easily mixed up with a simple structure for
representing currency. Second of all, 128 is not 100. In fact, a 128-bit
integer simply backs up what I said in 2. Naming data types is getting
ridiculous. What is longer than long? I guess it could be 'extended' or
'stretch', but seriously... Let's make things a bit less complicated.
Sep 22 2004
parent reply Regan Heath <regan netwin.co.nz> writes:
On Wed, 22 Sep 2004 17:09:37 -0400, Brian Bober <netdemonz yahoo.com> 
wrote:
 I believe integer data types (http://www.digitalmars.com/d/), such as 
 long,
 should be reconsidered. I brought this up a couple years ago and 
 discussed
 it with Pavel Minayev but had a different solution then. I now rehash
 it with a new suggestion:

 bit -- 1 bit
 byte -- 8 bits signed
 ubyte -- 8 bits unsigned
 int16 -- 16 bits signed
 uint16 -- 16 bits unsigned
 int32, uint32,int64,uint64, etc

 You can provide a temporary standard header that will provide the 
 alternate
 names you provided on http://www.digitalmars.com/d/type.html until people
 have migrated to the new system I suggested here.

 Reasons for my suggestion are that:
 1) It is more logical because it shows the length of the variable.

 2) It won't suffer from issues if there is an addition of more integer
 types, such as 256 and 512 bit integers. This is what caused the whole
 mess with int and long in C/C++, so you are just dooming us to the same
 mess. Pavel Minayev said that # of bits in processors increase
 logarithmically. We cannot assume this to always be the case, especially
 if processors ever develop serial internal buses to space components out
 more. If that ever happens, and it will likely happen some day, then the
 size of integers won't really matter in terms of processor size.
 Scientific computers will likely have the capability for much larger
 integers.

 3) It will cause less confusion between C and C++ and what people
 remember from various systems (such as i386, long is 32 bits).

 4) It will cause less issues for automatic conversions, especially using
 tools like sed or awk.

 5) It will cause people to think more about what names they use when
 converting.

 6) This method has proved effective for cross platform in Mozilla's
 prInt32, etc.

 7) It'll be easier for embedded system designers who want to make,
 say, 24-bit integers to implement it in a meaningful manner.
 8) cent and ucent is not a good name for a 128-bit variable. First
 of all, it might be too easily mixed up with a simple structure for
 representing currency. Second of all, 128 is not 100. In fact, a 128-bit
 integer simply backs up what I said in 2. Naming data types is getting
 ridiculous. What is longer than long? I guess it could be 'extended' or
 'stretch', but seriously... Let's make things a bit less complicated.

What no go all the way... "byte" -> "int8" "float" -> "float32" "double" -> "float64" "real" -> "float80" (intel only?) "char" -> "char8" "wchar" -> "char16" "dchar" -> "char32" Regan -- Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/
Sep 22 2004
parent reply Regan Heath <regan netwin.co.nz> writes:
Cross-posted from the old group 'D' to 'digitalmars.D'.

On Thu, 23 Sep 2004 09:21:52 +1200, Regan Heath <regan netwin.co.nz> wrote:
 On Wed, 22 Sep 2004 17:09:37 -0400, Brian Bober <netdemonz yahoo.com> 
 wrote:
 I believe integer data types (http://www.digitalmars.com/d/), such as 
 long,
 should be reconsidered. I brought this up a couple years ago and 
 discussed
 it with Pavel Minayev but had a different solution then. I now rehash
 it with a new suggestion:

 bit -- 1 bit
 byte -- 8 bits signed
 ubyte -- 8 bits unsigned
 int16 -- 16 bits signed
 uint16 -- 16 bits unsigned
 int32, uint32,int64,uint64, etc

 You can provide a temporary standard header that will provide the 
 alternate
 names you provided on http://www.digitalmars.com/d/type.html until 
 people
 have migrated to the new system I suggested here.

 Reasons for my suggestion are that:
 1) It is more logical because it shows the length of the variable.

 2) It won't suffer from issues if there is an addition of more integer
 types, such as 256 and 512 bit integers. This is what caused the whole
 mess with int and long in C/C++, so you are just dooming us to the same
 mess. Pavel Minayev said that # of bits in processors increase
 logarithmically. We cannot assume this to always be the case, especially
 if processors ever develop serial internal buses to space components out
 more. If that ever happens, and it will likely happen some day, then the
 size of integers won't really matter in terms of processor size.
 Scientific computers will likely have the capability for much larger
 integers.

 3) It will cause less confusion between C and C++ and what people
 remember from various systems (such as i386, long is 32 bits).

 4) It will cause less issues for automatic conversions, especially using
 tools like sed or awk.

 5) It will cause people to think more about what names they use when
 converting.

 6) This method has proved effective for cross platform in Mozilla's
 prInt32, etc.

 7) It'll be easier for embedded system designers who want to make,
 say, 24-bit integers to implement it in a meaningful manner.
 8) cent and ucent is not a good name for a 128-bit variable. First
 of all, it might be too easily mixed up with a simple structure for
 representing currency. Second of all, 128 is not 100. In fact, a 128-bit
 integer simply backs up what I said in 2. Naming data types is getting
 ridiculous. What is longer than long? I guess it could be 'extended' or
 'stretch', but seriously... Let's make things a bit less complicated.

What no go all the way... "byte" -> "int8" "float" -> "float32" "double" -> "float64" "real" -> "float80" (intel only?) "char" -> "char8" "wchar" -> "char16" "dchar" -> "char32" Regan

-- Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/
Sep 22 2004
next sibling parent Regan Heath <regan netwin.co.nz> writes:
(no offence intended to anyone except myself)
My england very bad in this post :(


On Thu, 23 Sep 2004 11:36:26 +1200, Regan Heath <regan netwin.co.nz> wrote:
 Cross-posted from the old group 'D' to 'digitalmars.D'.

 On Thu, 23 Sep 2004 09:21:52 +1200, Regan Heath <regan netwin.co.nz> 
 wrote:
 On Wed, 22 Sep 2004 17:09:37 -0400, Brian Bober <netdemonz yahoo.com> 
 wrote:
 I believe integer data types (http://www.digitalmars.com/d/), such as 
 long,
 should be reconsidered. I brought this up a couple years ago and 
 discussed
 it with Pavel Minayev but had a different solution then. I now rehash
 it with a new suggestion:

 bit -- 1 bit
 byte -- 8 bits signed
 ubyte -- 8 bits unsigned
 int16 -- 16 bits signed
 uint16 -- 16 bits unsigned
 int32, uint32,int64,uint64, etc

 You can provide a temporary standard header that will provide the 
 alternate
 names you provided on http://www.digitalmars.com/d/type.html until 
 people
 have migrated to the new system I suggested here.

 Reasons for my suggestion are that:
 1) It is more logical because it shows the length of the variable.

 2) It won't suffer from issues if there is an addition of more integer
 types, such as 256 and 512 bit integers. This is what caused the whole
 mess with int and long in C/C++, so you are just dooming us to the same
 mess. Pavel Minayev said that # of bits in processors increase
 logarithmically. We cannot assume this to always be the case, 
 especially
 if processors ever develop serial internal buses to space components 
 out
 more. If that ever happens, and it will likely happen some day, then 
 the
 size of integers won't really matter in terms of processor size.
 Scientific computers will likely have the capability for much larger
 integers.

 3) It will cause less confusion between C and C++ and what people
 remember from various systems (such as i386, long is 32 bits).

 4) It will cause less issues for automatic conversions, especially 
 using
 tools like sed or awk.

 5) It will cause people to think more about what names they use when
 converting.

 6) This method has proved effective for cross platform in Mozilla's
 prInt32, etc.

 7) It'll be easier for embedded system designers who want to make,
 say, 24-bit integers to implement it in a meaningful manner.
 8) cent and ucent is not a good name for a 128-bit variable. First
 of all, it might be too easily mixed up with a simple structure for
 representing currency. Second of all, 128 is not 100. In fact, a 
 128-bit
 integer simply backs up what I said in 2. Naming data types is getting
 ridiculous. What is longer than long? I guess it could be 'extended' or
 'stretch', but seriously... Let's make things a bit less complicated.

What no go all the way... "byte" -> "int8" "float" -> "float32" "double" -> "float64" "real" -> "float80" (intel only?) "char" -> "char8" "wchar" -> "char16" "dchar" -> "char32" Regan


-- Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/
Sep 22 2004
prev sibling parent Brian Bober <netdemonz yahoo.com> writes:
Yeah, sorry about the confusion of there being two threads on this... I 
accidentally submitted the article by pressing the wrong buttons 
(CTRL+RETURN, thank you Pan!) before I was finished writing it, but 
thought I lost it, then submitted another, rewritten better, to the wrong
group :-/ (I guess today is not my day). I have a quoted response for you
in the thread titled "Integer names should be renamed", and sent at
9/22/2004.

Let's bring the discussion to the one that first posted in this group
"Integer names should be renamed" so that there is only one thread.
Sep 22 2004