Why Does a Long Int Take 12 Bytes on Some Machines?

It'd be defined by the architecture you were using. On a Zilog z80 chip (common embedded chip) they'd be one size while they could be an entirely different size on a x86 chipset. However, the sizes themselves are fixed ratios to each other. Essentially short and long aren't types but qualifies for the int type. Short ints will be one order of magnitude smaller than (regular) int and long ints will be an order of magnitude higher. So say your Int is bounded to 4 bytes, the short qualifier bounds it to 4 bytes though 2 bytes is also very common and the long qualifier boosts it potentially to 8 bytes though it can be less down to 4 bytes. Keep in mind that this is subject to word length as well so on a 32 bit system you'd max out at 4 bytes per int anyway making long the same as a regular int. Thus, Short ≤ Int ≤ Long.

However, if you lengthen it again, you can push in the int to the next cell giving you 8 whole bytes of storage. This is the word size for 64 bit machines so they don't have to worry about such things and just use the one cell for long ints allowing them to be another order above standard ints while long long ints get really bit.

As far as which to choose, it boils down to something that Java programmers for instance don't have to worry about. "What is your architecture?" Since it all depends on the word size of the memory of the machine in question, you have to understand that up front before you decide which to use. You then pick the smallest reasonable size to save as much memory as you can because that memory will be allocated whether you use all of the bits in it or not. So you save where you can and pick shorts when you can and ints when you can't and if you need something bigger than what regular ints you give; you'd lengthen as needed until you hit the word ceiling. Then you'd need to supply big number routines or get them from a library.

C may well be "portable assembly" but you still have to know thine hardware.

Most of the C++ standard library, including all the streams which cout is part of, are inline template classes. Whenever you #include one of these inline library components, the compiler will copy and paste all that code to the source file that is including it. This will help the code to run faster, but will also add a lot of bytes to the final executable. This is likely the reason for the results you got.

Doing a similar test with the clang compiler on OSX (Apple LLVM version 5.1), using default flags, I got comparable results:

hello_cpp_cout:

#include <iostream>
int main()
{
    std::cout << "Hello world" << std::endl;
    return 0;
}

Size: 14,924 bytes

hello_c:

#include <stdio.h>
int main()
{
    printf("hello world\n");
    return 0;
}

Size: 8,456 bytes

And, as a bonus, I tried to compile a .cpp file with the exact same code as hello_c, i.e.: using printf instead of cout:

hello_cpp_printf:

#include <stdio.h>
int main()
{
    printf("hello world\n");
    return 0;
}

Size: 8,464 bytes

As you can see, the executable size is hardly related to the language, but to the libraries you include in your project.

Update:

As it was noted by several comments and other replies, the choice of compiler flags will also be influential in the size of the compiled executable. A program compiled with debug flags will be a lot larger than one compiled with release flags, for example.