Coder Legion - Recent posts tagged cplusplus

Tuesday Coding Tip 20 — Be `explicit`!

Tue, 21 Jul 2026 09:59:00 +0000

Tuesday coding tips are super short posts about various tidbits mainly from C++, but also from other programming languages I use. You can also follow the #TuesdayCodingTips hashtag on Mastodon and Linkedin.

If you choose to add a conversion operator for your class in C++, be sure to mark it as explicit or you can get nasty side-effects that will be hard to debug. For example, having an implicit conversion operator to bool will make the operator less-than “work” for your class, meaning that class can be used as a key for std::map and suddenly, all hell breaks loose.

#include <iostream>
#include <vector>

class A {
public:
    operator bool() {
        return true;
    }
};

class B {
public:
    explicit operator bool() {
        return true;
    }
};

int main() {
    // This is ok
    std::cout << (A() < A()) << std::endl;
    A a;
    if (a); // implicit conversion allowed

    // Error: error: invalid operands to binary expression
    std::cout << (B() < B()) << std::endl;
    B b;
    if (bool(b)); // explicit conversion required

    return 0;
}

Similarly, it is good practice to mark single parameter constructors explicit to prevent implicit conversions from trivial data types or to possibly track places where your object is copied.

class A {
public:
    A(int) {}
    A(const A&) {}
};

class B {
public:
    explicit B(int) {}
    explicit B(const B&) {}
};

int main() {
    A a1 = 10; // ok
    A a2 = { 10 }; // ok
    A a3 = a1; // ok

    B b1 = 10; // error: no viable conversion, explicit constructor is not a candidate
    B b2 = { 10 }; // error
    B b3 = B{10}; // ok
    B b4 = b1; // error
    B b5 = B{b1}; // ok

    return 0;
}

Tuesday Coding Tip 19 — [[nodiscard]] annotation

Tue, 14 Jul 2026 09:59:00 +0000

Since C++17, one can use [[nodiscard]] annotation to mark API functions whose return values should not be discarded without consideration. This usually applies to methods that make no sense to call without evaluating their return value (like predicate functions such as empty or a factory function). The compiler will issue a warning if the return value is not handled.

class [[nodiscard]] A {};

// OR

class B {
public:
    [[nodiscard]] B() = default;
};

// Enums can be nodiscard too
enum class [[nodiscard]] State {
    Default,
    Foo,
    Bar
};

int main()
{
    // warning: ignoring temporary created by a constructor declared with 'nodiscard' attribute
    A();
    B();
}

But beware! Sometimes it might be tempting to return some scope guard that will maintain postconditions automatically at the end of the scope using RAII (such as committing transactions). However, a user of your API can pipe the result of your nodiscard function into a std::ignore helper which causes the temporary to destruct immediately, defeating the idea of end-of-scope cleanup.

#include <tuple> // std::ignore

class [[nodiscard]] A {};
class B {
public:
    [[nodiscard]] bool isOk() const { return true; }
};

// no need for nodiscard, A is nodiscard
A foo() {
    return A();
}

// B is not nodiscard, mark it explicitly
[[nodiscard]] B bar() {
    return B();
}

int main()
{    
    foo(); // warning: ignoring temporary created by a constructor declared with 'nodiscard' attribute
    bar(); // warning

    std::ignore = foo(); // ok
    auto b = bar(); // ok
    b.isOk(); // warning
    if (b.isOk()) {} // ok
}

Tuesday Coding Tip 18 — Generating random numbers in C++

Tue, 07 Jul 2026 09:59:00 +0000

Classic C way of generating random numbers is to set the current time as a seed and then modulo results of the rand function to get somewhat random numbers (modulo can introduce bias based on the implementation of rand).

#include <iostream>
#include <random>

// Get random integer in range <min, max)
int getRandomNumber(int min, int max)
{
    return rand() % (max - min) + min;
}

int main()
{
    // seeding with current time to get different output each time
    srand(time(NULL));

    for (int i = 0; i < 10; i++)
        std::cout << getRandomNumber(10, 20) << std::endl;
}

C++11 introduces the concept of engines, adaptors, and distributions. Engines are seedable and give you random numbers similar to rand() calls. However, each engine is implemented differently, impacting its speed and memory footprint. Adapters tamper with RNG output, such as shuffling the order of output values or discarding them.

Distributions transform the output from the generators to get values in certain ranges and probabilistic properties, such as the middle value being the most probable (normal distribution). Distributions are more nuanced than just using the modulo operator so their outputs are more suitable for cryptography use-cases.

#include <iostream>
#include <random>

// Get random integer in range <min, max)
int getRandomNumber(int min, int max)
{
    return rand() % (max - min) + min;
}

int main()
{
    std::random_device rd; // non-seedable source of non-deterministic numbers from hardware
    std::mt19937 generator(rd()); // deterministic generator with uniform distribution
                                  // seeded with totally random number

    std::uniform_int_distribution<> distribution(10, 19);

    for (int i = 0; i < 10; i++)
        std::cout << distribution(generator) << std::endl;
}

Tuesday Coding Tip 17 — Wrapping C APIs

Tue, 30 Jun 2026 09:59:00 +0000

Resource Acquisition is Initialization (RAII) is an awfully named principle saying that your class should be fully usable after construction and should clean itself up in the destructor (in other words, no (de)init methods). This principle is common in modern programming languages and is also adopted in modern C++ codebases.

But what if you work with C-like API like fopen? It returns a pointer you need to manually free before it goes out of scope. Otherwise, you leak memory and open file handles. This is where smart pointers come to the rescue as you can wrap raw pointers with them and give them custom callbacks to execute when they leave the scope.

#include <cstdlib>
#include <iostream>
#include <memory>

// MSVC disallows calling fopen
#pragma warning(disable : 4996)

void CloseFile(FILE* f)
{
    std::cout << "Closing file" << std::endl;
    fclose(f);
}

auto SafeFopen(const char* path, const char* mode)
{
    return std::unique_ptr<FILE, decltype(&CloseFile)>(
        fopen(path, mode), CloseFile);
}

int main()
{
    auto&& fp = SafeFopen("myfile.txt", "w");
    return 0;
    // Outputs: Closing file
}

Tuesday Coding Tip 16 — Creating objects in existing memory

Tue, 16 Jun 2026 09:59:00 +0000

C++ allows you to scrap your OS’ memory allocators, get yourself a huge chunk of memory and write your own allocators (they can be used with the standard library). It’s a hardcore optimization, but here’s a related tip that might be handy in normal projects as well.

When using the operator new, one can provide it with an already allocated memory, so it runs a constructor for a particular type in there. After that, reinterpret that memory as a pointer to your desired object and use it normally. However, deletion is a bit more complicated, as you have to call the destructor on that object manually (because delete must be called on the original memory, not the object).

// using some template type T
auto&& buffer = static_cast<std::byte*>(::operator new(sizeof(T)));
if (!buffer) throw std::bad_alloc();

new (buffer) T();
auto&& object = reinterpret_cast<T*>(buffer);

// ...

object->~T(); // call destructor
delete[] buffer; // properly release memory

I used this trick when implementing a resource manager that needs to hold any user data type (that is still default-constructible in my case): link

