Hello, world!

(something I was wondering for a long time)

Since C99 does have 'long long', wouldn't it be more consistent if 
there also was a 'short short' type?

That way, plain int could be 64 bits on platforms where that makes
sense, and still two smaller types would be free designating 32 and
16 bit types.

What does everyone think?

On Feb 8, 4:43=A0pm, Tubular Technician <n...@spam.invalid> wrote:
> Hello, world!
>
> (something I was wondering for a long time)
>
> Since C99 does have 'long long', wouldn't it be more consistent if
> there also was a 'short short' type?
>
> That way, plain int could be 64 bits on platforms where that makes
> sense, and still two smaller types would be free designating 32 and
> 16 bit types.
>
> What does everyone think?

http://www.dinkumware.com/manuals/?manual=3Dcompleat&page=3Dstdint.html

"Tubular Technician" <no@spam.invalid> wrote in message 
> Hello, world!
> 
> (something I was wondering for a long time)
> 
> Since C99 does have 'long long', wouldn't it be more consistent if 
> there also was a 'short short' type?
> 
> That way, plain int could be 64 bits on platforms where that makes
> sense, and still two smaller types would be free designating 32 and
> 16 bit types.
> 
> What does everyone think?
> 
That's a nice bit of lateral thinking.

-- 
Free games and programming goodies.
http://www.personal.leeds.ac.uk/~bgy1mm

On Feb 9, 7:41 am, "Malcolm McLean" <regniz...@btinternet.com> wrote:
> "Tubular Technician" <n...@spam.invalid> wrote in message
> > Hello, world!
>
> > (something I was wondering for a long time)
>
> > Since C99 does have 'long long', wouldn't it be more consistent if
> > there also was a 'short short' type?
>
> > That way, plain int could be 64 bits on platforms where that makes
> > sense, and still two smaller types would be free designating 32 and
> > 16 bit types.
>
> > What does everyone think?
>
> That's a nice bit of lateral thinking.
>
> --
> Free games and programming goodies.http://www.personal.leeds.ac.uk/~bgy1mm

If, in bits, a long long is twice the size of a long, a short short
should be half the size of a short.  Is that not a char?

CJ said:

> On Feb 9, 7:41 am, "Malcolm McLean" <regniz...@btinternet.com> wrote:
>> "Tubular Technician" <n...@spam.invalid> wrote in message
>> > Hello, world!
>>
>> > (something I was wondering for a long time)
>>
>> > Since C99 does have 'long long', wouldn't it be more consistent if
>> > there also was a 'short short' type?
>>
>> > That way, plain int could be 64 bits on platforms where that makes
>> > sense, and still two smaller types would be free designating 32 and
>> > 16 bit types.
>>
>> > What does everyone think?
>>
>> That's a nice bit of lateral thinking.
>>
>> --
>> Free games and programming
>> goodies.http://www.personal.leeds.ac.uk/~bgy1mm
> 
> If, in bits, a long long is twice the size of a long, a short short
> should be half the size of a short.  Is that not a char?

Not necessarily. It is perfectly legal to have, say, a 37-bit char and a 
37-bit short.


-- 
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

"CJ" <spambox1@mindspring.com> wrote in message news
>
> If, in bits, a long long is twice the size of a long, a short short
> should be half the size of a short.  Is that not a char?
>
So we've got rid of that annoying overwork of the 'char' keyword to mean 
"small integer". Where int is 64 bits, short 32, short shor 16, we can 
introducue a short short short type of 8 bits.
Now I know what you're going to say. Shouldn't we have a short short short 
short? The answer is no. That violates the rule of three (see website). 
short short short short should be s4, and is, conveniently, 4 bits on a 
64-bit system.

-- 
Free games and programming goodies.
http://www.personal.leeds.ac.uk/~bgy1mm

 

