Forem: Unicorn Developer

C++ digest: News, helpful resources, & your own programming language as bonus

Unicorn Developer — Tue, 26 May 2026 12:44:29 +0000

While the industry debates memory safety, the ISO committee and developers continue shaping the future of a much-loved language, we've gathered the most exciting recent events from the C++ world, along with some useful resources.

The road to C++26: contracts and reflection

The ISO Committee has finished the technical work on C++26. During a series of meetings, the committee refined the upcoming standard's feature set, exceeding many expectations. Key additions include:

compile-time reflection, which enables a program to describe its own structure and generate code at compile time;
std::execution, a universal framework for asynchronous execution, concurrency, and parallelism;
the pre, post, and contract_assert contracts, which enable developers to define preconditions, postconditions, and assertions directly in function declarations;
new parallel algorithms, #embed for binary data, better metaprogramming capabilities, and many other important updates.

Both GCC and Clang compilers have already implemented most C++26 features during the standardization process, and they'll soon appear in other compilers as well.

Security profiles

Efforts to improve security in the upcoming C++29 continue. Bjarne Stroustrup is actively promoting the concept of C++ Profiles. They're sets of additional rules that developers can apply in their code to ensure security.

Profiles help prevent common issues, such as null pointer dereferences or buffer overflows. They also provide a unified foundation for improving safety without sacrificing the core strengths of C++.

The LLVM 22 update

This spring brought a new release of LLVM 22.1. This update brings a wide range of changes: supporting different architectures and adding advanced memory management tools. Key highlights include:

support for new processors (Intel Nova Lake, Wildcat Lake, RISC-V, and other architectures);
support for new C++26 features;
advanced memory control tools (special allocation tagging tokens for memory tracking).

You can find the full list of updates on the official website.

Articles

Rust vs C++: Competition or Evolution in Systems Programming for 2026

C and C++ form the foundation of modern software. Operating systems, databases, game engines, and compilers—they all trace their origins back to these languages. Their speed, power, and reliability made them the choice of many. Today, developers have another choice: Rust. This language incorporates the strengths of C++ and addresses some of its issues like memory safety and undefined behavior. So, what's the best option for a developer? The article author explains in detail cases where Rust or C++ has benefits and also describes the pros and cons of these languages.

How far does lookup see in C++?

Placing functions near the types they're intended for is a good practice in C++. However, to properly apply this approach , one should understand how the name lookup mechanisms work as well as where to place functions without violating the language rules. The article author covers the concept of name lookup and explores an argument-dependent lookup (ADL) in particular.

Silent foe or quiet ally: Brief guide to alignment in C++

Have you ever wondered how data is stored in computer memory? Each variable occupies space in memory as a sequence of bytes at a specific address. However, access to this data is winding: data first gets into the fast cache, which exchanges data blocks with RAM.

In this series of articles, the author carefully explains the data alignment mechanism. The second part is here. And here's the third one.

Let's check vibe code that acts like optimized C++ one but is actually a mess

Vibe coding is a hot topic these days. In the article, the author uses a small project called Markus as an example to explain why it's important to understand AI-generated code and be able to see what lies beneath a program's elegant syntax. What do you think of vibe coding? Let us know in the comments!

To stay up to date on the latest C++ news, follow us on X and LinkedIn. We post articles by our company's experts, video reviews featuring the latest analyzer updates, event announcements, memes, and much more. Most importantly, you're always welcome to leave comments—we'll be happy to respond!

Talks

Creator of C++: Bell Labs, Negative Overhead Abstraction, Mistakes | Bjarne Stroustrup — Ryan Peterman

In this talk, Bjarne Stroustrup, creator of C++ and former Bell Labs researcher, reflects on the origins of C++, tracing its evolution from Simula to a system built on C. He discusses the C++ standards committee, memory safety, AI writing code, zero-overhead abstraction, and what he wishes he'd fought harder for from the start.

Lightning Talk: Learning C++ Through Writing Coding Questions — CppCon 2025

CppCon has shared talks from the last event. In this talk, the speaker explains why creating custom exercises for employee training is one of the best ways to master the knowledge of the modern C++ standards. He also discusses how to go from understanding a language feature to explaining it with code example and implementing it in a project.

Lightning Talk: A C++20 Modules Performance Field Report — Tyler Drake — CppCon 2025

At CppCon 2025, Tyler Drake shared an interesting field report. He wrapped "header-heavy" third-party libraries into custom C++20 modules. The result: full build time on his laptop dropped by 41.5%, and incremental builds were cut in half—down to just 1 second. A compelling argument for anyone still hesitant to adopt modules due to legacy dependencies.

Podcasts

GPU Programming and HLSL with Chris Bieneman — CppCast 407 — C++Weekly Ep 533 — C++ Weekly With Jason Turner

Jason Turner, Mathieu Ropert, and Chris Bieneman talk about the history of GPU shading languages from DirectX assembly in the early 2000s through today, why HLSL is gradually becoming more C++-like (templates, structs, auto), and where it deliberately draws the line. They discuss current industry trends around AI-generated code, and the difficulties of maintaining floating-point consistency across platforms.

P.S. When choosing content for the digest, we noticed that they also mentioned our article on analyzing vibe-coded projects. Thank you for your kind words about PVS-Studio, it means a lot to us to hear such positive feedback from you.

Sea of Thieves — Keeping Games Up to Standard — Keith Stockdale — CppCast 406 / C++Weekly 529

Here's another episode of CppCast with Jason Turner and Mathieu Ropert. Keith Stockdale, senior software engineer at Rare, brings up the topic about challenges of maintaining large, long-term C++ codebases in game dev. The talk covers modern C++ standards, the effect of compiler-specific code on portability, and the practical realities of upgrading systems such as Unreal Engine in professional studio environments.

Measure Twice, Optimize Once — Two's Complement Podcast

In this podcast episode, Ben Rady and Matt Godbolt talk about performance optimization: benchmarks and microbenchmarks, real performance problems in software systems. They also discuss how to measure performance before optimization and how to understand profiling noise.

Episode 286: GPU Profiling with NVIDIA Nsight Compute (NCU) — ADSP: The Podcast

The talk focuses on GPU optimization techniques, profiling tools, and high-performance algorithm design. Marco Salgado explains how GPU workloads often become limited by memory throughput. The speakers examine profiling with NVIDIA Nsight Compute, GPU rotate algorithms, and the role of libraries such as NVComp for GPU-based compression. They also discuss how high-level libraries and languages can outperform hand-written low-level implementations by automatically applying optimizations.

A series of talks on how to create your own programming language

C++ is constantly evolving and growing: new useful features appear, making it easier to use, but new challenges also arise. If you want to better understand how any language works, it's worth trying to create your own.

We invite you to watch a series of talks where we create a custom programming language in a live-coding format. Yuri Minaev, experienced C++ developer and architect at PVS-Studio, will guide you through the journey of mastering C++: from implementing a lexer and a recursive descent method to creating your own evaluator. Less boring theory and more actual coding is a great way to boost your programming skills.

Want to learn how to create your own programming language? Follow the link and join new webinars!

Conclusion

Thank you for reading our digest! Share with us any other fresh news or events you found noteworthy. You can submit them using our feedback form.

Don't forget, PVS-Studio stands guard over your codebase. Get the 30-day trial promo code here!

Unity’s AI agent went public: the developers of a static analysis tool on what that means for code quality

Unicorn Developer — Fri, 22 May 2026 14:21:23 +0000

In early May, Unity opened its built-in Unity Agent to all users.

It runs in two modes. In chat mode, the AI assistant suggests improvements to game mechanics and helps track down bugs. In agent mode, it works autonomously: analyzing your project, generating and editing code on its own.

The official demo runs through a workflow: a user builds a game arena, generates a car from reference images, turns it into a playable character, and adds a minigun. The entire thing runs on text prompts, so no code is written manually.

In the post, Unity described it as AI taking over the tedious parts, while developers stay in charge of creative direction.

“Our goal with AI is to help you build better games, faster. Unity AI gives you access to our own in-project agentic assistant, which leverages deep context from your projects and is built specifically for Unity workflows”

The response was split. Some users worry gaming platforms will be flooded with low-effort projects chasing viral trends. But there’s another concern that gets less attention: code quality.

The PVS-Studio team builds a static analysis tool for code quality, reliability, and security. Here’s their comment on the Unity update:

Learn about Medium’s values
“Tools like this are a logical step forward, but their limitations matter too. Generative AI genuinely speeds up development, yet it makes mistakes regularly: wrong logic, unsafe patterns, code that runs but isn’t necessarily safe. The root cause is plain: AI generates code based on probabilities, not strict security requirements.

That’s where static analyzers come in. Not just to catch bugs, but to systematically check for vulnerabilities before anything ships.

PVS-Studio has been used in game development for years, by studios and engine teams alike. Part of what makes it effective on game code is a combination of deep code analysis and built-in annotations for many Unity and Unreal Engine functions and classes. That extra metadata lets the tool warn developers when an API is being used incorrectly.

It also covers optimization. Poor performance hurts players just as much as bugs do. Surely, an AI assistant can also suggest optimizations when prompted, and that’s fine for small projects. But at scale, things slip through: suboptimal ordering of math operations across different data structures, unnecessary allocations, repeated calculations that should be cached.

PVS-Studio currently has 20 Unity-specific diagnostic rules, as well as general diagnostics tuned to account for how Unity scripts actually work.

The broader point: the more AI-generated code enters a codebase, the more you need tooling that filters it. SAST tools become a necessary filter, not an optional one. AI and static analysis aren’t in competition, they’re increasingly paired by necessity. Skip the verification layer, and quality and security will erode as AI usage grows.”

PVS-Studio is a static code analyzer for C, C++, C#, and Java — a SAST tool focused on safety and security defects. Since 2008, it has been used by hundreds of companies worldwide. Over 17 years, the team has reviewed more than 500 open-source projects and written about them extensively: ~1,500 articles published on the PVS-Studio blog.

The analyzer provides more than 1,100 diagnostic rules covering a wide range of error patterns and security defects, and integrates with major IDEs, game engines (Unity, Unreal Engine), build systems, and CI pipelines, including cloud environments. It can operate in air-gapped setups, maps warnings to CWE and SEI CERT, and supports MISRA standards.

PVS-Studio is used across mechanical engineering, medicine, finance, construction, and game development.

Game++. Part 1.2: C++, game engines, and architectures

Unicorn Developer — Thu, 21 May 2026 13:34:13 +0000

This book offers insights into C++, including algorithms and practices in game development, explores strengths and weaknesses of the language, its established workflows, and hands-on solutions. C++ continues to dominate the game development industry today thanks to its combination of high performance, flexibility, and extensive low-level control capabilities.

AI

Of all the aspects of game development, AI is my favorite topic. Over the past years, I've spent so much time wrestling with mobs that if I had a dollar for every one stuck in a corner, I'd have bought a house by now. First there were lone enemies, then packs of mobs, then coordinated groups sharing behavior trees (BTs).

Turns out, not every game actually needs "smart" AI. That sounds counterintuitive, but half the time, a couple of simple scripts that have enemies yelping "Ouch!" on a timer and blindly charging into walls are more than enough to satisfy players. AI isn't magic—it's just code. If your engine supports if, switch, coroutines, or timers—congrats: you already have AI support. All the "intelligence" is just a bunch of conditions cleverly disguised as brainpower. But when devs want to go "pro", they usually adopt one or more of the approaches below.

...Behavior Trees (BT)

Basically, think of it as a simple priority list: if you are hungry, eat; if you see an enemy, attack; if you are badly injured, flee. Behavior trees (BTs) express decisions as a hierarchy of composite and leaf nodes; each node returns one of three statuses: Success, Failure, or Running.

Composite nodes—Selector, Sequence, and Parallel—control how child nodes run and implement priorities from the top down. A Selector might order branches such as "health below 20% → flee," "enemy in sight → attack," "hunger above 80% → eat," evaluating them in sequence until one succeeds. Leaf nodes (Action, Condition) perform concrete actions or checks. That structure tends to stay readable—the tree mirrors the intended logic— which is why BTs are widely used in games and work well with visual editors and hot reload, letting designers iterate on AI without recompiling. Still, a BT with 500+ nodes can devolve into spaghetti that nobody can follow, not even whoever wrote it.

...GOAP (Goal-Oriented Action Planning)

GOAP-style AI starts from a question like: "I want to kill the player. What should I do?" It doesn't simply run a fixed script; it assembles a plan from the actions that exist in the world and the current state. Elegant? Yes. But rolling your own planner is no small job. You must handle resources, conflicting effects, action costs, cycles in the search space, and more. GOAP fits heavy, systemic games and is common at large studios, yet it costs serious engineering time and a strong team to implement and debug.

Unlike rigid behavior trees or finite state machines, GOAP is largely declarative: you specify actions with preconditions and effects, and the planner searches for a sequence that transforms the current world state into one that satisfies the goal. For a goal such as "kill the player," it might produce something like: acquire a weapon → close with the player → attack. The planner can infer that attacking needs a weapon, getting a weapon may require reaching an armory, and movement depends on being able to move. That yields more natural, adaptive behavior: the NPC can respond to a changing world and replan when conditions shift.

...FSM (Finite State Machine)

This is the classic setup with states and transitions—idle → walk → attack → flee. A finite state machine (FSM) is a simple formal model: an entity is always in exactly one of a finite number of states, and it moves between them according to rules driven by events or conditions. The pattern maps cleanly to character and enemy behavior. A player might use states such as idle, walk, run, jump, attack, or dead; an AI mob might use patrol, pursue, attack, retreat, or take cover. Each state bundles its own logic: animations, audio, physics tuning, and which actions are allowed. Transitions hinge on explicit triggers: input, collisions, health thresholds, distance to a target, so behavior stays predictable and comparatively easy to debug.

...Utility AI

Look at NPC with a handful of possible actions, each runnable only when its requirements are satisfied. The system repeatedly scores every eligible action by utility and picks the strongest candidate, which yields smooth blending between behaviors: none of the brittle gatekeeping typical of finite state machines, none of the explicit planning overhead of GOAP. Once you give that NPC more than about ten actions, though, and tie each utility curve to dozens of parameters, forecasting what it will do in a given situation becomes almost impossible.

Debugging gets ugly fast—"why did it break into a dance instead of attacking?"—because you must chase every utility term and how they combine. Tuning weights per enemy type or scenario also fights the fact that the architecture keeps chasing locally best moves. That is why production setups often pair Utility AI with an FSM for coarse phases, or restrict scoring to explicit contexts so choices stay interpretable.

...exotic ones: HTN, ML, Neural Nets, RL

HTN (Hierarchical Task Network) extends the GOAP idea with hierarchical task decomposition: complex goals are broken into subtasks through a system of methods and primitive actions. It produces structured plans and supports long-term strategic planning for NPCs defined in that way.

Reinforcement learning (RL) and neural networks promise even more dramatic results: agents that learn strong policies through interaction with the environment, adapt to the player's style, and exhibit emergent behavior.

The results speak for themselves: AlphaStar in StarCraft II, OpenAI Five in Dota 2, agents that outperform humans in complex strategy games.

Those successes create an illusion that the technology is ready for broad use, yet training an agent for even a relatively simple game can take millions of rollouts—weeks or months of continuous computation on powerful GPU clusters. A single training run can cost hundreds of thousands of dollars. Moreover, any gameplay change or new mechanic often means restarting training from scratch.

On top of that, trained models can be hard to reason about. Debugging this kind of "black box" is difficult even for the ML engineers who built it. That is why large studios still tend to reserve ML for targeted uses—procedural generation, player analytics, and similar—while relying on classical methods for core gameplay AI, where predictable behavior and controlled costs matter most.

...pathfinding

