Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > Standard integer types vs <stdint.h> types

Reply
Thread Tools

Standard integer types vs <stdint.h> types

 
 
Bart C
Guest
Posts: n/a
 
      01-18-2008
"Richard Heathfield" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> 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).

If I distribute an appl as source code I don't have control of the final
size unless I specify the exact compiler and version.

So it's necessary to use alternatives, like the stuff in stdint.h.

--
Bart


 
Reply With Quote
 
 
 
 
Richard Heathfield
Guest
Posts: n/a
 
      01-18-2008
Bart C said:

> "Richard Heathfield" <(E-Mail Removed)> wrote in message
> news:(E-Mail Removed)...
>> 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?


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

> So it's necessary to use alternatives, like the stuff in stdint.h.


If you'd said that *you* find it necessary, okay, I'd have to accept that,
obviously. I don't think I've ever found it necessary, though.

--
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
 
Reply With Quote
 
 
 
 
euler70@gmail.com
Guest
Posts: n/a
 
      01-18-2008
On Jan 18, 6:41 am, Richard Heathfield <(E-Mail Removed)> wrote:
> Bart C said:
>
> > "Richard Heathfield" <(E-Mail Removed)> wrote in message
> >news:(E-Mail Removed)...
> >> 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?

>
> <shrug> For 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|smallest) 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".
 
Reply With Quote
 
James Kuyper
Guest
Posts: n/a
 
      01-18-2008
http://www.velocityreviews.com/forums/(E-Mail Removed) wrote:
> char and unsigned char have specific purposes: char is useful for
> representing characters of the basic execution character set and
> unsigned char is useful for representing the values of individual
> bytes. The remainder of the standard integer types are general
> purpose. Their only requirement is to satisfy a minimum range of
> values, and also int "has the natural size suggested by the
> architecture of the execution environment". What are the reasons for
> using these types instead of the [u]int_fastN_t types of <stdint.h>?


Keep in mind that the C type system grew over decades. The committee
considers backwards compatibility to be very important (IMO, correctly),
but it has also attempted to alleviate some of the problems associated
with the original language design. As a result of those conflicting
goals, C has a lot of internal inconsistencies.

If it had been designed from scratch with something similar to the
current result in mind, we would probably have only the size-named types
from stdint.h, they wouldn't require a special header, and they'd
probably have simpler, shorter names. Aside from the fact that their
names are easier to type, char, short, int, and don't have any inherent
advantage over the size-named types.

If and when C99 gets fully adopted by most mainstream compilers and
programmers, the main remaining reason for using char, short, int, or
long, will be that your code must be compatible with an interface
defined in terms of those types. That applies to almost the entire C
standard library, as well as large parts of most of the other libraries
I've used.
 
Reply With Quote
 
Malcolm McLean
Guest
Posts: n/a
 
      01-18-2008
<(E-Mail Removed)> wrote in message news:
> On Jan 18, 6:41 am, Richard Heathfield <(E-Mail Removed)> wrote:
>> Bart C said:
>>
>> > "Richard Heathfield" <(E-Mail Removed)> wrote in message
>> >news:(E-Mail Removed)...
>> >> 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?

>>
>> <shrug> For 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|smallest) 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.
I think we are creating a mess with all these integer types and conventions
on how they should be used.

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.

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

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

 
Reply With Quote
 
Richard Heathfield
Guest
Posts: n/a
 
      01-18-2008
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
 
Reply With Quote
 
Richard Heathfield
Guest
Posts: n/a
 
      01-18-2008
(E-Mail Removed) 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
 
Reply With Quote
 
Flash Gordon
Guest
Posts: n/a
 
      01-18-2008
Malcolm McLean wrote, On 18/01/08 12:19:
>
> "Bart C" <(E-Mail Removed)> wrote in message news:fI%jj.79153
>> 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
 
Reply With Quote
 
Flash Gordon
Guest
Posts: n/a
 
      01-18-2008
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
 
Reply With Quote
 
Flash Gordon
Guest
Posts: n/a
 
      01-18-2008
Malcolm McLean wrote, On 18/01/08 13:25:
> <(E-Mail Removed)> wrote in message news:
>> On Jan 18, 6:41 am, Richard Heathfield <(E-Mail Removed)> wrote:
>>> Bart C said:
>>>
>>> > "Richard Heathfield" <(E-Mail Removed)> wrote in message
>>> >news:(E-Mail Removed)...
>>> >> 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?
>>>
>>> <shrug> For 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|smallest) 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
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
How do I add an Integer to another Integer? Sebastian Stelzer Java 6 04-07-2010 07:03 PM
CType(x,Integer) vs. Integer.Parse(x) =?Utf-8?B?Sm9l?= ASP .Net 7 02-07-2006 02:30 AM
how do I make Class.forName("Integer") returning java.lang.Integer? Johannes Zellner Java 22 12-19-2005 11:22 AM
How do I add an Integer to another Integer? Sebastian Stelzer Java 2 10-15-2004 01:17 PM
No Math.min(Integer, Integer)? =?ISO-8859-1?Q?Thomas_Gagn=E9?= Java 0 07-29-2003 07:46 PM



Advertisments