What is "long unsigned int" ?? variable

Using Arduino Programming Questions
1

What is " long unsigned int" when the variable declared is "unsigned long"?

Arduino: 1.5.4 (Windows XP), Board: "Arduino Uno"

D:\Program Files\Arduino\hardware\tools\avr\bin\avr-g++ -c -g -Os -w -fno-exceptions -ffunction-sections -fdata-sections -MMD -mmcu=atmega328p -DF_CPU=16000000L -DARDUINO=154 -DARDUINO_AVR_UNO -DARDUINO_ARCH_AVR -ID:\Program Files\Arduino\hardware\arduino\avr\cores\arduino -ID:\Program Files\Arduino\hardware\arduino\avr\variants\standard -ID:\Program Files\Arduino\libraries\LiquidCrystal\src -ID:\Program Files\Arduino\libraries\EEPROM\src -ID:\Program Files\Arduino\libraries\EEPROM\arch\avr C:\DOCUME~1\v\LOCALS~1\Temp\build7288923728861606407.tmp\Atlas_2014_6.cpp -o C:\DOCUME~1\v\LOCALS~1\Temp\build7288923728861606407.tmp\Atlas_2014_6.cpp.o

Atlas_2014_6.ino: In function 'void loop()':
Atlas_2014_6:657: error: call of overloaded 'LCD_Debug(const char [16], long unsigned int&, const char [3], int, int, int)' is ambiguous
Atlas_2014_6.ino:239: note: candidates are: bool cDebug::LCD_Debug(char*, long int, char*, long int, int, bool)
Atlas_2014_6.ino:269: note: bool cDebug::LCD_Debug(char*, long unsigned int, char*, long unsigned int, int, bool)
Atlas_2014_6.ino:304: note: bool cDebug::LCD_Debug(char*, int, char*, int, int, bool)

2

This compiles OK:

void setup ()
  {
  long unsigned int foo = 22;
  }  // end of setup

void loop () { }

All numbers* are really "int" (integers) it's just that if you don't qualify them with "long" or "long long" you get the default which on this processor is 2 bytes.

  • Other than floats, obviously.
3

Post your code.
I know it is Christmas, but I really don't want to play guessing games.
Don't forget to use code tags. :wink:

4

Here are three polymorphic functions and none of them has a variable defined as "long unsigned int" so how did I get this error. So if that compiles it must be legal, but weird.
I am going to add char data1 / data2 to see what comes up next , just for drill.

bool LCD_Debug(char Line1[], long data1,char Line2[], long data2, int delay1, bool bLoop)
{
  Serial.println("long");
  lcd.clear();
  lcd.print(Line1);
  lcd.print(" ");
  lcd.print(data1 );   // np CR /LF and zero decimals 


  lcd.setCursor(0,1);
  lcd.print(Line2);
  lcd.print(" ");
  lcd.print(data2);
  Serial.print(Line1); 
  Serial.println(data1);
  Serial.print(Line2); 
  Serial.println(data2);

  if(delay1 == 1)
    delay(gDelay);    // global delay 
  else if (delay1 > 1)
    delay(delay1);

  if(bLoop)
  {
    for(;;);  
  }
  return true;
}

bool LCD_Debug(char Line1[], unsigned long data1,char Line2[], unsigned long data2, int delay1, bool bLoop)
{
  Serial.println("Unsigned long");
  lcd.clear();
  lcd.print(Line1);
  lcd.print(" ");
  lcd.print(data1 );   // np CR /LF and zero decimals 


  lcd.setCursor(0,1);
  lcd.print(Line2);
  lcd.print(" ");
  lcd.print(data2);
  Serial.print(Line1); 
  Serial.println(data1);
  Serial.print(Line2); 
  Serial.println(data2);

  if(delay1 == 1)
    delay(gDelay);    // global delay 
  else if (delay1 > 1)
    delay(delay1);

  if(bLoop)
  {
    for(;;);  
  }
  return true;
}