The A* (A-star) algorithm and its variants are the workhorses of game AI: they search a discrete navigation graph efficiently by combining the cost-so-far from the start with a heuristic estimate of the remaining cost to the goal. Practical tweaks turn that elegant textbook algorithm into something that can absorb hundreds of path requests per frame.

The harder problems are usually building and updating the graph, and turning graph paths into motion in the real level. A* outputs a polyline of nodes, but the character still has to move along it with a body, inertia, clearance, and dynamic clutter in mind. Familiar failure modes include corner snagging on coarse geometry, jams in tight choke points, trouble routing around movers (other NPCs, the player, physics props), and fragile vertical routing (ladders, ledges, jumps). Even so, A* (plus navmesh or grid tooling around it) remains the backbone of most shipped navigation, while every new map still means tuning geometry and chasing edge cases.

... navmesh

Finally, the bedrock of in-game navigation: a navigation mesh (navmesh) turns messy 3D level geometry into a discrete walkable surface made of polygons and the links between them. Each polygon is (usually) a walkable region; shared edges or portals are where the agent can move from one patch to the next.

A good navmesh trades fidelity against cost. Too much detail spawns unnecessary complexity and slows search; too little detail skews paths and causes characters to hug corners or snag. Today's pipelines lean on automatic bakes. Recast & Detour—the open-source stack behind many Unity and Unreal workflows—voxelizes or samples the level and outputs a mesh using agent parameters (radius, height, max step, max slope, and so on). Commercial tools and in-house bakes at big studios add more specialized rules and are tuned to specific engines and production needs.

No generator, however sophisticated, truly understands a level. It does not know a nook is meant for stealth, that a footbridge is scripted to break, or that a ladder needs a bespoke climb. Common bake failures include links through paper-thin walls or open windows, bogus connections between platforms at different heights, doors/elevators/destructibles treated as static, and broken islands in dense spaces.

So modern workflow is automation plus hand pass: designers place jump links, cover hints, corner fixes, and mark areas with special costs, speed scales, or unit-class rules. Without that manual nav polish, the fanciest decision-making stack is like a wheelbarrow with a wheel missing—it can decide what to do, but it still cannot reliably carry it out in the real geometry.

...AI isn't about "smart enemies"

Game AI is mostly about selling the illusion of intelligence. Players need reactions, pressure, and the occasional surprise. Behind the curtain it is still if statements, switches, and a pile of navmesh—exactly the kind of machinery they should not have to think about. "Good" AI is not the same as genuinely smart AI: the job is to entertain and stave off boredom, not to pass a Turing test. A slow-witted opponent is fine if it behaves the way the player expects. A predictable opponent is fine, too: readable patterns make mastery feel earned. A hand-authored script is fine if it is reliable, fun to play against, and does not break the world.

In short, the goal is not to be smart; the goal is to seem smart. If the player believes they are facing something clever, you have done the important part of the work.

Scripts and configs

Embedded gameplay logic often lives in scripting layers: Lua, Python, JavaScript, AngelScript, and similar, especially when the core engine is built in C++. Those languages tend to fail more gracefully at runtime and can save a lot of iteration time. Even if you are writing an engine from scratch, it pays to plan for scripting early and to keep the host language's strengths and limits in mind: that reduces glue cost and keeps integration straightforward.

Building an engine still means writing plenty of code; there is no real shortcut. Which language should you pick? Frankly, what you already know well matters more than the label on the tin. A seasoned developer will squeeze much more out of performance-sensitive paths in a familiar language and will sidestep the usual traps more reliably. Low-level options such as C++ give you clear control over resources, but they expect solid architecture judgment and a firm grasp of how systems fail and scale.

...it's not about performance or FPS

Script layers and data-driven configs exist mainly so designers can iterate quickly and so less engineering-heavy teammates can contribute safely. High-level languages—Lua, Python, a bespoke DSL, or similar—give you a flexible sandbox for gameplay prototyping: tune balance, try new mechanics, and adjust AI behavior without kicking off a full native rebuild or pulling an engineer into every tweak.

With a low-level-only workflow, even small changes often mean compile, link, and deploy—minutes to hours, depending on the codebase. Interpreted scripts plus JSON/XML-style configuration draw a clean boundary between the stable C++ core and the volatile content layer. You pay a modest runtime tax (parse time, interpretation) but you buy shorter iteration loops, easier A/B experiments, and content patches that do not require shipping new binaries.

...it's about convenience and development speed

Scripting enables a fundamentally different development rhythm: the write–test–fix loop collapses to seconds because languages are interpreted and many setups support hot reload. You can nudge an enemy's detection logic or aggression tuning and see the outcome immediately in-game. Modern engines add live inspectors, debug consoles, and visual debugging hooks - exactly what you want when design asks for constant pivots. Standing up several AI behavior variants in one evening becomes realistic, so teams can experiment without treating every idea like a production milestone. Compared with the C++ pipeline, where each tweak might cost thirty seconds to minutes of rebuild time, a script-forward workflow is simply easier to stay "in the zone" with.

...surprisingly, it's also about safety

Sandboxed scripting is mostly about isolation: each script runs inside a controlled environment with a deliberately narrow API. In Lua, for instance, you can spin up separate VMs (lua_State) with their own global tables and expose only the bindings you intend—blocking raw filesystem access, sockets, process spawning, and similar primitives unless you explicitly whitelist them. Typical gameplay-facing surfaces might look like SpawnActor(), GetPlayerHealth(), or PlaySound().

You can also cap risk operationally: maximum CPU time per script tick, memory budgets, instruction budgets, call counts, recursion depth (whatever your VM exposes) and hard-stop the script when a limit trips. When script code misbehaves, the interpreter can usually trap the error, log context, and let the native core keep running. Native plugins and dynamically loaded modules are different: they generally execute in-process with the engine, so a stray pointer or buffer overrun can still take the whole process down.

...it's about overall project reconfigurability

Hard-coded literals in C++ become architectural friction: every tweak to an AI tunable forces a full native iteration: preprocess, compile, link, ship bits and before anyone can feel the change in-game. That pain shows up fastest when you are chasing numbers such as damage modifiers, nav penalties, aggression thresholds, or weapon timings. The straightforward fix is to push anything gameplay-facing into external data (JSON/XML/INI), spreadsheets, custom DAG formats, or database rows, so designers can rebalance without touching source. Many engines layer reflection-style property systems on top so values hydrate from disk and can be edited live in inspectors.

Hot reload for scripts usually boils down to watching files and re-importing modules: the tooling notices that a script changed, reloads that unit inside the running interpreter, and keeps the native host process alive. That workflow matters when you are iterating on AI rules, event handlers, or broader mechanics and want feedback without a reboot cycle.

...it'so a door for the community

User-generated content needs a low floor for contributors: easy tooling and modest prerequisites. Shipping a mod-facing C++ surface usually means an SDK with headers, build docs, ABI promises, and matrix-testing across compiler versions and platforms: Visual Studio generations, GCC, Clang, and whatever else your players use. Scripting sidesteps much of that: the interpreter already ships inside the game, so modders mainly need an editor, your dialect docs, and enough syntax to stay out of trouble.

A modular script API also gives you a narrow contract: gameplay-facing calls stay stable while native internals churn. Native plugins are different—engine upgrades often force rebuilds, toolchain bumps, and subtle breakage even when nothing "meaningful" changed on paper. Script packs tend to keep working across releases as long as the exposed bindings and semantics stay compatible.

...you can't please everyone

Lua has become the de facto gold standard for embedded gameplay scripting: small runtime, fast enough for tight loops, straightforward C/C++ binding, and oceans of examples and reference material. Most titles drive it from a single gameplay thread; when teams need parallelism, they typically spin up separate Lua states (or isolate work carefully), rather than treating one VM as freely multithreaded.

Python's ecosystem is deep and the syntax is approachable, but shipping it inside an engine is often painful: interpreter startup, packaging, the GIL, and embedding details can consume engineering time you would rather spend on gameplay. That friction pushes many projects toward Lua for in-engine scripting.

JavaScript, through embeddable engines (V8, QuickJS, etc.), can deliver strong throughput and reasonable memory use—modern JIT/AOT JS stacks are mature, and for some teams they are a credible alternative to the usual Lua route.

Smaller embeddables—AngelScript, Wren, Squirrel, ChaiScript, and friends—fill niches. They trade different ergonomics and feature sets, and could have been stronger contenders if Lua had not become the default reference point; today they are usually judged against that baseline.

Networking

It is no secret that everyone dreams about it: persistent worlds, co-op, PvP, MMO-scale ambitions, or even simple player chat. Then you crack open Wireshark and your dreams narrow to one thing—getting any of it to actually run.

Here is the good news first: your game may not need networking at all. If you are building something offline—a puzzle game, a platformer, or "SimTower but with toads"—you can happily ignore the whole topic. If "multiplayer" suddenly sounds tempting, though, tighten your seatbelt. You are stepping onto a road where everything matters, and there is no universal architecture that fits every title.

Modern languages such as C#, Rust, or Go ship tolerable ergonomics for sockets—async IO, nice coroutines, that sort of thing. In C++ (you have my sympathies) you will probably reach for a battle-tested third-party stack such as RakNet, ENet, or similar. None of them feel "brand new," but they have shipped in countless titles.

Sockets are only the handshake at the door. Establishing a connection is roughly one percent of the job; the interesting problems start immediately afterward. What exactly is a "networking engine," anyway? Good question—I asked myself the same thing while hacking together my first co-op prototype. I never got a crisp definition, but I collected a long list of features you suddenly care about, which I will walk through next.

...state synchronization

This is the bedrock of multiplayer, and also one of the hardest parts of network programming. Every participant runs their own local simulation of the world, yet those simulations must stay compatible enough that play feels coherent. Perfect lockstep is not achievable in principle: latency means that by the time news of one player's action reaches everyone else, the situation may already have moved on.

So, teams pick strategies that match the genre. Turn-based games can pause until acknowledgements arrive. Real-time titles usually trade purity for responsiveness—either constrain pacing to the worst connection, or predict locally and reconcile mistakes afterward. Another common pattern is an authoritative server: simple conceptually, tough on high-latency clients who constantly receive corrections.

Fast-moving interactions are where it gets ugly—mutual kills, two players grabbing the same pickup, racing inputs on a contested objective. Some arbiter (often time-stamped server adjudication plus latency-aware rewinds) has to decide what "happened first," even though each player experienced different delays. Get that wrong and players see constant rewind-snaps—"rubberbanding"—as the simulation reconciles against what actually occurred.

...input prediction and rollback netcode

Rollback netcode keeps fast games playable even when latency is high. The idea is straightforward: do not stall the simulation waiting for remote input—advance locally using predictions. When real inputs finally arrive, compare them with what you assumed; if they disagree, rewind to a saved checkpoint and replay forward with the corrected inputs.

Shippable rollback stacks almost always need fast snapshotting or equivalent bookkeeping: enough history to restore an earlier timestep and resimulate deterministically. Practically, that means storing periodic world snapshots or compact state deltas—positions, velocities, animation phases, RNG seeds, anything that affects simulation outcomes—plus the input stream needed to replay.

When a mismatch fires, you load the snapshot at the divergence point and fast-forward to "now," applying the true inputs along the way. Done well, players barely perceive the correction—the game keeps feeling crisp even around 100–150 ms RTT, where naive lockstep feels awful.

The catch is engineering cost: the gameplay simulation must be deterministic and replay-safe, which often forces broad refactors across gameplay code, physics hooks, and fixed-point or controlled-float policies. Saving "the entire world every frame" is the textbook mental model; production engines usually optimize that snapshot strategy, but the obligation remains the same —you must be able to reconstruct the past quickly enough to hide latency.

...interpolation, extrapolation, smoothing

Networked games constantly deal with messy delivery: packets show up at uneven intervals, drop entirely, or land out of order. If you simply apply each update as it arrives, motion looks choppy and often unplayable. Interpolation smooths that out by blending between known samples, if you know a player was at point A at time T1 and at point B at time T2, you can render a continuous motion between those keys instead of snapping.

Extrapolation pushes further: you guess where something will be next from its current velocity and heading so you can keep moving it while you wait for fresh data. The trade-off is accuracy— the longer you predict ahead, the more likely the object suddenly stops or turns, and your guess diverges from reality.

...secure communication protocol

Network protocol security begins with never trusting the wire blindly. Every inbound message should be validated: correct framing, sane ranges, and consistency with what that peer is allowed to do right now. If you apply client-supplied state without checks, you invite classic exploits: arbitrary teleports, inventory stuffing, stat inflation, and worse.

Authentication and authorization harden the perimeter: only legitimate clients should join a session, and each peer should only act within its role. Sessions normally start with identity proof—tokens, signatures, or platform-issued tickets—and critical operations should re-check permissions and freshness. Rotate credentials on a sensible schedule, enforce validation on high-risk actions, and treat session keys as a second line of defense so a stolen long-lived password does not instantly mean game over.

