Standard integer types vs <stdint.h> types

[Richard Heathfield]

Re: Standard integer types vs &lt;stdint.h&gt ; types

Flash Gordon said:

Richard Heathfield wrote, On 18/01/08 11:29:

<snip>

>At the very least, [C with new integer types] becomes *uglier* to read.
>C as it stands, if well-written, is at least a relatively elegant
>language, not just technically and syntactically but also visually. All
>these stretched-out underscore-infested type names will be a real
>nuisance when scanning quickly through unfamiliar code.

>
That, in my opinion, is an argument over the chosen names rather than
the addition of the types.

Yes, it is. My argument against the new types *was* that they are
unnecessary, but I accept that what I really mean is that *I* don't see a
need for them in the kind of code I tend to write. If they will bring real
benefits to other C programmers, well, they're a wart I can live with,
since at least I won't have to come across it all that often, and then
only in other people's code, not my own.

But they could have found better names, surely? Abigail, for instance. Or
Rhododendron.

Yeah, all right, maybe not those precise names... :-)

Personally I don't find underscores in names
a problem for scanning, especially once I have learnt the patterns.

Is ugliness a problem? I guess ugliness is in the eye of the beholder.

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

[Richard Heathfield]

Re: Standard integer types vs &lt;stdint.h&gt ; types

euler70@gmail.c om said:

<snip>

If I
want a fast type with at least 32-bit range, C90 says I should choose
long. This might end up being a good choice for one compiler, but on
another compiler where long has another de-facto purpose for long that
causes long to be significantly less efficient than another available
at-least-32-bit type, then half of the intent behind my choice of long
has been ruined.
>
If you argue against the preceding paragraph by saying "you should not
be so concerned about efficiency",

It depends. :-) We cannot and should not *ignore* efficiency.
Nevertheless, there is more to life than speed. Correctness, clarity,
generality and portability are all important too. But, as I said before,
there *are* occasions when you need to push the hardware as fast as it
will go. I do accept that.

<snip>

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

[Flash Gordon]

Re: Standard integer types vs &lt;stdint.h&gt ; types

Malcolm McLean wrote, On 18/01/08 12:19:

>
"Bart C" <bc@freeuk.comw rote in message news:fI%jj.7915 3

>My own view is the opposite. How can one program without knowing the
>bitsize of one's datatypes? But I've probably spent too many years
>low-level
>programming.

<snip>

However normally you don't. The integer represents something, which is
normally an index into an array (even chars are really usually indices
into glyph tables).

Please be aware that Malcolm seems to be the only person who thinks this.

So what you need is an integer that can index the
biggest array possible, and is also fast. Which on some architectures is
a bit of a contradiction, because the vast majority of your arrays will
never grow to more than a hundred items or so, whilst there is a flat
memory space that is many gigabytes in size.

As a result Malcolm seems to be the only person who thinks this.

The flaws in Malcolm's arguments have been pointed out many times so you
should be able to find them using Google.
--
Flash Gordon

[Flash Gordon]

Re: Standard integer types vs &lt;stdint.h&gt ; types

Malcolm McLean wrote, On 18/01/08 13:25:

<euler70@gmail. comwrote in message news:

>On Jan 18, 6:41 am, Richard Heathfield <r...@see.sig.i nvalidwrote:

>>Bart C said:
>>>
>"Richard Heathfield" <r...@see.sig.i nvalidwrote in message
>>news:nISdnc6D MakBEA3anZ2dnUV Z8uqdnZ2d@bt.co m...
>>Bart C said:
>>>
>>>How can one program without knowing the bitsize of one's datatypes?
>>>
>>We know the minimum value range of our data types - why would we
>>need >to
>>know more than that?
>>>
>For ... performance?
>>>
>><shrugFor some, maybe. I generally find that simply selecting good
>>algorithms is sufficient to give me "good-enough" performance. Yeah,
>>absolutely, there are some situations where you need to hack every last
>>spare clock out, but they are not as common as people like to
>>imagine. I'd
>>rather write clear code than fast code (which doesn't mean I don't
>>like my
>>code to be fast). And in any case, when you start selecting types
>>based on
>>their performance, it won't be long before you discover that what's
>>faster
>>on one machine could well turn out to be slower on another.

