# c++11 – How many bytes will be required to store number in binary and text files respectively

## c++11 – How many bytes will be required to store number in binary and text files respectively

It depends on:

- text encoding and number system (decimal, hexadecimal, many more…)
- signed/not signed
- single integer or multiple (require separators)
- data type
- target architecture
- use of compressed encodings

In ASCII a character takes 1 byte. In UTF-8 a character takes 1 to 4 bytes, but digits always take 1 byte. In UTF-16 or Unicode it takes 2 or more bytes per character.

Non-ASCII formats may require additional 2 bytes (initial BOM) for the file, this depends on the editor and/or settings used when the file was created.

But lets assume you store the data in a simple ASCII file, or the discussion becomes needlessly complex.

Lets also assume you use the decimal number system.

In hexadecimal you use digits

`0-9`

and letters`a-f`

to represent numbers. A decimal (base-10) like`34234324423`

would be`7F88655C7`

in hexadecimal (base-16). In the first system we have 11 digits, in the second just 9 digits. The minimum base is 2 (digits`0`

and`1`

) and the common maximum base is 64 (base-64). Technically, with ASCII you could go as high as base-96 maybe base-100, but thats very uncommon.

Each digit (`0-9`

) will take one byte. If you have signed integers, an additional minus sign will lead the digits (so negative numbers charge 1 additional byte).

In some circumstances you may want to store several numerals. You will need a separator to tell the numerals apart. A comma (`,`

), colon (`:`

), semicolon (`;`

), pipe (`|`

) or newline (`LF`

, `CR`

or on Windows `CRLF`

, which takes 2 bytes) have all been observed in the djungle as legit separators of numerals.

What is a

numeral? The concept or idea of the quantity8that is IN YOUR HEAD is the number. Any representation of that concept on stone, paper, magnetic tape, or pixels on a screen are just that: REPRESENTATIONS. They are symbols which stand for what you understand in your brain. Those are numerals. Please dont ever confuse numbers with numerals, this distinction is the foundation of mathematics and computer science.

In these cases you want to count an additional character for the separator *per numeral*. Or maybe *per numeral minus one*. It depends on if you want to *terminate* each numeral with a marker or *separate* the numerals from each other:

Example (three digits and three newlines): 6 bytes

```
1<LF>
2<LF>
3<LF>
```

Example (three digits and two commas): 5 bytes

```
1,2,3
```

Example (four digits and one comma): 5 bytes

```
2134,
```

Example (sign and one digit): 2 bytes

```
-3
```

If you store the data in a **binary format** (not to be confused with the **binary number system**, which would still be a text format) the occupied memory depends on the *integer type* (or, better, bit length of the integer).

An octet (0..255) will occupy 1 byte. No separators or leading signs required.

A 16-bit `float`

will occupy 2 bytes. For C and C++ the underlying architecture must be taken into account. A common `integer`

on a 32-bit architecture will take 4 bytes. The very same code, compiled against a 64-bit architecture, will take 8 bytes.

There are exceptions to those *flat* rules. As an example, Googles *protobuf* uses a *zig-zag VarInt* implementation that leverages *variable length encoding*.

Here is a `VarInt`

implementation in C/C++.

**EDIT**: added Thomas Wellers suggestion

Beyond the actual file **CONTENT** you will have to store metadata about the file (for bookkeeping such as the first sector, the filename, access permissions and more). This metadata is not shown for the file occupying space on disk, but actually is there.

If you store each numeral in a separate file such as the numeral `10`

in the file `result-10`

, these metadata entries will occupy more space than the numerals themselves.

If you store ten, hundred, thousands or millions/billions of numerals in one file, that overhead becomes increasingly irrelevant.

**EDIT**: to be clearer about file overhead

The overhead is under circumstances relevant, as discussed above.

But it is not a differentiator between textual and binary formats. As doug65536 says, however you store the data, if the filesystem structure is the same, it does not matter.

A file is a file, independently if it contains binary data or ASCII text.

Still, the above reasoning applies independently from the format you choose.

The number of digits needed to store a number in a given number base is `ceil(log(n)/log(base))`

.

Storing as decimal would be base 10, storing as hexadecimal text would be base 16. Storing as binary would be base 2.

You would usually need to round up to a multiple of eight or power of two when storing as binary, but it is possible to store a value with an unusual number of bits in a packed format.

Given your example number (ignoring negative numbers for a moment):

```
56789 in base 2 needs 15.793323887 bits (16)
56789 in base 10 needs 4.754264221 decimal digits (5)
56789 in base 16 needs 3.948330972 hex digits (4)
56789 in base 64 needs 2.632220648 characters (3)
```

Representing sign needs an additional character or bit.

To look at how binary compares to text, assume a byte is 8 bits, each ASCII character would be a byte in text encoding (8 bits). A byte has a range of 0 to 255, a decimal digit has a range from 0 to 9. Each character (8 bits) can encode about 3.32 bits of a number per byte `(log(10)/log(2))`

. A binary encoding can store 8 bits of a number per byte. Encoding numbers as text takes about 2.4x more space. If you pad out your numbers so they line up in fields, then numbers are very poor storage encoding, with a typical width being 10 digits youll be storing 80 bits, which would be only 33 bits of binary encoded data.

#### c++11 – How many bytes will be required to store number in binary and text files respectively

I am not too developed in this subject; however, I believe it would not just be a case of the content, but also the META-DATA attached. But if you were just talking about the number, you could store it in ASCII or in a binary form.

In binary, `56789`

could be converted to `1101110111010101`

; there is a simple way to work this out on paper. But, http://www.binaryhexconverter.com/decimal-to-binary-converter is a website you can use to convert it.

`1101110111010101`

has 16 characters, therefore 16 bits which is two bytes.