The SOzão has this very simple code:

#include<stdlib.h>
#include<stdio.h>
#include<math.h>

int main()
{
    int bin, dec = 0, i;
    printf("\nEnter A Binary Number: \t");
    scanf("%d", &bin);
    for(i = 0; bin > 0; i++)
    {
        dec = dec + pow(2, i) * (bin % 10);
        bin = bin / 10;
    }
    printf("\nDecimal Equivalent of Binary Number: \t %d\n", dec);
    return 0;
}

See working at IDEONE .

The same code, adapted to read from strings , for you to test with larger numbers:

#include<stdio.h>
#include<string.h>
#include<math.h>

int main()
{
    char bin[100];
    unsigned long dec = 0;
    int i = 0;
    int s;
    fgets( bin, sizeof(bin), stdin);
    s = strlen( bin );
    while( s-- ) {
        if( bin[s] == '0' || bin[s] == '1' ) {
            dec = dec + pow(2, i++) * (bin[s] - '0');
        }
    };
    printf("\nDecimal Equivalent of Binary Number: \t %u\n", dec);
    return 0;
}

See working at IDEONE .

Original:

  

link

    

The best way

The best way is to create a code that does this. C has only the basics. C is not C # or Java.

You can look for a library that does this, but there is nothing that everyone uses and is considered as "almost official". It is very common for C programmers to create their own library for these things and leave only complex problems for libraries.

Representation

Note that people often confuse data with data representation. The number is the number. You do not see the number, it only exists. What you see is a representation. And to see it certainly is a text string.

So if you have a number that in memory is equivalent to what we know as the 129 to display on the screen we will have to find the character 1 , then the 2 and then the 9 . Just as if we are going to show in binary we will find a text 10000001 . And hexadecimal 81 . Obviously a representation can be stored too. But it is always text. The key is to find the correct characters. You do it with pure math. Alias who has adequate mathematical understanding produces simple algorithms for simple problems. And I'm not talking about decorating formulas. In fact, anyone who does this does not learn to solve problems.

I consider it a mistake to work with numeric values to represent data. But I see many exercises like this.

Algorithm

The common exercise in doing this is great for developing the ability to produce good algorithms.

The best solution is to divide or multiply the number by the base. Example:

If you have a binary number, how does it calculate it to decimal? From right to left it will always be worth 0 or a value, when 1 appears, according to the position, equal is the decimal.

Let's look at the decimal we are accustomed to. We start from the right which is the least significant value. You could start from the left, but then you would have to calculate how many digits you have before you start.

Then the last digit is worth its value. Generally speaking is the value of it times 10 (the base) raised to the position. In case the position is zero (remember that we always start from zero). When I taught I wanted to cry when students did not know that raising to zero is 1. Math teachers often say it's convention. But this exercise helps to understand why it is this "convention." The result is stored somewhere. On paper or in computer memory, it depends on where you are doing the algorithm. If the digit was 5, then we have 5 as a result.

Then we go to the next digit. Again its value is multiplied by the high base to the position. Now the position is 1. So 10 ^ 1 is 10. So if the digit was 3, then we have 30 as a result.

Next we use the digit 6 (for example) times 10 to 2 (next position.

To do otherwise, we change multiplication by division.

If you only have these digits, we add all together and give 635. This is how a printf() or toString() in other languages do to transform the number into representation, or take the representation and generate a number ( parsing , which scanf() usually does.)

The binary only changes the base, the algorithm is the same. So let's go:

0011 1011 0101 from right to left:

1 X 2^0 (1) = 1
0 X 2^1 (2) = 0
1 X 2^2 (4) = 4
0 X 2^3 (8) = 0
1 X 2^4 (16) = 16
1 X 2^5 (32) = 32
0 X 2^6 (64) = 0
1 X 2^7 (128) = 128
1 X 2^8 (256) = 256
1 X 2^9 (512) = 512

Adds all 949.

Now takes 949 and does the other way around:

949 % 2 = 1 -> 949 / 2 = 474
474 % 2 = 0 -> 474 / 2 = 237
237 % 2 = 1 -> 237 / 2 = 118
118 % 2 = 0 -> 118 / 2 = 59
59 % 2 = 1 -> 59 / 2 = 29
29 % 2 = 1 -> 29 / 2 = 14
14 % 2 = 0 -> 14 / 2 = 7
7 % 2 = 1 -> 7 / 2 = 3
3 % 2 = 1 -> 3 / 2 = 1
1 % 2 = 1 -> 1 / 2 = 0

Put together all remains in reverse: 1110110101

For hexadecimal the base is 16, but the algorithm is the same , both on one side and the other. You can even convert from binary to hexadecimal and vice versa, all straight without going through the decimal.

Basically that's it. Now just encode. Or get it ready.

Conclusion

The problem is common: link Making huge is optional . The problem is simple and requires a simple, short solution. Only here it has been asked several times.