On Feb 9, 10:41 am, "Malcolm McLean" <regniz...@btinternet.com> wrote:
> "CJ" <spamb...@mindspring.com> wrote in message news
>
> > If, in bits, a long long is twice the size of a long, a short short
> > should be half the size of a short.  Is that not a char?
>
> So we've got rid of that annoying overwork of the 'char' keyword to mean
> "small integer". Where int is 64 bits, short 32, short shor 16, we can
> introducue a short short short type of 8 bits.
> Now I know what you're going to say. Shouldn't we have a short short short
> short? The answer is no. That violates the rule of three (see website).
> short short short short should be s4, and is, conveniently, 4 bits on a
> 64-bit system.
>
> --
> Free games and programming goodies.http://www.personal.leeds.ac.uk/~bgy1mm

LOL, I enjoyed your addition to the "rule of three," however I don't
totally agree with it.  I a five dimensional array container that I
conceptualized, implemented and functions quite well.  True, most
developers who follow on to my logic have difficulty visualizing
beyond three dimensions, they can learn how it works.

Physics is rapidly approaching complete acceptance of eleven
dimensions since realizing it united the various string theories into
one "magically."

That said, a short short is as redundant as long long.  I understand
as our technology advances, increasing variable storage to currently
inconceivable widths, new "language" will always be needed to insure
backwards portability with existing software. But, at some point we
will stop this practice.

Perhaps a long should be the largest integer available on all
hardware, and int should be half the size of a long, a short half the
size of an int, and a char half the size of a short.  So long as the
number of bits reflected in each primitive defined is accessible, one
can adapt their use accordingly.

When our technology extends to 128-bit system, we do not simply adopt
"long long long" declaration for a 128-bit integer.

cj

In article <H8OdneciMrE-VDDanZ2dnUVZ8vydnZ2d@bt.com>,
Malcolm McLean <regniztar@btinternet.com> wrote:

>So we've got rid of that annoying overwork of the 'char' keyword to mean 
>"small integer". Where int is 64 bits, short 32, short shor 16, we can 
>introducue a short short short type of 8 bits.
>Now I know what you're going to say. Shouldn't we have a short short short 
>short? The answer is no. That violates the rule of three (see website). 
>short short short short should be s4, and is, conveniently, 4 bits on a 
>64-bit system.

no, short short short short *should* be a single bit. Until we
get to 256 bit systems, for which short short short short short short
would be a bit.
-- 
  "I will speculate that [...] applications [...] could actually see a
  performance boost for most users by going dual-core [...] because it
  is running the adware and spyware that [...] are otherwise slowing
  down the single CPU that user has today"           -- Herb Sutter

user923005 wrote:

> On Feb 8, 4:43 pm, Tubular Technician <n...@spam.invalid> wrote:
>> Hello, world!
>>
>> (something I was wondering for a long time)
>>
>> Since C99 does have 'long long', wouldn't it be more consistent if
>> there also was a 'short short' type?
>>
>> That way, plain int could be 64 bits on platforms where that makes
>> sense, and still two smaller types would be free designating 32 and
>> 16 bit types.
>>
>> What does everyone think?
> 
> http://www.dinkumware.com/manuals/?manual=compleat&page=stdint.html

These are ultimately just typedefs for char, signed char, unsigned char,
short, unsigned short, int, unsigned int, long, unsigned long, long long
and unsigned long long. (The implementation might define other types.)
The OP is asking to add to that list. But then, which will the conversion
specifier for *printf? "hhd" is already used for signed char...
More seriously, I think that a short short type would likely have the same
size of short, or char, on most systems. More useful would be a short
float, which would have the same size of a short int but wider dynamic
range: http://en.wikipedia.org/wiki/Half_precision


-- 
Army1987 (Replace "NOSPAM" with "email")

Tubular Technician:

