This question already has answers here:
What does it mean when a numeric constant in C/C++ is prefixed with a 0?
(7 answers)
Closed 7 years ago.
I am unable to understand output of below mentioned program-
#include <stdio.h>
int main()
{
int i, a[8]={000, 001, 010, 011, 100, 101, 110, 111};
for(i=0;i<8;i++)
{
printf("%d\t",a[i]);
}
system("pause");
return 0;
}
OUTPUT -
0 1 8 9 100 101 110 111
Why are the initial four values getting converted here???
Any integer literal that starts with a 0 followed by other digits is octal, just like any integer literal starting with 0x or 0X, followed by digits, is hexadecimal. C++14 will add 0b or 0B as a prefix for binary integer literals.
See more on integer literals in C++ here.
If you start a number with a 0 it gets converted to an octal number
0xNumber is hex
Related
When an integer is initialized as int a = 010, a is actually set to 8, but for int a = 10, a is set to 10.
Can anyone tell me why a is not set to 10 for int a = 010?
Because it's interpreting 010 as a number in octal format. And in a base-8 system, the number 10 is equal to the number 8 in base-10 (our standard counting system).
More generally, in the world of C++, prefixing an integer literal with 0 specifies an octal literal, so the compiler is behaving exactly as expected.
0 before the number means it's in octal notation. So since octal uses a base of 8, 010 would equal 8.
In the same way 0x is used for hexadecimal notation which uses the base of 16. So 0x10 would equal 16 in decimal.
In C, C++, Objective C and related languages a 0 prefix signifies an octal literal constant, so 010 = 8 in decimal.
Leading 0 in 010 means that this number is in octal form. So 010 means 8 in decimal.
This question already has an answer here:
C printf %d incorrect value with leading zeros? [duplicate]
(1 answer)
Closed 4 years ago.
Why is the output of these two examples different in C++?
int a=025;
float b=5.5;
cout<<a+b;
26.5
int a=25;
float b=5.5;
cout<<a+b;
30.5
From cppreference:
octal-literal is the digit zero (0) followed by zero or more octal digits (0, 1, 2, 3, 4, 5, 6, 7)
So 025 is actually the octal literal corresponding to decimal 21 which is why your answers differ by 4 (25-025 or 25-21).
In the first example, you have assigned "a" the value of an octal literal. It's not the same as decimal 25. It's equivalent to 21 decimal.
this is the function that returns sum of digits of a given no.
ex: 345 gives 12 (3+4+5)
def digit_sum(n):
s=0
while(n>0):
r=n%10
n=n/10
s=s+r
return s
print digit_sum(0123)
output: 11 instead of 6
Prior to Python 3, 0123 is an octal literal as it starts with a leading 0.
(Its decimal value is 83, and those digits sum to 11.)
This question already has answers here:
printf with "%d" of numbers starting with 0 (ex "0102") giving unexpected answer (ex '"66")
(4 answers)
Closed 7 years ago.
I have a simple program.
#include <cstdio>
int main()
{
int num = 000012345; printf("%d\n",num);
return 0;
}
The above program gives 5349. Why ? I mean it should be wrong, but why 5349 ?
Numbers starting with 0 are octal in c/c++.
Octal = 000012345
Decimal= 0×8⁸+0×8⁷+0×8⁶+0×8⁵+1×8⁴+2×8³+3×8²+4×8¹+5×8⁰ = 5349
Binary = 1010011100101
Hex = 14E5
A number starting with one or more leading zeros specifies octal format instead of decimal. So 000012345 is 1 * 8^4 + 2 * 8^3 + 3 * 8^2 + 4 * 8^1 + 5 * 8^0 = 5349.
Similarly, a number starting with 0x is in hexadecimal format.
I have a code in C++ which convert 2 digits octal number to binary number. For testing validity of the code I used several online conversion site like
this and
this
When I enter 58 or 59 in as an octal value it says invalid octal values but when I enter 58 in my code it gives binary number as - 101000. Again for testing I enter 101000 as binary number in above website's calculator then they gives me result 50 as octal value.
I need some explanation why this is so.
Here is the C++ code -
#include <iostream.h>
#include <conio.h>
void octobin(int);
void main()
{
clrscr();
int a;
cout << "Enter a 2-digit octal number : ";
cin>>a;
octobin(a);
getch();
}
void octobin(int oct)
{
long bnum=0;
int A[6];
//Each octal digit is converted into 3 bits, 2 octal digits = 6 bits.
int a1,a2,quo,rem;
a2=oct/10;
a1=oct-a2*10;
for(int x=0;x<6;x++)
{
A[x]=0;
}
//Storing the remainders of the one's octal digit in the array.
for (x=0;x<3;x++)
{
quo=a1/2;
rem=a1%2;
A[x]=rem;
a1=quo;
}
//Storing the remainders of the ten's octal digit in the array.
for(x=3;x<6;x++)
{
quo=a2/2;
rem=a2%2;
A[x]=rem;
a2=quo;
}
//Obtaining the binary number from the remainders.
for(x=x-1;x>=0;x--)
{
bnum*=10;
bnum+=A[x];
}
cout << "The binary number for the octal number " << oct << " is " << bnum << "." << endl;
}
Octal numbers have digits that are all in the range [0,7]. Thus, 58 and 59 are not octal numbers, and your method should be expected to give erroneous results.
The reason that 58 evaluates to 101000 is because the first digit of the octal number expands to the first three digits of the binary number. 5 = 101_2. Same story for the second part, but 8 = 1000_2, so you only get the 000 part.
An alternate explanation is that 8 = 0 (mod 8) (I am using the = sign for congruency here), so both 8 and 0 will evaluate to 000 in binary using your code.
The best solution would be to do some input validation. For example, while converting you could check to make sure the digit is in the range [0,7]
You cannot use 58 or 59 as an input value. It's octal, for Christ's sake.
Valid digits are from 0 to 7 inclusive.
If you're encoding a number in base 8, none of the octets can be 8 or greater. If you're going to do the code octet by octet, there needs to be a test to see whether the octet is 8 or 9, and to throw an error. Right now your code isn't checking this so the 8 and 9 are overflowing to 10.
58 and 59 aren't valid octal values indeed ... the maximum digit you can use is yourbase-1 :
decimal => base = 10 => Digits from 0 t 9
hexadécimal => base = 16 => Digits from 0 to 15 (well, 0 to F)
Octal => base = 8 => Digits from 0 to 7