>[snip]
>>
>The problem with signed char and [unsigned] (short|int|long |long long)
>is that they are too general purpose. They are at an awkward
>not-very-useful spot between the super-high-level "give me an integer
>object in which I can store any integer value" and the super-low-level
>"give me this many bits that I can play with". As a result, what seems
>to have happened in practice is that different camps have created
>their own de-facto purposes for some of these types. For example in
>the world of Windows, long is essentially a type that has exactly 32
>bits. Elsewhere, long may be the de-facto 64-bit type.
>>
>For portable code, this can become detrimental to efficiency. If I
>want a fast type with at least 32-bit range, C90 says I should choose
>long. This might end up being a good choice for one compiler, but on
>another compiler where long has another de-facto purpose for long that
>causes long to be significantly less efficient than another available
>at-least-32-bit type, then half of the intent behind my choice of long
>has been ruined.
>>
>If you argue against the preceding paragraph by saying "you should not
>be so concerned about efficiency", then I think your reasoning is a
>very short step away from concluding that we can discard our worries
>about type ranges and efficiency and simply use only intmax_t and
>uintmax_t everywhere. Surely this is not the level of abstraction that
>C is intended for.
>>
>This is the reasoning that has led me to conclude that the
>[u]int_(fast|least )N types are more useful than signed char and
>[unsigned] (short|int|long |long long). They allow me to state my
>entire intent instead of stating only half of it and hoping the other
>half works out. Having types that allow me to say "I want the
>(fastest|small est) type that gives me at least N bits" is more useful
>than having types that only allow me to say "I want a type that gives
>me at least N bits".
>>

I absolutely agree.

Do you realise you are agreeing to having several integer types? I
though you wanted there to be only a single one size fits hardly anyone
integer type!

I think we are creating a mess with all these integer types and
conventions on how they should be used.

Urm, he was just saying to use the new types which you say make things work!

However generally I want an integer which can index or count an array,
and is fast, and is signed, because intermediate calculations might go
below zero.

Unsigned arithmetic handles that nicely, but to meet your desires I
suggest you use ptrdiff_t and size_t as appropriate. These types have
been there since at least the 1989 standard was implemented.

This is usually semi-achievable. There will be a fast type the same
width as the address bus, the one bit we can ignore as we are unlikely
to want a char array taking up half memory (we can always resort to
"unsigned" for that special situation), but it might not be the fastest
type, and most arrays will in fact be a lot smaller than the largest
possible array.

See above, the types you want have been supported for a long time. If
you don't like the spelling you can typedef them to something else.
--
Flash Gordon

[Flash Gordon]

Re: Standard integer types vs &lt;stdint.h&gt ; types

Richard Heathfield wrote, On 18/01/08 13:37:

Flash Gordon said:
>

>Richard Heathfield wrote, On 18/01/08 11:29:

<snip discussion of types in stdint.h>

I think we reached this point before.

But they could have found better names, surely? Abigail, for instance. Or
Rhododendron.
>
Yeah, all right, maybe not those precise names... :-)

Of course not those names, they should be Brenda, Heather... ;-)

>Personally I don't find underscores in names
>a problem for scanning, especially once I have learnt the patterns.

>
Is ugliness a problem? I guess ugliness is in the eye of the beholder.

It is indeed. I'm so used to underscores in names that I don't see them
as such I just see N words grouped together.
--
Flash Gordon

[Malcolm McLean]

Re: Standard integer types vs &lt;stdint.h&gt ; types


"Flash Gordon" <spam@flash-gordon.me.ukwro te in message

See above, the types you want have been supported for a long time. If you
don't like the spelling you can typedef them to something else.
>

bool breaks libraries.

If ANSI decides that "s64" shall be the name of a new type, that's fine. If
I define it myself, either the whole world adopts my convention, which is to
say I have usurrped ANSI / ISO, or it is a nuisance to everybody trying to
call or read my code.


--
Free games and programming goodies.

http://www.personal.leeds.ac.uk/~bgy1mm

[jacob navia]

Re: Standard integer types vs &lt;stdint.h&gt ; types

Flash Gordon wrote:

>
There *are* times when you need to know, and there are times when you
need to know a type has at least a specific range, but a lot of the time
you do not care if it is larger.