> Hello, world!
> 
> (something I was wondering for a long time)
> 
> Since C99 does have 'long long', wouldn't it be more consistent if 
> there also was a 'short short' type?
> 
> That way, plain int could be 64 bits on platforms where that makes
> sense, and still two smaller types would be free designating 32 and
> 16 bit types.
> 
> What does everyone think?


I'd rather the idea where you specify:

1) The range you want
2) The optimisation you want (e.g. for speed, for less memory consumption)

Something like:

    int(min = -235,max = 78933,opt = fast) i;

-- 
Tom�s � h�ilidhe

On Feb 9, 8:16=A0pm, Army1987 <army1...@NOSPAM.it> wrote:
> user923005 wrote:
> > On Feb 8, 4:43=A0pm, Tubular Technician <n...@spam.invalid> wrote:
> >> Hello, world!
>
> >> (something I was wondering for a long time)
>
> >> Since C99 does have 'long long', wouldn't it be more consistent if
> >> there also was a 'short short' type?
>
> >> That way, plain int could be 64 bits on platforms where that makes
> >> sense, and still two smaller types would be free designating 32 and
> >> 16 bit types.
>
> >> What does everyone think?
>
> >http://www.dinkumware.com/manuals/?manual=3Dcompleat&page=3Dstdint.html
>
> These are ultimately just typedefs for char, signed char, unsigned char,
> short, unsigned short, int, unsigned int, long, unsigned long, long long
> and unsigned long long. (The implementation might define other types.)
> The OP is asking to add to that list. But then, which will the conversion
> specifier for *printf? "hhd" is already used for signed char...

All these printf specifiers seem to be getting out of hand. All that's
needed for integral values really is signed/unsigned, passed as the
largest int width. After all chars and shorts need to be widened to
the stack width anyway (for machines with a stack..).

And in practice perhaps a single format specifier, ? or whatever,
filled in by the compiler (for const format strings) with the default
for whatever is being passed:

printf("X =3D %? \n", x);   /* Don't need to know exact type of x */

Then there'd be a lot less format specifiers to remember.

> More seriously, I think that a short short type would likely have the same=

> size of short, or char, on most systems. More useful would be a short
> float, which would have the same size of a short int but wider dynamic
> range:

With one syntax I use (derived from Fortran) you just specify how many
bits directly:

int*16 a
float*16 x

leaving the compiler to sort out how to implement it. I know,
stdint.h(?) has a range defined, and with a bunch of defines, a lot is
possible, but it's not quite the same as having it actually in the
language.

--
Bart

"Army1987" <army1987@NOSPAM.it> wrote in message 
news:fol1mh$cpu$1@tdi.cu.mi.it...
> user923005 wrote:
>
>> On Feb 8, 4:43 pm, Tubular Technician <n...@spam.invalid> wrote:
>>> Hello, world!
>>>
>>> (something I was wondering for a long time)
>>>
>>> Since C99 does have 'long long', wouldn't it be more consistent if
>>> there also was a 'short short' type?
>>>
>>> That way, plain int could be 64 bits on platforms where that makes
>>> sense, and still two smaller types would be free designating 32 and
>>> 16 bit types.
>>>
>>> What does everyone think?
>>
>> http://www.dinkumware.com/manuals/?manual=compleat&page=stdint.html
>
> These are ultimately just typedefs for char, signed char, unsigned char,
> short, unsigned short, int, unsigned int, long, unsigned long, long long
> and unsigned long long. (The implementation might define other types.)
> The OP is asking to add to that list. But then, which will the conversion
> specifier for *printf? "hhd" is already used for signed char...
> More seriously, I think that a short short type would likely have the same
> size of short, or char, on most systems. More useful would be a short
> float, which would have the same size of a short int but wider dynamic
> range: http://en.wikipedia.org/wiki/Half_precision
>

'short float' is an interesting naming idea.
I added this type, but ended up calling it "float16"...

so, possible:
'short float': 16 bit float
'double double': 128 bit float
'double long': 128 bit integer (not to be confused with 'long double' or 
'long long').