// test int data text int data delay 1 globald delay > 1 selected delay 1 forever loop 
bool LCD_Debug(char Line1[], int data1,char Line2[], int data2, int delay1, bool bLoop)
{
   Serial.println("int");
  lcd.clear();
  lcd.print(Line1);
  lcd.print(" ");
  lcd.print(data1);
  lcd.setCursor(0,1);
  lcd.print(Line2);
  lcd.print(" ");
  lcd.print(data2);
  Serial.print(Line1); 
  Serial.println(data1);
  Serial.print(Line2); 
  Serial.println(data2);

  if(delay1 == 1)
    delay(gDelay);    // global delay 
  else if (delay1 > 1)
    delay(delay1);

  if(bLoop)
  {
    for(;;);  
  }
  return true;
}  
  
};
5

I see we're still having problems with the concept of "post all your code".
Or maybe it's just polymorphism.

6

The problem is in the part of the code that you haven't posted. The error message hints at it:

Atlas_2014_6:657: error: call of overloaded 'LCD_Debug( .... )' is ambiguous

It is what is calling LCD_Debug that is causing the problem. That is why we need to see all your code.

Pete
[EDIT] Thanks AWOL.

7

is ambiguous

8

Vaclav:
What is " long unsigned int" when the variable declared is "unsigned long"?

The compiler error message is not directly quoting your code, it is describing the type as it is represented internally within the compiler. From the compiler's point of view, these are all equivalent and would be represented internally in the same way:

unsigned long foo;
unsigned long int foo;
long unsigned foo;
long unsigned int foo;
int long unsigned foo;
int unsigned long foo;

... etc, you get the idea.
9

Thanks, got my answer. Still would like to know how "long unsigned int" is acceptable.
And no I am not going to post my 5000 lines of code for your scrutiny. I know better by now.
Merry Christmas to all, peace.
Vaclav

10

Vaclav:
Thanks, got my answer. Still would like to know how "long unsigned int" is acceptable.

It's acceptable because the compiler says it's acceptable.

And no I am not going to post my 5000 lines of code for your scrutiny. I know better by now.
Merry Christmas to all, peace.

For what it's worth, left unsaid was "or enough of it to illustrate the problem", which, if you'd read the error message carefully, would have let you know that the call to that function was part, if not all, of the problem.

But you just keep on doing what you're doing, and you'll get the responses you seem to be asking for.

11

Vaclav:
Still would like to know how "long unsigned int" is acceptable.

Because the compiler accepts it, because the language definition says it is acceptable.

12

Vaclav:
Thanks, got my answer. Still would like to know how "long unsigned int" is acceptable.

See reply #1.

Also:

http://www.cplusplus.com/doc/tutorial/variables/

In particular:

Here is the complete list of fundamental types in C++:

...

  • The names of certain integer types can be abbreviated without their signed and int components - only the part not in italics is required to identify the type, the part in italics is optional. I.e., signed short int can be abbreviated as signed short, short int, or simply short; they all identify the same fundamental type.

My emphasis.

13

I still do not see "long unsigned int" here as basic type.
It should be "unsigned long int" by this table.

Group Type names* Notes on size / precision
Character types char Exactly one byte in size. At least 8 bits.
char16_t Not smaller than char. At least 16 bits.
char32_t Not smaller than char16_t. At least 32 bits.
wchar_t Can represent the largest supported character set.
Integer types (signed) signed char Same size as char. At least 8 bits.
signed short int Not smaller than char. At least 16 bits.
signed int Not smaller than short. At least 16 bits.
signed long int Not smaller than int. At least 32 bits.
signed long long int Not smaller than long. At least 64 bits.
Integer types (unsigned) unsigned char (same size as their signed counterparts)
unsigned short int
unsigned int
unsigned long int
unsigned long long int
Floating-point types float
double Precision not less than float
long double Precision not less than double
Boolean type bool
Void type void no storage
Null pointer decltype(nullptr)

14

Interesting. I must have missed the statement that says the speciifiers have to be in Vaclav order. Could you point it out for me?

