When should I use int32_t rather than int

Started by
35 comments, last by DvDmanDT 7 years, 6 months ago


for( auto end= someVec. size(), i =end *0;i<	end; ++i) {
    {
 if (!someVec[ i] .invalid () !=false ) {
 return;
    }
    }
                                                          }
Nailed it.


L. Spiro

I think this should be a part of your mandated coding guidelines (as per your other thread).

Already sent the e-mail to the committee.

I have a pretty good feeling about this style guideline.

L. Spiro

I restore Nintendo 64 video-game OST’s into HD! https://www.youtube.com/channel/UCCtX_wedtZ5BoyQBXEhnVZw/playlists?view=1&sort=lad&flow=grid

Advertisement

To write code that compiles and works properly and well across the widest range of platforms you should favor int and you only ever specify a fixed size when you are working with serialized data.

You generally should not be indexing data-structures and if you must then it should be contained within the class if possible.

Iteration is generally best performed by the higher-level C++ constructs or pointers.

If you have large buffers that you are sharing and must expose indices then either use size_t/ssize_t or expose your own public typedef (favored name is size_type).

If 'int' does not match the register size of the machine then that is a defect in the compiler and is your warning sign to stop using it because there will be worse problems coming.

- The trade-off between price and quality does not exist in Japan. Rather, the idea that high quality brings on cost reduction is widely accepted.-- Tajima & Matsubara

To write code that compiles and works properly and well across the widest range of platforms you should favor int and you only ever specify a fixed size when you are working with serialized data.

I initially wanted to disagree with this, but I think I changed my mind to "it depends". My adjusted stance:

  • If you want to write standalone code that makes efficient use of the hardware across the widest range of platforms, you should use int.
  • If you want to write standalone code that has consistent output across the widest range of platforms, you should use fixed sizes.
  • If you want to write code that interfaces with other code (std library or other cross platform api/library) you should use whatever they use.

Note that it's very much possible to write standalone code that achieves consistent output using 'int' etc, but it's imho easier to screw up than when using fixed sizes. How big of a problem this is depends very much on what you are working on.

This is how you count backwards with an unsigned counter:


  while (n-->0) {
    //...
  }
It looks like an arrow makes n go to 0, which is cute. And, more importantly, it's correct and really easy to remember.

Yeah, I'm a fan of that. I use:


for(int i = 50; i --> 0; )
{
    //...
}

Careful though, this apparently causes some programmers to foam at the mouth...

" --> is not an operate but looks like one! Don't you dare use that in *my* codebase, or you'll confuse newer programmers!", etc...

But yea, I love it for exactly the reason you said: It's correct (no off-by-one issues) and super easy to remember.

It might, true. And I beleive that the future improvements of auto will help there so that we could use it without the type defaulting to int... This might be true now (and I'm unsure about this to be a requirement), but a future version might change this.


The reason why it's defaulting to 'int' is because the '0' in 'auto i = 0' is an int-literal.

For example, it'd default to 'unsigned' if you assigned it an unsigned literal like 'auto i = 0u;', or default to 'char' if you passed it a char literal like 'auto i = '0';'

Or pass it a 64 bit signed or unsigned literal to have it adopt that type (e.g. 'auto i = 0LL;' or 'auto i = 0ULL;').

If 'int' does not match the register size of the machine then that is a defect in the compiler and is your warning sign to stop using it because there will be worse problems coming.

So, any and every compiler on an ARM processor, inc which register sizes can change depending on thumb?

Every SPARC compiler, in which the register sizes can vary up to 128 bits but addressable memory was always in 32-bit quantities?

IBM 370 with its 192-bit registers but variable-size memory addressing scheme?

What exactly is the size of a register on x86 anyway? Is it the size of the A/B/C/D regs, or the AX/BX. or the EAX, and do you include the segment registers? Should you really have all ints fixed at 8/16/32/64 bits (pick your register) even though your address bus is limited to 24/32/48 bits (depending on processor)?

I dunno, sounds complex to me and a simplistic solution might just not apply.

Stephen M. Webb
Professional Free Software Developer

So, any and every compiler on an ARM processor, inc which register sizes can change depending on thumb?

I didn't think the size of the registers changed based on thumb mode, just the size of instructions and number of available registers..? Is there some circumstance or ARM version where the register size changes in thumb mode?

This topic is closed to new replies.

Advertisement