at present I call these types __float16, __float128, and __int128, but a 
more "conventional" set of names could make sense...


>
> -- 
> Army1987 (Replace "NOSPAM" with "email") 

CJ wrote:
> 
> If, in bits, a long long is twice the size of a long, a short short
> should be half the size of a short.

What if it isn't?

> Is that not a char?

Not necessarily.

"Tom�s � h�ilidhe" <toe@lavabit.com> schreef in bericht 
news:Xns9A3FD7A05F81Dtoelavabitcom@194.125.133.14...
> Tubular Technician:
>
>> Hello, world!
>>
>> (something I was wondering for a long time)
>>
>> Since C99 does have 'long long', wouldn't it be more consistent if
>> there also was a 'short short' type?
>>
>> That way, plain int could be 64 bits on platforms where that makes
>> sense, and still two smaller types would be free designating 32 and
>> 16 bit types.
>>
>> What does everyone think?
>
>
> I'd rather the idea where you specify:
>
> 1) The range you want
> 2) The optimisation you want (e.g. for speed, for less memory consumption)
>
> Something like:
>
>    int(min = -235,max = 78933,opt = fast) i;

brrr pandora and boxes is what Im thinking of now
There are lots of practical concerns with this 

Bart wrote:
) With one syntax I use (derived from Fortran) you just specify how many
) bits directly:
)
) int*16 a
) float*16 x
)
) leaving the compiler to sort out how to implement it. I know,
) stdint.h(?) has a range defined, and with a bunch of defines, a lot is
) possible, but it's not quite the same as having it actually in the
) language.

You mean like bit fields ?

  int a:16;
  float x:16;

I think that would be the least intrusive way of adding it to C.


SaSW, Willem
-- 
Disclaimer: I am in no way responsible for any of the statements
            made in the above text. For all I know I might be
            drugged or something..
            No I'm not paranoid. You all think I'm paranoid, don't you !
#EOT

Tom�s � h�ilidhe schrieb:
> Tubular Technician:
> 
>> Hello, world!
>>
>> (something I was wondering for a long time)
>>
>> Since C99 does have 'long long', wouldn't it be more consistent if 
>> there also was a 'short short' type?
>>
>> That way, plain int could be 64 bits on platforms where that makes
>> sense, and still two smaller types would be free designating 32 and
>> 16 bit types.
>>
>> What does everyone think?
> 
> 
> I'd rather the idea where you specify:
> 
> 1) The range you want
> 2) The optimisation you want (e.g. for speed, for less memory consumption)
> 
> Something like:
> 
>     int(min = -235,max = 78933,opt = fast) i;
> 

Would that be worth the effort over current types such as
int_fast32_t
?

Philipp

Tubular Technician <no@spam.invalid> wrote:

> Hello, world!

Hello, twink.

Richard

cr88192 wrote:

> "Army1987" <army1987@NOSPAM.it> wrote in message 

> 'short float' is an interesting naming idea.
> I added this type, but ended up calling it "float16"...
> 
> so, possible:
> 'short float': 16 bit float
> 'double double': 128 bit float
> 'double long': 128 bit integer (not to be confused with 'long double' or 
> 'long long').
'double long' is the same as 'long double' in standard C. If you want your
implementation without adding new _Keywords, the best (the least bad)
thing I can think of is long long long... (Or maybe double long int?)


-- 
Army1987 (Replace "NOSPAM" with "email")

On Mon, 11 Feb 2008 03:40:03 -0600, Army1987 wrote
(in article <fop55i$649$2@tdi.cu.mi.it>):

> cr88192 wrote:
> 
>> "Army1987" <army1987@NOSPAM.it> wrote in message 
> 
>> 'short float' is an interesting naming idea.
>> I added this type, but ended up calling it "float16"...
>> 
>> so, possible:
>> 'short float': 16 bit float
>> 'double double': 128 bit float
>> 'double long': 128 bit integer (not to be confused with 'long double' or 
>> 'long long').
> 'double long' is the same as 'long double' in standard C. If you want your
> implementation without adding new _Keywords, the best (the least bad)
> thing I can think of is long long long... (Or maybe double long int?)

