next topic »

[Reply #30 on:]

your the boss,

No, I'm just a moderator.

To be a boss, you have to be an admin.

[Reply #31 on:]

so why don't we add to the pages that describe each of the types, that you can, and are encouraged to abbreviate to uint16_t, uint32_t, uint64_t, uint128_t, int8_t, int16_t, int32_t, int64_t, int128_t

Unless portability is a necessity, I'd say you're not encouraged to use any of the types listed.
I'd rather not see them listed at all on the Arduino reference pages.

I've been reading about the Arduino DUE coming out sometime.  If you ever expect to move code that needs to have integers of appropriate sizes (particularly for binary communication) between the 8 bit current Ardunios and the new Due, you probably should start thinking about using int8_t, int16_t, etc.

[Reply #32 on:]

  probably should start thinking about using int8_t, int16_t

A char will still be a char, and a byte still a byte, so that's part of that problem solved

[Reply #33 on:]

  probably should start thinking about using int8_t, int16_t

A char will still be a char, and a byte still a byte, so that's part of that problem solved

Well there have been machines in the past whose 'char', 'short', 'int', and 'long' were all 64-bits.  There have been machines with  9 and 10-bit characters.  You won't see them with modern microprocessors though.

When I was on the original ANSI C committee (early 80's through 1990), we did have some vendors with historical machines that are weird by today's standards, and the standard did have to deal with these machines.

My point was more for int16_t/int32_t that you can't assume that int will continue to be 16-bits and long will be 32-bits.  If you move 8-bit Arduino code to other machines, such as the 32-bit Arm based machines, and it is important that the sizes be a particular size, you want to use uint16_t, etc.

[Reply #34 on:]

I wish there were a way to handle int128's on the Atmel 328P but I guess if I ever want to implement a quadratic solution for a 16-bit ADC calibration routine then I'll have to graduate the board design to a 16 or 32-bit microprocessor.

Already using long long (64 bit integers) goes through program memory faster than a bunch of orphans going through cream buns at the Vicar's garden party. I don't think you would want to do any serious maths with 128-bit integers.

I ported the "big number" library to the Arduino:

http://www.gammon.com.au/forum/?id=11519

That lets you use very large numbers, still with the caveat that you will run out of RAM if you are not careful. Still, I was able to calculate 80 factorial using it.

As for uint8_t vs byte or int8_t vs char, personally I think it is cluttered. But that's just me.

I can see at a glance (and I emphasise that) that one is unsigned (byte) and one is signed (char). It doesn't say so, but I pull in the big guns here: my memory.

Whereas with uint8_t vs int8_t, I find I need to slow down, stare at it a bit, and ask myself "is there a 'u' at the start?". Or, for the width, look in the middle for 8/16/32 etc.

And (again personally) I find this better documenting:

Code:

unsigned long foo;

Compared to:

Code:

uint32_t foo;

The first one is "in your face" that is is unsigned. Heck, the word "unsigned" is actually there. The second is just a tiny "u" at the start of the typename.

[Reply #35 on:]

Mr. Gammon,

Wow, that is one amazing library. Is it possible to multiply/divide BigNumbers with each other?

[Reply #36 on:]

Certainly it is. Look at how it calculates 'e'.

[Reply #37 on:]

char, unsigned char, and signed char are three different types.  This bit of C/C++ strangeness happened because a signed type was used for char in C on some early machines and an unsigned type was used on others.

The C/C++ standards have three type of char.

So this compiles:

Code:

void f(char x) {Serial.println("char");}
void f(signed char x) {Serial.println("signed char");}
void f(unsigned char x) {Serial.println("unsigned char");}

void setup() {
  Serial.begin(9600);
  f ('H');
  f((int8_t)1);
  f((uint8_t)1);
}
void loop() {}

and prints this:

char
signed char
unsigned char

Other types like short, int, and long are the same as signed short, signed int, and signed long.  

You can't define the functions f(int x) and f(signed int x) in a program like above.

So char is not int8_t or uint8_t.  It may act like one or the other on different machines.

The Arduino group didn't implement this correctly in Print.  print(uint8_t) and print(int8_t) should both print a number and print(char) should write an ASCII character.