...encryption (you don't get paranoid for nothing)

Encryption in games is not paranoia, it is basic hygiene. Even casual titles move data that should stay private: progression, virtual currency, handles tied to accounts. Modern capture tools are so approachable that unencrypted traffic is trivially observable. TLS is the usual baseline for protecting bytes on the wire, but cryptography is not free: handshakes cost round trips, and ciphered payloads add CPU to margins that can sting in latency-sensitive modes where tens of milliseconds matter. That is why many realtime stacks blend approaches, such as lighter session crypto for steady-state updates, selective encryption for the highest-risk fields, or tuned stacks built for games and while still refusing to ship gameplay plaintext that trivially enables spoofing and griefing.

...object replication

In a multiplayer game, the same logical object often exists in several places at once: on the server, on each client, and sometimes in more than one representation on the same machine (for example, authoritative versus predicted). The server copy typically owns the facts that matter for outcomes (health, transforms, inventory counts), while what you render locally may be interpolated, extrapolated, or rolled back.

A replication layer must choose what to sync, how often, and to whom. Private facts (full inventory loadouts, quest flags, hidden traps) should narrowcast to the owning player; public signals (rough pose, equipped silhouette, team tint) can broadcast to everyone who needs them for rendering or fairness. Delta compression and other bandwidth tricks shrink payloads, but each trick adds edge cases you must reason through when state diverges.

...logging and debugging

Logging in networked games is not merely an ops checkbox. For contentious bugs you often want an audit trail for player inputs, meaningful state transitions, and sometimes even packet-level breadcrumbs when you can afford it.

The catch is volume: a busy title can spill gigabytes per hour if you log naively. Production setups therefore rate-limit, sample, struct-tag, and compress, and they aggressively drop chattier channels in hot paths.

Structured logs (timestamps, build ids, match ids, player ids, entity ids) are what let you rebuild a story after the fact. When a report says "my unit turned into a different type," you need a thread you can follow: spawn time, command stream, authority changes, template swaps, replication apply order. Without that kind of chain, the bug becomes guesswork.

... dealing with cheaters

Fighting cheaters is a slow arms race, and the house does not win every round. Every mitigation invites a countermeasure; every anti-cheat update trains tooling to adapt faster. The structural issue is simple: part of your game executes on hardware the attacker owns. Anything you ship to the client can be inspected, patched, replayed, or spoofed at some level of effort.

Server authority is still your backbone: validate outcomes and sanity-check inputs so blatant lies die server-side. Pure perfection would mean simulating everything centrally, which quickly collides with responsiveness and cost, so teams settle on layered checks on the moments that matter.

Client-side anti-cheat scans memory and modules for known signatures and anomalies. It can help, but it walks straight into trust and privacy debates: kernel drivers and elevated monitors feel invasive, players hesitate to install them, and false positives annoy legitimate setups from capture tools to security suites.

UI

You can ship a game with no physics, no AI, even no sound. Shipping without UI is almost impossible. These days a completely UI-less title reads as intentional avant-garde indiesperimentation. Besides, you still need somewhere to put New Game and Quit.

On paper it sounds trivial: draw a few buttons, drop in labels, maybe a slider. Then reality arrives. Interactive widgets accumulate states. A button is not one bitmap; it is idle, hovered, pressed, focused, disabled, and sometimes half a dozen custom variants. Same story for fields, toggles, lists.

Hierarchy piles on complexity. Modern screens are trees: a button lives inside a row inside a panel inside a sheet that might not exist until a tab opens. Each layer needs layout, clipping, focus routing, and visibility rules that do not fight each other.

Coordinate spaces make UI math fiddly. Meshes live in one world space; UI fragments flip between pixel screenspace, scaled logical units, and parent-relative boxes. Hit testing, anchoring, DPI scaling, and safe areas all sit on top of that stack.

Input parity is another whole axis. Desktop expects mouse precision and keyboard traversal; mobile expects fat fingers and gestures; consoles expect focus rings and analog navigation. One layout rarely fits all without deliberate affordances.

Polish is where hobby UI dies and production UI begins: transitions, micro-motion, feedback on press, disabled styling that still reads clearly. None of that is mere ornament; it is what separates "dead controls" from something that feels alive.

And then you notice the trap: you set out to ship a game, but you are halfway to authoring a mini framework that may never leave this codebase. Even when you embed a mature stack (Scaleform is better than its reputation, for what it is worth), you still owe integration work: input translation, event bubbling, font atlases, shader passes, batching, localization hooks.

So yes, UI is structured, layered, platform-sensitive work that teams routinely underestimate. It is still worth doing properly at least once, even in a small scope. Just do not expect weekend one to reproduce Unity UI, Unreal Slate, or the entire HTML ecosystem.

Tools

Not every engine or game needs a heavyweight toolchain around it, and that should not surprise anyone. Sometimes a handful of Python glue scripts is enough. Many commercial stacks ship editors that feel like an IDE crossed with a DCC app: place entities, tweak materials and shaders, tune physics, scrub animations, poke UI, and scrub changes live.

Building an editor that polished is almost as expensive as building the runtime itself. For a small custom engine, chasing Unity-parity chrome is usually a bad ROI: months disappear into docking layouts and undo stacks you never needed.

Still, do not ignore small tools. A few evenings of scripting for bake helpers, batch exporters, or sanity validators routinely buys back weeks of manual slog later.

...level converters

Custom binary schemas exist because you often want load paths that map cleanly onto engine structs and arrays with minimal translation cost.

Text interchange formats such as JSON or XML pay for human readability at runtime: lexing, parsing, string-to-number conversion, heap churn. A well-designed packed blob can mmap or fread straight into layouts you already use in simulation, which matters when a level streams thousands of transforms, material handles, and tagging metadata.

Binary pipelines also give you room for embedded compression, baked LOD chains, precooked nav data, hash tables, whatever preprocessing saves milliseconds on the critical path.

Conversion tooling ties into normal asset workflows: watch folders, rebuild packs when sources change, split authoring formats from shipping blobs so artists keep familiar exporters while engineers evolve on-disk layouts or platform-specific variants without forcing daily disruption.

...asset validation

Asset validation is one of the few things that cheaply pays for build integrity: it blocks bad data before it poisons a milestone. Validators walk reference graphs, because every serious asset points at other assets through GUIDs, source paths, or custom handles, and a missing link is a late-night crash you do not want in QA.

They also enforce content rules: materials must resolve textures, mesh chunks must bind valid skeletons, animation clips must line up with rig definitions, shader permutations must exist for the platforms you actually ship.

Hook those checks into CI and the content bake so failures surface with filenames, not mystery repros. On big teams, that is how you keep an artist's innocent rename from silently deleting someone else's dependency three departments away.

Time invested in tooling should pay rent: if a workflow still means hand-editing two hundred lines of JSON, a small exporter or inspector script will usually earn its keep faster than another meeting about process. You still should not build a glittering editor "because engines have editors," but targeted automation is rarely wasted effort.

Architecture

Eventually the parts exist: rendering, audio, data, physics, UI, maybe AI and scripts. The missing question is how you wire it all into something that runs as one product. A few established patterns keep showing up in production codebases.

...no architecture is also architecture

After fighting overbuilt frameworks, many small teams fall back to a deliberately dumb architecture: a handful of independent libraries, each owning one slice of the problem. You wrap rendering behind a gfx module, audio behind audio, streaming behind assets, polling behind input. Modules stay loosely coupled on purpose; nothing magically knows about anything else unless you wire the calls.

That was the default posture of late-nineties and early-aughts codebases. It is quick to stand up, easy to reason about in small scopes, and leaves execution order entirely visible.

Discipline becomes the hidden dependency: without scene graphs or forced pipelines, nothing stops you from forgetting a step.

Scale hurts first in your head: the call graph sprawls, initialization order turns fragile, and regressions arrive as subtle sequencing bugs. UI stops refreshing after a content reload, music fails to cue on level transition, physics wakes before assets finish streaming. Each fix is manual glue, because the missing piece was never "library quality," it was composition.

Ironically, the wiring you tried to postpone is the architecture. Evading structure does not delete it; it just relocates the burden into ad hoc calls sprinkled everywhere.

...godobject is also architecture

Large game engines like Unity, Unreal, Godot, CryEngine, Dagor, and others often adopt an approach based on a single base class. Typically named Object, Entity, GameObject, Actor, or similar, this class becomes the ancestor of all game entities. This base class usually contains virtual methods for core game functions:

struct GameObject {
  virtual void update(float dt);
  virtual void render();
  virtual void onEvent(const Event&);
};

Everything you author, from HUD widgets to hostile NPCs, subclasses one mega-type. Each instance magically inherits tick callbacks, draw hooks, and event plumbing. Convenient? Extremely. You get a uniform surface area "for free," plus a natural place to hang a central registry.

The downside is inheritance sprawl: one mammoth base class fights composition, mixing orthogonal concerns into the same vtable. Want multiple reusable behaviors? You bolt more flags and overrides onto GameObject. Within a few milestones that base type balloons into hundreds of lines of virtual hooks.

Bolting "components" onto the same hierarchy often compounds the mess instead of curing it. Eventually you regret the shape of the tree, yet countless shipped titles prove you can still finish under this pattern if scope stays modest.

...ECS is good! But...

This architectural model has exploded in popularity among indie developers and enthusiasts in recent years. The core idea is a radical separation of data and logic, built around three key concepts. An entity is just an identifier, with no logic or data of its own. A component is a container for a specific type of data, such as position, health, or sound parameters. A system is a functional block that processes components according to specific rules. None of them works alone, but together they replace traditional object hierarchies with batch-oriented data processing.

For instance, a physics system can walk all entities that have both Transform and Velocity and update every moving object's coordinates in one structured pass. Benefits include strong performance from cache-friendly layouts, clearer separation of responsibilities between subsystems, and good scalability.

Drawbacks include jumping straight into a fairly complex architecture that often needs a lot of boilerplate and patterns. Without specialized editors, ECS-heavy codebases can be hard to read, and without visual debugging tools, diagnosing issues gets painful. For smaller projects, it can feel like using a sledgehammer to crack a nut.

Game engine

Maybe you should leave everything exactly as it is? Yes and no. The engine, and the scaffolding around it, is a means to an end. If you are hacking on a weekend hobby project, do not chase the perfect framework, or you may ship nothing but scaffolding while the actual game keeps slipping. Still, architecture matters the way a skeleton matters: nobody admires your ribs in screenshots, but if the bones are crooked, everything built on top aches, bends, and snaps under light stress. When the structure becomes genuinely painful, do not be precious about it. Throw it out and rebuild. Everyone tosses bad foundations sometimes (that is the spirit behind the "three systems" rule). Classics such as Jason Gregory's Game Engine Architecture remain relevant because nobody has handed us a strictly better substitute.

To learn how games actually tick, you do not need an Unreal-scale codebase on day one. If you want to avoid becoming yet another résumé line that reads "Unreal C++" yet hides shallow familiarity with how containers or allocators behave, try shipping your first or second project with minimal middleware. Make something deliberately crude: a window, a handful of sprites, a tiny resource loader that stuffs textures into a .zip. Call it a toy engine if you like: simple, buggy, full of reinvented wheels, but yours, and built while knowing what each lever does. Skip Unity, skip Godot, skip the polished shortcuts that quietly vault you past ninety percent of what is happening under the hood.

You will fight architecture problems, patterns, and asset budgets head-on. It costs calendar time, but you earn more than a demo reel clip: you earn intuition about internals that is hard to fake in interviews. That is where serious growth starts, without borrowing momentum from black boxes. Someone who only knows editor wiring may stay boxed into one toolchain; someone who understands memory layouts, threading contracts, and asset pipelines can adapt across engines.

That said, if Godot, Unreal, or another turnkey stack matches your patience and goals, use them. Ambition and pace matter more than purity contests. Even if you eventually standardize on third-party tech, the scars from rolling your own stack become leverage: you stop treating engines like magic and start reading them as engineered systems.

As always, the choice is yours.

Author: Sergei Kushnirenko

Sergei has over 20-year experience in coding and game development. He graduated from ITMO National Research University and began his career developing software for naval simulators, navigation systems, and network solutions. For the past fifteen years, Sergei has specialized in game development: at Electronic Arts, he worked on optimizing The Sims and SimCity BuildIt, and at Gaijin Entertainment, Sergei headed up the porting of games to the Nintendo Switch and Apple TV platforms. Sergei actively participates in open-source projects, including the ImSpinner library and the Pharaoh (1999) game restoration project.

All parts

Game++. Part 1.1: C++, game engines, and architectures

Let's make a programming language. Lexer—Key points

Unicorn Developer — Tue, 19 May 2026 13:54:45 +0000

This is the third part in our series of talks on creating a programming language. The episode focuses on building a lexer—a fundamental component of a language interpreter responsible for breaking down input strings into atomic tokens.

About the speaker

Yuri Minaev is an experienced C++ developer, architect at PVS-Studio, and a recognized voice in the C++ community who has spoken at CppCast, C++ on Sea, and CppCon. Over the course of ten sessions, he'll guide you through each stage of building your own programming language.

The lexer in action

The speaker begins by revisiting grammars and describes how a lexer handles the lowest-level grammar elements like numbers, identifiers, operators, variable names, and keywords. Using simple binary expressions as examples, Yuri demonstrates how the lexer scans an input string character by character, groups symbols into tokens, and ignores whitespaces.

How the lexer works in C++

Yuri explains the lexer's internal design in C++, including the token structure, iterator-based scanning, and "lazy tokenization". Why is it "lazy"? Instead of handling the entire input at once, the lexer generates tokens on demand and supports token previewing through a cached token mechanism. The implementation uses string_view to avoid unnecessary memory allocations and relies on helper functions to classify characters as digits, letters, separators, or operators.

The talk also covers handling integers, floating-point numbers, identifiers, keywords, single-character operators, and multi-character operators such as == and !=. The lexer follows a greedy strategy and continues parsing even after encountering invalid input, producing error tokens rather than stopping execution.

Yuri wraps up the session by discussing ambiguous grammar problems in languages like C++, explains why the custom language avoids them, and outlines plans to implement a parser in the next part.

Want more?

If you want to watch other talks or see the whole episode, follow this link.

You can also sign up for our upcoming webinars, for example: Let's make a programming language. Parser.

If you'd like to learn more about PVS-Studio analyzer, check out our website.

See ya!

PVS-Studio in CMake: It's official now!

Unicorn Developer — Mon, 18 May 2026 09:36:47 +0000

If you're working on a cross-platform project in C or C++, you usually don't rely on a single build system, but instead use a build script generator. CMake, the most popular one, has recently been officially integrated with PVS-Studio static analyzer for these languages.

CMake is Kitware's flagship product for software developers. This is a project with a rich history that dates back almost as far as the company itself. The first version was released in 2000, about two years after the founding of Kitware.

Over time, all of Kitware's projects (such as the Visualization Toolkit library and the ParaView engine based on it and designed to for interactive scientific visualization) began using CMake to define their project structure and build process. Other major open-source projects followed suit: KDE, LLVM, and Qt all replaced GNU Autoconf in CMake's favor at various times. PVS-Studio analyzer for C and C++ fully switched to CMake in early 2020.

PVS-Studio can analyze projects regardless of the build system: on Windows, the analyzer intercepts calls to the compiler and its start commands. Compilation tracing is available for GNU/Linux systems.

How does it work?

Starting with version 4.3.0, CMake can run PVS-Studio while compiling a C or C++ project. Analyzer warnings will appear alongside compiler messages and warnings.

Picture 1. The beginning of the build log file for the libcrypto component from LibreSSL 4.3.1 combined with the PVS-Studio analysis

The process of configuring PVS-Studio static analyzer is almost identical to that of other solutions supported by CMake: simply declare the CMAKE_<LANG>_PVS_STUDIO directive and list the parameters after it, just as if you were running CompilerCommandsAnalyzer on Windows or pvs-studio-analyzer on *nix systems. <LANG> can take the C and CXX values.

set(CMAKE_C_PVS_STUDIO CompilerCommandsAnalyzer analyze -a GA)
set(CMAKE_CXX_PVS_STUDIO CompilerCommandsAnalyzer analyze -a GA)

You can place this directive at any level in CMakeLists.txt, controlling how much code the analyzer checks.

We checked the CMake 4.1 source code in August 2025. PVS-Studio analyzer for C and C++ detected many interesting things there.

Using the built-in integration to analyze code limits your options for interacting with the analysis results: the PVS-Studio report is not saved, since source code files are analyzed individually. So, the report conversion via plog-converter is unavailable, but you can aggregate analyzer warnings in CDash—a test result monitoring system also developed by Kitware. The developers on the CMake team did just that—you can see the result of the integration here.

Let's put it into practice

We'll go over the analysis process using the example of the LibreSSL cryptographic library, which is a hard fork of OpenSSL designed to improve the codebase quality, security, and maintenance. The examples of command-line commands are written for Windows.

Open the root CMakeLists.txt file and add the following line:

set(CMAKE_C_PVS_STUDIO CompilerCommandsAnalyzer analyze -a "GA\;OP")

Then, generate files for the Ninja build system:

cmake -B build -G Ninja

Next, run any build target, such as libtls—a new version of the libssl library for TLS connections:

cd build
ninja tls

The build starts, and the analysis begins.

Picture 2. The head of the build log file for the libtls component from LibreSSL 4.3.1 combined with the PVS-Studio analysis

PVS-Studio warnings are displayed in an easy-to-read format: the path to the file with the line number, the diagnostic rule number, and its description. Let's take a look at some warnings from the libcrypto cryptographic library used in libtls:

Some trickery

void
BF_ecb_encrypt(const unsigned char *in, unsigned char *out,
    const BF_KEY *key, int encrypt)
{
    BF_LONG l, d[2];

    n2l(in, l);
    d[0] = l;
    n2l(in, l);
    d[1] = l;
    if (encrypt)
        BF_encrypt(d, key);
    else
        BF_decrypt(d, key);
    l = d[0];
    l2n(l, out);
    l = d[1];
    l2n(l, out);
    l = d[0] = d[1] = 0;              // <=
}

PVS-Studio warning: V1001 The 'l' variable is assigned but is not used by the end of the function. blowfish.c 587

Here's a simple and straightforward Blowfish algorithm. In this case, the data buffer is quickly flushed for encryption or decryption, depending on the value of encrypt. However, the data won't be overwritten if the app was compiled with optimization enabled, and the 12 bytes—8 of which are a data block—will remain in memory.

You're repeating yourself. You're repeating yourself.

To read information from X.509 certificates and similar documents, the Abstract Syntax Notation Once (ASN.1) parser is required.

PVS-Studio warning: V501 There are identical sub-expressions '(c == ' ')' to the left and to the right of the '||' operator. a_print.c 77:

int
ASN1_PRINTABLE_type(const unsigned char *s, int len)
{
  int c;
  ....
  while (len-- > 0 && *s != '\0') {
    c= *(s++);
    if (!(((c >= 'a') && (c <= 'z')) ||
        ((c >= 'A') && (c <= 'Z')) ||
        (c == ' ') ||                   // <=
        ((c >= '0') && (c <= '9')) ||
        (c == ' ') || (c == '\'') ||    // <=
        (c == '(') || (c == ')') ||
        (c == '+') || (c == ',') ||
        (c == '-') || (c == '.') ||
        (c == '/') || (c == ':') ||
        (c == '=') || (c == '?')))
      ia5 = 1;
    if (c & 0x80)
      t61 = 1;
  }
  ....
}

We'll stretch it out a bit by placing the conditions in if in a single column:

if (!(
       ((c >= 'a') && (c <= 'z'))
    || ((c >= 'A') && (c <= 'Z'))
    || (c == ' ')                   // <=
    || ((c >= '0') && (c <= '9'))
    || (c == ' ')                   // <=
    || (c == '\'')
    ....
))

And here's the sneaky duplicate space check. We believe this is purely a coincidence :)

You can remove it from any part of the condition without losing any functionality:

if (!(((c >= 'a') && (c <= 'z')) |
    ((c >= 'A') && (c <= 'Z')) ||
    ((c >= '0') && (c <= '9')) ||
    (c == ' ') || (c == '\'') ||
    (c == '(') || (c == ')') ||
    (c == '+') || (c == ',') ||
    (c == '-') || (c == '.') ||
    (c == '/') || (c == ':') ||
    (c == '=') || (c == '?')))

More complex cases involving repeated checks within a condition also exist. To prevent this, you can use table-style code formatting.

Will the old analysis options remain?

The familiar ways of analyzing CMake projects using compile_commands.json and the CMake module haven't gone anywhere—you can still use them. You can find more details in our documentation. Keeping your code bug-free has become even easier, and we hope that integrating static analysis into your development pipeline will be just as easy! If you'd like to try out the new integration now, you can request a free trial license.

Static code analysis and software time to market

Unicorn Developer — Fri, 15 May 2026 14:06:43 +0000

This article focuses on the methodology of static code analysis and its role in streamlining the time to market for software products. Let's think about how relevant it is to ask about the value of static analysis. We'll explore how it works alongside other software quality assurance practices. Integrating static analysis into the development process is not an overhead—it's an investment that pays for itself through early defect detection.

How static analysis speeds up time to market

You might have heard the question: "How does static analysis get a product to market faster?". Phrased like that, the answer is disappointing: static analysis by itself does not speed up market entry—it takes time to introduce static analysis and handle warnings. But the real issue is that the question itself is flawed—much like asking whether the testing phase speeds up a product release.

The right question to ask is: "How does static analysis reduce time to market when shipping products at a given level of quality and reliability?". This framing reveals the methodology's core value.

"Counter-intuitively, adding quality checks accelerates development cycles rather than slowing them down. When developers have confidence that their changes won't break architectural constraints or introduce subtle bugs, they can work more boldly and efficiently" [1]

Why the quick approach is flawed

The testing analogy is particularly telling. No one asks whether testing speeds up a product release—everyone understands it's a necessary quality assurance step. Yet, in theory, the fastest way to launch a product is to write some working code and deploy it to production right away.

But in practice, nobody even thinks about shortening the testing phase. More often, we see that testing alone isn't enough.

According to the research, poor software quality costs the US economy over $2 trillion annually [2]. In such projects, up to 50% of effort goes into fixing bugs instead of creating business value [3].

Economics of bug detection: the earlier, the cheaper

Figure 1. According to IBM System Science Institute — Relative cost of fixing defects.

The exponential growth in the cost of fixing a defect at later development stages is the key principle that explains the value of static analysis. According to the IBM Systems Science Institute, fixing a bug during testing might cost 2–3 times more than fixing it at the implementation (coding) stage. After the release, fixing that same bug costs 6 times more than during testing, and 15 times more than during implementation [4].

Static analysis runs during the implementation stage—right when developers write code. It helps eliminate many errors before they even get to the build system, long before testing or production. Automated tools check for typos, control-flow anomalies, buffer overflows, and other defects without requiring test scenarios.

Static analysis does not replace other methods—it complements them

Static analysis is no silver bullet, nor does it aim to replace other quality assurance methods. Integrating it into the development life cycle improves software quality, security, and reliability. This way, static analysis shortens development time through early bug detection. However, the most effective approach combines several complementary methods.

Experienced developers don't pick a single approach; they leverage a whole toolkit: static analysis, unit testing, dynamic analysis, composition analysis, manual testing, and more. The synergy of using different techniques together catches a broad range of defects before the release.

Experts estimate that most testing methods find around 35% of software defects [5]. This reinforces the need for a multi-level approach, in which static analysis detects those categories of errors that are difficult or impossible to find using other methods.

Real-life cases and measurable results

Figure 2. Static Application Security Testing (SAST) makes it possible to focus more on building new features rather than on bugs and vulnerabilities.

The usefulness of static analysis has been proven in practice by large companies. After adopting static analysis for mobile device development, Motorola halved the number of bugs that users discovered during alpha and beta testing [6].

Once a team has spent 50 hours tracking down a bug that the analyzer could have caught right at the start [7].

Research shows that development teams adopting DevSecOps practices with static analysis fix defects 11.5 times faster than those without such practices [8]. Also, implementing static analysis tools doesn't add to the development workload to teams before the release. As developers become more skilled, the false-positive rate drops thanks to cleaner code.

Applying the Shift Left approach

Static analysis is a key component of the Shift Left approach, in which quality checks are moved to earlier stages of development. Implementing static analysis into the CI/CD pipeline enables fixing issues straight away, rather than days or weeks later.

This automates most of the work involved in ensuring compliance with coding standards (MISRA C/C++, SEI CERT, OWASP ASVS) and frees up development time for higher-priority tasks.

ROI

Implementing static analysis involves costs: purchasing tools, training the team, and integrating the process, yet these investments pay off. Static analysis tools spot potential vulnerabilities and bugs at a stage when fixing them remains cheap.

Industry research highlights that the ROI from static analysis goes beyond prevented defects and faster regulatory compliance. It also gives teams confidence that they can keep developing the product with a low bug rate [1]. This matters greatly for large-scale projects with a large amount of legacy code.

PVS-Studio tool as an example

Figure 3. PVS-Studio.

PVS-Studio is a static code analyzer for C, C++, C#, Java, Go, JavaScript, and TypeScript.

The tool is a classic example of a tool that accelerates the release of high-quality software. By integrating with IDEs and CI/CD systems, PVS-Studio catches bugs and potential vulnerabilities early, saving both budget and time.

Conclusion

Adopting static analysis tools takes resources. Yet asking whether it speeds up time to market without considering quality misses the point. If the goal is simply to ship a product as fast as possible, the quickest route would indeed be to skip all checks.

But when the goal is to deliver a high-quality, reliable, and secure product, static analysis becomes an essential tool for ensuring both quality and security. Using static analysis tools enables you to:

find errors early, when the cost to fix them is lowest;
reduce the risk of vulnerabilities surfacing in production, which can lead to significant financial and reputational damage;
automate standards compliance checks and lighten the team's workload;
focus on high-level logic and architectural decisions during code reviews, rather than on looking for typos and other low-level defects;
increase the stability of both new feature development and changes to legacy code;
speed up time to market by cutting down unforeseen delays from fixing defects found late in the cycle.

So, a static analyzer is a tool that speeds up development while raising quality. Just like testing, static analysis has become an essential part of professional software development. Its value lies in making the process predictable and the outcome aligned with business and user expectations.

Error handling in Go: Common pitfalls

Unicorn Developer — Fri, 08 May 2026 11:10:11 +0000

Developers coming to Go from languages that use try/catch constructs, like Java or C#, may feel a bit turned around. The inner voice suggests using 'recover' with 'defer' as the nearest equivalent, but that's considered bad practice. This article covers why, and looks at common error-handling mistakes in Go.

Introduction

The idea for this article came up spontaneously. Error handling in Go is already well covered, so I wasn't planning to rehash the same points.

But things changed while I was building diagnostic rules for PVS-Studio's new Go analyzer. Testing them on real open-source projects, I kept running into the same error-handling mistakes.

We've written before about how we test the analyzer on large projects from GitHub, but this time, the findings were interesting enough to deserve their own article. Hopefully it saves someone a headache. But first, here's a quick refresher on how error handling works in Go, and the reasoning behind it.

Common approach to error handling in Go

Leaving out try catch wasn't an oversight—it was a deliberate design decision. The authors believe that tying error handling to that control structure makes code more convoluted. It also pushes developers to treat plain errors as exceptions. You can read more about this here.

Take a program that opens a file and modifies it. Various scenarios are possible: a file might exist or might not. Treating a missing file as an exception feels wrong.

Go follows a simple principle: an error is a value. It's an ordinary value that a function returns explicitly, and the caller must explicitly handle it. Look at the example:

file, err := os.Open(filename)
if err != nil {
  // error handling
}

At first glance the code looks verbose, and it's obviously boilerplate. But the upside is that the control flow remains transparent, and the program is easy to read from top to bottom.

But then why do we need panic and recover?

In Go, panic is a sign of that something went unexpectedly wrong. In ways that should never happen in correct code: an out-of-bounds slice index, dereferencing a nil pointer, and so on. The recover mechanism lets us intercept a panic before it brings the whole program down. But using it as try/catch substitute goes against Go idioms and conventions.

That said, catching a panic does have its place. The most common approach is at package or goroutine boundaries, so that a panic doesn't crash the entire program:

func (e *encodeState) marshal(v any, opts encOpts) (err error) {
  defer func() {
    if r := recover(); r != nil {
      if je, ok := r.(jsonError); ok {
        err = je.error
      } else {
        panic(r)
      }
    }
  }()
  e.reflectValue(reflect.ValueOf(v), opts)
  return nil
}

This example comes from the standard json package, specifically the encode.go file. Here, if a panic unwinds the stack up to the top-level function call, the program recovers and returns an expected error value.

So recover is meant to prevent crashes, not to handle business logic.

How to make mistakes when handling errors

So, in Go errors are stored in a variable and checked against nil. It seems simple, but even this straightforward approach leaves room for mistakes. As an example, let's look at the vault project—an open-source tool for managing sensitive data.

func (c *Core) PersistTOTPKey(....) error {
  ks := &totpKey{
    Key: key,
  }
  val, err := jsonutil.EncodeJSON(ks)
  if err != nil {
    return err
  }
  if c.barrier.Put(ctx, &logical.StorageEntry{
    Key:   fmt.Sprintf(....),
    Value: val,
  }); err != nil {
    return err
  }
  return nil
}

The PVS-Studio warning: V8014 Two 'if' statements have identical conditions. The first 'if' statement contains function return, making the second 'if' redundant, or the code contains a logical error. login_mfa.go 1099

In this snippet, the error from jsonutil.EncodeJSON(ks) is checked. Then, the same error is checked again in the next condition:

if c.barrier.Put(ctx, &logical.StorageEntry{
        Key:   fmt.Sprintf(....),
        Value: val,
    }); err != nil {
        return err
    }

Clearly, there's no point in checking the same error twice. Besides, if errl != nil is true, the method will return. The developer most likely intended to capture a value from Put and check it. What's more, the Put method returns an error value that is worth checking:

type Storage interface {
  ....
  Put(context.Context, *StorageEntry) error
  ....
}

So, the fix might look like this:

val, err := jsonutil.EncodeJSON(ks)
if err != nil {
  return err
}
if err := c.barrier.Put(ctx, &logical.StorageEntry{
  Key:   fmt.Sprintf(....),
  Value: val,
  }); err != nil {
    return err
}

The second if block checks the error that Put returns.

In the FerretDB project, which is an alternative to MongoDB, we spot a similar one:

func (h *Handler) msgKillCursors(....) (*middleware.Response, error) {
  ....
  cursorsV, err := getRequiredParamAny(doc, "cursors")
  if err != nil {
    return nil, err
  }

  curArr, ok := cursorsV.(wirebson.AnyArray)
  if !ok {                                             // <=
    msg := fmt.Sprintf(....)
    return nil, lazyerrors.Error(....)
  }

  cursors, err := curArr.Decode()
  if !ok {                                             // <=
    return nil, lazyerrors.Error(err)
  }
  ....
}

The value of the err variable changes here. But instead, the code checks twice if the cursorsV variable is cast to the wirenson.AnyArray type. Most likely, the second !ok was a mistake, and the code should look like this:

cursors, err := curArr.Decode()
if err != nil {
  return nil, lazyerrors.Error(err)
}

This is another piece of code that accidentally re-checks the same error, now in Incus—a manager for virtual machines.

func (d *proxy) Start() (*deviceConfig.RunConfig, error) {
  ....
  err = p.Save(pidPath)
  if err != nil {
    // Kill Process if started, but could not save the file
    err2 := p.Stop()
    if err != nil {
      return fmt.Errorf("....: %s: %s", err, err2)
  }

    return fmt.Errorf("....: %w", d.name, err)
  }
  ....
}

The PVS-Studio warning: V8020 Recurring check. The 'err != nil' condition was already verified on line 407 proxy.go 407

The second condition should obviously check err2 instead of err—err has already been checked and hasn't changed since. Also, err2 appears in the error handling:

return fmt.Errorf("....: %s: %s", err, err2)

So, it makes sense to check it too. PVS-Studio flagged 65 warning of this type in the open-source platform Rancher—more than anywhere else:

func (c *MachineClient) ListAll(opts *types.ListOpts) (....) {
  resp := &MachineCollection{}
  resp, err := c.List(opts)
  if err != nil {
    return resp, err
  }
  data := resp.Data
  for next, err := resp.Next(); 
    next != nil && err == nil; next, err = next.Next() {
    data = append(data, next.Data...)
    resp = next
    resp.Data = data
  }
  if err != nil {
    return resp, err
  }
  return resp, err
}

This one is tricky precisely because it looks right: the loop iterates as long as next != nil and err == nil, then check err != nil after the loop. But there's a catch.

The analyzer points out that the err used inside the loop is not the same err that is checked after it. The err checked after the loop is the original error from the earlier declaration:

resp, err := c.List(opts)

If the loop terminates because err != nil, we'd want to output that error. Instead, the code will return the error from the earlier declaration.

The fix is easy: check err inside the loop and return early. This way, the method returns the error that actually caused the iteration to stop.

The number of repeated warnings is easy to explain: many types require the same code with minor changes, so the old code gets copied along with all its bugs.

I got curious and traced the origins of this code, which lead me to this commit. It adds a whopping 307,251 lines of code, and the comment "Add generated code" settles it. The bug was introduced and then spread across the entire project.

Conclusion

What's the takeaway for today? Go is unquestionably clearer and more explicit about error handling. Still, it's possible to slip up—as the examples from open-source GitHub projects show that. Even in large and popular projects (some have over 30,000 stars), some very ordinary errors persist.

This is a good reminder that no codebase is too big or too well-known to benefit from an extra set of eyes. That's where a static analyzer comes in handy.

We've recently launched the beta test for the new PVS-Studio analyzers coming. You are welcome to join it here! The EAP is available for JavaScript, TypeScript, and Go.

Take care of yourself and your code!

Building a programming language live: it’s time for the parser

Unicorn Developer — Thu, 07 May 2026 15:05:37 +0000

Ever wondered how a parser works? Good news: in this session, we’ll cover exactly that, and build our own expression parser live.

Join the new webinar: Let’s make a programming language. Parser on May 21

Previously, we implemented a lexer: the component that takes raw input and turns it into a sequence of tokens. The recording of that session is coming soon to our website and YouTube channel.

The parser takes that stream of tokens and gives it structure. This is where the grammar of your language really comes to life (if you missed our session on grammars, you can check it out here.)

In our experience, every parser starts with one thing: parsing expressions — so that’s exactly where we’ll begin. We’ll explain what a parser is, walk through the recursive descent approach, and show how to build your own expression parser step by step.

Our speaker, Yuri Minaev, is an experienced C++ developer and static analyzer architect at PVS-Studio. He’s hosted every session in the series and is always happy to answer questions on language design along the way. Don’t hesitate to ask online!

This series is aimed at developers who want to go beyond just using languages and start understanding how they’re built. Whether you’ve been with us from the beginning or are jumping in now, this is a great place to start.

If you missed any of the previous sessions, don’t worry. All registered participants get access to the recordings. You can also catch up on YouTube or the PVS-Studio website.

First talk: Let’s make a programming language. Intro

Second talk: Let’s make a programming language. Grammars

Register now to join us live, ask your questions, and get the most out of the session. Don’t miss the chance to build your own language alongside an experienced developer.

Join the webinar — Let’s make a programming language. Parser on May 21

P.S. Don’t forget to check your inbox and confirm your registration!

What's new in Java 26

Unicorn Developer — Tue, 05 May 2026 11:20:38 +0000

Java keeps evolving! Java 26 is out. The release brings many features aimed at optimizing Java applications and drops support for applets. We cover all of this and more below.

Currently, Java ships a new version every six months. The last release was Java 25 in September 2025, so March 2026 meant it was time for Java 26.

Java 25 was an LTS release; this version, however, isn't designed for long-term support. The new version didn't add as many features as the previous one, but it brought important changes to the language. After all, it's not about quantity :)

So, what's new in Java 26?

JEP 500 Prepare to Make Final Mean Final

The JEP link.

A curious name. What does it mean, though? Here's some background info.

Starting with JDK 5, we can use reflection to change the value of final fields (java.lang.reflect#setAccessible and java.lang.reflect#set). Handy for those who need it (but how often do you modify final fields?). Either way, it's not ideal for two other reasons:

When working with the final field, you expect the primitive object to never change after initialization. But with reflection in the picture, the specs and the actual behavior don't match up.
You can't perform optimizations on final fields. Constant folding is impossible if there's any chance the value or expression in the constant could change.

To eliminate inconsistencies and enable optimization for everything related to final fields, starting with this JEP, developers will gradually lose the option to modify them. How?

In Java 26, the JVM will issue special warnings when the final value is changed. In future versions, attempting to modify the final field will result in an exception.

This approach gives developers time to adapt their applications and libraries to the change. The JVM, on the other hand, will have room for optimization. Also, there will be more consistency for final fields.

JEP 504 Remove the Applet API

The JEP link.

The nine-year saga is coming to an end. Yes, now applets are gone.

Here's the whole timeline of the applet removal:

2017 (JEP 289, JDK 9), applets are marked as Deprecated because browsers no longer support them.
2018 (JDK 11), Appletviewer, which enabled testing applets outside a browser, is removed. No more applet testing in the JDK.
2020 (JEP 398, JDK 17), the applet API is marked with forRemoval=true.
2024 (JEP 486, JDK 24), SecurityManager, which handled security during applet execution, is removed.

So now, in 2026, nine years after the efforts to remove the Applet API began, this whole story has come to its logical conclusion!

They weren't even 33 years old... Gone too soon, never truly understood.

JEP 517 HTTP/3

The JEP link.

Java 11 introduced HttpClient, which replaced the deprecated HttpUrlConnection. It handles HTTP requests using HTTP/1.1 and HTTP/2. The HTTP/3 protocol was standardized in 2022. According to W3Techs, more than a third of web servers already support it.

So, the time has come: this JEP adds support for HTTP/3 requests to HttpClient.

To make client requests use HTTP/3, the proper flag must be explicitly set when configuring HttpClient:

var client = HttpClient.newBuilder()
                       .version(HttpClient.Version.HTTP_3) // <=
                       .build();

Alternatively, you can do the same when configuring the query:

var request = HttpRequest.newBuilder(URI.create("https://openjdk.org/"))
                         .version(HttpClient.Version.HTTP_3) // <=
                         .GET().build();

However, if the target server doesn't support HTTP/3, the request will be downgraded under the hood—first to HTTP/2, and then to HTTP/1.1 if necessary.

The benefits of using HTTP/3 include:

Faster handshakes.
More reliable data transmission.
Fixing the head-of-line blocking issue.

JEP 526 Lazy Constants (Second Preview)

The JEP link.

On to the preview features. This JEP is a direct follow-up to JEP 502: Stable Values. Let's briefly recap what it's about.

These changes will add an API for defining lazy constants. Currently, static constants are initialized when a class is loaded, even if they won't be used until way later (or at all). This JEP will introduce an entity that combines immutability with lazily initialized values—only when accessed.

The advantages include better startup performance and the ability to optimize these values just like constants.

In the second preview:

The API under development has been renamed from StableValue to the higher-level LazyConstant.
Some low-level methods and factories have been removed. Only high-level factories that take values directly remain available.
For optimization purposes, null is no longer allowed as a computed value.

JEP 529 Vector API (Eleventh Incubator)

The JEP link.

If you need a refresher on what the Vector API is, here's a quick overview.

The Vector API enables vector computation to Java at the CPU level and provides data-level parallelism. The goal is to pair raw performance with developer-friendly, high-level API.

What's vector computation?

Vector computation is a way for processors to operate on data vectors using the SIMD (Single Instruction, Multiple Data) architecture, where a single machine instruction is applied in parallel to all elements of the vector.

First, it's worth noting the irony of this JEP staying in the Incubator for the 11th time. Simple math calculations reveal that the feature was first introduced in Java 16 (JEP 338).

According to the authors themselves, there are no significant changes in this particular iteration. This feature is scheduled for release with Project Valhalla, and once that lands, Vector API will be available in Preview. No firm release date yet, but hopefully, it'll be out as soon as possible. After all, both the Vector API and Value Classes sound like cool and niche features.

JEP 530 Primitive Types in Patterns, instanceof, and switch (Fourth Preview)

The JEP link.

That bring us to the final JEP on today's list; the 4th preview of a feature that enables using primitives in pattern-matching constructs with the instanceof and switch.

It may look something like this. The switch statement before:

switch (x.getStatus()) {
    case 0 -> "okay";
    case 1 -> "warning";
    case 2 -> "error";
    default -> "unknown status: " + x.getStatus();
}

The after:

switch (x.getStatus()) {
    case 0 -> "okay";
    case 1 -> "warning";
    case 2 -> "error";
    case int i -> "unknown status: " + i;
}

This fourth preview doesn't introduce any new APIs or features, but it does clarify and expand the way the language behaves with two new things:

Safety of conversion is a formalization that describes possible primitive type conversions for pattern matching (specifying which are safe, which may result in data loss, and which are uncompilable).
Dominance is a compile-time check ensuring that one case branch doesn't dominate another. If it does, Java 26 will now throw a compilation error. As a result, some Java 25 code won't compile in Java 26.

Here are some examples of uncompilable constructs:

byte x = ...;
switch (x) {
    case short s -> {}
    case 42      -> {}   // error: dominated since 42 can be
                         // converted unconditionally exactly to short
}

Or:

int x = ...;
switch (x) {
    case int _      -> {}  // unconditional pattern
    case float _    -> {}  // error: dominated
}

Summary

Java 26 didn't ship a ton of new features or APIs on its own. Still, this update brought quite a few changes that enhanced what's already there. The final modifier, Lazy Constants, and everything else are part of the ongoing trend toward optimizing Java program execution.

It's great that Java is never standing still. The optimizations, the ongoing API work, and everything in between are a clear sign that Java is more alive than ever and still going strong.

You can find the original descriptions of all the changes here. If you'd like to read our previous reviews of new Java versions, check out the list below:

Silent foe or quiet ally: Brief guide to alignment in C++. Part 3

Unicorn Developer — Thu, 30 Apr 2026 11:34:09 +0000

We've already covered basic field alignment and explored how inheritance layers data atop one another. By now you might think we have uncovered every trap. But not so fast! This topic has a truly dark side that few discuss. One short word—virtual—completely rewrites a class "geometry," introducing alignment corrections we can't ignore. Let's find out what really happens under the hood when alignment meets virtuality.

Introduction

We continue our deep dive into memory mechanics. If you are just joining us, I recommend reviewing the foundations first. The first part covered the basics and the magic of simple data alignment, while the second part focused on how ordinary inheritance affects memory layout.

So far, we've treated an object as a static, rigidly determined data structure. Every field address was known at compile time, and inheritance simply layered parent and child attributes. Alas, object-oriented programming is impossible without dynamic polymorphism, which is implemented in C++ via the RTTI mechanism and virtual functions.

What is virtuality?

Let me start from an off-topic question. How does the compiler know which piece of machine code to execute at a specific line in your program? Answering this question will help us understand what virtuality really means.

Imagine we write object.print(). For the processor, it's not an abstract action but a command to jump to a certain address in memory with some function instructions. But where do we take that address from?

During compilation, each code line becomes one or more machine instructions, each receives a unique sequential address in memory. The same applies to functions. A compiler translates them into machine code and assigns the next available address. Stitching a function call in code to its actual memory address is called binding.

Depending on when the call address is bound to the function address, there are two scenarios.

1. Static/early binding.

By default, static (early) binding is used. A compiler rigidly "hardwires" a specific function address at the call place in code during compilation. This decision relies solely on the pointer or reference type, not the actual object in memory. For instance, when a compiler sees a Base* pointer, it chooses the method address from the base class. It's fast and requires no additional evaluations. So, the jump goes to an already known address. It's also efficient, but it makes the program inflexible at runtime.

2. Dynamic/late binding.

Unlike static binding, dynamic (late) binding postpones function selection until the program runs. In this case, a compiler can't insert a specific function address into the code in advance. Instead, it generates a special instruction: "At the moment of call, look inside the object, find the current address of the needed function, and only then jump." This provides tremendous flexibility: the program makes decisions on the fly based on which object is currently in front of it (a derived class or a base class), rather than on the pointer type we are using.

Now that we've covered the mechanics of binding, we can answer the question of what virtuality actually is. Virtuality is a mechanism that implements dynamic polymorphism based on late binding. By marking a method with the virtual keyword, we shift it from static binding to late binding. From this point on, the address of the function's entry point is no longer a compile-time constant but a variable whose value derives from the context of a specific object at runtime.

The C++ standard doesn't specify how virtuality must be implemented, but de facto it follows the rules of specific ABIs (Itanium ABI, MSVC ABI). The key components here are the vtable (Virtual Method Table) and vptr (Virtual Pointer).

Virtual functions

We have unpacked the concept of virtuality, but in practice the main tool for its implementation is the virtual function. Let's see how it works.

Here's a simple class hierarchy where we attempt to override a parent method in a derived class:

class Base
{
public:
  std::string_view NameClass() const {return "Base";}  
};

class Derived : public Base
{
public:
  std::string_view NameClass() const {return "Derived";}
};

Full code fragment

#include <iostream>
#include <format>
#include <string_view>

class Base
{
public:
  std::string_view NameClass() const {return "Base";}  
};

class Derived : public Base
{
public:
  std::string_view NameClass() const {return "Derived";}

};

int main()
{
  Derived derived {};
  Base& base {derived};

  std::cout << "=== Name class ===\n";
  std::cout << "Base has static type " << base.NameClass() <<"\n";
}

Program output
Compiler Explorer

=== Name class ===
Base has static type Base

The result may seem strange. We created a Derived object, but the program insists it's Base. Early bonding is to blame here. The compiler sees the Base& reference and determines the method call at build time. From its perspective, this is a safe and fast optimization—it doesn't have to check what type of object the reference points to while the program is running.

Let's move the decision from compile time to runtime by adding just one word—virtual:

class Base
{
public:
  virtual std::string_view NameClass() const {return "Base";}  
};

class Derived : public Base
{
public:
  std::string_view NameClass() const override {return "Derived";}
};

Full code fragment

#include <iostream>
#include <format>
#include <string_view>

class Base
{
public:
  virtual std::string_view NameClass() const {return "Base";}  
};

class Derived : public Base
{
public:
  std::string_view NameClass() const override {return "Derived";}

};
int main()
{
  Derived derived {};
  Base& base {derived};

  std::cout << "=== Name class ===\n";
  std::cout << "Base has static type " << base.NameClass() <<"\n";
}

Program output
Compiler Explorer

=== Name class===
Base has static type Derived

Seems like it worked out. Despite the reference, the program now sees the object real type in memory. Dynamic binding kicks in: the function address selection occurs at runtime.

Now we can move on to the definition. A virtual function is a class method that is called not based on a reference or pointer type, but on the actual type of the object in memory. The virtual keyword instructs the compiler to replace a direct function call with a dynamic dispatch. This way, a derived class can override the implementation of a base class while maintaining the same structure.

We'll focus on the pros and cons of virtual functions later, but first note: the C++ standard describes the expected behavior of virtual functions but leaves implementation details to compiler developers. But the vast majority of modern compilers (GCC, Clang, MSVC) use a mechanism that has become the default standard: virtual function tables.

Virtual function table (vtable)

A virtual table (vtable, virtual method table, dispatch table) is a static array of pointers that the compiler creates for each class that uses virtual functions (or inherits from such classes).

Let's start with a piece of theory. How does a vtable work?

The compiler creates the table once per class at compile time, not per object.
Each table entry points to an address of the most derived function available to that class. If a derived class overrides a function, its table stores its own version's address; if not—it stores the base class version's address.
Each class in the inheritance hierarchy receives its own unique vtable.
The table itself is only a static structure in memory. To ensure that a specific object knows which table to use, the compiler implicitly adds a hidden field—vptr—to every instance of the class. The constructor initializes it and links the object to its vtable. More on this later.
The compiler strictly determines the function order in the table at compile time. For example, if funcA() is listed first in the base class, it occupies the first index in all derived class tables. As a result, the program finds the desired address in constant time O(1) simply by adding the offset to the table address.
Besides function addresses, the vtable often contains a pointer to a structure with type information (Run-Time Type Information, RTTI). This ensures correct functioning of operators that check the actual object type directly during program execution.
If a polymorphic class is designed correctly, one of the entries in its vtable is always reserved for the destructor. This guarantees that deleting an object via a base class pointer calls the destructor chain of all derived classes to prevent memory leaks.

The chart below illustrates the process:

What have we got here? A memory-level architecture of dynamic polymorphism. The linking element is the vptr, which is a hidden 8-byte pointer at the beginning of the class that redirects calls to the vtable. In this table, the negative index stores type metadata (RTTI), while the zero index stores the address of the virtual destructor. The remaining entries contain physical addresses of the functions. This fixed order is crucial, as calling any method boils down to two operations: reading from and writing to memory.

When the code contains a call to a virtual function via a pointer or a reference to the base class, the following steps execute:

The program accesses a class instance and, through its hidden pointer, finds the corresponding virtual table for its actual type.
The program selects the required entry in the table, since the compiler already knows the function index.
The program extracts the function address from that entry.
The program performs an indirect call to the function at the found address.

Theory always looks bright and shiny, but now let's see how it works in practice:

class Base
{
public:
  virtual ~Base() {};
  virtual void func1() {}
  virtual void func2() {}
};

class Derived : public Base
{
public:
  void func1() override {}
};

class Derived1 : public Base
{
public:
  void func2() override {}
};

Here's a common scenario: we've designed a base interface called Base and created its subclasses. Each child class overrides some virtual functions. Logically everything is simple and clear, but let's look under the hood.

Note: all examples use the Clang compiler.

/* vtable has 3 entries: {
       [0] = ~Base((null)), 
       [2] = func1((null)), 
       [3] = func2((null)), 
    } */

At first glance it seems strange that the first index is skipped, but it's correct. The issue here is the destructor, which can be called in two different contexts:

a complete object destruction—deleting an object via delete;
a deleting destruction—deleting an object via a base class pointer.

The compiler must distinguish these two situations: it creates two entry points in the virtual table. That is why there is no first index—the destructor occupies it. Such behavior is the result of the Itanium ABI. Ordinary virtual functions follow two slots for a destructor.

If we add the -Xclang -fdump-record-layouts flag in Compiler Explorer, we get the following table output:

 vtable for Derived:
        .quad   0
        .quad   typeinfo for Derived
        .quad   Derived::~Derived() [base object destructor]
        .quad   Derived::~Derived() [deleting destructor]
        .quad   Derived::func1()
        .quad   Base::func2()

From the table we see that the destructor was created in two contexts.

Full code fragment
Compiler Explorer

#include <iostream>

class Base
{
public: 
  virtual ~Base() {};
  virtual void func1() {}
  virtual void func2() {}
};

class Derived : public Base
{
public:
  void func1() override {}
};

class Derived1 : public Base
{
public:
  void func2() override {}
};

Base bs;
Derived dr;
Derived1 dr1;

We've now figured out how the compiler constructs the table of functions and sets the indices in a static array. A virtual table is simply a passive data structure that exists as a single instance for the entire class. It's just stored in memory. For polymorphism to work, we need a virtual pointer.

Virtual pointer (vptr)

The vptr (virtual methods table pointer) is a hidden data member (a pointer) that the compiler automatically adds to any base class containing at least one virtual function. It points to the static table of function addresses (vtable) corresponding to the object specific type at runtime.

How the pointer works

Let's delve a bit into the mechanics. The vptr's operation forms the foundation of dynamic polymorphism in object-oriented languages.

class Base
{
public:
  virtualTable *vptr;
  virtual void func1() {}
  virtual void func2() {}
};

class Derived : public Base
{
public:
  void func1() override {}
};

class Derived1 : public Base
{
public:
  void func2() override {}
};

Let's take the same code and add the virtual pointer at the beginning. It follows three fundamental stages.

preparing infrastructure at compile time;
dynamic initialization during object construction;
dispatching calls in real time.

You can see our code represented in the following chart:

When compiling code with virtual functions, the compiler adds a hidden vptr pointer to each object, referencing the virtual function table. For the Base class, it creates a vtable with the addresses of its virtual methods. In derived classes (Derived, Derived1), the compiler replaces the addresses of overridden methods in the table while saving fixed indices for each method. This completes the first stage.

Now we create a class instance via calling:

Base* bs = new Derived();

We are launching a layer-by-layer initialization process that transforms memory into a polymorphic object. First, a block of memory is allocated to store the object data and vptr. The parent class constructor runs first and writes the address of its table into the pointer.

Then the control passes to the Derived constructor. It performs a key operation—it overwrites the pointer value, substituting the address of its own table:

vtable for Derived:
        .quad   0
        .quad   typeinfo for Derived
        .quad   Derived::~Derived() [base object destructor]
        .quad   Derived::~Derived() [deleting destructor]
        .quad   Derived::func1()
        .quad   Base::func2()

By the time all constructors are done, the object becomes stable. Its internal pointer is now firmly linked to the table of the lowest class in the hierarchy. This guarantees that any polymorphic call uses the method version corresponding to an object real type, not the pointer type. We can call this process dynamic initialization during object construction.

When bs->func1() is executed, a dynamic call dispatch mechanism (based on the principle of late binding) triggers. The compiler generates the code that ignores the static type of the Base* pointer and instead extracts the current pointer value from the object memory. It contains the address of the actual virtual table for the real dynamic type. The vtable is then indirectly accessed via the vptr. Using a fixed offset in that table, the program gets the address of the required method implementation. The processor jumps to that address, ensuring the call of the overridden method from Derived rather than the base implementation.

Full code fragment
Compiler Explorer

#include <iostream>

class Base
{
public:
  virtual ~Base() {};
  virtual void func1() {}
  virtual void func2() {}
};

class Derived: public Base
{
public:
  void func1() override {}
};

class Derived1: public Base
{
public:
  void func2() override {}
};

int main()
{
  Base* bs = new Derived();
  bs-> func1();
}

Now that we understand how the vptr enables polymorphism, we should look at its physical impact on the object. Since the pointer is a full-fledged field within the structure, its presence inevitably adjusts memory topology. Let's break down how introducing this pointer triggers alignment mechanisms and affects the structure final size in bytes.

The alignment and vptr

In modern 64-bit systems, the virtual pointer occupies 8 bytes. According to most ABI specifications, data must align to an address that is a multiple of its own size. So, the virtual pointer requires 8-byte alignment.

How does this affect offsets? Since the pointer field takes the first 8 bytes, we can't arbitrarily place any following field—the compiler must adhere to the alignment rules for each data type within the structure.

Let's recall how field placement works. If the vptr is followed by a type with a lower alignment requirement, such as char, it will occupy the next byte. However, if it is followed by a type that requires 4 or 8 bytes, the compiler will insert padding to align the address of the next field. Let's look at the example:

class Example
{
public:  
  virtual void func() {}
  char c;
};

What is its alignment? Mathematically the size would be 9 bytes, but there's a catch. The answer is 16 bytes.

*** Dumping AST Record Layout
         0 | class Example
         0 | (Example vtable pointer)
         8 |  char c
           | [sizeof=16, dsize=9, align=8,
           |  nvsize=9, nvalign=8]

The final size arithmetic is straightforward: 8 bytes for the pointer, 1 byte for data, and 7 bytes for final alignment. But to figure out how this object will behave within the inheritance hierarchy, we need to interpret the specification generated by the compiler. What do the terms dsize, nvsize, and nvalign mean? Let's break them down.

sizeof is the final object size in bytes.
dsize is the actual memory volume used by useful data. We put it together using 8 bytes of vptr and 1 byte of char. Basically, this is the raw size of the object state before the final alignment rules are applied.
align is the address alignment requirement for the object in memory. Since the most restrictive type in the class is an 8-byte pointer, the entire object is assigned an alignment attribute of 8.
nvsize is the size of the "non-virtual" part of the class. In the context of single inheritance, this refers to the amount of memory occupied by a class when it serves as the base class for another. In our example, it matches dsize because the hierarchy is simple.
nvalign is the alignment that a derived class must maintain when placing its own fields.

Armed with this solid foundation, we can now dive into a really dark topic—inheritance.

Inheritance and virtuality

The diamond problem

Look at the following example:

class Entity
{
public:
  int id;
  virtual void update();
};

class Movable: public Entity 
{
public:
  float velocity;
  void move() {}
};

class Renderable: public Entity
{
public:
  int textureId;
  void draw();
};

class Player: public Movable, public Renderable
{
public:
   char name[32];
};

At first glance, this appears logical and well-structured. Let's try using this class in code and see the result.

Creating a Player object and looking at its memory layout reveals something strange:

Player hero;
*** Dumping AST Record Layout
         0 | class Player
         0 |   class Movable (primary base)
         0 |     class Entity (primary base)
         0 |       (Entity vtable pointer)
         8 |       int id
        12 |     float velocity
        16 |   class Renderable (base)
        16 |     class Entity (primary base)
        16 |       (Entity vtable pointer)
        24 |       int id
        28 |     int textureId
        32 |   char[32] name
           | [sizeof=64, dsize=64, align=8,
           |  nvsize=64, nvalign=8]

Instead of carefully combining properties from all ancestors, the compiler literally "glues" two complete structures: Renderable and Movable. The diagram shows the class relationships:

The problem is that both parent classes already contain a full copy of the Entity base class. As a result, there are two independent Entity instances within a single Player object. Each has its own vptr and its own id field. From the perspective of binary structure, the object is redundant: it doesn't simply inherit functionality, but physically duplicates the state of the base class in different segments of its memory.

This structural issue pops up at the worst possible moment—when we try to simply access a player's ID:

hero.id = 1;

The compiler hits a dead end. It sees that the hero object has two paths to the id field:

via the movement branch (Movable);
via the rendering branch (Renderable).

In memory these fields exist separately from each other: the program can't guess which identifier we intend to modify. We end up with an object with an inconsistent internal state: one memory area allocated for Entity (via Movable) may store the value id = 1, while the second area (via Renderable) remains uninitialized or contain a different value. Since these are two physically distinct address-space locations, writing to one has no effect on the other. This situation is called the diamond problem.

Full code fragment
Compiler Explorer

#include <iostream>

class Entity
{
public:
  int id;
  virtual void update();
};

class Movable : public Entity 
{
public:
  float velocity;
  void move() {}
};

class Renderable : public Entity
{
public:
  int textureId;
  void draw();
};

class Player : public Movable, public Renderable
{
public:
  char name[32];
};

int main()
{
  Player hero;
  hero.id = 1;
}

To eliminate this redundancy and restore consistency, we should use virtual inheritance:

class Entity
{
public:
  int id;
  virtual void update()
  {
    std::cout << "Entity update, ID " << id << std::endl;
  }
};

class Movable : virtual public Entity 
{
public:
  float velocity;
  void move()
  {
    std::cout << "Moving with velocity " << velocity << std::endl;
  }
};

class Renderable : virtual public Entity
{
public:
  int textureId;
  void draw()
  {
    std::cout << "Drawing texture " << textureId << std::endl;
  }
};

class Player : public Movable, public Renderable
{
public:
  char name[32];
  void update() override 
  {
    std::cout << "Player " << name << " updating ... " << std::endl;
  }
};

In that case, the compiler changes the algorithm to construct the object. Instead of statically embedding Entity data into each branch, it allocates a single shared memory area for the base class. Now the final Player object will contain only one instance of id and one set of virtual methods regardless of the number of intermediate classes. This area is accessed via additional offset pointers, ensuring the object logical and physical unity.

Full code fragment
Compiler Explorer

#include <iostream>
#include <cstring>

class Entity
{
public:
  int id;
  virtual void update()
  {
    std::cout << "Entity update, ID " << id << std::endl;
  }
};

class Movable: virtual public Entity 
{
public:
  float velocity;
  void move()
  {
    std::cout << "Moving with velocity " << velocity << std::endl;
  }
};

class Renderable: virtual public Entity
{
public:
  int textureId;
  void draw()
  {
    std::cout << "Drawing texture " << textureId << std::endl;
  }
};

class Player: public Movable, public Renderable
{
public:
  char name[32];
  void update() override 
  {
    std::cout << "Player " << name << " updating ... " << std::endl;
  }
};

int main()
{
  Player hero;

  hero.id = 1;
  hero.velocity = 6.5f;
  hero.textureId = 1;
  std::strcpy(hero.name, "Tom");

  hero.update();
  hero.move();
  hero.draw();
}

Program output

Player Tom updating ... 
Moving with velocity 6.5
Drawing texture 1

Virtual inheritance mechanisms: vbptr, vbtable, VTT

Virtual inheritance disrupts the usual linear memory layout. The compiler once knew the exact address of the id field from the start of the object, but now that certainty is lost. The virtual base becomes a dynamic component: one day it's a part of Player, another day —a part of Movable. Its exact location in memory depends on a specific hierarchy in which the final object was built.

To avoid guessing addresses, the compiler introduces an indirect addressing mechanism via the vbptr (virtual base pointer) and vbtable (virtual base table). Each intermediate class that virtually inherits a base receives a hidden pointer—the vbptr. It serves as an entry point to a static offset table (vbtable) that the compiler generates for a specific type whose object contains this vbptr.

The table stores integer values that define the exact distance from the current vbptr position to the start of the parent's virtual base. Therefore, any access to a field transforms into the following algorithm:

read the address from the vbptr;
extract the needed offset from the vbtable;
add the current object address and the retrieved offset to get the final physical data address.

Now that we understand how the process goes, we can provide definitions.

vbptr (virtual base pointer) is a hidden system pointer that the compiler inserts in the layout of a derived class. It acts as a dynamic reference to an offset table, enabling an object to determine at runtime, where its virtual ancestor locates in the current memory configuration.

vbtable (virtual base table) is a static data structure that the compiler generates for each type that uses virtual inheritance. This structure is an array of integer values that specify the exact distance in bytes from the vbptr to the start of each virtual base subobject.

Regular polymorphism and virtual inheritance are often confused, here is a table to show the difference:

After reviewing the comparison table and understanding how individual pointers work, a question arises: how does this complex machinery spring into action? If the vtable and vbtable are static tables, then when creating an object, we need a mechanism that will correctly set all the pointers to their proper locations. In complex hierarchies with virtual inheritance, the VTT (Virtual Method Table Hierarchy Table) plays this role within the Itanium ABI.

A VTT is a data structure that can be informally described as a "table of tables."While a regular virtual table stores function addresses, a VTT stores the addresses of the virtual tables that are needed for a specific inheritance branch. The key technical task of the VTT is to ensure correct object behavior during that borderline moment when the base class constructor has already launched but the derived class constructor hasn't finished yet. Without this mechanism, calling a virtual function or accessing virtual base data from a constructor could result in a crash. It's because the object isn't fully built yet and its pointers may reference incorrect or empty areas.

The VTT operation follows this algorithm.

When the most derived class constructor is called, the compiler secretly passes it the address of the corresponding VTT as an argument.
The compiler reads the addresses of the initial and secondary virtual tables from the VTT and writes them to the vptr and vbptr of the current object.
When constructors of base classes are called, they receive not the entire VTT but only a pointer to its specific fragment for the relevant branch.
The base class uses the received fragment to temporarily adjust the object pointers ensuring that, for the duration of its constructor, the object behaves as an instance of that specific base class.

Now that we've figured out who's responsible for what, we can move on to alignment in the virtual environment.

The pitfalls of virtual inheritance

Pointer casting

Let's look at the challenges we might face with virtual inheritance. The first issue surfaces when we cast a pointer from a derived class to its base types. We are used to thinking of a pointer to an object as a static label that points to the start of a memory block. However, multiple and virtual inheritance introduce their own complications.

Look at this example:

struct Parent1
{
  int num;
  virtual ~Parent1() {}
};

struct Parent2
{
  int num2;
  virtual ~Parent2() {} 
};

struct Derived : Parent1, Parent2
{
  int res;
};

Here we have a classic scenario of multiple inheritance: two parents and one child. Let's output their addresses.

Full code fragment
Compiler Explorer

#include <iostream>
#include  <cstring>

struct Parent1
{
  int num;
  virtual ~Parent1() {}
};

struct Parent2
{
  int num2;
  virtual ~Parent2() {} 
};

struct Derived : Parent1, Parent2
{
  int res;
};

int main()
{
  Derived* d = new Derived();
  Parent1* p1 = d;
  Parent2* p2 = d;

  std::cout << "Derived address: " << d << std::endl;
  std::cout << "Parent1 address: " << p1 << std::endl;
  std::cout << "Parent2 address: " << p2 << std::endl;
}

Program output

Derived address: 0x55b3bf4b92b0
Parent1 address: 0x55b3bf4b92b0
Parent2 address: 0x55b3bf4b92c0

If we run this code, we'll see something strange: the addresses of Derived and Parent2 differ. Here we see a fundamental peculiarity: the same object can have different addresses depending on the type of pointer used to access it.

We expect that a pointer to an object always points to the start of the corresponding subobject in memory. Since Derived contains Parent1 and Parent2, they can't share the same location. The compiler places them one after another.

Thus, when we wrote Parent2* p2 = d; more than just bit copying occurred—the compiler performed a pointer adjustment. It took the address of the Derived start and added an offset so that p2 would point only to the beginning of the data related to Parent2. In ordinary multiple inheritance this offset is static, but when virtuality enters, the situation becomes dynamic.

The order of base classes in memory can change depending on the hierarchy.
The compiler can no longer add +16 bytes to the code.
The compiler generates code that accesses the vbtable, gets the current offset for the object type, and adds it to the address.

What's going on with the alignment here? It also makes its own changes:

*** Dumping AST Record Layout
         0 | struct Derived
         0 |   struct Parent1 (primary base)
         0 |     (Parent1 vtable pointer)
         8 |     int num
        16 |   struct Parent2 (base)
        16 |     (Parent2 vtable pointer)
        24 |     int num2
        28 |   int res
           | [sizeof=32, dsize=32, align=8,
           |  nvsize=32, nvalign=8]

Parent1 is located at the very beginning (at offset 0), but instead of the expected 4 bytes for int num, it takes up 16. The reason is the virtual destructor that forces the compiler to insert an 8-byte vptr and add 4 bytes of padding after the num field so that the next object starts at the correct address.

The second base, Parent2, starts exactly at byte 16—this is the very offset we've seen in the code (p2 != d). It also receives 8 bytes for its own virtual pointer and 4 bytes for data. The structure ends with the res field of the Derived class. The final object size is 32 bytes, even though the sum of useful data and pointers gives only 28. The extra 4 bytes are added at the end to comply with the align=8 rule. The entire object must be a multiple of its most stringent member—the 8-byte pointer.

Let's see what other surprises alignment may have in store.

Casting to void*

Let's go over a situation that often comes up when working with low-level code. We need to pass the complex Derived object to the callback function via a raw void* pointer. So, we pack it into an unaddressed container. Then, in the handler, we try to extract it back as the Parent2 base class. At first, it seems simple, but not when it comes to virtual inheritance. Let's complete the previous code fragment:


void process_callback(void* raw_data)
{
  Parent2* broken_p2 = (Parent2*)raw_data;
  std::cout << "--- The result of a void cast ---" << std::endl;
  std::cout << "Original void* address: " << raw_data << std::endl;
  std::cout << "Broken Parent2 address: " << broken_p2 << " (Not offset)" <<
std::endl;
}

Look at the program output.

Program output

--- The result of a void cast ---
Original void* address: 0x5baf237792b0
Broken Parent2 address: 0x5baf237792b0 (Not offset)

When we run this code, we'll see that broken_p2 points to the same address as the start of the entire object, even though the Parent2 data is offset in memory. void* completely "blinds" the compiler, erasing all information about subobjects' location. When attempting to restore Parent2* directly from void, the compiler incorrectly interprets that the data for this parent starts right at the void*address. In reality, Parent2 is separated from the object start by service pointers and alignment bytes.

As a result, broken_p2 becomes invalid: it ignores the necessary pointer adjustment, and any attempt to read a field returns garbage. The whole mechanism relies on precise byte calculations and technical padding. Casting through void* ignores these gaps, causing the program to read data with a shift.

How can we fix this? We need the compiler to see the correct offsets again. To do this, the pointer has to be restored in stages:

void process_callback(void* raw_data)
{
  Parent2* broken_p2 = (Parent2*)raw_data; 

  Derived* restored_d = (Derived*)raw_data;
  Parent2* safe_p2 = restored_d; 

  std::cout << "--- The result of a void cast ---" << std::endl;
  std::cout << "Original void* address: " << raw_data << std::endl;
  std::cout << "Broken Parent2 address: " << broken_p2 << " (Not offset)" <<
  std::endl;
  std::cout << "Safe Parent2 address: " << safe_p2 << " (Offset)" << std::endl;

}

Instead of attempting a direct leap from untyped memory straight to a base class, we should first return the pointer to its original full type—Derived*. At this stage, the compiler restores the memory layout context of the entire object. It again sees the boundaries of all subobjects, the presence of service pointers, and the current offset tables. Only then, upon the next cast to Parent2*, does the pointer adjustment mechanism activate. The compiler refers to the type metadata (including the vbtable in the case of virtual inheritance), takes alignment requirements into account, and calculates the final effective address of the needed data segment.

Full code fragment
Compiler Explorer

#include <iostream>
#include  <cstring>

struct Parent1
{
  int num;
  virtual ~Parent1() {}
};

struct Parent2
{
  int num2;
  virtual ~Parent2() {} 
};

struct Derived : Parent1, Parent2
{
  int res;
};

void process_callback(void* raw_data)
{
  Parent2* broken_p2 = (Parent2*)raw_data; 

  Derived* restored_d = (Derived*)raw_data;
  Parent2* safe_p2 = restored_d; 
  std::cout << "--- The result of a void cast ---" << std::endl;
  std::cout << "Original void* address: " << raw_data << std::endl;
  std::cout << "Broken Parent2 address: " << broken_p2 << " (Not offset)"
<<std::endl;
  std::cout << "Safe Parent2 address: " << safe_p2 << " (Offset)" << std::endl;

}

int main()
{
  Derived* d = new Derived();
  process_callback((void*)d);
  return 0;
}

Empty Base Optimization with virtual

In the first part we covered Empty Base Optimization (EBO). By the standard, the size of any object can't be zero, so even a completely empty class takes 1 byte in memory. In ordinary inheritance, the compiler can collapse that byte so that the empty base class doesn't bloat the derived class size. We do remember that. But as soon as virtuality enters the hierarchy, this optimization fails.

Here comes a spoiler alert: Clang worked wonders with optimization and managed to optimize everything. It places all empty classes at offset zero, effectively hiding them inside the vtable pointer. So, for this example, we set Clang aside and turn to MSVC to take a look at this code:

class Empty1 {};
class Empty2 {};
class Empty3 {};

class Root : virtual public Empty1
{
  int r;
};

class Root1 : virtual public Empty2
{
  int r1;
};

class Root2 : virtual public Empty3
{
  int r2;
};
class Base : virtual public Root, virtual public Root1, virtual public Root2
{
public:
  double X;
  char symbol;
  virtual void service() {}
};

Let's check the size of the Base class.

Program output

sizeof(Empty): 1 byte
sizeof(Base): 96 byte

We can put it like this:

Compiler Explorer layout

class Base  size(96):
  +---
 0  | {vfptr}
 8  | {vbptr}
16  | X
24  | symbol
    | <alignment member> (size=7)
    | <alignment member> (size=4)
    | <alignment member> (size=4)
  +---
  +--- (virtual base Empty1)
  +---
  +--- (virtual base Root)
32  | {vbptr}
40  | r
    | <alignment member> (size=4)
  +---
  +--- (virtual base Empty2)
  +---
  +--- (virtual base Root1)
56  | {vbptr}
64  | r1
    | <alignment member> (size=4)
  +---
  +--- (virtual base Empty3)
  +---
  +--- (virtual base Root2)
80  | {vbptr}
88  | r2
    | <alignment member> (size=4)
  +---

The object has bloated to 96 bytes, even though its useful payload barely reaches a third of that volume. At the object's start we see the standard "head": 8 bytes for the vfptr (pointer to the function table) and another 8 bytes for the vbptr (pointer to the base table). Then comes the data double X, which due to its size imposes strict 8-byte alignment on the entire structure. But the most interesting part begins after the char symbol field. Instead of packing data more tightly, the compiler inserts massive blocks of alignment members (technical voids of 7 and 4 bytes) to make sure that each following virtual base starts strictly on a clean eight-byte boundary.

The object turns into a chain of virtual databases (Root, Root1, Root2), each of them comes at a high cost. Instead of collapsing Emptyclasses as Clang did, MSVC allocates a separate vbptr for each navigation branch. As a result, each such section consumes 16 to 24 bytes: 8 bytes for the service pointer, 4–8 bytes for the data, and a required padding to maintain symmetry.

The net result is a structure where real variables literally drown in service pointers and gaps.

Full code fragment
Compiler Explorer

#include <iostream>
#include  <cstring>

class Empty1 {};
class Empty2 {};
class Empty3 {};

class Root : virtual public Empty1
{
  int r;
};

class Root1 : virtual public Empty2
{
  int r1;
};

class Root2 : virtual public Empty3
{
  int r2;
};
class Base : virtual public Root, virtual public Root1, virtual public Root2
{
public:
  double X;
  char symbol;
  virtual void service() {}
};

int main()
{
  std::cout << "sizeof(Empty): " << sizeof(Empty1) << " byte" << std::endl;
  std::cout << "sizeof(Base): " << sizeof(Base) << " byte" << std::endl;
  return 0;
}

Performance impact

Having covered theory and examples, we should discuss the cost of virtual inheritance—specifically, how it affects processor performance through cache misses.

We know that data location is crucial in system programming. The more tightly the fields are packed in memory, the higher the probability that the processor loads them into cache in a single fetch. Virtual inheritance, however, deliberately destroys this density. Since the virtual base subobject is forcibly placed at the very end of the layout, while its controlling vbptr locates at the beginning, the data of one logical object becomes split across different cache lines. The processor must repeatedly access main memory, causing execution delays.

On top of all that, there's also an issue of alignment. To ensure consistent pointer access, the compiler inserts extra empty bytes. We end up with an object with holes. When processing such objects, the processor is forced to use memory bus bandwidth to transfer unnecessary alignment bytes along with the useful data. As a result, the cache can't hold all the useful information.

If we work with large arrays of data, things worsen even more. In an ordinary class, fields lie in a dense block, and the processor reads them in a single linear pass. With virtual inheritance, this integrity gets lost: the base class data is moved to the very end of the structure, while only a pointer to the offset table (vbptr) remains at the beginning.

So, to access any database field, the processor must first access the vbptr, calculate the address using a table, and only then jump to the data itself at the end of the object. These constant computations and memory jumps between service pointers and scattered fields deprive the program of caching advantages and multiply array processing slowdowns.

Is virtuality worth it?

We see that using the word virtual can easily bloat our object memory footprint, confuse our code, and introduce various errors. Here comes the question: why do we really need it?

On the one hand, virtual inheritance and virtual functions are fundamental design tools. They enable designing flexible, extensible systems, and solve the diamond problem. In complex architectures, the convenience of polymorphism and clean hierarchies often outweighs the loss of a few dozen bytes. It helps us think in terms of abstractions rather than memory addresses.

On the other hand, architectural flexibility comes at a hardware cost. As we've seen, virtuality transforms compact structures into bulky objects with memory holes. Also, double indirect addressing via the vbtable can become a bottleneck in critical paths of game engines. Yet we wouldn't recommend abandoning this mechanism. In practice, context determines the choice.

If the logic inside a virtual function is complex and lengthy, the microscopic delay of looking up an address in a table becomes negligible and simply dissolves in the overall execution time. Moreover, when it comes to a vast number of derived classes, attempting to replace polymorphism with manual type checking via switch or if-else often proves slower than a direct table jump. Alternatives like CRTP, which promise free static typing, quickly turn into unmaintainable monsters in multiple inheritance scenarios.

In such hierarchies, standard virtuality remains the lesser evil, delivering clean code at an acceptable price. In the end, the choice between static and dynamic structure is always a search for balance.

Conclusion

So, we've come a long way and made sure that virtuality and alignment are an inseparable pair that dictate the physical structure of an object. Understanding these mechanisms transforms abstract classes into a precise architectural layout, where every byte and every offset falls under engineering control. This enables us to strike a balance between the flexibility of dynamic polymorphism and execution efficiency.

To ensure that your code remains under full control and that complex hierarchies create no hidden memory issues, you're welcome to use our static analyzer.

AI integrations: Rely or verify? Checking Semantic Kernel

Unicorn Developer — Thu, 23 Apr 2026 12:48:25 +0000

Semantic Kernel is a Microsoft's SDK for integrating AI models into applications. Can PVS-Studio static analyzer find defects in the source code of a project like this? This article answers this question. Enjoy reading!

Projects that involve AI integration increasingly shape everyday development. One such project is Semantic Kernel. It's an SDK for building AI agents and orchestrating LLM scenarios, and Microsoft actively develops it.

But underneath even the most modern solutions, you'll find ordinary C# code—with all the usual problems that come with it. We'll try to confirm that today.

To analyze the C# part of the project, we used PVS-Studio static analyzer version 7.41. The source code we checked corresponds to this commit.

Note that we'll only discuss the most interesting code snippets to keep the article concise.

Let's start breaking down suspicious spots!

Misplaced priorities

Code snippet 1

internal static async Task 
                CreateToolsAsync(this AgentDefinition agentDefinition,
                                 BedrockAgent agent, 
                                 CancellationToken cancellationToken)
{
  ....
  if (knowledgeBase.Options
                   ?.TryGetValue(KnowledgeBaseId, 
                                 out var value) ?? false && value is not null 
                                                         && value is string)
  {
    var knowledgeBaseId = value as string;
    var description = knowledgeBase.Description ?? string.Empty;
    await agent.AssociateAgentKnowledgeBaseAsync(knowledgeBaseId!, 
                                                 description,
                                                 cancellationToken)
               .ConfigureAwait(false)
  }
  ....
}

The PVS-Studio warning: V3177 The 'false' literal belongs to the '&&' operator with a higher priority. It is possible the literal was intended to belong to '??' operator instead. BedrockAgentDefinitionExtensions.cs 44

The developer likely intended this condition to work as follows: if knowledgeBase.Options?.TryGetValue(KnowledgeBaseId, out var value) is not null then check that value is not null && value is string. But the actual behavior differs. The && operator takes higher priority than ??, so the checks on value never execute.

Another clue that an error lurks here: the right operand of ??. It looks like false && value is not null && value is string. The outcome of that expression is obvious. The condition contains only && operators, and one operand is false. So, the entire expression is always false.

To fix it, the author needs to add parentheses:

(knowledgeBase.Options
                   ?.TryGetValue(KnowledgeBaseId, 
                                 out var value) ?? false) && value is not null 
                                                          && value is string

Note that 4 other places in the source code contain the same issue:

Code snippet 2

private static readonly RestApiParameterFilter s_restApiParameterFilter = 
(RestApiParameterFilterContext context) =>
{
  if (   ("me_sendMail".Equals(context.Operation.Id, 
                               StringComparison.OrdinalIgnoreCase) 
      || ("me_calendar_CreateEvents".Equals(context.Operation.Id,
                                            StringComparison.OrdinalIgnoreCase))
      && "payload".Equals(context.Parameter.Name, 
                          StringComparison.OrdinalIgnoreCase)))
  {
    context.Parameter
           .Schema = TrimPropertiesFromRequestBody(context.Parameter.Schema);
    return context.Parameter;
  }
  return context.Parameter;
};

The PVS-Studio warning: V3088 The expression was enclosed by parentheses twice: ((expression)). One pair of parentheses is unnecessary or misprint is present. CopilotAgentBasedPlugins.cs 212

The outermost parentheses wrap the entire if condition, making them pointless. The developer probably intended this logic: apply the payload parameter name check to both operations (me_sendMail and me_calendar_CreateEvents). But in reality, the payload check applies only to the second operation because && has a higher priority than ||. To fix it, the developer needs to parenthesize only the checks for me_sendMail and me_calendar_CreateEvents, not the entire condition.

Forgot something

Code snippet 3

private static string? GetAudioOutputMimeType(ChatAudioOptions? audioOptions)
{
  if (audioOptions is null)
  {
    return null;
  }

  if (audioOptions.OutputAudioFormat == ChatOutputAudioFormat.Wav) // <=
  {
    return "audio/wav";
  }

  if (audioOptions.OutputAudioFormat == ChatOutputAudioFormat.Mp3)
  {
    return "audio/mp3";
  }

  if (audioOptions.OutputAudioFormat == ChatOutputAudioFormat.Opus)
  {
    return "audio/opus";
  }

  if (audioOptions.OutputAudioFormat == ChatOutputAudioFormat.Wav) // <=
  {
    return "audio/wav";
  }

  if (audioOptions.OutputAudioFormat == ChatOutputAudioFormat.Flac)
  {
    return "audio/flac";
  }

  if (audioOptions.OutputAudioFormat == ChatOutputAudioFormat.Pcm16)
  {
    return "audio/pcm16";
  }

  throw new NotSupportedException
  (
    $"Unsupported audio output format '{audioOptions.OutputAudioFormat}'. " +
    "Supported formats are 'wav', 'mp3', 'opus', 'flac' and 'pcm16'."
  );
}

The PVS-Studio warning: V3021 There are two 'if' statements with identical conditional expressions. The first 'if' statement contains method return. This means that the second 'if' statement is senseless ClientCore.ChatCompletion.cs 985

The GetAudioOutputMimeType method contains the same check twice: audioOptions.OutputAudioFormat == ChatOutputAudioFormat.Wav. The repeated check for ChatOutputAudioFormat.Wav is unreachable code—the method returns when the first match occurs. This is a typical copy-paste error.

Interestingly, the ChatOutputAudioFormat struct declares a ChatOutputAudioFormat Aac format. This is the only format the GetAudioOutputMimeType method doesn't handle. Perhaps it should replace one of the audioOptions.OutputAudioFormat == ChatOutputAudioFormat.Wav check.

public readonly partial struct ChatOutputAudioFormat 
                                 : IEquatable<ChatOutputAudioFormat>
{
  ....
  public static ChatOutputAudioFormat Wav { get; } = 
    new ChatOutputAudioFormat(WavValue);

  public static ChatOutputAudioFormat Aac { get; } =        // <=
    new ChatOutputAudioFormat(AacValue);

  public static ChatOutputAudioFormat Mp3 { get; } = 
    new ChatOutputAudioFormat(Mp3Value);

  public static ChatOutputAudioFormat Flac { get; } = 
    new ChatOutputAudioFormat(FlacValue);

  public static ChatOutputAudioFormat Opus { get; } = 
    new ChatOutputAudioFormat(OpusValue);

  public static ChatOutputAudioFormat Pcm16 { get; } = 
    new ChatOutputAudioFormat(Pcm16Value);
  ....
}

Code snippet 4

public async Task<KernelSearchResults<TextSearchResult>>
      GetTextSearchResultsAsync(string query, 
                                TextSearchOptions? searchOptions = null,
                                CancellationToken cancellationToken = default)
{
  var searchResult = await this.SearchInternalAsync(query, 
                                                    searchOptions, 
                                                    cancellationToken)
                               .ConfigureAwait(false);

  var results = 
   searchResult.Select(x => 
      new TextSearchResult(x.Text ?? string.Empty) 
        { Name = x.SourceName, Link = x.SourceLink });
  return 
    new(searchResult.Select(x =>
      new TextSearchResult(x.Text ?? string.Empty)
        { Name = x.SourceName, Link = x.SourceLink }).ToAsyncEnumerable());
}

The PVS-Studio warning: V3220 The result of the 'Select' LINQ method with deferred execution is never used. The method will not be executed. TextSearchStore.cs 204

The results variable receives the result of a LINQ method call, but the variable is never used after that. Many LINQ methods have deferred execution. So, value obtained from the LINQ expression is not evaluated when forming that expression. It will be evaluated only when we iterate over the resulting sequence (for example, in a foreach loop).

The value assignment to results is followed by a return statement with a similar LINQ expression. Most likely, one of the LINQ expressions is redundant. The author should either remove the results variable or use it when forming the return value:

return new(results.ToAsyncEnumerable());

Code snippet 5

/// <summary>
/// Creates a new instance of the <see cref="KernelProcess"/> class.
/// </summary>
/// <param name="state">The process state.</param>
/// <param name="steps">The steps of the process.</param>
/// <param name="edges">The edges of the process.</param>
/// <param name="threads">The threads associated with the process.</param>
public KernelProcess(
           KernelProcessState state, 
           IList<KernelProcessStepInfo> steps,
           Dictionary<string, List<KernelProcessEdge>>? edges = null, 
           IReadOnlyDictionary<string, 
                               KernelProcessAgentThread>? threads = null)
    : base(typeof(KernelProcess), state, edges ?? [])
{
  Verify.NotNull(steps);
  Verify.NotNullOrWhiteSpace(state.Name);

  this.Steps = [.. steps];
}

The PVS-Studio warning: V3117 Constructor parameter 'threads' is not used. KernelProcess.cs 46

The threads parameter wasn't used. When calling the KernelProcess method, the caller may pass an argument matching threads. That suggests the caller expects the parameter to be used.

Note that the KernelProcess class has a property named Threads. Perhaps that property should initialize from the unused parameter.

Array index out of bounds

Code snippet 6

private int ComputeTruncationIndex(
                     IReadOnlyList<ChatMessageContent> chatHistory,
                     ChatMessageContent? systemMessage)
{
  var truncationIndex = -1;

  var totalTokenCount = (int)(systemMessage?.Metadata?["TokenCount"] ?? 0);
  for (int i = chatHistory.Count - 1; i >= 0; i--)                        // <=
  {
    truncationIndex = i;
    var tokenCount = (int)(chatHistory[i].Metadata?["TokenCount"] ?? 0);
    if (tokenCount + totalTokenCount > this._maxTokenCount)
    {
      break;
    }
    totalTokenCount += tokenCount;
  }

  // Skip function related content
  while (truncationIndex < chatHistory.Count)                             // <=
  {
    if (chatHistory[truncationIndex].Items.Any(i => i is FunctionCallContent 
                                                      or FunctionResultContent))
    {
      truncationIndex++;
    }
    else
    {
      break;
    }
  }

  return truncationIndex;
}

The PVS-Studio warning: V3106 Possible negative index value. The value of 'truncationIndex' index could reach -1. ChatHistoryMaxTokensReducer.cs 75

The truncationIndex variable initializes to -1. If the chatHistory collection is empty, the execution flow won't enter the for loop as the condition -1 >= 0 fails before the first iteration. Thus, the value of truncationIndex doesn't change. Immediately after the for loop comes a while loop whose condition will be true if chatHistory has zero elements (-1 < 0). Inside the while loop, the code uses truncationIndex as an index, and it may still be -1. Accessing an element with a negative index throws an IndexOutOfRangeException.

To fix this, the developer should check that the index is not negative before using it.

Issues with null

Code snippet 7

public KernelProcessProxy ToKernelProcessProxy()
{
  KernelProcessStepInfo processStepInfo = this.ToKernelProcessStepInfo();
  if (this.State is not KernelProcessStepState state)
  {
    throw new KernelException($"Unable to read state from proxy with name " +
                              $"'{this.State.Name}', Id '{this.State.Id}' " +
                              $"and type {this.State.GetType()}.");
  }

  return new KernelProcessProxy(state, this.Edges)
  {
    ProxyMetadata = this.ProxyMetadata,
  };
}

public required KernelProcessStepState State { get; init; }

The PVS-Studio warning: V3080 [SEC-NULL] Possible null dereference. Consider inspecting 'this.State'. DaprProxyInfo.cs 30

The condition checks that this.State does not match theKernelProcessStepState type. The State property declaration indicates that its type is KernelProcessStepState. So the condition seems always false? Not exactly. If this.State is null, then this.State is not KernelProcessStepState will be true.

We expect a KernelException in the then block of the if statement. But the actual behavior differes. The exception message accesses properties of this.State. The only way execution flow reaches the then block is when this.State is null, the result will be a NullReferenceException.

Code snippet 8

private static RestApiPayload? 
                  CreateRestApiOperationPayload(string operationId,
                                                OpenApiRequestBody requestBody)
{
  if (requestBody?.Content is null)
  {
    return null;
  }

  var mediaType = GetMediaType(requestBody.Content) 
            ?? throw new KernelException(
               $"Neither of the media types of {operationId} is supported.");

  var mediaTypeMetadata = requestBody.Content[mediaType];

  var payloadProperties = GetPayloadProperties(operationId, 
                                               mediaTypeMetadata.Schema); // <=

  return new RestApiPayload(mediaType,
                            payloadProperties,
                            requestBody.Description,
                            mediaTypeMetadata?.Schema?.ToJsonSchema());   // <=
}

The PVS-Studio warning: V3095 The 'mediaTypeMetadata' object was used before it was verified against null. Check lines: 464, 466. OpenApiDocumentParser.cs 464

The mediaTypeMetadata variable is fisrt accessed without a null check, and then on the very next line is checked using a null-conditional operator ?.. Perhaps the check in the second case is redundant, and authors should remove it. If mediaTypeMetadata can indeed be null, then the first access will result in a NullReferenceException.

Code snippet 9

internal async Task<ReActStep?> GetNextStepAsync(....)
{
  ....
  if (this._logger.IsEnabled(LogLevel.Information))                       // <=
  {
    this._logger?.LogInformation("question: {Question}", question);
    this._logger?.LogInformation("functionDescriptions: {FunctionDescriptions}",
                                 functionDesc);
    this._logger?.LogInformation("Scratchpad: {ScratchPad}", scratchPad);
  }

  var llmResponse = await this._reActFunction
                              .InvokeAsync(kernel, arguments)
                              .ConfigureAwait(false);

  string llmResponseText = llmResponse.GetValue<string>()!.Trim();

  if (this._logger?.IsEnabled(LogLevel.Debug) ?? false)
  {
    this._logger?.LogDebug("Response : {ActionText}", llmResponseText);
  }
  ....
}

The PVS-Studio warning: V3095 The 'this._logger' object was used before it was verified against null. Check lines: 144, 146. ReActEngine.cs 144

This case resembles the previous example. In the same context, the this._loggerfield is used with a null check and without it. Besides the code above, the GetNextStepAsync method contains two more places where this._logger is not checked for null. As before, this indicates inconsistent handling of a potential null value forthis._logger.

Code snippet 10

public override async Task<MAAI.AgentRunResponse> 
                         RunAsync(IEnumerable<ChatMessage> messages, 
                                  MAAI.AgentThread? thread = null,
                                  MAAI.AgentRunOptions? options = null,
                                  CancellationToken cancellationToken = default)
{  
  ....
  AgentResponseItem<ChatMessageContent>? lastResponseItem = null; 
  ChatMessage? lastResponseMessage = null;                              // <=

  await foreach (var responseItem in ....)
  {
    lastResponseItem = responseItem;
  }

  return new MAAI.AgentRunResponse(responseMessages)
  {
    AgentId = this._innerAgent.Id,
    RawRepresentation = lastResponseItem,
    AdditionalProperties = lastResponseMessage?.AdditionalProperties,   // <=
    CreatedAt = lastResponseMessage?.CreatedAt,                         // <=
  };
}

The PVS-Studio warnings:

V3022 Expression 'lastResponseMessage' is always null. The operator '?.' is meaningless. SemanticKernelAIAgent.cs 111
V3022 Expression 'lastResponseMessage' is always null. The operator '?.' is meaningless. SemanticKernelAIAgent.cs 112

The lastResponseMessage variable initializes to null. The code then uses its properties to initialize AdditionalProperties and CreatedAt of a new object. Turns out, those properties will always initialize to null.

Perhaps by the time of AdditionalProperties and CreatedAt initialization, lastResponseMessage should contain a non-null value. If the intention is to assign null to these properties, then authors can remove lastResponseMessage, as it only appears in the shown snippets.

Conclusion

Our analysis of the C# portion of Semantic Kernel shows the expected picture: despite the project high profile and Microsoft involvement, the code contains typical issues. This is not unusual—complex systems under active development almost always contain questionable spots and various defects.

If you'd like to analyze your own project with PVS-Studio, you can try the analyzer via this link.

Webinar: Let's make a programming language. Grammars—Key points

Unicorn Developer — Wed, 22 Apr 2026 13:58:49 +0000

PVS-Studio continues a series of webinars on how to create your own programming language using C++.

Previously, we discussed what a programming language is and its overall structure. This time, the talk host, Yuri Minaev, went a level deeper—into grammars.

What's the talk about?

A grammar consists of terminal and non-terminal symbols, production rules, and a starting point. Non-terminals define higher-level constructs in terms of other symbols, while terminals represent basic, indivisible elements like digits or characters.

Yuri explains how the way you design grammar determines how expressions are parsed and evaluated, including the associativity and priority of operations. He also introduces recursive definitions and explains how they form tree-like structures during parsing.

The webinar wraps up by connecting grammar theory to actual implementation, describing recursive descent parsing as a flexible and an easy to implement approach. It mirrors the grammar structure through functions, enabling the parser to process input from the top down and construct meaning step by step.

Learn more: How do compilers work?

Want more?

If you want to learn more and see the whole webinar, follow this link.

You can also sign up for the next webinar in the series: Let's make a programming language. Lexer. During the webinar, Yuri will walk you through what a lexer is and how it's actually implemented in code.

Don't worry if you missed our previous webinar sessions! You can watch them on our YouTube channel or website as well.

We hope to see you there!

Forem: Unicorn Developer

C++ digest: News, helpful resources, & your own programming language as bonus

The road to C++26: contracts and reflection

Security profiles

The LLVM 22 update

Articles

Talks

Podcasts

A series of talks on how to create your own programming language

Conclusion

Unity’s AI agent went public: the developers of a static analysis tool on what that means for code quality

Game++. Part 1.2: C++, game engines, and architectures

AI

Scripts and configs

UI

Tools

Architecture

Game engine

All parts

Let's make a programming language. Lexer—Key points

About the speaker

The lexer in action

How the lexer works in C++

Want more?

PVS-Studio in CMake: It's official now!

How does it work?

Let's put it into practice

Some trickery

You're repeating yourself. You're repeating yourself.

Will the old analysis options remain?

Static code analysis and software time to market

How static analysis speeds up time to market

Why the quick approach is flawed

Economics of bug detection: the earlier, the cheaper

Static analysis does not replace other methods—it complements them

Real-life cases and measurable results

Applying the Shift Left approach

ROI

PVS-Studio tool as an example

Conclusion

Links

Error handling in Go: Common pitfalls

Introduction

Common approach to error handling in Go

How to make mistakes when handling errors

Conclusion

Building a programming language live: it’s time for the parser

What's new in Java 26

JEP 500 Prepare to Make Final Mean Final

JEP 504 Remove the Applet API

JEP 517 HTTP/3

JEP 526 Lazy Constants (Second Preview)

JEP 529 Vector API (Eleventh Incubator)

JEP 530 Primitive Types in Patterns, instanceof, and switch (Fourth Preview)

Summary

Silent foe or quiet ally: Brief guide to alignment in C++. Part 3

Introduction

What is virtuality?

Virtual functions

Virtual function table (vtable)

Virtual pointer (vptr)

How the pointer works

The alignment and vptr

Inheritance and virtuality

The diamond problem

Virtual inheritance mechanisms: vbptr, vbtable, VTT

The pitfalls of virtual inheritance

Pointer casting

Casting to void*

Empty Base Optimization with virtual

Performance impact

Is virtuality worth it?

Conclusion

AI integrations: Rely or verify? Checking Semantic Kernel

Misplaced priorities

Forgot something

Array index out of bounds

Issues with null

Conclusion

Webinar: Let's make a programming language. Grammars—Key points