just as bad as "long long" was.  How about extralong?  massive?  Is 
that a long in your pocket or are you just....



-- 
Randy Howard (2reply remove FOOBAR)
"The power of accurate observation is called cynicism by those 
 who have not got it."  - George Bernard Shaw

On Feb 11, 5:22 am, Randy Howard <randyhow...@FOOverizonBAR.net>
wrote:
> On Mon, 11 Feb 2008 03:40:03 -0600, Army1987 wrote
> (in article <fop55i$64...@tdi.cu.mi.it>):
>
> > cr88192 wrote:
>
> >> "Army1987" <army1...@NOSPAM.it> wrote in message
>
> >> 'short float' is an interesting naming idea.
> >> I added this type, but ended up calling it "float16"...
>
> >> so, possible:
> >> 'short float': 16 bit float
> >> 'double double': 128 bit float
> >> 'double long': 128 bit integer (not to be confused with 'long double' or
> >> 'long long').
> > 'double long' is the same as 'long double' in standard C. If you want your
> > implementation without adding new _Keywords, the best (the least bad)
> > thing I can think of is long long long... (Or maybe double long int?)
>
> just as bad as "long long" was.  How about extralong?  massive?  Is
> that a long in your pocket or are you just....
>
> --
> Randy Howard (2reply remove FOOBAR)
> "The power of accurate observation is called cynicism by those
>  who have not got it."  - George Bernard Shaw

How about notation similar to c++ templates one specifies the accuracy
in bits for integers, and the precision for reals and let the compile
"pick" the "object" to contain it.

int<1> a truly Boolean variable (_Bool)
int<8> a UTF-7 char, or signed smallint
int<16> a signed short
int<32> a signed int
int<256> a "long long long long" ???

unsigned<64> an unsigned long long

real<6.2> a float
real<12.2> a double

This allows for future compatibility to CPUs yet to be designed.

Just a thought.
cj

"CJ" <spambox1@mindspring.com> wrote in message 
news:2d8408dd-a73b-4df5-9bec-288d7549d696@d4g2000prg.googlegroups.com...

>> > cr88192 wrote:

>> >> so, possible:
>> >> 'short float': 16 bit float
>> >> 'double double': 128 bit float
>> >> 'double long': 128 bit integer (not to be confused with 'long double' 
>> >> or
>> >> 'long long').

> How about notation similar to c++ templates one specifies the accuracy
> in bits for integers, and the precision for reals and let the compile
> "pick" the "object" to contain it.
>
> int<1> a truly Boolean variable (_Bool)

I take it that one's unsigned?

> int<8> a UTF-7 char, or signed smallint
> int<16> a signed short
> int<32> a signed int
> int<256> a "long long long long" ???
> unsigned<64> an unsigned long long

> real<6.2> a float
> real<12.2> a double

Is this really in C++? Looks more like fixed point than float.

--
Bart 

"Walter Roberson" <roberson@ibd.nrc-cnrc.gc.ca> wrote in message 
news:fokl2q$8g2$1@canopus.cc.umanitoba.ca...
> In article <H8OdneciMrE-VDDanZ2dnUVZ8vydnZ2d@bt.com>,
> Malcolm McLean <regniztar@btinternet.com> wrote:
>
>>So we've got rid of that annoying overwork of the 'char' keyword to mean
>>"small integer". Where int is 64 bits, short 32, short shor 16, we can
>>introducue a short short short type of 8 bits.
>>Now I know what you're going to say. Shouldn't we have a short short short
>>short? The answer is no. That violates the rule of three (see website).
>>short short short short should be s4, and is, conveniently, 4 bits on a
>>64-bit system.
>
> no, short short short short *should* be a single bit. Until we
> get to 256 bit systems, for which short short short short short short
> would be a bit.

