Base Conversion: Raw Binary Strings vs C++ Bitset Pitfalls

When your base conversion tool spits out a 32-bit binary string, can you paste it straight into a C++ std::bitset declaration?

Most developers assume yes. Convert a decimal or hex value to binary, copy the result, and drop it between the quotes of a std::bitset constructor. Sometimes it works. Sometimes it quietly shifts every bit into the wrong position, and the program compiles without a warning.

The difference between those two outcomes comes down to how the constructor reads a string, and whether the string you pasted is longer than the bitset you pasted it into. This guide walks through both failure modes and gives you a paste workflow that cannot corrupt a value silently.

How the string constructor reads its input

std::bitset accepts a std::string, and that string is interpreted as a binary number. The direction is the part people get wrong: the rightmost character is the least significant bit, and the string is read right to left.

So std::bitset<8>("110010") does not mean "twelve bits of nothing and then 110010". It means the six characters occupy bits 5 down to 0, and the two remaining bit positions are zero on the left. The result is 00110010, which is 50 in decimal.

Two consequences follow directly from that mapping:

- A shorter string is safe. Missing positions are padded with zeros on the left, so std::bitset<8>("101") sets bits 2 and 0 and evaluates to 5. - Leading zeros in the string are meaningful and preserved. std::bitset<8>("00001111") is 15, exactly as intended.

The constructor also takes optional parameters for a starting position and a length, so you can read a slice of a longer string rather than all of it. When you supply neither, the whole string is used.

The silent truncation trap

Now the problem. If the string is longer than the bitset's size, the extra characters have nowhere to go — and the constructor does not complain. Because the rightmost character is bit 0, the characters that fall off are the leftmost ones.

Take a value that needs nine bits. Your converter reports decimal 300 as 100101100, and you paste it into an 8-bit bitset:

std::bitset<8> a("11001010");  // 11001010 -> 202, fits exactly
std::bitset<8> b("100101100"); // nine characters into eight bits

Only the rightmost eight characters survive: 00101100, which is 44. Not 300, and not 150 either — the value most people expect when they think "the leading 1 was dropped". The result is the low eight bits of 300, and nothing in the output tells you a bit was lost.

The same thing happens to std::bitset<8>("10000000000"), which is decimal 1024 in eleven characters. The rightmost eight are 00000000, so the bitset holds zero. A value of one thousand and twenty-four becomes zero, silently.

This is worth stating plainly because it is counter-intuitive: the direction of truncation is the opposite of what most people assume. It is not the lowest bits that are discarded; it is the highest bits, because the highest bits are the leftmost characters.

Why a converter hands you a minimal-length string

The base converter on this site, like most, produces the shortest possible representation: it strips leading zeros. Decimal 5 comes out as 101, not 00000101. Decimal 202 comes out as 11001010. Decimal 300 comes out as 100101100.

That is correct for display and dangerous for pasting, because the length of the output is the width you did not choose. The converter does show you the width as a separate readout — the field labeled with the bit count — and that number is the one to compare against your bitset size before you copy anything. It also flags values at or above 2,147,483,648 as outside the 32-bit signed range, which is a useful signal that you are past the width most embedded code assumes.

The rule that follows is simple: the converter's output length must be less than or equal to the bitset's template parameter. If it is greater, pad the declaration or widen the bitset — do not hope.

String literals versus C++14 binary literals

There are two ways to get a binary-looking value into a bitset, and they behave differently because they are different kinds of thing.

std::bitset<8> from_string("11001010"); // a std::string: read right-to-left
std::bitset<8> from_literal(0b11001010); // an integer literal: value 202

The string form is what most people mean when they talk about "copying binary code in". It preserves digits exactly as typed, including leading zeros, and it is the only form that can represent a bitset wider than 64 bits, because a string has no width limit.

The 0b form is a C++14 integer literal, not a binary string. It is evaluated by the compiler into an integer first, and only then handed to the bitset's integer constructor, which copies the low N bits. That has two consequences. First, an integer literal cannot exceed 64 bits, so 0b... is unusable for a 128-bit bitset — the compiler rejects the literal before bitset ever sees it. Second, an oversized value truncates by masking rather than by dropping characters. Interestingly, the results agree: std::bitset<8>(0b100101100) also yields 44, because 300 modulo 256 is 44. Both routes keep the low eight bits. Neither route warns you.

If your values fit in 64 bits and you want the compiler to do the conversion, the 0b form is tidier. If you are pasting output from a converter, or you need more than 64 bits, the string form is the one you want — with the padding check that goes with it.

A paste workflow that cannot silently corrupt

1. Read the converter's width, not just the digits. If the width is 9 and your bitset is 8, stop. 2. Pad the string to exactly the bitset size when you want the digits to line up visually: "0100101100" into a 10-bit bitset rather than "100101100". Padding on the left is safe because it only adds zero bits at the top. 3. Assert the round trip. Immediately after declaring the bitset, convert it back with to_string() and compare against the padded input. A mismatch at this point is a compile-time-visible bug rather than a field failure. 4. Prefer the integer constructor when you have the integer. If your converter also reports the decimal value, std::bitset<N>(value) removes the string entirely and makes the width explicit in N.

For fixed constants, a static_assert on the round trip costs nothing at runtime and turns a silent truncation into a build failure, which is the cheapest place to find it.

What actually throws, and what does not

The exceptions are narrower than most people expect, and this is the source of a lot of misplaced confidence:

- std::invalid_argument is thrown when a character is not '0' or '1' (or whatever alternate digits were configured). A stray O instead of a zero, or a space in the middle of the string, throws. - std::out_of_range is thrown when the starting position is past the end of the string. - A string longer than the bitset does not throw. It truncates, exactly as described above.

So "it compiled and it did not throw" is not evidence that your value survived. The only evidence is the round trip, or comparing the converter's width readout against your template parameter before you paste.

The short version

std::bitset reads a binary string from the right, so the last character is bit 0 and the string is left-zero-padded. A string shorter than the bitset is safe; a string longer than the bitset loses its leftmost characters, taking the most significant bits with them, and reports nothing. A converter that strips leading zeros gives you a string whose length you did not choose, which is why its width readout is the number that matters. Check the width against the template parameter, pad deliberately, and assert the round trip. After that, pasting converted binary into a bitset declaration is as safe as it looks.