Who likes short shorts?

[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?

 

[user923005]

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

 

[Malcolm McLean]

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.

 

[CJ]

That's a nice bit of lateral thinking.

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?

 

[Richard Heathfield]

CJ said:

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.

 

[Malcolm McLean]

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.

 

[CJ]

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.

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

 

[Walter Roberson]

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.

 

[Army1987]

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

 

[Tomás Ó hÉilidhe]

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;

 

[Bart]

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 = %? \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.

 

[cr88192]

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...

 

[J. J. Farrell]

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.

 

[Serve Laurijssen]

Tubular Technician:



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

 

[Willem]

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

 

[Philipp Klaus Krause]

Tubular Technician:



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

 

[Richard Bos]

Hello, world!

Hello, twink.

Richard

 

[Army1987]

"Army1987" <[email protected]> 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?)

 

[Randy Howard]

'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....

 

[CJ]

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

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