I suggest short, shorter and shortest.

Or, short, very short, ultra short (a bit like vhf and uhf).

And perhaps medium for ints which are neither short nor long.

Otherwise it gets a bit silly..

--
Bart 

On Mon, 11 Feb 2008 13:53:42 -0600, CJ wrote
(in article 
<2d8408dd-a73b-4df5-9bec-288d7549d696@d4g2000prg.googlegroups.com>):

> On Feb 11, 5:22 am, Randy Howard <randyhow...@FOOverizonBAR.net>
> wrote:
>> On Mon, 11 Feb 2008 03:40:03 -0600, Army1987 wrote
>> (in article <fop55i$64...@tdi.cu.mi.it>):
>> 
>>> cr88192 wrote:
>> 
>>>> "Army1987" <army1...@NOSPAM.it> wrote in message
>> 
>>>> 'short float' is an interesting naming idea.
>>>> I added this type, but ended up calling it "float16"...
>> 
>>>> so, possible:
>>>> 'short float': 16 bit float
>>>> 'double double': 128 bit float
>>>> 'double long': 128 bit integer (not to be confused with 'long double' or
>>>> 'long long').
>>> 'double long' is the same as 'long double' in standard C. If you want your
>>> implementation without adding new _Keywords, the best (the least bad)
>>> thing I can think of is long long long... (Or maybe double long int?)
>> 
>> just as bad as "long long" was.  How about extralong?  massive?  Is
>> that a long in your pocket or are you just....
>> 
>> --
>> Randy Howard (2reply remove FOOBAR)
>> "The power of accurate observation is called cynicism by those
>> who have not got it."  - George Bernard Shaw
> 
> How about notation similar to c++ templates one specifies the accuracy
> in bits for integers, and the precision for reals and let the compile
> "pick" the "object" to contain it.
> 
> int<1> a truly Boolean variable (_Bool)
> int<8> a UTF-7 char, or signed smallint
> int<16> a signed short
> int<32> a signed int
> int<256> a "long long long long" ???
> 
> unsigned<64> an unsigned long long
> 
> real<6.2> a float
> real<12.2> a double
> 
> This allows for future compatibility to CPUs yet to be designed.

I was joking around actually.  I guess emoticons really are still 
required even in silly cases.

Anyway, more seriously why not just use something like stdint.h 
instead? 

-- 
Randy Howard (2reply remove FOOBAR)
"The power of accurate observation is called cynicism by those 
 who have not got it."  - George Bernard Shaw

On Mon, 11 Feb 2008 14:54:24 -0600, Bartc wrote
(in article <4C2sj.5585$XI.1670@text.news.virginmedia.com>):

> 
> "Walter Roberson" <roberson@ibd.nrc-cnrc.gc.ca> wrote in message 
> news:fokl2q$8g2$1@canopus.cc.umanitoba.ca...
>> In article <H8OdneciMrE-VDDanZ2dnUVZ8vydnZ2d@bt.com>,
>> Malcolm McLean <regniztar@btinternet.com> wrote:
>> 
>>> So we've got rid of that annoying overwork of the 'char' keyword to mean
>>> "small integer". Where int is 64 bits, short 32, short shor 16, we can
>>> introducue a short short short type of 8 bits.
>>> Now I know what you're going to say. Shouldn't we have a short short short
>>> short? The answer is no. That violates the rule of three (see website).
>>> short short short short should be s4, and is, conveniently, 4 bits on a
>>> 64-bit system.
>> 
>> no, short short short short *should* be a single bit. Until we
>> get to 256 bit systems, for which short short short short short short
>> would be a bit.
> 
> I suggest short, shorter and shortest.
> 
> Or, short, very short, ultra short (a bit like vhf and uhf).
> 
> And perhaps medium for ints which are neither short nor long.
> 
> Otherwise it gets a bit silly..