Tuesday Coding Tip 15 — Mathematical constants in C++

Tue, 09 Jun 2026 09:59:00 +0000

Since C++20, you can include header <numbers> and use many commonly used, precomputed mathematical constants like Pi, Phi, square root of 2 and 3, natural logarithms of 2 and 10, and many more! Even better, you can choose their precision by specifying the underlying type via a template.

And since C++17, the <cmath> header contains some special math functions I’ve never heard of like cylindrical Bessel functions, associated Legendre polynomials, or Riemann zeta function.

#include <iostream>
#include <numbers>
#include <iomanip> // std::setprecision
#include <limits> // std::numeric_limits

template<typename T>
void printConstant(T value)
{
    const auto default_precision{std::cout.precision()};

    std::cout << std::setprecision(std::numeric_limits<T>::digits10 + 1);
    std::cout << value << std::endl;

    std::cout << std::setprecision(default_precision);
}

int main()
{
    using namespace std::numbers;
    printConstant(pi_v<float>);
    printConstant(pi_v<double>);
    printConstant(pi_v<long double>);

    /* Outputs:
    3.141593
    3.141592653589793
    3.141592653589793239
    */
}

Constants are documented here: https://en.cppreference.com/w/cpp/numeric/constants
Special functions are documented here: https://en.cppreference.com/w/cpp/numeric/special_functions

Tuesday Coding Tip 13 — Deleting problematic overloads

Tue, 26 May 2026 09:59:00 +0000

Suppose you have a C++ function for opening a file stream that accepts a path to a file and a string (view) with open-mode specifications (like fopen). The issue is, even though your API is strongly typed, users can still swap the arguments by accident and don’t get a compile time error, due to implicit conversions from string-like constants.

Luckily, there is an easy hack with which you can disable implicit conversions for one particular function by explicitly deleting all overloads (via auto template) and allowing just one particular version. The coolest thing is that even the return value doesn’t have to match!

#include <filesystem>

using path = std::filesystem::path;

void fopen2(const auto&, const auto&) = delete;

FILE* fopen2(const path& fp, const std::string& mode)
{
    /* dummy implementation */
    return nullptr;
}

int main()
{
    // error: call to deleted function 'fopen2'
    // note: candidate function [with auto:1 = char[11], auto:2 = char[2]] has been explicitly deleted
    fopen2("myfile.txt", "r");

    // This is ok
    fopen2(path { "myfile.txt" }, std::string { "r" });
    return 0;
}

Tuesday Coding Tip 12 — Stack trace

Tue, 19 May 2026 09:59:00 +0000

C++23 brings a new feature that I always wanted since I’ve seen it in C# — stack trace.

When combined with exceptions, it can immensely help with the analysis of user error reports, when you cannot simply attach a debugger. The code snippet shows how to create an exception class that can automatically capture stack trace at the point where it was constructed.

#include <iostream>
#include <stacktrace>
#include <stdexcept>

class stacktrace_error : public std::runtime_error
{
public:
    stacktrace_error(std::stacktrace trace = std::stacktrace::current())
        : std::runtime_error(std::to_string(trace))
    {}
};

void bar() { throw stacktrace_error(); }
void foo() { bar(); }

int main()
{
    try
    {
        foo();
    }
    catch (std::exception& e)
    {
        std::cerr << e.what() << std::endl;
        /* OUTPUTS:
        0> C:\...\Main.cpp(19): Sandbox!bar+0x44
        1> C:\...\Main.cpp(25): Sandbox!foo+0x20
        2> C:\...\Main.cpp(31): Sandbox!main+0x32
        3> D:\a\_work\1\s\src\vctools\crt\vcstartup\src\startup\exe_common.inl(79): Sandbox!invoke_main+0x39
        4> D:\a\_work\1\s\src\vctools\crt\vcstartup\src\startup\exe_common.inl(288): Sandbox!__scrt_common_main_seh+0x12E
        5> D:\a\_work\1\s\src\vctools\crt\vcstartup\src\startup\exe_common.inl(331): Sandbox!__scrt_common_main+0xE
        6> D:\a\_work\1\s\src\vctools\crt\vcstartup\src\startup\exe_main.cpp(17): Sandbox!mainCRTStartup+0xE
        7> KERNEL32!BaseThreadInitThunk+0x14
        8> ntdll!RtlUserThreadStart+0x21
        */
    }
}

The API even allows you to iterate over each stack entry, but honestly — who needs that?

Note: Linux versions of GCC and Clang have this stupid idea of requiring you to manually link stacktrace (akin to math library), because -std=c++23 is apparently not enough of a feature flag. So don't forget to use -lstdc++_libbacktrace argument for compilation.

UltrafastSecp256k1 v4.0 — Optional Secondary secp256k1 Backend for Evaluation

Sun, 17 May 2026 00:46:15 +0000

Overview
UltrafastSecp256k1 v4.0 is a high-performance secp256k1 engine built for evaluation as an optional secondary backend for Bitcoin Core. The goal is not to replace libsecp256k1, but to make it possible to measure, compare, and selectively enable an alternative implementation under controlled conditions.

This post presents the current state of the project, its integration model, and the evidence gathered through continuous audit infrastructure.

Repository: https://github.com/shrec/UltrafastSecp256k1 Release v4.0.0: https://github.com/shrec/UltrafastSecp256k1/releases/tag/v4.0.0

Integration Model
Integration uses a shim layer that exposes the identical secp256k1.h API surface. Bitcoin Core can be built with the alternative backend using a single CMake flag:

cmake -B build -DSECP256K1_BACKEND=ultrafast
cmake --build build
The default backend remains libsecp256k1 unchanged. All existing Bitcoin Core C++ source files remain unmodified — only the CMake build system references a different library.

Fork demonstrating this integration: https://github.com/shrec/bitcoin/tree/feature/ultrafast-secp256k1-backend

Shim API coverage:

secp256k1.h — context, pubkey, seckey
secp256k1_extrakeys.h — keypair, x-only pubkey (BIP-340/341)
secp256k1_schnorrsig.h — Schnorr sign/verify (BIP-340)
secp256k1_ecdh.h — ECDH
secp256k1_recovery.h — ECDSA recovery
secp256k1_ellswift.h — ElligatorSwift (BIP-324)
secp256k1_musig.h — MuSig2 (BIP-327, all 14 functions)
Performance — Bitcoin Core Integration Paths
All numbers from bench_bitcoin (Bitcoin Core's native benchmark harness) on Intel i5-14400F, GCC 14.2.0, Release+LTO, intel_pstate/no_turbo=1, taskset -c 0, nice -20, 5 runs.

Canonical artifact: docs/BITCOIN_CORE_BENCH_RESULTS.json

Transaction signing:

BenchmarkUltralibsecp256k1Delta
SignSchnorrWithMerkleRoot83.9 µs113.4 µs+35% faster
SignSchnorrWithNullMerkleRoot84.0 µs113.0 µs+35% faster
SignTransactionECDSA149.5 µs165.1 µs+10% faster
SignTransactionSchnorr125.4 µs137.5 µs+10% faster
Script verification:

BenchmarkUltralibsecp256k1Delta
VerifyScriptP2TR_KeyPath45.4 µs46.3 µs+2.0% faster
VerifyScriptP2TR_ScriptPath76.5 µs83.8 µs+10% faster
VerifyScriptP2WPKH46.0 µs45.8 µsparity (within noise)
Block validation aggregate (ConnectBlock, 2000 unique signatures):

ScenarioUltralibsecp256k1Delta
All ECDSA254.3 ms257.4 ms+1.2% faster
All Schnorr253.0 ms255.3 ms+0.9% faster
Mixed (2k Schnorr + 1k ECDSA)253.9 ms257.7 ms+1.5% faster
Without LTO: ConnectBlock is ~0.5–1.0% slower than libsecp256k1 due to i-cache pressure from a larger code footprint. LTO is required for Ultra to win the aggregate. This tradeoff is documented in docs/SHIM_KNOWN_DIVERGENCES.md.

Bitcoin Core test suite: 749/749 passing with Ultra backend (GCC 14.2.0, May 2026).

Performance — Constant-Time Signing Primitives
From docs/bench_unified_2026-05-16_gcc14_x86-64.json. CT-vs-CT co-measured in the same run (ratios are TSC-independent):

OperationUltra CTlibsecp256k1Ratio
CT ECDSA sign21.6 µs59.7 µs1.30× faster
CT Schnorr sign (BIP-340)18.1 µs46.5 µs1.28× faster
Schnorr verify84.3 µs84.3 µsequal
Field arithmetic primitives:

PrimitiveUltralibsecp256k1Ratio
field_mul20.1 ns26.5 ns1.32×
field_sqr18.7 ns22.3 ns1.19×
field_inv1253.9 ns1506.0 ns1.20×
field_from_bytes4.8 ns13.0 ns2.71×
Continuous Audit and Assurance (CAAS)
The repository includes a continuous audit infrastructure tracking security regressions across every commit.

Current state at v4.0.0:

262 exploit PoC modules covering 20+ CVE/attack classes — all pass
369 total audit modules (262 exploit PoC + 107 non-exploit)
CAAS autonomy score: 100/100 (8/8 gates)
Source: docs/SECURITY_AUTONOMY_KPI.json

Audit surfaces include: nonce reuse, side-channel timing (dudect), CT boundary verification, batch verify soundness, MuSig2/FROST protocol attacks, adaptor signatures, DER BIP-66 strict parsing, BIP-340/RFC-6979 known-answer tests, Wycheproof vectors, structure-aware fuzzing, differential testing vs libsecp256k1, and Python-based algebraic property testing.

Security properties enforced:

Constant-time signing: ECDSA, Schnorr, MuSig2, FROST, BIP-324 XDH
Per-context DPA blinding (secp256k1_context_randomize fully implemented)
Strict scalar parsing for private key inputs (parse_bytes_strict_nonzero)
Fail-closed batch signing APIs
BIP-66 strict DER enforcement in all shim paths
Benchmarking Methodology
Benchmarks distinguish between:

CT vs CT — constant-time Ultra signing vs constant-time libsecp signing (production-equivalent, fair comparison)
Bitcoin Core integration — bench_bitcoin binary, real validation pipeline
LTO vs no-LTO — both measured and documented
Warm-cache vs cold-cache — noted where applicable
All claimed improvements include error percentage from nanobench's internal statistics. Inconclusive results (overlapping ranges) are reported as such. Results are reproducible from the canonical JSON artifacts in the repository.

Reproducibility
Builds are deterministic:

-ffile-prefix-map strips source paths from debug info
SOURCE_DATE_EPOCH awareness
Fixed -march=x86-64-v3 (no host-native variation)
SLSA provenance attached to v4.0.0 release artifacts (via Sigstore/Cosign)
Platform Coverage
CI passing on all platforms as of v4.0.0:

PlatformArchitectureCompiler
Linuxx86-64-v3GCC 14 / Clang 17
LinuxARM64GCC 14
LinuxRISC-V 64GCC 14
macOSARM64 (Apple Silicon)Clang 15
Windowsx86-64MSVC / GCC
Additional: Android ARM64 (NDK), WASM, ESP32, STM32.

Known Limitations
ConnectBlock improvement requires Release+LTO. Without LTO: ~0.5–1.0% slower than libsecp256k1.
GPU backends (CUDA, OpenCL, Metal) are present but not part of the Bitcoin Core evaluation profile.
This covers the CPU backend only.
Current Objective
No mandatory integration path is proposed. The current objective is to make an alternative backend available for evaluation on technical grounds, with reproducible evidence, minimal integration surface, and an easy rollback path.

The default backend remains libsecp256k1. All existing behavior is preserved unless the new backend is explicitly enabled at build time.

Reviewer Entry Path
git clone https://github.com/shrec/UltrafastSecp256k1
cd UltrafastSecp256k1
python3 ci/verify_external_audit_bundle.py --allow-commit-mismatch
Key documents:

docs/BITCOIN_CORE_BACKEND_EVIDENCE.md — full reviewer package
docs/BENCHMARKS.md — benchmark methodology and raw data
docs/AUDIT_CHANGELOG.md — security audit history
docs/SHIM_KNOWN_DIVERGENCES.md — documented behavioral differences from libsecp256k1
All performance numbers are from controlled benchmark runs with hard turbo lock. Raw data available in the repository. Canonical benchmark artifact: docs/BITCOIN_CORE_BENCH_RESULTS.json, docs/bench_unified_2026-05-16_gcc14_x86-64.json.

Tuesday Coding Tip 10— CTest

Tue, 05 May 2026 09:59:00 +0000

CMake can do many things and instrumenting your test suite is one of them. Use add_test to tell cmake it should run a particular command with given parameters. If it returns zero, it succeeded. You can use it to simply run a testrunner binary or to make a matrix of input parameters that are expected to not crash the program.

cmake_minimum_required ( VERSION 3.26 )

project ( testrunner )
add_executable ( ${PROJECT_NAME} Main.cpp )

enable_testing()
add_test(
   NAME "Example with no params"
   COMMAND ${PROJECT_NAME}
)

add_test(
   NAME "Example with help param"
   COMMAND ${PROJECT_NAME} -h
)

In order to add_test do anything, one has to also call enable_testing(). Running the tests is just a matter of running ctest from command line. Just note that ctest requires you to specify a build configuration if you have more than one.

Tuesday Coding Tip 09 — Source location

Tue, 28 Apr 2026 09:59:00 +0000

If you want to log a filename and line number prior to C++20, you need to use the likes of __FILE__ and __LINE__ macros. To use those easily, you have to create a wrapper macro for logging, which usually leads to an ugly macro bonanza.

#include <iostream>
#include <format>

void log(
    const std::string& message,
    const std::string& fileName = __FILE__,
    unsigned lineNo = __LINE__)
{
    std::cout << std::format(
        "{}({}): {}\n",
        fileName,
        lineNo,
        message);
}

#define LOG(msg) log(msg, __FILE__, __LINE__)

int main()
{
    log("hello world");
    // logs: example.cpp(7): hello world
    // Note that __FILE__ and __LINE__ are expanded at their
    // position, not at the callsite
    LOG("hello world2");
    // logs: example.cpp(22): hello world2
    // Wrapping the call in another macro with explicit placement
    // of __FILE__ and __LINE__ makes them expand at the correct place
}

C++20 introduces std::source_location, a regular object that can be constructed as a default value of a logging function parameter and passed along as the user needs.

#include <iostream>
#include <source_location>
#include <format>

void log(
    const std::string& message,
    std::source_location location = std::source_location::current())
{
    std::cout << std::format(
        "{}({}) {}: {}\n",
        location.file_name(),
        location.line(),
        location.function_name(),
        message);
}

int main()
{
    log("hello world");
    // logs: example.cpp(19) int main(): hello world
}

Tuesday Coding Tip 08 — Explicit template specialization

Tue, 21 Apr 2026 09:59:00 +0000

While template instantiation can be used to move your template implementation from header files to object files for a given subset of types, specialization allows you to override the default template implementation for a particular type.

Specialization requires that you first define the template implementation and then you can implement any number of specializations for given types. This way, you can override free functions (while maintaining their overall signature) or you can override whole classes (and you don’t have to respect their interfaces). This way, you can create drop-in replacements for library containers specialized for particular types and try to optimize them for your use case.

#include <filesystem>
#include <iostream>
#include <string>

template<class T>
T concat(T a, const T& b)
{
    return a + b;
}

namespace fs = std::filesystem;

fs::path concat(fs::path a, const fs::path& b)
{
    return a / b;
}

int main()
{
    using namespace std::string_literals;
    std::cout << concat("aaa"s, "bbb"s) << std::endl;        // outputs: aaabbb
    std::cout << concat("aaa", "bbb").string() << std::endl; // outputs: aaa\bbb
    return 0;
}

The specialization can also be partial and it can be inline/const whatever even if the original template is not.

#include <iostream>
#include <string>

template<class T>
struct CustomType
{
    T foo() { return T {}; }
};

template<>
struct CustomType<std::string>
{
    std::string bar() { return "hello world"; }
};

int main()
{
    CustomType<int> ct1;
    std::cout << ct1.foo() << std::endl; // outputs: 0
    CustomType<std::string> ct2;
    std::cout << ct2.bar() << std::endl; // outputs: "hello world"
}

Last but not least, if you’re implementing a template and need to change only a few lines of implementation for one particular type, you don’t need specialization. Instead, use constexpr conditions — they are evaluated in compile time and optimized away when the compiler emits its own specialized code.

#include <concepts>
#include <filesystem>
#include <iostream>
#include <string>

template<class T>
T concat(T a, const T& b)
{
    if constexpr (std::is_same_v<T, std::filesystem::path>)
        return a / b;
    else
        return a + b;
}

int main()
{
    using namespace std::string_literals;
    using path = std::filesystem::path;
    std::cout << concat("aaa"s, "bbb"s) << std::endl; // outputs: aaabbb
    std::cout << concat(path{ "aaa" }, path{ "bbb" }).string()
              << std::endl; // outputs: aaa\bbb
    return 0;
}

Tuesday Coding Tip 06 - Explicit template instantiation

Tue, 07 Apr 2026 09:59:00 +0000

Templated code in C++ must be defined in the header files (or a function within the same .cpp file). This is because whenever a templated function is called, the compiler generates a new implementation using the concrete type the function was called with. If you split the definition from the declaration, you need to tell it what implementations to generate and link.

That’s what explicit template instantiation is for. It is useful when you’re writing generic code for a well-known subset of types, like string manipulation. It cannot be used for totally generic types because you need to be able to list all types the template will be used with (otherwise the user will get a linker error).

// .hpp
#pragma once

#include <string>
#include <concepts>

// Note me using constructible_from instead of is_same_v. This will
// get me into trouble
template<class T>
concept NarrowOrWideString = std::constructible_from<std::string, T>
|| std::constructible_from<std::wstring, T>;

template<NarrowOrWideString StringType>
StringType StrTransformation(StringType source);

template<NarrowOrWideString StringType>
class ClassTemplate
{
public:
    static StringType StrTransformation(StringType source);
};

// .cpp
template<NarrowOrWideString StringType>
StringType StrTransformation<StringType>(StringType source)
{
   /* some transformation */
   return source;
}

template std::string StrTransformation<std::string>(std::string);
template std::wstring StrTransformation<std::wstring>(std::wstring);


template<NarrowOrWideString StringType>
StringType ClassTemplate<StringType>::StrTransformation(StringType source)
{
   /* some transformation */
   return source;
}

template class ClassTemplate<std::string>;
template class ClassTemplate<std::wstring>;

// main.cpp
int main()
{
   {
      // This links, note the explicitly created string in parameters
      auto str = StrTransformation(std::string("aaa"));
    
      auto wstr = StrTransformation(std::wstring(L"bbb"));
    
      // ERROR: Type does not conform to concept
      // auto num = StrTransformation(10);
    
      // ERROR: Type does conform to concept,
      // but template was not instantiated for const char[4]
      // auto str2 = StrTransformation("aaa");
    
      // This works, template overload was explicitly specified
      // and the concept allows conversion of const char* to std::string
      // Note that if I used is_same_v instead of constructible_from,
      // I couldn't use const char* as an argument.
      auto str3 = StrTransformation<std::string>("aaa");
    
      // Or I can make an alias
      constexpr auto&& StrTransformationA = StrTransformation<std::string>;
      auto str4 = StrTransformationA("aaa");
   }
  
   {
      // ERROR: C++ template type deduction is not good enough
      // auto str1 = ClassTemplate::StrTransformation(std::string("aaa"));
    
      // I need to be explicit
      auto str2 = ClassTemplate<std::string>::StrTransformation("aaa");
    
      // Or make an alias
      using ClassTemplateA = ClassTemplate<std::string>;
      auto str3 = ClassTemplateA::StrTransformation("aaa");
   }
}

Tuesday Coding Tip 05 - Object initialization in C++

Tue, 31 Mar 2026 09:26:00 +0000

There is a five-hundred-page book about C++ initialization out there. Why? Because we cater to way too many styles and many constructor capabilities. This tip is not about explaining all the options but rather about some good practices you can use to minimize mistakes.

The “classic” or pre-C++11 way of initializing objects has the pitfall of triggering the “most vexing parse”. In such case, the compiler cannot tell whether you are calling a constructor or making a function declaration. And because C allowed for function declaration inside functions, it will pick the function declaration. You can omit the braces for the default constructor, but you can still encounter problems as shown in the ‘mvp2’ case. Trunk versions of GCC and Clang emit a helpful warning in this case.

// Classic C++ style
Object obj1(param1, param2); // This works
Object mvp1(); // Most Vexing Parse
Object mvp2(int(param1), int(param2)); // Also MVP

The “modern”, “universal” or post-C++11 way is also not the best one. It is consistent with struct initialization but can invoke incorrect constructors if you intermix normal parameters and std::initializer_list as demonstrated with the std::vector.

// Modern (uniform) C++ style
Object obj2{param1, param2};
Object obj2_2 = {param1, param2};
std::vector<int> vec(10); // vector containing ten default constructed items
std::vector<int> vec{10}; // vector containing one element with value 10

Then you have what I call a “Java” style. It’s verbose and has the same issues if you use curly braces. At least it doesn’t trigger MVP. The last version is what I often use due to its similarity to many other languages where you use var or let to denote the variables and usually specify the type name after the variable name.

// Verbose Java style
Object obj3 = Object(param1, param2);
Object obj3_2 = Object{param1, param2};

// Modern language style
auto obj4 = Object(param1, param2);
auto obj4_2 = Object{param1, param2};

Note that even though there is an assignment operator, no assignment, copy or move is happening — objects are constructed directly.

I recommend using the “modern language style” with simple braces only for regular constructors and curly braces only for initializer-list constructors. It makes your intent clear and prevents you from accidentally shooting yourself in the foot. “Java style” might be preferable for class attribute declarations, with the same rules regarding braces.

Tuesday Coding Tip 04 - Precompiled headers

Tue, 24 Mar 2026 10:59:00 +0000

Do you use CMake and need to improve your C++ compile times? There’s a technique called precompiled headers. Usually, it is somewhat obtuse to set up, MSVC tends to force you to include the precompiled header in every single .cpp file.

With CMake, you can use a single command to instantly boost your compile times with zero invasiveness. On my hobby project, I reduced compile time down from 3m30s to just 30s (in single threaded CI, I went from 7m to 3m30s).

# PROJECT_NAME refers to target that was used with
# add_library or add_executable command
target_precompile_headers ( ${PROJECT_NAME}
    PRIVATE
        <vector>
        <format>
        <map>
        <unordered_map>
        <array>
        <optional>
        <expected>
        <fstream>
        <filesystem>
        <functional>
        <concepts>
        <memory>
        <string>
        <cstdint>
        <DGM/dgm.hpp>
        <TGUI/tgui.hpp>
        <json.hpp>
)

Just remember to only include headers that don’t change often, presumably never. Good candidates are std headers and third party header-only dependencies.

Error does not name a type C++

Mon, 23 Mar 2026 09:40:17 +0000

Error does not name a type in C++

The "error does not name a type" in C/C++ is defined as the when user declares outside of the function or does not include it properly in the main file this error will through.

Why this error occurs?
How to resolve:
Conclusion

Why this error occurs?

File: sample.h  
 #ifndef SAMPLE_H__<br />#define SAMPLE_H__
   namespace Sampletest {
    class CP_M_ReferenceCounted<br />{<br />};
    }
    #endif
    <br />File : test.cpp
#include "sample.h"
    typedef CP_M_ReferenceCounted FxRC;
   <br />int main(int argc, char **argv)<br />{
    <p>return 0;<br />}

If you run the above code you will get the error "...error: CP_M_ReferenceCounted does not name a type"

How to resolve :

To overcome this error follow this two methods of solutions

Solution 1:

To avoid this error, we have to add the "using namespace Sampletest" at the start of the program in C++.

<p>File : test.cpp</p>
<p><code>#include "sample.h"</p>
<p>//Add the following to your code</p>
<p>using namespace Sampletest</p>
<p>typedef CP_M_ReferenceCounted FxRC;</p>
<p><br />int main(int argc, char **argv)<br />{</p>
<p>return 0;<br />}</code></p>

Solution 2:

To avoid this kind of error we need to add the header "#include sample.h" at the starting of the program in C++.

Same Problem while declaring outside of the function

These kinds of errors are also acquired while printing outside of any function.
A statement which isn't declaration in C++ need to be printed inside of the function

File test.cpp

<p>#include <iostream><br />#include <cstring><br />using namespace std;</p>
<p>struct Node{<br />char *name;<br />int age;<br />Node(char *nc = "", int ax = 0){<br />name = new char[strlen(nc) + 1];<br />strcpy(name, n);<br />age = ax;<br />}<br />};</p>
<p>Node node1("Roger", 20), node2(node1);<br />cout << node1.name << ' ' << node1.age << ' ' << node2.name << ' ' << node2.age;<br />strcpy(node2.name, "Wendy");<br />node2.name = 30;<br />cout << node1.name << ' ' << node1.age << ' ' << node2.name << ' ' << node2.age;</p>
<p> </p>
<p><b>Output :</b></p>
<p>error: ‘node2’ does not name a type</p>
<br/>

Solution 3:

To avoid these types of errors you need to add everything inside the function,
because a statement that isn't a declaration in C++ needs to be inside the function

<p><code>int main() {<br />Node node1("Roger", 20), node2(node1);<br />cout << node1.name << ' ' << node1.age << ' ' << node2.name << ' ' << node2.age;<br />strcpy(node2.name, "Wendy");<br />node2.name = 30;<br />cout << node1.name << ' ' << node1.age << ' ' << node2.name << ' ' << node2.age;<br />}</code></p>

Conclusion:

In this article, we have seen why the undefined error occurs in C/C++ and discussed how to resolve these errors in various methods.

Tuesday Coding Tip 03 - Structured bindings

Tue, 17 Mar 2026 10:59:00 +0000

Since C++17, we can use “structured bindings”. These allow you to perform tuple, array, or even structure unpacking. Such unpacking is commonly helpful when iterating over maps, so you don’t have to define an alias for key and value manually. It is equally useful when a function returns a tuple.

// Iterating over key-value pairs
auto myMap = std::unordered_map<std::string, int>{ /* ... */ };
for (auto&& [key, value] : myMap)
{ /* ... */ }

// Tuple unpacking
auto&& [index, quantity, name] = std::tuple{10, 30, "a"};

// Struct member aliasing
struct S {
    int veryLongAndDescriptiveName;
    std::string anotherVeryWordyName;
};

auto&& [index2, name2] = S{}; // s is of type S

// Array unpacking
auto&& [first, second, third] = std::array{1, 2, 3};

Unpacking struct members and arrays is just a cherry on top. You won’t use it much, but it is there should you ever need it!

Tuesday Coding Tip 02 - Template with type-specific API

Tue, 10 Mar 2026 11:00:00 +0000

What if you had a template class and you wanted to give it extra methods for certain specializations?

For example, you might want to make a templated initialization guard and you want it to be as non-intrusive as possible. So you want it to support arithmetic operations if the underlying type is an arithmetic type.

Before C++20, you could leverage std::enable_if. However, such code is clunky and unreadable:

#include <type_traits>
#include <string>

// Pre C++20
template<class T>
class TemplatedClass
{
public:
  template<class = typename std::enable_if<std::is_integral<T>::value>::type>
  void foo() {}
};

int main()
{
  TemplatedClass<int> a;
  a.foo(); // OK

  TemplatedClass<std::string> b;
  b.foo(); /* Error:
  error: failed requirement 'std::is_integral<std::basic_string...>' requested here
  error: no matching member function for call to 'foo'
  note: candidate template ignored: couldn't infer template argument ''
  */
}

With C++20, you can use concepts and the requires keyword to clean up the syntax significantly, either by in-place definition of type properties or by defining a dedicated concept. It also improves readability of error messages.

#include <type_traits>
#include <string>

// C++20, requires
template<class T>
class TemplatedClass2
{
public:
  template<typename = void>
  requires std::is_integral_v<T>
  void foo() {}
};

// C++20 with concept
template<class T>
concept IsIntegral = std::is_integral_v<T>;

template<class T>
class TemplatedClass3
{
public:
  template<typename = void>
  requires IsIntegral<T>
  void foo() {}
};

int main() {
  TemplatedClass2<int> a;
  a.foo(); // Ok

  TemplatedClass3<std::string> b;
  b.foo(); /* Error:
  error: no matching member function for call to 'foo'
  note: candidate template ignored: constraints not satisfied [with $0 = void]
  note: because 'std::basic_string<char>' does not satisfy 'IsIntegral'
  note: because 'std::is_integral_v<std::basic_string<char> >' evaluated to false
  */
}

Tuesday Coding Tip 01 - C++ Concepts

Tue, 03 Mar 2026 11:00:00 +0000

Concepts are a C++20 feature that greatly simplifies templated code and allows you to build powerful type trait restrictions.

#include <concepts>

class Interface {
public:
    ~Interface() = default;
};

template<class T>
concept DerivedFromInterface = std::derived_from<T, Interface>;

// Note how 'class' or 'typename' is replaced with 'DerivedFromInterface'
template<DerivedFromInterface ObjectType>
void DoSomethingWith(ObjectType& object) {}

// Usage
class A final : public Interface {};
A a;
DoSomethingWith(a);

For example, you can create a function that accepts a concrete type that implements a certain interface, potentially allowing the compiler to optimize away the virtual table. Or you can define static interfaces where an object is required to have certain methods or even attributes, even if it doesn’t implement any inheritance-based interface. Or you can restrict the function to be called only with a small subset of well-known types.

#include <concepts>
#include <string>

template<class T>
concept Serializable = requires(T&& object)
{
    // Object has callable method 'serialize' which
    // returns something that works same as std::string
    { object.serialize()} -> std::same_as<std::string>;
};

template<Serializable T>
void UploadSerializable(const T& object)
{
    auto data = object.serialize();
    // ...
}

// Usage
class Settings {
public:
    std::string serialize() const { return ""; }
};

Settings settings;
UploadSerializable(settings);

Concepts do not replace dynamic polymorphism as you cannot do everything in compile-time. Still, it can open new optimization opportunities and help you write in-place construction functions like std::make_unique without an excessive amount of unreadable templates.

#include <concepts>
#include <string>
#include <memory>

// A function that accepts any string, disregarding if wide or narrow
template<typename T>
requires std::is_same_v<T, std::string> || std::is_same_v<T, std::wstring>
void DoSomethingWithAString(const T& str) {}

// A better implementation of make_unique which checks whether the
// object can be created from given arguments
template<class T, class ... Args>
requires std::constructible_from<T, Args...>
std::unique_ptr<T> make_unique(Args&& ... args)
{
    return std::unique_ptr<T>(new T(std::forward<Args>(args)...));
}

Lastly, among the benefits to the syntax, they improve the compiler error messages, making life of your users way simpler.

std::visit is awesome, here’s why

Tue, 17 Feb 2026 22:55:13 +0000

One of the very few features of the C++ standard library that I unapologetically like, is the std::visit. It reduces the amount of boilerplate code, kills multiple birds with a single stone, and doesn’t sacrifice performance while doing it. So let’s have a look at how to use it.

Visitor pattern

The Visitor pattern is a more complex OOP design pattern, but once you understand it, it becomes a great tool for breaking up dependencies and removing obtuse conditional statements with RTTI.

It allows you to separate data structures from algorithms operating on those data structures, making it easier to add new algorithms or alter the structures without having to redeploy the other half.

It is popular in compilers, where your source code is represented by an abstract syntax tree (AST), and every single optimization or analysis, like constant propagation, expression folding, or precondition analysis is implemented as its own class (so-called Visitor), separately from the AST declaration.

If you’d like to know how to implement Visitor from the ground up, look no further than superb refactoring.guru website.

Without inheritance

Unlike the standard object-oriented implementation of the Visitor pattern, std::visit doesn’t require you to use inheritance. Due to the underlying use of std::variant and dark standard library magic, std::visit doesn’t use double dispatch and thus you don’t need any accept method on your data structures:

#include <iostream>
#include <variant>
#include <vector>

struct NodeA {};
struct NodeB {};
struct NodeC {};

using Nodes = std::variant<NodeA, NodeB, NodeC>;

struct Visitor {
    void operator() (const NodeA&) { std::cout << "NodeA" << std::endl; }
    void operator() (const NodeB&) { std::cout << "NodeB" << std::endl; }
    void operator() (const NodeC&) { std::cout << "NodeC" << std::endl; }
};

int main() {
    std::vector<Nodes> nodes = {
        NodeA{},
        NodeB{},
        NodeA{},
        NodeC{}
    };

    for (auto&& node : nodes) std::visit(Visitor{}, node);

    // Prints:
    // NodeA
    // NodeB
    // NodeA
    // NodeC
}

As you can see, all you need is a callable struct with overloads for required types. Note that you need to overload on all types that belong to Nodes or you’ll get a compiler error (like with pattern matching in other languages).

The error itself is a classic std nonsense, so look out for this message:

no type named 'type' in 'std::invoke_result<Visitor, TypeThatIsMissing&>'

With inheritance

However, std::visit allows using inheritance. That is even darker magic because you can, but don’t have to, add overloads for only some of the inherited types. The algorithm needs to be able to match the type on at least one overload, and the base class also applies:

#include <iostream>
#include <variant>
#include <vector>

struct NodeBase {};
struct NodeA : public NodeBase{};
struct NodeB : public NodeBase{};

using Nodes = std::variant<NodeA, NodeB>;

struct Visitor {
    void operator() (const NodeA&) { std::cout << "NodeA" << std::endl; }
    void operator() (const NodeBase&) { std::cout << "NodeBase" << std::endl; }
};

int main()
{
    std::vector<Nodes> nodes = {
        NodeA{},
        NodeB{},
    };

    for (auto&& node : nodes) std::visit(Visitor{}, node);

    // Prints:
    // NodeA
    // NodeBase
}

The order of overloads doesn’t matter here. Specialization is preferred over the base class.

Faster than manual dispatch

While std::visit surely has a nice interface (a rare sight in the standard library) and it requires less boilerplate than implementing double dispatch manually, how’s the performance? I do have an unexpected answer - it is faster or at least as fast as the other solutions!

I highly recommend watching Klaus Ingleberger’s talk about the Visitor pattern implementations where he also shows comparison times on GCC and Clang (timestamped to the part with the performance comparison). My own benchmarks on MSVC way back showed a clear win for std::visit over other methods.

Functional programming

C++ committee often comments on how they like their proposals to kill multiple birds with one stone and in the notion of that mindset, you can use std::visit functionally as well.

#include <iostream>
#include <variant>
#include <vector>

struct NodeA {};
struct NodeB {};

using Nodes = std::variant<NodeA, NodeB>;

template<class... Ts>
struct overloaded : Ts... { using Ts::operator()...; };

// Some compilers might require this explicit deduction guide
template<class... Ts>
overloaded(Ts...) -> overloaded<Ts...>;

int main()
{
    std::vector<Nodes> nodes = {
        NodeA{},
        NodeB{},
    };

    for (auto&& node : nodes) {
        std::visit(overloaded{
            [] (const NodeA&) { std::cout << "NodeA" << std::endl; },
            [] (const NodeB&) { std::cout << "NodeB" << std::endl; }
        }, node);
    }

    // Prints:
    // NodeA
    // NodeB
}

Instead of creating one dedicated visitor struct, you can use a helper template class to create an object out of a set of lambdas. This way, you can define your visiting code in the same place as you call it. Some people use this trick to emulate match statements from other languages, others might like it simply because it is functional programming.

Disadvantages

As noted by Klaus in his talk, every approach has its advantages and disadvantages. Because this approach is driven by the std::variant, you must keep in mind its shortcomings:

Types need to be fully defined before they can be used in the variant. This is because their storage size needs to be known.
Using types with vastly different sizes means that your variant will inherently waste a lot of space.
Adding a new type might mean updating all existing visitors (not if you use inheritance) and updating the variant (which you don’t have to do with the classic OO approach).

Do note that you can address the first two problems by using wrapper types like smart pointers or employing the Pimpl pattern.

Summary

As I said in the beginning, I like std::visit very much. Implementing the Visitor pattern takes some getting used to and with this feature, you greatly reduce the amount of boilerplate, improve the readability of the code, and don’t sacrifice performance.

Functional invocation is just a cherry on top for very localized usage where brand new class would just add noise to the code base.

Unlocking Performance: How C++ Optimization Techniques in Compilers Outperform Python

Mon, 07 Jul 2025 02:08:59 +0000

C++ and Python are two popular programming languages that have distinct performance characteristics. C++ is a statically-typed, compiled language that is known for its efficiency and speed, while Python is a dynamically-typed, interpreted language that prioritizes ease of use and flexibility. One of the key factors that contribute to C++'s performance advantage is the optimization techniques employed by its compilers.

C++ compilers, such as GCC and Clang, use a range of optimization techniques to generate efficient machine code. These techniques can be broadly categorized into several areas, including:

Instruction Selection and Scheduling: C++ compilers can select the most efficient instructions for a given operation and schedule them to minimize dependencies and maximize parallelism. This can lead to significant performance improvements, particularly in compute-intensive applications.
Register Allocation: C++ compilers can optimize the use of CPU registers to minimize memory accesses, which can significantly impact performance. By allocating registers efficiently, compilers can reduce the number of memory loads and stores, leading to faster execution times.
Dead Code Elimination: C++ compilers can eliminate code that is never executed, which can reduce the overall size of the program and improve performance. By removing unnecessary code, compilers can also reduce the number of cache misses and improve instruction-level parallelism.
Constant Folding and Propagation: C++ compilers can evaluate constant expressions at compile-time and propagate the results, eliminating unnecessary runtime calculations. This can lead to significant performance improvements, particularly in applications that involve complex mathematical calculations.
Loop Optimization: C++ compilers can optimize loops by techniques such as loop unrolling, loop fusion, and loop tiling. These optimizations can improve performance by reducing the overhead of loop control statements, improving cache locality, and increasing parallelism.

These optimization techniques can significantly contribute to C++'s performance advantage over Python. Python, being an interpreted language, does not have the same level of optimization opportunities as C++. While Python's interpreter can perform some optimizations, such as caching frequently executed code, it is generally limited by the dynamic nature of the language.

One of the primary reasons why C++'s optimization techniques are more effective is that they are applied at compile-time, when the compiler has a complete view of the code and its dependencies. This allows the compiler to make informed decisions about optimization, such as which instructions to use, how to allocate registers, and how to schedule code.

In contrast, Python's interpreter must make optimization decisions at runtime, based on the current state of the program. This can lead to less effective optimizations, as the interpreter may not have a complete view of the code and its dependencies.

To illustrate the performance difference between C++ and Python, consider a simple example. Suppose we want to implement a program that performs a complex mathematical calculation, such as matrix multiplication.

Example Code:

C++:

#include <iostream>

void matrixMultiply(int** A, int** B, int** C, int n) {
    for (int i = 0; i < n; i++) {
        for (int j = 0; j < n; j++) {
            C[i][j] = 0;
            for (int k = 0; k < n; k++) {
                C[i][j] += A[i][k] * B[k][j];
            }
        }
    }
}

int main() {
    int n = 1000;
    int** A = new int*[n];
    int** B = new int*[n];
    int** C = new int*[n];

    for (int i = 0; i < n; i++) {
        A[i] = new int[n];
        B[i] = new int[n];
        C[i] = new int[n];
    }

    // Initialize matrices A and B

    matrixMultiply(A, B, C, n);

    return 0;
}

Python:

import numpy as np

def matrix_multiply(A, B):
    return np.matmul(A, B)

A = np.random.rand(1000, 1000)
B = np.random.rand(1000, 1000)

C = matrix_multiply(A, B)

In this example, the C++ code uses manual memory management and loop optimizations to perform matrix multiplication, while the Python code uses the NumPy library to perform the same operation. While the Python code is easier to write and maintain, the C++ code is likely to be faster due to its manual memory management and loop optimizations.

Conclusion:

In conclusion, C++'s optimization techniques in compilers contribute significantly to its performance advantage over Python. By applying optimizations at compile-time, C++ compilers can generate efficient machine code that is tailored to the specific use case. While Python's interpreter can perform some optimizations, it is generally limited by the dynamic nature of the language.

Why C++ Compilers Prefer Performance Over Safety Checks?

Fri, 20 Jun 2025 09:24:12 +0000

C++ is a language synonymous with performance, control, and portability. For decades, it has powered the world's most demanding software systems, from operating systems to game engines and real-time trading platforms. At the heart of its power lies a controversial feature: undefined behavior (UB). This feature, or rather lack of behavior definition, has led to immense performance gains but also to programming pitfalls. When modern C++ compilers like GCC and Clang prioritize performance, they do so by aggressively assuming that undefined behavior never occurs. In this article, we will explore why these compilers make such design choices, the benefits and trade-offs involved, and how developers can harness these tools responsibly.

1. The C++ Design Philosophy: Trust the Programmer

One of the key tenets of C++ is that it "trusts the programmer." This trust is not blind; it is intentional and foundational. Unlike languages like Java or Python that emphasize safety and abstraction, C++ offers low-level memory and hardware access. It does so while striving for zero-overhead abstractions. The premise is that a knowledgeable programmer can write highly efficient code if the compiler doesn't impose runtime safety checks that might slow execution.

Control and Efficiency

C++ gives developers precise control over resource management. You decide how memory is allocated, how objects are constructed, and when resources are released. This fine-grained control enables performance tuning at a level unmatched by most high-level languages.

No Built-in Safety Net

By default, C++ does not include bounds checking, null pointer validation, or automatic garbage collection. This lack of safety net is a double-edged sword. On one side lies blazing speed and fine control. On the other, the danger of undefined behavior.

2. What is Undefined Behavior?

In the context of C++, undefined behavior refers to code that does not have a well-defined effect according to the C++ standard. When such code is executed, anything can happen. It may crash the program, produce unexpected results, or appear to work fine (only to break later).

Common Sources of UB

Dereferencing null or dangling pointers
Accessing array elements out of bounds
Using uninitialized variables
Violating strict aliasing rules
Shifting integers by more than their width
Modifying a variable more than once between sequence points
Invoking functions through function pointers with the wrong signature

These are not bugs that merely produce wrong results; they allow the compiler to assume they never happen.

3. Why Compilers Exploit Undefined Behavior

Both GCC and Clang are highly optimizing compilers. They use undefined behavior as a license to transform code under the assumption that such errors never occur. This leads to several advantages:

a. Dead Code Elimination

Consider the following:

if (ptr != nullptr) {
   *ptr = 10;
}

If the compiler determines that ptr is never null (or that dereferencing null is UB), it might remove the check entirely, resulting in more streamlined code.

b. Loop Optimizations

UB assumptions allow the compiler to:

Unroll loops
Perform strength reduction
Vectorize operations for SIMD instructions
Parallelize independent iterations

c. Constant Folding and Propagation

If a branch or operation leads to UB under certain conditions, compilers may discard it entirely or simplify control flow under the assumption that such branches are never taken.

d. Register Allocation Improvements

Assuming UB allows for more flexible reuse of registers, reducing memory access and increasing pipeline throughput.

4. Benefits of This Approach

4.1 Performance

By ignoring checks and relying on the programmer's correctness, the compiler produces leaner, faster machine code. In performance-critical domains (e.g., embedded systems, high-frequency trading), even a 1-2% gain can be significant.

4.2 Simpler Compiler Internals

When the compiler is allowed to assume certain operations never happen (like null pointer access), it simplifies the internal logic for code generation and optimization passes.

4.3 Portability

This model ensures the same code can run efficiently across different platforms without runtime dependencies like garbage collectors or VM-based safety checks.

4.4 Greater Flexibility for Developers

Developers who understand their system well can fine-tune performance and optimize memory usage, trading safety for precision when necessary.

5. The Cost: Dangerous Flexibility

5.1 Debugging Nightmares

Because UB can manifest unpredictably, bugs are often hard to detect. Code that works on one compiler version may break on another. Debuggers might show misleading or inconsistent information when UB is triggered.

5.2 Security Vulnerabilities

Many buffer overflows and privilege escalation exploits originate from UB that goes unchecked during development. Attackers exploit these flaws to insert malicious code, steal data, or crash systems.

5.3 Non-deterministic Behavior

A program might behave differently on each run or platform due to optimizations exploiting UB. This leads to issues in testing, especially in distributed or multithreaded applications.

5.4 Loss of Portability

Code relying unknowingly on UB may work on one architecture but fail on another. For example, pointer alignment or endianness assumptions may cause subtle and hard-to-detect issues.

6. Mitigation Strategies for Developers

6.1 Use Static Analysis Tools

Tools like Clang-Tidy, Cppcheck, and Coverity help detect UB patterns in source code before runtime. They analyze control flow, memory access patterns, and data usage.

6.2 Enable Compiler Sanitizers

Compiler sanitizers are invaluable for catching UB during testing:

-fsanitize=undefined: Catches most UB issues like invalid casts or pointer arithmetic
-fsanitize=address: Detects heap buffer overflows, use-after-free
-fsanitize=thread: Catches race conditions in multithreaded programs
-fsanitize=leak: Helps track memory leaks

6.3 Adopt Safe Subsets

Frameworks like MISRA-C++ or AUTOSAR C++ define subsets of the language that eliminate or constrain UB-prone features. These are essential in safety-critical industries like automotive and aerospace.

6.4 Use Modern C++ Features

Prefer smart pointers (std::unique_ptr, std::shared_ptr), std::optional, std::variant, std::array over raw pointers and C-style arrays. These features enforce safer access and clearer intent.

6.5 Enforce Code Reviews and Testing

Robust peer reviews and extensive unit/integration testing help catch unintended UB before code reaches production.

6.6 Leverage Formal Verification (Advanced)

For critical systems, formal methods can be used to prove the absence of UB under all conditions using mathematical techniques.

7. Why Not Just Eliminate UB?

Eliminating undefined behavior would fundamentally change what C++ is:

More runtime checks would degrade performance.
It would become more like Java or Rust.
Backward compatibility with decades of C/C++ code would break.

UB is a deliberate, though controversial, part of the design. It is the price for raw power and flexibility.

Languages like Rust take a different path: they eliminate most classes of UB at compile time through strict ownership and borrowing rules. But this comes at the cost of a steeper learning curve and more restrictive coding patterns.

C++ allows expert programmers to write fast code with minimal abstraction costs, but the responsibility lies with the programmer to avoid UB through discipline and tooling.

8. Real-World Use Cases Embracing UB for Speed

8.1 Operating Systems

Linux kernel code is filled with performance-critical sections that rely on UB being carefully avoided but never checked. Kernel developers rely on strict coding guidelines and peer review to manage UB risk.

8.2 Game Engines

Engines like Unreal Engine are written in C++ with heavy use of UB-ignoring constructs for maximum speed. Real-time rendering and physics engines must meet frame deadlines every few milliseconds.

8.3 Trading Systems

Low-latency trading platforms depend on compiler-optimized binaries where every nanosecond counts. Programmers in this domain carefully avoid UB through disciplined coding and extensive testing.

8.4 Embedded Systems

In microcontrollers and IoT firmware, memory and processing power are limited. Developers must write tight, efficient code and often disable runtime checks, accepting the trade-offs of UB.

8.5 Scientific Simulations

High-performance computing (HPC) relies on C++ to run simulations on massive datasets. UB assumptions allow compilers to fully exploit hardware capabilities.

9. Compiler Flags That Matter

GCC and Clang both offer many flags to control optimization and UB behavior:

-O2, -O3: Enable aggressive optimizations
-fstrict-aliasing: Assumes pointers don’t alias unless explicitly cast
-fno-strict-overflow: Prevents assuming signed integer overflow is UB
-fsanitize=: Enables various runtime checks
-Wall -Wextra: Turns on helpful warnings
-pedantic: Enforces strict standard compliance

Recommended Combinations

For development:

g++ -O0 -g -fsanitize=undefined,address -Wall -Wextra

For production:

g++ -O3 -fstrict-aliasing -fomit-frame-pointer

10. Conclusion: Master the Power, Respect the Danger

C++ gives you a powerful toolset, but with it comes responsibility. GCC and Clang prioritize performance because that’s what the language promises: speed without overhead. Undefined behavior is not a mistake in the spec; it's a contract with the programmer. The compiler trusts you not to invoke UB, and in return, it gives you unmatched performance.

To use C++ effectively:

Understand the risks of undefined behavior
Use the right tools to catch it early
Write clean, testable, standards-compliant code

In the world of systems programming, performance often trumps safety—but with the right knowledge and practices, you don’t have to choose between them.

Final Thoughts

While undefined behavior may seem like a flaw, it is in fact a feature that empowers developers to write some of the fastest code in the world. If used with care, and backed by tooling and discipline, it allows C++ to remain at the forefront of high-performance software engineering.