15

A variable definition has a type and it has modifiers (or qualifiers if you prefer).

Of the basic types there is: char, int, float, double. The default, if no type is specified, is "int". You can only omit the type if you provide modifiers, in which case the type is taken as "int".

Modifiers can be given in any order, and proceeed the type. Common modifiers include: static, const, unsigned, long, short, volatile. Not all modifiers are applicable to all types.

char can have: static, const, unsigned, volatile.
int can have: static, const, unsigned, volatile, short, long.
float can have: static, const, volatile.
double can have: static, const, volatile, long (if the compiler supports long doubles - 80 bit floating point).

"long" and "short" modify the size of the type. For an integer the default size is architecture dependant - on the Arduino it is 16 bits. "Long" and "short" specify 32 bits and 16 bits respectively. You can also double up the longs with "long long", which is 64 bits.

As I said, the modifiers can go in any order, and if you miss out the type it defaults to int, so all of the following are the same:

unsigned foo;
unsigned int foo;
unsigned short foo; // on the Arduino as an int and a short are the same size
unsigned short int foo; // ditto
short unsigned int foo;
short unsigned foo;

And the following:

long foo;
long int foo;

"static", "const" and "volatile" affect how the compiler treats the variables in certain specific situations.

16

Vaclav:
I still do not see "long unsigned int" here as basic type.
It should be "unsigned long int" by this table.

Would you agree that a "small black cat" is the same type of beast as a "black small cat"? Or not? If not, in what way would they differ?

17

Lets see, quoting from the C99 standard with the key sentence underlined:

6.2.5 Types
...
There are five standard signed integer types, designated as signed char, short
int, int, long int, and long long int. (These and other types may be
designated in several additional ways, as described in 6.7.2.) There may also be
implementation-defined extended signed integer types.25) The standard and extended
signed integer types are collectively called signed integer types.26)
...
6.7.2 Type specifiers
Syntax
type-specifier:
void
char
short
int
long
float
double
signed
unsigned
_Bool
_Complex
_Imaginary
struct-or-union-specifier
enum-specifier
typedef-name

Constraints
At least one type specifier shall be given in the declaration specifiers in each declaration,
and in the specifier-qualifier list in each struct declaration and type name. Each list of
type specifiers shall be one of the following sets (delimited by commas, when there is
more than one set on a line); the type specifiers may occur in any order, possibly
intermixed with the other declaration specifiers.
— void
— char
— signed char
— unsigned char
— short, signed short, short int, or signed short int
— unsigned short, or unsigned short int
— int, signed, or signed int
— unsigned, or unsigned int
— long, signed long, long int, or signed long int
— unsigned long, or unsigned long int
— long long, signed long long, long long int, or signed long long int
— unsigned long long, or unsigned long long int
— float
— double
— long double
— _Bool
— float _Complex
— double _Complex
— long double _Complex
— float _Imaginary
— double _Imaginary
— long double _Imaginary
— struct or union specifier
— enum specifier
— typedef name

18

"long int" has been an acceptable alternative to "long" , since a very long long time ago.

19

"long int" has been an acceptable alternative to "long" , since a very long long time ago.

Understandable - the OP claims to have been programming for only thirty years.

20

AWOL:

"long int" has been an acceptable alternative to "long" , since a very long long time ago.

Understandable - the OP claims to have been programming for only thirty years.

Well it wasn't in the V6 C compiler that I used in 1978, because neither long nor unsigned were in the language at the time.

Unsigned ang long were in the V7 compiler. I vaguely recall that the original Ritchie compiler for the PDP-11 was more restricted than the later Johnson portable C compiler that became the base for K&R-1. K&R-1's appendix A became the kernel of the C-89 ANSI and C-90 ISO standards.

When I wrote the Data General C compiler front end from scratch (somewhere around 1983-1984), I believe it was accepted practice at that time that the type names could come in any order.

I don't know where my original K&R-1 or my copy of the C-89/90 standard is any more, so I can't really check at this stage.