It's already silly.  :-)

-- 
Randy Howard (2reply remove FOOBAR)
"The power of accurate observation is called cynicism by those 
 who have not got it."  - George Bernard Shaw

In article <4C2sj.5585$XI.1670@text.news.virginmedia.com>,
Bartc <bc@freeuk.com> wrote:
>
>"Walter Roberson" <roberson@ibd.nrc-cnrc.gc.ca> wrote in message 
>news:fokl2q$8g2$1@canopus.cc.umanitoba.ca...

>> no, short short short short *should* be a single bit. Until we
>> get to 256 bit systems, for which short short short short short short
>> would be a bit.

>I suggest short, shorter and shortest.

>Or, short, very short, ultra short (a bit like vhf and uhf).

>And perhaps medium for ints which are neither short nor long.

Tall, Grande, and Vente ?
-- 
   "Any sufficiently advanced bug is indistinguishable from a feature."
   -- Rich Kulawiec

"Walter Roberson" <roberson@ibd.nrc-cnrc.gc.ca> wrote in message 
> 
> Tall, Grande, and Vente ?
> 
Or double shorts. 

-- 
Free games and programming goodies.
http://www.personal.leeds.ac.uk/~bgy1mm

"CJ" <spambox1@mindspring.com> wrote in message 
news:2d8408dd-a73b-4df5-9bec-288d7549d696@d4g2000prg.googlegroups.com...
> How about notation similar to c++ templates one specifies the accuracy
> in bits for integers, and the precision for reals and let the compile
> "pick" the "object" to contain it.
>
> int<1> a truly Boolean variable (_Bool)

_Bool (or bool, with <stdbool.h>) works fine.

> int<8> a UTF-7 char, or signed smallint

int8_t

> int<16> a signed short

int16_t

> int<32> a signed int

int32_t

> int<256> a "long long long long" ???

int256_t, one day...

> unsigned<64> an unsigned long long

uint64_t

It appears you haven't heard of <stdint.h>...

> real<6.2> a float
> real<12.2> a double

Hmmm; perhaps a <stdfloat.h> is needed as well?

> This allows for future compatibility to CPUs yet to be designed.

No, it guarantees incompatibility with any (present or future) CPU that 
isn't designed exactly how you expect (i.e. power-of-two-sized integer 
types).  C's original set of integer types are specified as "at least" as 
large as a certain size for a reason: not all systems are alike, and 
assuming even basic things like register size would make the language less 
portable.  If you want a specific size integer, and don't care about _your_ 
code being portable, those are now available as well with any decent 
implementation.

S

-- 
Stephen Sprunk         "God does not play dice."  --Albert Einstein
CCIE #3723         "God is an inveterate gambler, and He throws the
K5SSS        dice at every possible opportunity." --Stephen Hawking 

roberson@ibd.nrc-cnrc.gc.ca (Walter Roberson) wrote:

> Bartc <bc@freeuk.com> wrote:
> >I suggest short, shorter and shortest.
> >Or, short, very short, ultra short (a bit like vhf and uhf).
> >And perhaps medium for ints which are neither short nor long.
> 
> Tall, Grande, and Vente ?

How about Mocha? And I want an Assam double, and Ozzie programmers will
desire a Pea_Soup float.

Richard

Bartc wrote:
> I suggest short, shorter and shortest.
> 
> Or, short, very short, ultra short (a bit like vhf and uhf).
> 
> And perhaps medium for ints which are neither short nor long.
> 
> Otherwise it gets a bit silly..
>
What about XXS, XS, S, M, L, XL, XXL for _Bool, char, short, int, long,
long long, __int128? So we can have 3XL for 256 bits integers, and 7XL for
4096-bit integers.


-- 
Army1987 (Replace "NOSPAM" with "email")