Pages: 1 2 [3]   Go Down
Author Topic: uint_8 or such like  (Read 6230 times)
0 Members and 1 Guest are viewing this topic.
Global Moderator
UK
Offline Offline
Brattain Member
*****
Karma: 309
Posts: 26525
I don't think you connected the grounds, Dave.
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

Quote
your the boss,

No, I'm just a moderator.

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

"Pete, it's a fool looks for logic in the chambers of the human heart." Ulysses Everett McGill.
Do not send technical questions via personal messaging - they will be ignored.

Ayer, Massachusetts, USA
Offline Offline
Edison Member
*
Karma: 54
Posts: 1857
View Profile
WWW
 Bigger Bigger  Smaller Smaller  Reset Reset

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

Global Moderator
UK
Offline Offline
Brattain Member
*****
Karma: 309
Posts: 26525
I don't think you connected the grounds, Dave.
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

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

"Pete, it's a fool looks for logic in the chambers of the human heart." Ulysses Everett McGill.
Do not send technical questions via personal messaging - they will be ignored.

Ayer, Massachusetts, USA
Offline Offline
Edison Member
*
Karma: 54
Posts: 1857
View Profile
WWW
 Bigger Bigger  Smaller Smaller  Reset Reset

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

Global Moderator
Online Online
Brattain Member
*****
Karma: 504
Posts: 19106
Lua rocks!
View Profile
WWW
 Bigger Bigger  Smaller Smaller  Reset Reset

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


Peoples Republic of Cantabrigia
Offline Offline
God Member
*****
Karma: 6
Posts: 722
Arduino happiness
View Profile
WWW
 Bigger Bigger  Smaller Smaller  Reset Reset

Mr. Gammon,

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

Global Moderator
Online Online
Brattain Member
*****
Karma: 504
Posts: 19106
Lua rocks!
View Profile
WWW
 Bigger Bigger  Smaller Smaller  Reset Reset

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


0
Offline Offline
Edison Member
*
Karma: 67
Posts: 1658
Arduino rocks
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

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:
Quote
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.
« Last Edit: July 26, 2012, 04:59:53 pm by fat16lib » Logged

Pages: 1 2 [3]   Go Up
Jump to: