Infinite precision integer in C++20

Question

This is my infinite precision integer implemented in C++20. It supports negative numbers. I have implemented addition, subtraction, multiplication and binary integer division, which returns quotient and remainder, and all bitwise operators.

Addition is done by base-256 addition with carry, subtraction is done by subtraction with borrow in base-256. Multiplication is base-256 long multiplication, division is done by binary long division using bits.

I have implemented all comparison operators, all arithmetic operators, left-shift, right-shift, bitwise-AND, bitwise-OR, bitwise-XOR, bitwise-NOT, modulus, unary minus, and all in place modification operators, including (pre, post) * (decrement, increment).

And I have overloaded all the operators so that they work with built-in integral types as well. Left-shift and right-shift require the shift amount to be of unsigned integral type, all bitwise operators require both operands to be nonnegative.

I have fixed all the bugs I can find, all the tests I conducted give correct results, but there might be some bugs I haven't found, though there might be no bugs at all.

This is done as a programming challenge, it is for research purposes, though I do wish to make it as efficient as possible.

#include <algorithm>
#include <array>
#include <cstdint>
#include <cstring>
#include <iostream>
#include <stdexcept>
#include <string>
#include <type_traits>
#include <utility>
#include <vector>

using bytes = std::vector<uint8_t>;
using std::string;

class BigInt {
public:
    bytes value;
    bool sign = false;
    size_t length;
    static const BigInt ZERO;
    static const BigInt ONE;
    static const BigInt MINUS_ONE;
    static const BigInt TEN;
    BigInt() : value{ 0 }, sign(false), length(1) {}
    template<std::integral T>
    BigInt(T n) {
        using U = std::make_unsigned_t<T>;
        U num;
        if (std::is_signed_v<T> && n < 0) {
            sign = true;
            num = static_cast<U>(-n);
        }
        else {
            sign = false;
            num = n;
        }

        uint8_t size = sizeof(U);
        value.resize(size);
        std::memcpy(value.data(), &num, size);
        trim();
    }
    explicit BigInt(const string& repr) {
        sign = false;
        value = { 0 };
        length = 1;
        size_t i = 0;
        size_t size = repr.size();
        if (size && repr[0] == '-') {
            sign = true;
            i = 1;
        }
        for (; i < size; ++i) {
            if (!std::isdigit(repr[i]))
                throw std::invalid_argument("Invalid decimal digit in input string");
            *this = *this * BigInt::TEN + BigInt(repr[i] - '0');
        }
        trim();
    }
    constexpr inline explicit operator bool() const {
        return std::any_of(value.begin(), value.end(), [](uint8_t b) { return b != 0; });
    }
    string to_string() const {
        if (!*this) return "0";
        BigInt n = *this;
        n.sign = false;
        string s;
        while (n) {
            auto [q, r] = n.divmod(BigInt::TEN);
            s.push_back("0123456789"[r.value[0]]);
            n = q;
        }
        if (sign) s.push_back('-');
        std::reverse(s.begin(), s.end());
        return s;
    }
    friend std::ostream& operator << (std::ostream& os, const BigInt& n) {
        os << n.to_string();
        return os;
    }
    const inline BigInt copy() const {
        BigInt result;
        result.value = value;
        result.sign = sign;
        result.length = length;
        return result;
    }
    constexpr inline bool operator == (const BigInt& rhs) const { return sign == rhs.sign && value == rhs.value; }
    constexpr inline bool operator != (const BigInt& rhs) const { return !(*this == rhs); }
    constexpr inline bool operator <  (const BigInt& rhs) const { 
        int8_t diff;
        if (diff = int8_t(sign) - rhs.sign) return diff < 0;
        return abs_compare(rhs) == -1 + sign * 2; 
    }
    constexpr inline bool operator >  (const BigInt& rhs) const { 
        int8_t diff;
        if (diff = int8_t(sign) - rhs.sign) return diff > 0;
        return -abs_compare(rhs) == -1 + sign * 2; 
    }
    constexpr inline bool operator >= (const BigInt& rhs) const { return !(*this < rhs); }
    constexpr inline bool operator <= (const BigInt& rhs) const { return !(*this > rhs); }
    const inline BigInt operator + (const BigInt& rhs) const {
        BigInt result;
        if (sign == rhs.sign) {
            length >= rhs.length ? abs_add(value, rhs.value, result) : abs_add(rhs.value, value, result);
            result.sign = sign;
            return result;
        }
        BigInt minuend, subtrahend;
        if (sign) {
            minuend.value = rhs.value;
            subtrahend.value = value;
        }
        else {
            minuend.value = value;
            subtrahend.value = rhs.value;
        }
        return minuend - subtrahend;
    }
    const inline BigInt operator - (const BigInt& rhs) const {
        BigInt result;
        int8_t cmp = abs_compare(rhs);
        if (sign != rhs.sign) {
            cmp == 1 ? abs_add(value, rhs.value, result) : abs_add(rhs.value, value, result);
            result.sign = sign;
            return result;
        }
        if (!cmp) {
            return BigInt::ZERO;
        }
        else if (cmp == 1) {
            abs_sub(value, rhs.value, result);
            result.sign = sign;
        }
        else {
            abs_sub(rhs.value, value, result);
            result.sign = !sign;
        }
        return result;
    }
    const inline BigInt operator << (const size_t& shift) const {
        if (sign) throw std::invalid_argument("Left shift on negative number");

        if (!shift) return *this;
        BigInt result;
        size_t byte_shift = shift >> 3;
        uint8_t bit_shift = shift & 7;
        size_t end = byte_shift + length;
        if (!bit_shift) {
            bytes number(end, 0);
            std::memcpy(&number[byte_shift], &value[0], length);
            result.value = number;
            result.trim();
            return result;
        }
        bytes number(end + 1, 0);
        uint8_t hi_bit = 8 - bit_shift, lo_mask = (1 << hi_bit) - 1, hi = 0, byte;
        for (size_t i = 0, j = byte_shift; i < length; i++, j++) {
            byte = value[i];
            number[j] = (byte & lo_mask) << bit_shift | hi;
            hi = byte >> hi_bit;
        }
        if (hi) number[end] = hi;
        result.value = number;
        result.trim();
        return result;
    }
    const inline BigInt operator >> (const size_t& shift) const {
        if (sign) throw std::invalid_argument("Right shift on negative number");

        if (!shift) return *this;
        BigInt result;
        size_t byte_shift = shift >> 3;
        uint8_t bit_shift = shift & 7;
        if (byte_shift >= length) return result;
        size_t shorth = length - byte_shift;
        bytes number(shorth, 0);
        if (!bit_shift) {
            std::memcpy(&number[0], &value[byte_shift], shorth);
        }
        else {
            uint8_t hi_bit = 8 - bit_shift, hi = 0, byte;
            for (size_t i = shorth, j = length - 1; i-- > 0; j--) {
                byte = value[j];
                number[i] = (byte >> bit_shift) | hi;
                hi = byte << hi_bit;
            }
        }
        result.value = number;
        result.trim();
        return result;
    }
    const inline BigInt operator & (const BigInt& rhs) const {
        if (sign || rhs.sign)
            throw std::invalid_argument("Bitwise AND on negative number");
        
        size_t shorth = std::min(value.size(), rhs.value.size());
        BigInt result;
        bytes number(shorth);
        for (size_t i = 0; i < shorth; i++) number[i] = value[i] & rhs.value[i];
        result.value = number;
        result.trim();
        return result;
    }
    const inline BigInt operator | (const BigInt& rhs) const {
        if (sign || rhs.sign)
            throw std::invalid_argument("Bitwise OR on negative number");

        BigInt result;
        const bytes* longer_ptr = &value, * shorter_ptr = &rhs.value;
        if (length < rhs.length) std::swap(longer_ptr, shorter_ptr);
        const bytes longer = *longer_ptr, shorter = *shorter_ptr;
        size_t longth = longer.size(), shorth = shorter.size();
        bytes number(longth);
        size_t i = 0;
        for (; i < shorth; i++) number[i] = longer[i] | shorter[i];
        std::memcpy(&number[shorth], &value[shorth], longth - shorth);
        result.value = number;
        result.trim();
        return result;
    }
    const inline BigInt operator ^ (const BigInt& rhs) const {
        if (sign || rhs.sign)
            throw std::invalid_argument("Bitwise OR on negative number");

        BigInt result;
        const bytes* longer_ptr = &value, * shorter_ptr = &rhs.value;
        if (length < rhs.length) std::swap(longer_ptr, shorter_ptr);
        const bytes longer = *longer_ptr, shorter = *shorter_ptr;
        size_t longth = longer.size(), shorth = shorter.size();
        bytes number(longth);
        size_t i = 0;
        for (; i < shorth; i++) number[i] = longer[i] ^ shorter[i];
        std::memcpy(&number[shorth], &value[shorth], longth - shorth);
        result.value = number;
        result.trim();
        return result;
    }
    const inline BigInt operator ~ () const {
        if (sign)
            throw std::invalid_argument("Bitwise NOT on negative number");

        BigInt result = *this;
        for (auto& b : result.value) b ^= 255;
        result.trim();
        return result;
    }
    const inline BigInt operator * (const BigInt& rhs) const {
        BigInt result;
        size_t longth = rhs.length;
        uint16_t carry, prod;
        bytes number(length + longth, 0);
        size_t k;
        for (size_t i = 0; i < length; i++) {
            carry = 0;
            for (size_t j = 0; j < longth; j++) {
                prod = uint16_t(value[i]) * rhs.value[j] + number[k = i + j] + carry;
                number[k] = prod & 0xFF;
                carry = prod >> 8;
            }
            number[i + longth] = carry;
        }
        result.sign = sign != rhs.sign;
        result.value = number;
        result.trim();
        return result;
    }
    const inline BigInt operator / (const BigInt& rhs) const {
        return divmod(rhs).first;
    }
    const inline BigInt operator % (const BigInt& rhs) const {
        return divmod(rhs).second;
    }
    const inline BigInt operator - () const {
        BigInt result = *this;
        if (*this != BigInt::ZERO) result.sign = !sign;
        return result;
    }
    const inline BigInt pow(const BigInt& rhs) const {
        if (rhs.sign)
            throw std::invalid_argument("Negative exponents are not supported");

        bool odd = rhs.value[0] & 1;
        BigInt product = 1;
        BigInt square = this->copy();
        BigInt exponent = rhs;
        square.sign = false;
        while (exponent) {
            if (exponent.value[0] & 1) product = product * square;
            square = square * square;
            exponent = exponent >> 1;
        }
        product.sign = sign && odd;
        return product;
    }
    template <std::integral T>
    const inline BigInt pow(T exp) const {
        if (exp < 0)
            throw std::invalid_argument("Negative exponents are not supported");

        bool odd = exp & 1;
        BigInt product = 1;
        BigInt square = this->copy();
        square.sign = false;
        while (exp) {
            if (exp & 1) product = product * square;
            square = square * square;
            exp >>= 1;
        }
        product.sign = sign && odd;
        return product;
    }
    friend inline BigInt pow(const BigInt& lhs, const BigInt& rhs) { return lhs.pow(rhs); }
    template <std::integral T>
    friend inline BigInt pow(const BigInt& lhs, T exp) { return lhs.pow(exp); }
    inline BigInt& operator <<= (const size_t& rhs) { *this = *this << rhs; return *this; }
    inline BigInt& operator >>= (const size_t& rhs) { *this = *this >> rhs; return *this; }
    inline BigInt& operator += (const BigInt& rhs) { *this = *this + rhs; return *this; }
    inline BigInt& operator -= (const BigInt& rhs) { *this = *this - rhs; return *this; }
    inline BigInt& operator *= (const BigInt& rhs) { *this = *this * rhs; return *this; }
    inline BigInt& operator /= (const BigInt& rhs) { *this = *this / rhs; return *this; }
    inline BigInt& operator %= (const BigInt& rhs) { *this = *this % rhs; return *this; }
    inline BigInt& operator &= (const BigInt& rhs) { *this = *this & rhs; return *this; }
    inline BigInt& operator |= (const BigInt& rhs) { *this = *this | rhs; return *this; }
    inline BigInt& operator ^= (const BigInt& rhs) { *this = *this ^ rhs; return *this; }
    inline BigInt& operator++() { *this += BigInt::ONE; return *this; }
    inline BigInt operator++(int) { BigInt temp = *this; ++(*this); return temp; }
    inline BigInt& operator--() { *this -= BigInt::ONE; return *this; }
    inline BigInt operator--(int) { BigInt temp = *this; --(*this); return temp; }
    template <std::integral T>
    inline BigInt operator + (T rhs) const { return *this + BigInt(rhs); }
    template <std::integral T>
    inline BigInt operator - (T rhs) const { return *this - BigInt(rhs); }
    template <std::integral T>
    inline BigInt operator * (T rhs) const { return *this * BigInt(rhs); }
    template <std::integral T>
    inline BigInt operator / (T rhs) const { return *this / BigInt(rhs); }
    template <std::integral T>
    inline BigInt operator % (T rhs) const { return *this % BigInt(rhs); }
    template <std::integral T>
    inline BigInt operator & (T rhs) const { return *this & BigInt(rhs); }
    template <std::integral T>
    inline BigInt operator | (T rhs) const { return *this | BigInt(rhs); }
    template <std::integral T>
    inline BigInt operator ^ (T rhs) const { return *this ^ BigInt(rhs); }
    template <std::integral T>
    inline BigInt& operator += (T rhs) { *this = *this + BigInt(rhs); return *this; }
    template <std::integral T>
    inline BigInt& operator -= (T rhs) { *this = *this - BigInt(rhs); return *this; }
    template <std::integral T>
    inline BigInt& operator *= (T rhs) { *this = *this * BigInt(rhs); return *this; }
    template <std::integral T>
    inline BigInt& operator /= (T rhs) { *this = *this / BigInt(rhs); return *this; }
    template <std::integral T>
    inline BigInt& operator %= (T rhs) { *this = *this % BigInt(rhs); return *this; }
    template <std::integral T>
    inline BigInt& operator &= (T rhs) { *this = *this & BigInt(rhs); return *this; }
    template <std::integral T>
    inline BigInt& operator |= (T rhs) { *this = *this | BigInt(rhs); return *this; }
    template <std::integral T>
    inline BigInt& operator ^= (T rhs) { *this = *this ^ BigInt(rhs); return *this; }
    template <std::integral T>
    friend inline BigInt operator + (T lhs, const BigInt& rhs) { return BigInt(lhs) + rhs; }
    template <std::integral T>
    friend inline BigInt operator - (T lhs, const BigInt& rhs) { return BigInt(lhs) - rhs; }
    template <std::integral T>
    friend inline BigInt operator * (T lhs, const BigInt& rhs) { return BigInt(lhs) * rhs; }
    template <std::integral T>
    friend inline BigInt operator / (T lhs, const BigInt& rhs) { return BigInt(lhs) / rhs; }
    template <std::integral T>
    friend inline BigInt operator % (T lhs, const BigInt& rhs) { return BigInt(lhs) % rhs; }
    template <std::integral T>
    friend inline BigInt operator & (T lhs, const BigInt& rhs) { return BigInt(lhs) & rhs; }
    template <std::integral T>
    friend inline BigInt operator | (T lhs, const BigInt& rhs) { return BigInt(lhs) | rhs; }
    template <std::integral T>
    friend inline BigInt operator ^ (T lhs, const BigInt& rhs) { return BigInt(lhs) ^ rhs; }
    template <std::integral T>
    inline bool operator == (T rhs) const { return *this == BigInt(rhs); }
    template <std::integral T>
    friend inline bool operator == (T lhs, const BigInt& rhs) { return BigInt(lhs) == rhs; }
    template <std::integral T>
    inline bool operator != (T rhs) const { return *this != BigInt(rhs); }
    template <std::integral T>
    friend inline bool operator != (T lhs, const BigInt& rhs) { return BigInt(lhs) != rhs; }
    template <std::integral T>
    inline bool operator > (T rhs) const { return *this > BigInt(rhs); }
    template <std::integral T>
    friend inline bool operator > (T lhs, const BigInt& rhs) { return BigInt(lhs) > rhs; }
    template <std::integral T>
    inline bool operator >= (T rhs) const { return *this >= BigInt(rhs); }
    template <std::integral T>
    friend inline bool operator >= (T lhs, const BigInt& rhs) { return BigInt(lhs) >= rhs; }
    template <std::integral T>
    inline bool operator < (T rhs) const { return *this < BigInt(rhs); }
    template <std::integral T>
    friend inline bool operator < (T lhs, const BigInt& rhs) { return BigInt(lhs) < rhs; }
    template <std::integral T>
    inline bool operator <= (T rhs) const { return *this <= BigInt(rhs); }
    template <std::integral T>
    friend inline bool operator <= (T lhs, const BigInt& rhs) { return BigInt(lhs) <= rhs; }

private:
    inline void trim() {
        auto rit = std::find_if(value.rbegin(), value.rend(), [](uint8_t v) { return v != 0; });
        value.erase(rit.base(), value.end());
        if (value.empty()) {
            value.push_back(0);
        }
        length = value.size();
    }
    constexpr inline int8_t abs_compare(const BigInt& rhs) const {
        size_t longth = rhs.length;
        if (length != longth) return length < longth ? -1 : 1;
        int16_t diff;
        for (size_t i = length; i-- > 0;) {
            if (diff = int16_t(value[i]) - rhs.value[i]) {
                return -1 + (diff > 0) * 2;
            }
        }
        return 0;
    }
    inline void abs_add(const bytes& longer, const bytes& shorter, BigInt& result) const {
        size_t longth = longer.size(), shorth = shorter.size();
        bytes value(longth, 0);
        uint16_t carry = 0;
        size_t i = 0;
        for (; i < shorth; i++) {
            uint16_t sum = uint16_t(longer[i]) + shorter[i] + carry;
            value[i] = sum & 255;
            carry = sum >> 8;
        }
        for (; i < longth; i++) {
            uint16_t sum = uint16_t(longer[i]) + carry;
            value[i] = sum & 255;
            carry = sum >> 8;
        }
        if (carry) value.push_back(carry);
        result.value = value;
        result.trim();
    }
    inline void abs_sub(const bytes& large, const bytes& small, BigInt& result) const {
        size_t longth = large.size(), shorth = small.size();
        bytes value(longth, 0);
        uint16_t borrow = 0;
        size_t i = 0;
        for (; i < shorth; i++) {
            int16_t diff = int16_t(large[i]) - small[i] - borrow;
            borrow = diff < 0;
            value[i] = static_cast<uint8_t>(diff + (borrow << 8));
        }
        for (; i < longth; i++) {
            int16_t diff = int16_t(large[i]) - borrow;
            borrow = diff < 0;
            value[i] = static_cast<uint8_t>(diff + (borrow << 8));
        }
        result.value = value;
        result.trim();
    }
    inline std::pair<BigInt, BigInt> divmod(const BigInt& rhs) const {
        if (!rhs) throw std::invalid_argument("Division by zero");
        int8_t cmp;
        if ((cmp = abs_compare(rhs)) == -1) {
            if (sign == rhs.sign) {
                return { BigInt::ZERO, this->copy() };
            }
            BigInt minuend = rhs.copy(), subtrahend = this->copy(), modulus;
            minuend.sign = subtrahend.sign = false;
            modulus = minuend - subtrahend;
            modulus.sign = rhs.sign;
            return { BigInt::MINUS_ONE, modulus };
        }
        if (!cmp) return {BigInt::ONE, BigInt::ZERO};
        bytes quotient(length);
        BigInt remainder, dividend = this->copy(), divisor = rhs.copy();
        dividend.sign = divisor.sign = false;
        uint8_t byte;
        for (size_t i = length; i-- > 0;) {
            byte = dividend.value[i];
            for (uint8_t j = 8; j-- > 0;) {
                remainder = remainder << 1;
                remainder.value[0] |= (byte >> j) & 1;
                if (remainder.abs_compare(divisor) >= 0) {
                    remainder = remainder - divisor;
                    quotient[i] |= 1 << j;
                }
            }
        }
        BigInt numerator;
        numerator.value = quotient;
        numerator.trim();
        if (sign != rhs.sign) {
            numerator = numerator + BigInt::ONE;
            numerator.sign = true;
            remainder = rhs.sign ? remainder + rhs : rhs - remainder;
        }
        remainder.sign = rhs.sign;
        return { numerator, remainder };
    }

};

const BigInt BigInt::MINUS_ONE = BigInt(-1);
const BigInt BigInt::ZERO = BigInt(0);
const BigInt BigInt::ONE = BigInt(1);
const BigInt BigInt::TEN = BigInt(10);

int main() {
    using std::cout;
    BigInt a("12200160415121876738"), b(46368);
    cout << "a: " << a << ", b: " << b << "\n";
    cout << "a + b: " << a + b << "\n";
    cout << "b + a: " << b + a << "\n";
    cout << "a - b: " << a - b << "\n";
    cout << "a * b: " << a * b << "\n";
    cout << "b * a: " << b * a << "\n";
    cout << "a / b: " << a / b << "\n";
    cout << "b / a: " << b / a << "\n";
    cout << "a > b: " << (a > b) << "\n";
    cout << "a >= b: " << (a >= b) << "\n";
    cout << "a < b: " << (a < b) << "\n";
    cout << "a <= b: " << (a <= b) << "\n";
    cout << "b > a: " << (b > a) << "\n";
    cout << "b >= a: " << (b >= a) << "\n";
    cout << "b < a: " << (b < a) << "\n";
    cout << "b <= a: " << (b <= a) << "\n";
    cout << "b - a: " << b - a << "\n";
    cout << "b - (-a): " << b - (-a) << "\n";
    cout << "(-b) - (-a): " << (-b) - (-a) << "\n";
    cout << "(-b) - a: " << (-b) - a << "\n";
    cout << "a - (-b): " << a - (-b) << "\n";
    cout << "(-a) - (-b): " << (-a) - (-b) << "\n";
    cout << "(-a) - b: " << (-a) - b << "\n";
    cout << "b << 25: " << (b << 25) << "\n";
    cout << "a >> 37: " << (a >> 37) << "\n";
    cout << "pow(a, 9): " << pow(a, 9) << "\n";
    cout << "pow(a, BigInt(9)): " << pow(a, BigInt(9)) << "\n";
}

Compiled with:

g++ -std=c++20 -march=native -O3 -flto -funroll-loops -fomit-frame-pointer -fstrict-aliasing -m64 -o "D:\CliExec\BigInt.exe" "D:\MyScript\BigInt.cpp"

Output:

PS C:\Users\xenig> D:\CliExec\BigInt.exe
a: 12200160415121876738, b: 46368
a + b: 12200160415121923106
b + a: 12200160415121923106
a - b: 12200160415121830370
a * b: 565697038128371180587584
b * a: 565697038128371180587584
a / b: 263115950981752
b / a: 0
a > b: 1
a >= b: 1
a < b: 0
a <= b: 0
b > a: 0
b >= a: 0
b < a: 1
b <= a: 1
b - a: -12200160415121830370
b - (-a): 12200160415121923106
(-b) - (-a): 12200160415121830370
(-b) - a: -12200160415121923106
a - (-b): 12200160415121923106
(-a) - (-b): -12200160415121830370
(-a) - b: -12200160415121923106
b << 25: 1555851902976
a >> 37: 88767850
pow(a, 9): 5988111380203749302281405938825593794758074921697104588146061703693668620265526517158513989265970683614253963908860200687001079849212560161352806929414971396504240019931648
pow(a, BigInt(9)): 5988111380203749302281405938825593794758074921697104588146061703693668620265526517158513989265970683614253963908860200687001079849212560161352806929414971396504240019931648

How can I improve the performance of my program? I want to reduce the execution time.

Not performance related, but the name sign as a bool is a bit confusing. Is true "positive" or "negative"? — Chris
– Chris, Commented May 9 at 19:54
Semi-related re: choice of chunk size/format: BigInt class in C++ - that one used base-10 instead of base-256, but my answer links to some stuff about base 10^9 vs. base 2^30 (like Python's C code) or base 2^32 or 2^64 (like GMP hand-written assembly normally uses, since add-with-carry is a thing most ISAs support.) — Peter Cordes
– Peter Cordes, Commented May 10 at 6:39
The usual term for this is "arbitrary precision". It grows with the numbers. It would take infinite time for the precision to actually become infinite. Also, that can't happen on any actual C++ implementation: size_t needs to have a specific width and a specific SIZE_MAX, which means any concrete C++ implementation has finite object sizes. — Peter Cordes
– Peter Cordes, Commented May 10 at 12:16
Please respond to answers and comments in comments. Do not edit the question after an answer has been posted. Your last edit invalidated at least one answer. Everyone needs to be able to see what the reviewer was referring to. What to do after the question has been answered. The question has been rolled back to the previous version. — pacmaninbw
– pacmaninbw ♦, Commented May 10 at 13:04
I don't have time for a full review but... why are the data-members value, sign and length public? That's how invariants get broken. — Matthieu M.
– Matthieu M., Commented May 11 at 14:56

score 13 · Accepted Answer · 2025-06-02 21:37:42Z

Endian-ness (fundamental information)

Lacking ANY comments, the reader is compelled to try to first deduce the organisation of the bits in the array of bytes used for storage and manipulation.

Review commentary: "off-putting"...

Missing caveat

    BigInt(T n) {
        ...
        std::memcpy(value.data(), &num, size);
        ...

Lacking comments and caveats, the intending adopter whose hardware is "Big Endian"
(eg. Motorola 68000) would find this code requires some careful adaptation before it could be used.

String-izing of values

    string to_string() const {
        ...
            auto [q, r] = n.divmod(BigInt::TEN);
        ...
        std::reverse(s.begin(), s.end());
        ...
    }

Suggest investigating "Double Dabble" to extract base-10 values from an array of 'n' binary bits.
(I have no interest in trying to follow the bitwise machinations of the OP's divmod(), and my sense is that it is somewhat costly.)

The classic "double dabble" nicely converts bits 'big-to-small' to BCD that is childsplay to convert to a string.

Trivialities

For 'completeness':

Code for ("integer") pow() but lacking code for abs().
Code tests <, <= and >, >= but lacking tests for == and !=.

These would help round out the expected suite of int operations.

Inserting some blank lines would help delineate each method's code. In fact, this code would benefit (imo) from separating out a <MyBigInt.h> that would act as a catalog of the overrides on offer...

It would be good to see "test cases" in main() that exercise the operations at-and-near-to 'boundary values' that would compel storage to both expand and shrink. The code seems to implement LOTS of operations that are not 'exercised' by the presented main() test harness. Don't expect the reader/reviewer to try to find edge cases to test your code.

The word "minus" could be either a verb or an adjective, whereas "negative" would be more readily recognised as an adjective. Suggest "MINUS_ONE" be replaced by "NEG_ONE" (or something similar).

Then there's this:

        uint16_t carry = 0;
        ...
        //  uint16_t sum = uint16_t(longer[i]) + shorter[i] + carry;
            uint16_t sum = carry + longer[i] + shorter[i];

If avoiding vertical whitespace (making the code more dense), and not leaving breadcrumbs of comments that may inform the reader, and otherwise compressing the code... then it's worth looking for opportunities to avoid explicit casting wherever they may be. (I apologise for this sarcasm.)

The above could be rewritten with only a single uint16_t 'accumulator'.
No need for both sum and carry.

Be consistent

The coding of abs_compare() is inconsistent in the use of braces of its two single line if() bodies. One hallmark of good coding practice is consistency. A bit of this; a bit of that leads the reader to be doubtful about the code on many levels.

Consider these two snippets:

    const inline BigInt operator * (const BigInt& rhs) const {
                ...
                number[k] = prod & 0xFF;

and

    inline void abs_add( ... ) const {
            ...
            value[i] = sum & 255;

The experienced reader understands what the code is trying to achieve, but scratches their head over this difference.

Suggest using a well-named macro (in both locations) that truncates its argument to an unsigned char result. Until upscaling to use a wider chunk of bytes, forgotten has been the compiler's token UCHAR_MAX. It's often worthwhile to step away from the code for a while.

It's recommended that the only "magic number" constants in code be 0 and 1, either being used only when their purpose is self evident.

Bit fields (to almost infinity and beyond)

Providing bitwise operations suggests this object should be "printable" with more than only
Base-10 strings. This object might be useful for someone interested in going to new heights with the Collatz Conjecture. Or to represent the board of the game Go.

Suggest providing (at least) native 'octal' and/or 'hexadecimal' conversions in this object.

Dream big! It's outside my ken, but I'm aware that cryptography and digitally signed certificates and such-like deal with massive integers.

Read-up on these topics and consider even modest elaborations to this class (or facilitating derivative classes) useful to these sorts of hot development frontiers. (A starting point might be simply providing Base64 conversions as well as bases 8, 10 and 16.) Considering the next topic discussed here, some of this BigInt's functions might be better as protected: than private:.

Use the language

C++ classes provide for 'inheritance'.

Suggest it may be worthwhile separating signed from unsigned datatypes and their peculiar operations. Encapsulating and separating functionality improves code legibility and execution. (Don't need to consider negative values and "signs" when dealing with unsigned BigInt objects.)

On the subject of conversions, being able to smoothly convert to a float or double may be useful to some customers. Perhaps directly from an ultra precise BigInt to an IEEE 754 datatype without having to pass through being a string. This sort of "unusual usage" may be best accommodated by a derived class. Make it possible.

Always one little thing...

Just out of the shower during which a mischievous thought crept into my head...

It appears the constructor from a string would allow "-0" to be converted to -0...

The downstream consequences (minimally that -0 < 0 ==> true) could be treacherous.

How can I improve the performance of my program? I want to reduce the execution time.

Other answers (and comments) have hinted at recognising where/when using the maximum available built-in integer datatype would give a considerable speed-up to your code. Have a read of "guru authored" code (such as that in standard library functions.) You'll see that, for instance, even a simple function like memcpy() has been written to let the hardware copy bytes in blocks of 4 or 8 in one iteration of a loop (instead of 4 or 8 iterations.) There's always a trade-off in coding. Should your code find daily use for 20+ years at 2000+ sites, increasing its speed (and complexity) today could pay dividends for years to come.

And, do your "future self" a favour by generously commenting what you've written. Don't presume that you'll recall the why's and wherefores somewhere down the road...

Speed makes NO difference if the code is wrong and gives incorrect results.
Make 'correct' your objective.

Final words (get there eventually)

Spread the code out (with whitespace and even braces.) The compiler doesn't care, but the readers do. Increasing the density of source code does not make the machine code execute any faster.
Consider using multiple source files to isolate "families of functions" such as "I/O" vs "logical" vs "arithmetic" operations.
Explanatory comments will re-pay the effort spent writing them many times over.
Consider using your own typedef datatypes like limb (instead of uint8_t), and perhaps wlimb as a double wide version. Properly done, you should be able to upscale to processing 'chunks' of 16 (or 32) bits at a time. In the future, when most CPUs have 256 bit registers, your code will be in the catbird seat as "first available working version". (Plan carefully. uint8_t is still available for single byte operations. Should a limb be 2, 4, or 8 bytes? The bigger the better for compare and bitwise operations, although multiplication and division do become more delicate. What if kids were taught in school to work with concatenations of 00-99 (base 100-ish) instead of 'units' 0-9? Keeping track of carries and borrows would be as second nature as it is currently for our single digit world. Think long-and-hard before commencing typing.)
This main() is a start, but its purpose will be MORE important every time you revisit this project. Take the time to expand this to thoroughly test each-and-every operation this class implements. Hard code correct results and let the test harness exercise and evaluate the results. Don't burden yourself with visually checking a "printed" output every time the code is altered & recompiled. Recognise the importance of automated "quality assurance" and maintain the testing code as diligently as the code itself.
Notice that the code of both operator | and operator ^ are quite similar. Do what you can to DISTINGUISH one from the other (eg Big Bold Comments that are hard to miss.) Prevent the possibility of accidentally modifying one while not noticing you intended to modify the other. Accidents happen; no one is perfect. (Only just noticed that the code's XOR exception string says "... OR ...". Oops! :-))

MAKE your testing robust

You've shown one compile command and a sprinkling of demonstrations (main()) that some functions seem to work.

Having proposed using typdef uint8_t limb, it may be apparent that, after the code is altered, building more than one version of the executable (g++ -Dfoobar...) implementing different widths for single limbs would facilitate easily running all tests using 8, 16 and 32 bit limbs. (Perhaps you have access to other compilers like clang... Perhaps you want to use 64bits per limb and write functions that deal with those complications.)

You want the code to function correctly. Try everything you can think of to stress-test its operations. Let clerical make make life slightly easier.

DRY (just because)

Noting the similarity (duplication?) of code for bitwise OR and XOR, below is an untested(!) blending of the two functions to reduce and reuse code at the expense of burning some unnecessary processing cycles. Another trade-off. Less code that exploits re-use may be cheaper in the long run if an unrecognised problem or bug or opportunity is detected and used early in the game. In this case, 34 lines of OP's dense code is, I hope, replaced with what could be equally dense code at only 24 lines. This may not be everyone's cup o' tea, but is not "code golf".

    const inline BigInt operator | (const BigInt& rhs) const {
        if (sign || rhs.sign)
            throw std::invalid_argument("Bitwise OR on negative number");
        return or_xor(rhs).first;
    }

    const inline BigInt operator ^ (const BigInt& rhs) const {
        if (sign || rhs.sign)
            throw std::invalid_argument("Bitwise XOR on negative number");
        return or_xor(rhs).second;
    }

    // and, in "private" section of class
    inline std::pair<BigInt, BigInt> or_xor(const BigInt& rhs) const {
        BigInt *plong = this, *pshort = this; // !! both point to same !!

        if (rhs.length >= length) // reassign one of the two ptrs
            plong = &rhs; // other BigInt is longer (or both same size)
        else
            pshort = &rhs; // other BigInt is shorter

        // two 'result' objects initially duplicates of "longest"
        BigInt result_OR = *plong, result_XOR = *plong;

        // process paired bytes ONLY to extent of shorter array
        for (size_t i = pshort->length; i--;) {
             result_OR.value[i] |= pshort->value[i]; // compute  OR
            result_XOR.value[i] ^= pshort->value[i]; // compute XOR
        }

        result_OR.trim(); result_XOR.trim();
        return { result_OR, result_XOR };
    }

(This is but one of several different ways this utility service could be written.)

Unfortunately, this re-write has brought to light a bug in both the OP's functions:

    //  std::memcpy(&number[shorth], &value[shorth], longth - shorth);
        std::memcpy(&number[shorth], longer_ptr + shorth, longth - shorth);

Again, oops... Need more QA testing before release...

Too often, "copy/paste/adapt" of code with an issue results in two versions of that issue... Too often, after detection, only ONE version is fixed, and people go home for the day... This can be expensive and ruin a company's reputation!

KISS

The value of comments is roughly the same as the tradition of "explaining the code to your rubber duck". One uses different regions of the brain writing formal code and simply telling a story.

    constexpr inline bool operator <  (const BigInt& rhs) const { 
        int8_t diff;
        if (diff = int8_t(sign) - rhs.sign) return diff < 0;
        ...

versus

    constexpr inline bool operator <  (const BigInt& rhs) const { 
        // when signs differ, I'm lesser if I'm NEG; and vice versa
        if (sign != rhs.sign) return sign;
        ...

There's some unnecessary 'cleverness' throughout the code that often is an indication of a need to just "take a break and come back to it".

Being redundant: "This code suffers from a lack of comments."

WET (Write Exhaustive Testcode)

Having mused over this answer for some days, I repeat the imperative to properly and fully develop a test harness that thoroughly exercises every facility. Don't make your paying customers your "Beta testers".

Ideally, running all tests will result in only one message, "All tests ran successfully." Strive to ensure 'all tests' actually test everything with all sorts of good and bad values thrown at the code.

Suggestion:
calculate 6! using both 1x2x3x4x5x6 and 6x5x4x3x2x1.
Do both paths land on the same result (720)? (bigger than 255/0xFF)
Now, reverse the operations to exercise division.
Do both paths return to 1 (or 6) on the LAST step (and not the 2nd last)?

Now wrap that in a loop that exercises 7!, 8!, 9!, ... n!.
You can 'test' the operations to some astronomical values without having to painstakingly work out each "correct" value.

When you're writing code (and comments) your purpose is to make the code work correctly.
When you're writing tests, your purpose is to BREAK the code in any way possible.
"White hat" vs "Black hat".

No more need for an oxygen mask (or pressure hull)

Seeking to prove the Collatz Conjecture will require these BigInt capabilities. An intending user would appreciate the speed-up of their calculations if those 'hailstone' values could be extracted from the BigInt into, for instance, unsigned long long built-ins when they fall down from the stratosphere (or rise from the depths, if signed). The 'supplemental oxygen' facilities of the BigInt was useful, but there's still a long way to go to return to 1 atm pressure. Application code should be able to resume using ordinary ints when it can.

This could be "on the user's shoulders" to code such functions.
More convenient if the object does the work reliably.

Suggest a simple, built-in boolean function to test if the BigInt value is close enough to zero to fit into a user specified type (eg. uint32_t or int16_t), performing extraction into that variable from the BigInt object (if possible). This must support both positive and negative extremities.

Use case: The code, so far, provides for modulo division by an ordinary built-in integer type. The result of x = biggie % 12 constrains x to also be a BigInt even though its value will be between 0 and 11 inclusive. 'Twould be nicer if this were accounted for in this operation, rather than the apparent copy/paste/adapt replication of similar arithmetic operations. Implementation seems to have been hasty without deep consideration for what's actually being coded. This same insight applies to (at least) & when one of the values is an ordinary integer datatype.

Wear your "white hat" when writing code, but get comfortable wearing a "black hat" when doing your own review of what you've written. None of us is as smart or as skilled as we each think we are!

When one stops to think about things, pow() should not be tied-up with intimate knowledge of the inner workings of this object. Find a (precedence) table listing standard C or C++ operators. Notice that there are no complex functions that process values of their operands. pow() is a library function, not an operator, and its implementation should be discrete - external to the class. Avoid overburdening the class with unrequired complexity. KISS.

On the topics of pow() and 'extreme', I question the need for pow(BigInt& exp). I've not done the math, but suspect that a ceiling of a (currently) 64 bit exponent for a non-trivial BigInt value may wind up simply blowing up memory allocation after many minutes, hours or days of appearing to be caught-up in an endless loop somewhere.
Even tiny 2 explodes: 2^(2⁶⁴-1) would require a truly collosal quantity of bits/bytes.

"Infinity is big. Really big. You just won't believe how vastly, hugely, mindbogglingly big it is. I mean, you may think a BigInt will take you places, but that's just peanuts to Infinity."
--- paraphrase of Douglas Adams' "Hitchhiker's Guide to the Galaxy"

(Don't miss "Towel Day"! May 25^th. Mark your calendar.)

Hex I/O would also be vastly more efficient for huge bigints. Especially vs. the OP's current implementation, but still quite a lot better than the best possible binary to base 10. Especially if you use SIMD manually (How to convert a binary integer number to a hex string? - 32 bytes to 64 hex digits with a handful of fast instructions on recent CPUs like Zen 4/5), or maybe even pure C++ that auto-vectorizes. — Peter Cordes
– Peter Cordes, Commented May 10 at 12:29
@PeterCordes Hear, hear! While 75 digit (decimal) values are an interesting curiosity, especially when one knows they aren't just estimates, I wonder how many people are actually interested in all of the digits (in most cases...) Big Hex numbers may serve just as well as Big Decimal... — user272752
– user272752, Commented May 10 at 12:34
Actually I don't know the complexity of bigint division... Stephen C says Java 8 has O(N^2), or 2K(N) + O(NlogN) for big numbers. For bigint / 1e9 (1 limb) it would be O(N) I think. (For example GMP has hand-written asm for mpn / limb - gmplib.org/repo/gmp/file/tip/mpn/x86_64/divrem_1.asm . Also asm for mpn / 2limb). Peeling off 9 decimal digits at a time would be simple and a 9x speedup over the naive algo. Probably slow enough that even if it doesn't fit in cache, memory bandwidth isn't a bottleneck, except maybe on big servers. — Peter Cordes
– Peter Cordes, Commented May 10 at 12:45
Integer division is fairly fast on modern CPUs, like 1 per 10 cycles on Alder Lake P-cores for div r64 (which does 128-bit / 64-bit division), 7 cycles on Zen 4, 6 cycles on Alder Lake E-cores (which don't clock as high). uops.info tested both fast (0 / 1) and slow inputs (0x343a9ed744556677:0000000000000085 / 0x75e6e44fccddeeff), and found both the same speed on Alder Lake, unlike some older cores. Apple M1 is even faster, like a throughput of like 3 cycles if I recall correctly? Hardware div is useful for bigint / 1limb, but IIRC GMPlib doesn't use it for bigint / bigint. — Peter Cordes
– Peter Cordes, Commented May 10 at 12:53
So Double Dabble has O(N^2) time complexity, which doesn't look bad. Except the number of N-bit operations is the number of bits, not the number of limbs, so the constant factor includes a factor of 32 or 64 (CHAR_BIT * sizeof(limb_t)) for the number of passes over the data. — Peter Cordes
– Peter Cordes, Commented May 10 at 13:00

indi · Accepted Answer · 2025-05-09 19:40:42Z

I don’t have time to do a full review, unfortunately, but while skimming your code, I did notice a lurking bug:

    template<std::integral T>
    BigInt(T n) {
        using U = std::make_unsigned_t<T>;
        U num;
        if (std::is_signed_v<T> && n < 0) {
            sign = true;
            num = static_cast<U>(-n);
// The problem is here ----------^^ ////////////////////////////////////
        }
        else {
            sign = false;
            num = n;
        }

        uint8_t size = sizeof(U);
        value.resize(size);
        std::memcpy(value.data(), &num, size);
        trim();
    }

Blindly applying negation to a number… especially one you already know is negative… is dangerous. When the integer type uses two’s complement (which will always be the case in C++20), the absolute value of the largest negative number will always be one greater than the largest positive number. For example, for an 8-bit integer, std::numeric_limits<std::int8_t>::max() is 127, but std::numeric_limits<std::int8_t>::lowest() is −128.

Surely you can see the problem now. If the value happens to be std::numeric_limits<T>::lowest(), then doing -n will overflow. Yes, you are eventually putting it into an unsigned type—immediately right after the negation—but by then it is too late. You have already triggered UB.

There are a number of ways to fix the problem. The obvious way is to just special-case std::numeric_limits<T>::lowest(). A branch-less solution could have you incrementing n, then doing the negation (which will be safe), then casting to the unsigned type, then incrementing. For example, if the value is −128, this will increment it to −127, then negate it to 127, then increment it again to 128. If the value happens to be −1, this will be harmless, because it will be incremented to 0, negated… which is still 0… then incremented to 1. There are probably also bit-twiddling solutions, too.

This is not the only bug I spotted. Even in this same constructor you have a whole wash of problems in that short bit just after the conditional. (And you probably want to make the constructor explicit to boot, among other things.) There are a lot of high-quality C++ experts around here though, so I’m sure someone else will help you out there.

Asking because I'm unsure 'bout this: Is there an inherent "endian" presumption in the OP's code you've focused on? (cf memcpy()) Wouldn't this impact using wider built-in integer types? — user272752
– user272752, Commented May 10 at 3:06
@Fe2O3: Using wider "limbs" could change the object-representation vs. a uint8_t version, and make it depend on native endianness. But unless you're mixing byte access with word access, things should still work other than serializing / deserializing with write/read of raw bytes across machines of different endianness. That would require care. — Peter Cordes
– Peter Cordes, Commented May 10 at 6:35
@PeterCordes Thank you. I've decided to add this concern to my answer to increase its prominence... It's a shame that the OP chose to "let the code speak for itself" without any comments... Cheers! :-) — user272752
– user272752, Commented May 12 at 0:28

user555045 · Accepted Answer · 2025-05-09 23:32:40Z

all bitwise operators require both operands to be nonnegative.

This is a possible design trade-off, personally I prefer Python's style of "as-if infinitely sign-extended", in which negative integers are considered to have a bit-pattern consisting of whatever the bottom bits would be in a two's complement representation, with an unlimited number of leading ones (which of course are not stored, but represented implicitly by the sign). Then for example the XOR of two negative integers is non-negative, the OR of a negative and a non-negative integer is negative, that sort of thing. It extends the semantics of bitwise operations on non-negative integers in a nice and consistent way to negative integers. Of course, whether you want to do that is entirely up to you.

though I do wish to make it as efficient as possible

Before I go way overboard on this, there is something simple that you can do that helps a lot: change std::vector<uint8_t> to std::vector<uint32_t>. That way many operations require about a quarter of the elementary operations, and the difference is much bigger for multiplication. uint64_t is an option, but then instead of having a convenient twice-as-wide type (that can hold the full result of a product, and a double-wide dividend before dividing it in Algorithm D) you need to do special things instead.

division is done by binary long division using bits

You could use word-based division eg Knuth's Algorithm D.

Multiplication is base-256 long multiplication

You could implement some extra algorithms, not replacements exactly but things that kick in at certain size thresholds:

Karatsuba
Toom-Cook
If you want to go this far, some FFT based multiplication such as Schönhage–Strassen or a floating-point based FFT (it sounds shady and unreliable but apparently there are ways to use it such that the result is fully correct), see eg http://www.numberworld.org/y-cruncher/internals/multiplication.html

while (n) {
    auto [q, r] = n.divmod(BigInt::TEN);
    s.push_back("0123456789"[r.value[0]]);
    n = q;
}

This is a nice and simple base conversion, there are more efficient options. A basic trick is to "chop off" more than 1 digit at the time, for example 9 digits, which still fit in a normal integer. Then convert that normal integer to a decimal string with normal integer operations (not big-integer operations, so they're much more efficient), taking care to keep leading zeroes for most blocks except the leading block. That way it only costs 1/9th of the big-integer divisions.

Another trick is you can "split" the big-int down the middle (approximately) by divmod-ing it by the appropriate power of ten, then recursively to_string both halves (the concern about conserving leading zeroes applies here as well). That very quickly reduces the size of the numbers that are worked with, which for bigintegers makes them more efficient to work with.

Full credit to @chux: #define STR_DEC_SIZE(num_bits) ((num_bits) *28 / 93 + 2) is suggested as a conversion formula to determine "base 10 width from base 2 bit count" (including trailing \0). This would be a handy value to have when "divmod-ing it by the appropriate power of ten". — user272752
– user272752, Commented May 10 at 3:09
28/93 is pretty good (thank you @chux), but comes with a proviso: Up to 128 bits, the formula tends to overestimate the base-10 equivalent width for many bit counts. (The 'width' aspect of the two number systems does not reconcile exactly, especially without recourse to floating point!) With 274/930, fewer overestimates result (with no underestimates). Caution: It seems that going too much above 128 bits may enter the Twilight Zone resulting in intermittent underestimations (FWIW). (128 bits => 39 decimal digits) — user272752
– user272752, Commented May 24 at 3:35

chux · Accepted Answer · 2025-05-11 22:08:21Z

+123

I'd expect "+123" to convert to a BigInt just fine. Allow an optional leading '+'.

    explicit BigInt(const string& repr) {
        sign = false;
        value = { 0 };
        length = 1;
        size_t i = 0;
        size_t size = repr.size();
        // if (size && repr[0] == '-') {
        if (size && (repr[0] == '-' || repr[0] == '+')) {
            // sign = true;
            sign = repr[0] == '-';
            i = 1;
        }

-0

Consider either 1) not encoding a BigInt -0 (.sign is only true when value is not 0) or 2) re-work code to proper handle BigInt -0. (many bugs so far.) Note -0 == +0.

Next: abs(), isqrt(), div() (form quotient and remainder), int signum()

apply()

Consider a member function int apply(int (*f)(byte &, void *st), void * state, int direction=up /* or down */) applies a passed in function to each byte of the big integer, potentially changing it. If f(byte[i], state) throws, catch it and stop iterating. Return last value return by f().

From this, all sorts of user generated integer helper function are possible: print in hex, find MSBit index, find smallest non-zero bit, parity, ...

Some C examples.

Just to say, a lonely "-" or "+" (with no digits following) should probably trigger an exception, too... Cheers! :-) — user272752
– user272752, Commented May 13 at 1:04
@Fe2O3 Ture, A first I thought OP's code handled that - guess it does not. — chux
– chux, Commented May 13 at 3:43

Toby Speight · Accepted Answer · 2025-05-19 14:56:13Z

`uint8_t`

I'm guessing that the uses of uint8_t are intended to be std::uint8_t, since C++ implementations are allowed to define global-namespace versions of these names in addition to the std namespace. However, that's a permission, not a requirement.

Even with that corrected, there's a portability problem in this code, as it won't compile for targets that don't support this optional type (the same is true for std::uint16_t).

There's some work involved in making the code more processor-agnostic, but it's not difficult.

This type seems to be used where it's clearly inappropriate (e.g. assigned from sizeof) or where plain unsigned would be more idiomatic (and possibly faster, depending on the target platform).

`constexpr`

I don't see very much constexpr in this code, but there's quite a bit that could be made so (subject to the restriction that all created instances are destroyed within the constexpr expression, due to the contained std::vector).

User-defined literal

It's worth adding a user-defined literal operator if you can.

Unit tests

We're completely lacking unit tests. The provided main() exercises some of the code but fails to check whether any of the results are correct.

Stack Exchange Network

Infinite precision integer in C++20

5 Answers 5

Endian-ness (fundamental information)

Missing caveat

String-izing of values

Trivialities

Be consistent

Bit fields (to almost infinity and beyond)

Use the language

Always one little thing...

Final words (get there eventually)

MAKE your testing robust

DRY (just because)

KISS

WET (Write Exhaustive Testcode)

No more need for an oxygen mask (or pressure hull)

`uint8_t`

`constexpr`

User-defined literal

Unit tests

You must log in to answer this question.

Linked

Hot Network Questions

Infinite precision integer in C++20

5 Answers 5

Endian-ness (fundamental information)

Missing caveat

String-izing of values

Trivialities

Be consistent

Bit fields (to almost infinity and beyond)

Use the language

Always one little thing...

Final words (get there eventually)

MAKE your testing robust

DRY (just because)

KISS

WET (Write Exhaustive Testcode)

No more need for an oxygen mask (or pressure hull)

uint8_t

constexpr

User-defined literal

Unit tests

You must log in to answer this question.

Linked

Related

Hot Network Questions

`uint8_t`

`constexpr`