Rarely.

If I write

int a = 45000;

that will not work in 16 bit implementations .

You HAVE to know the bitsize to know how much data
you can put into an integer!

Potentially, all assignments are affected unless
you never use integer data bigger than 32767.


--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique

http://www.cs.virginia.edu/~lcc-win32

[jacob navia]

Re: Standard integer types vs &lt;stdint.h&gt ; types

Richard Heathfield wrote:

Bart C said:
>

>How can one program without knowing the bitsize of one's datatypes?

>
We know the minimum value range of our data types - why would we need to
know more than that?
>

>But I've probably spent too many years low-level programming.

>
Okay, that's one reason. Any more? Huh? Huh? :-)
>

Consider

int i = 38700;

If you do not care about int size you will never know that
this will not work in 16 bit implementations , or (worst)
i will be initialized to something completely different.

Of course YOU never use data bigger than 32767, as everyone knows.

:-)


--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique

http://www.cs.virginia.edu/~lcc-win32

[Richard Heathfield]

Re: Standard integer types vs &lt;stdint.h&gt ; types

jacob navia said:

Flash Gordon wrote:

>>
>There *are* times when you need to know, and there are times when you
>need to know a type has at least a specific range, but a lot of the time
>you do not care if it is larger.

>
Rarely.
>
If I write
>
int a = 45000;
>
that will not work in 16 bit implementations .

That is not a counter-example to Flash's point. If you need an integer type
that can store 45000, then "you need to know a type has at least a
specific range". Since the least range for int is -32767 to +32767, you
know that this won't do in portable code, so you move up to long int:

long int a = 45000;

This will work just fine in 16 bit implementations , no matter how big a
long int is, because it *must* have at least 32 bits.

You HAVE to know the bitsize to know how much data
you can put into an integer!

No, you have to know whether the value you wish to store will fit into the
range for a given type. If so, it doesn't matter how many /more/ bits it
has. And if not, it still doesn't matter how many bits it has - if your
value doesn't fit, it doesn't fit.

Potentially, all assignments are affected unless
you never use integer data bigger than 32767.

Right, which is why we have this thing called long int.

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

[Richard Heathfield]

Re: Standard integer types vs &lt;stdint.h&gt ; types

jacob navia said:

<snip>

Consider
>
int i = 38700;

Why? It's not guaranteed to work. Instead, consider:

long int i = 38700;

which *is* guaranteed to work.

If you do not care about int size you will never know that
this will not work in 16 bit implementations , or (worst)
i will be initialized to something completely different.

I don't know whose point you're arguing against, but the above response
does not address any statement I have made.

Of course YOU never use data bigger than 32767, as everyone knows.

Not so. But when I do, I use long int. And if I need values higher than
2147483647 and know they can't be negative, I'll use unsigned long int.
And if I need values higher than 4294967295, I'll use my bignum library.

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

[Flash Gordon]

Re: Standard integer types vs &lt;stdint.h&gt ; types

Malcolm McLean wrote, On 18/01/08 15:21:

>
"Flash Gordon" <spam@flash-gordon.me.ukwro te in message

>See above, the types you want have been supported for a long time. If
>you don't like the spelling you can typedef them to something else.
>>

bool breaks libraries.

So don't use it. Use _Bool if you want instead. There is not requirement
for you to #include <stdbool.hto use the new boolean type.

If ANSI decides that "s64" shall be the name of a new type, that's fine.
If I define it myself, either the whole world adopts my convention,
which is to say I have usurrped ANSI / ISO, or it is a nuisance to
everybody trying to call or read my code.

Misusing int as you are want to do causes problems.

Either get yourself on the standard committee and try and get the
language changed
Or find a language that is defined as you want and use that
Or write your own language and use that
Or put up with the language as it is defined.

In any case, by your definition of what is wrong it was wrong in the
1989 standard so stop complaining that these things are rapidly
destroying the language, since that is patently false.
--
Flash Gordon

[Malcolm McLean]

Re: Standard integer types vs &lt;stdint.h&gt ; types


"jacob navia" <jacob@nospam.c omwrote in message

>
If I write
>
int a = 45000;
>
that will not work in 16 bit implementations .
>
You HAVE to know the bitsize to know how much data
you can put into an integer!
>

The question is, why do you want an integer equal to 45000?
We can thinks of lots of possible reasons, but a good one might be that you
have 45000 customer records you wish to read into memory.
Which means that you need 45000 * N bytes of contiguous storage, which most
machines will happily provide for fairly reasonable values of N. But not 16
bit machines.
As long as int is the same as a pointer and memory space is flat, everything
is fine.


--
Free games and programming goodies.

http://www.personal.leeds.ac.uk/~bgy1mm

[CBFalconer]

Re: Standard integer types vs &lt;stdint.h&gt ; types

euler70@gmail.c om wrote:

>

.... snip ...

>
For portable code, this can become detrimental to efficiency. If I
want a fast type with at least 32-bit range, C90 says I should
choose long. This might end up being a good choice for one
compiler, but on another compiler where long has another de-facto
purpose for long that causes long to be significantly less
efficient than another available at-least-32-bit type, then half
of the intent behind my choice of long has been ruined.
>
If you argue against the preceding paragraph by saying "you should
not be so concerned about efficiency", then I think your reasoning
is a very short step away from concluding that we can discard our
worries about type ranges and efficiency and simply use only
intmax_t and uintmax_t everywhere. Surely this is not the level of
abstraction that C is intended for.

I think you have exagerrated the problem. In general there will
only be one beast where you have to be critical of the exact size.
You should set up your own type, and alias it to the appropriate
standard type by using limits.h and conditional defines. Then
write your code in terms of that type. Note that this also allows
for use of other than the multiple of 8 sizes.

--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home .att.net>
Try the download section.



--
Posted via a free Usenet account from http://www.teranews.com

[CBFalconer]

Re: Standard integer types vs &lt;stdint.h&gt ; types

Bart C wrote:

"Richard Heathfield" <rjh@see.sig.in validwrote:

>Bart C said:
>>

>>How can one program without knowing the bitsize of one's datatypes?

>>
>We know the minimum value range of our data types - why would we
>need to know more than that?

>
For ... performance?
>
If I know I need, say, 32-bits, but not 64-bits which would be an
overkill, what do I use? int could be only 16. long int is at
least 32 but could be 64.
>
I would have to choose long int but at the risk of being
inefficient (I might need a few hundred million of them).

The basic problem here is historic. C was organized to allow for
16 bit processors, which lead to the 16 bit minimum size for ints.
Without that the minimum sizes for short, int, long could have been
16, 32, 64, and long long would never have arisen. We can't change
the minima without breaking all sorts of programs.

At least the situation is such that there can be no more than one
trap value for 16 bit ints. :-)

--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home .att.net>
Try the download section.



--
Posted via a free Usenet account from http://www.teranews.com

[Bart C]

Re: Standard integer types vs &lt;stdint.h&gt ; types

Malcolm McLean wrote:

I think we are creating a mess with all these integer types and
conventions on how they should be used.

That's probably inevitable with C having to target every conceivable
hardware and having to maintain compatibility with every line of code ever
written.

My main interest is PCs which are typically 32/64 bits now, and will be at
least that for the foreseeable future. So I don't really care about anything
other than 8,16,32,64 bits. (And it can't be a coincidence that these sizes
figure heavily in stdint.h.).

However generally I want an integer which can index or count an
array, and is fast, and is signed, because intermediate calculations
might go below zero.
This is usually semi-achievable. There will be a fast type the same
width as the address bus, the one bit we can ignore as we are
unlikely to want a char array taking up half memory (we can always
resort to "unsigned" for that special situation), but it might not be
the fastest type, and most arrays will in fact be a lot smaller than
the largest possible array.

The number of (physical) address bits appearing on the cpu pinouts is
unlikely to be a full 64 bits. Even virtual address spaces are a lot less
than 64-bits I would guess.

(64-bits addresses a *lot* of memory. It might just be enough to address all
the memory in every desktop PC in the world.)

If your task-space is 4GB or less than your array indexes/indices, size-t's
and so on don't need to be more than 32-bit unsigned. But your file-system
is likely to need 64-bits.

(Actually 48-bits will probably suffice for most purposes but that is too
odd a figure.)

--
Bart