Forem: Unicorn Developer

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!

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

Unicorn Developer — Tue, 21 Apr 2026 12:44:16 +0000

The value of a skilled developer is shifting toward the ability to effectively review code. Although generating code now is easier than ever, evaluating it for proper decomposition, correctness, efficiency, and security is still important. To see why it's important to understand generated code and to recognize what lies beneath a program's elegant syntax, let's look at a small project called markus, created using Claude Opus.

The markus project

While searching for an AI-generated project, I came across markus.

This is a single-header library for parsing text and converting it to HTML. It was created using Claude Opus 4.5.

I liked that the library is tiny. You can browse through it and even dive into exploring individual code snippets. When faced with a lot of code right off the bat, you don't even feel like starting to look into it.

The library consists of a single file, markus.h, containing 6,484 lines of C++20 code. In reality, there's even less code. Some algorithms use lookup table methods for optimization purposes. Four tables in the code are way too stretched out. The example:

static constexpr uint8_t kWhitespaceTable[256] = {
      0,
      0,
      0,
      0,
      ... // and so on for 256 lines

Apart from the tables, there are actually 1,000 fewer lines of code. PVS-Studio analyzer didn't spot anything unusual in the project, but the check gave me a reason to take a closer look at some code snippets. So now, as an expert, I can highlight the points worth discussing.

Vibe coding issues

Using AI for code generation can seem appealing, especially to an inexperienced programmer who hasn't worked on large legacy projects.

Anyone who has dealt with this knows that the main goal isn't just to write code; it's also to make sure that the code is easy to maintain and develop. Robert Martin put it really well:

When left on its own, AI just piles code on top of code. It cannot hold the big picture in its mind. It doesn't really even understand the concept of a big picture. Architecture is likely beyond its capacity.

Learning the principles of decomposition and knowing how to correctly formulate problems are becoming increasingly important skills for programmers.

Still, I'd like to focus on another aspect of vibe coding that is rarely discussed: the fascination with the code-generation process and, as a result, an excessive reliance on it.

Once people see that AI can perform simple tasks just as well if not better than they can themselves, they tend to lose their skepticism. It seems that even in large-scale projects, the quality would be high, and the code would be optimized.

The example is right here. Out of curiosity, I asked AI to write some code that could quickly count the number of set bits in large arrays. I was impressed by the algorithms it used. I didn't know about some of those clever solutions, even though I had once read a book that covered a whole range of algorithms.

Looking at the code generated for counting bits, one might think, "Isn't it time to take up farming?" I wouldn't have written code like that myself. In fact, I wouldn't have even thought to look for it since I didn't know such algorithms existed.

This fascination extends to all AI-generated code. At first glance, I thought there was no point in analyzing the markus code—it looked clean, well-structured, and full of optimized solutions:

fine-tuned compiler optimization using branch prediction hints like [[unlikely]];
conditional compilation using if constexpr;
optimized table-driven algorithms;
generation of SIMD-friendly helper functions;
containers from the std::pmr namespace that control memory allocation strategies.

The code looks good, so what's there to check? Well, there's actually a catch. The impression that the code is optimized is false. Or rather, some parts are really well optimized, while others are pretty bad.

Though, the project author deserves praise for his thoughtful and measured approach to describing the project. Ryan clearly warns:

DO NOT USE IN PRODUCTION. This is completely vibe coded and has not undergone any reviews for memory safety. Its performance is also 2-3x slower than cmark.

So, what issue do I want to highlight in this article? The code may appear pedantic, optimized, and secure, but it's not.

Fortunately, we can compare the performance of the markus project with that of another solution and see that markus isn't very fast. But what if there's nothing to compare it to? An expert opinion is required. The problem is that many people now believe that experts and code reviews aren't necessary.

Is an expert needed?

Or maybe an expert code review isn't really necessary, after all?

You created some code. It looks nice and neat. It feels optimized and works well. Could this be enough?

I think you can skip the review if all four conditions are met:

No one will get hurt or lose money if the code doesn't work as intended due to bugs or a misinterpretation of specifications.
The code is reckless. No one will break it, since no one needs to.
The code performance is irrelevant.
The project is expected to have a short lifespan. It won't require decades of development, ongoing maintenance, or adjustments for other platforms, etc.

Otherwise, it's still the same—all code quality requirements still apply, and they are even more important now. The same practices described in the SSDLC should apply to vibe code.

Why am I so strict about AI?

I'm not strict, but I'm demanding. The project is written in C++. The idea behind using C++ is to develop fast and efficient applications that can use memory in a smart way. If you don't need a fast program, don't use C++.

Since C++ was chosen for building a fast application, the goal is to write fast code. It doesn't matter whether a human developer writes it or an AI. If the code isn't fast, the task isn't solved.

My personal interest lies in exploring what vibe code is and how static analyzers can help ensure its reliability. Just like human programmers, AI-generated code is prone to anti-patterns, though they're different. It makes sense to develop PVS-Studio analyzer with these peculiarities in mind.

Well, since I'm looking at these projects anyway, I might as well write articles about them. I'm not trying to criticize vibe code or vibe coding in general. That would be silly—it's just a tool. Unlike AI evangelists, however, I'm not here to promote these technologies. If I see that the code is garbage, I'll say so.

SIMD-friendly code

The comment for the IsSpanBlank function states that the code is designed to streamline the vectorization process for the compiler, for example by using SSE instructions.

The key to optimization is simultaneously handling multiple elements to determine if they contain spaces.

// Check if a span contains only blank characters (space, tab, \r, \n)
// SIMD-friendly: processes 8 bytes at a time
inline bool IsSpanBlank(const char* data, size_t len) {
  size_t i = 0;
  // Process 8 bytes at a time
  for (; i + 8 <= len; i += 8) {
    // For each byte, check if it's NOT a blank character
    // Blank chars: space(0x20), tab(0x09), \n(0x0A), \r(0x0D)
    bool all_blank = true;
    for (size_t j = 0; j < 8; ++j) {
      unsigned char c = static_cast<unsigned char>(data[i + j]);
      bool is_blank = (c == ' ' || c == '\t' || c == '\n' || c == '\r');
      all_blank = all_blank && is_blank;
    }
    if (!all_blank) return false;
  }
  // Handle remaining bytes
  for (; i < len; ++i) {
    unsigned char c = static_cast<unsigned char>(data[i]);
    if (c != ' ' && c != '\t' && c != '\n' && c != '\r') {
      return false;
    }
  }
  return true;
}

The code makes it seem like the AI knows what it's doing. The inner loop handles eight characters at a time and can be optimized using SIMD instructions. A separate simple loop handles the remaining characters.

I found this code suspicious because the bytes are actually handled sequentially. The nested loop doesn't do anything useful. I think this code is just as good as the simplest way to implement it.

inline bool IsSpanBlank_Simple(const char* data, size_t len) {
  for (size_t i = 0; i < len; ++i) {
    unsigned char c = static_cast<unsigned char>(data[i]);
    if (c != ' ' && c != '\t' && c != '\n' && c != '\r') {
      return false;
    }
  }
  return true;
}

I'd write the code this way. Had I known this was a bottleneck and I absolutely had to optimize the code as much as possible, I would've looked for an intrinsic-based solution.

I wouldn't try any other option, such as one with a nested loop. I know a thing or two about optimization, but not enough to dare write fancy code just to give the compiler a hint.

One could say, "You're weak! Claude Opus did it—it came up with the smarter version!"

Now, let's compare performance. My colleague Phillip conducted a small experiment with GCC and Clang:

We create the same dataset for both benchmarks: we generate 1,000,000 strings of random lengths, with arbitrary content, ranging from 1 to 127 characters. The calculations don't include set generation.
We feed a dataset to the algorithm and determine whether each string contains spaces. We measure the total time.

In both cases, the code is compiled with aggressive -O3 optimizations. As you can see, in both compilers, the simple function performs better than the one with the nested loop.

Shall we specify a magic optimization key to better optimize the vibe code? That key doesn't exist. And even if it does, the compiler will generate an equally efficient version from simple code with a single loop, even without any hints.

Along with my colleague, I also experimented with the two previously explored options and three new algorithm variants. I used the MSVC compiler. Let's take a look at the measurement results.

First, someone suggested improving the code by replacing the original || with |. In our case, short-circuit evaluation only causes more harm than good. Here's an improved check:

bool is_blank = (c == ' ' | c == '\t' | c == '\n' | c == '\r');

The full function code

inline bool IsSpanBlank_BinOR(const char* data, size_t len) {
  size_t i = 0;
  // Process 8 bytes at a time
  for (; i + 8 <= len; i += 8) {
    // For each byte, check if it's NOT a blank character
    // Blank chars: space(0x20), tab(0x09), \n(0x0A), \r(0x0D)
    bool all_blank = true;
    for (size_t j = 0; j < 8; ++j) {
      unsigned char c = static_cast<unsigned char>(data[i + j]);
      bool is_blank = (c == ' ' | c == '\t' | c == '\n' | c == '\r');
      all_blank = all_blank && is_blank;
    }
    if (!all_blank) return false;
  }
  // Handle remaining bytes
  for (; i < len; ++i) {
    unsigned char c = static_cast<unsigned char>(data[i]);
    if (c != ' ' && c != '\t' && c != '\n' && c != '\r') {
      return false;
    }
  }
  return true;
}

Secondly, I asked DeepSeek. It suggested an optimization approach based on bitwise operations:

inline bool IsSpanBlank_Deepseek(const char* data, size_t len) noexcept {
    // Creating a bitmask for valid characters
    // Using a 128-bit mask for ASCII
    static constexpr uint64_t blank_mask_low = []() {
        uint64_t mask = 0;
        mask |= 1ULL << ' ';
        mask |= 1ULL << '\t';
        mask |= 1ULL << '\n';
        mask |= 1ULL << '\r';
        return mask;
    }();

    for (size_t i = 0; i < len; ++i) {
        unsigned char uc = static_cast<unsigned char>(data[i]);
        if (uc >= 64) return false;  // All blank characters in ASCII < 64
        if (!((blank_mask_low >> uc) & 1)) return false;
    }
    return true;
}

Finally, I asked DeepSeek for an optimized function that truly takes advantage of vectorization. Here's what I got:

inline bool IsSpanBlank_Deepseek_SSE(const char* data, size_t len) noexcept {
  // Creating vectors with valid characters
  const __m128i space = _mm_set1_epi8(' ');
  const __m128i tab = _mm_set1_epi8('\t');
  const __m128i newline = _mm_set1_epi8('\n');
  const __m128i carriage = _mm_set1_epi8('\r');

  size_t i = 0;

  // Processing 16 bytes at a time
  for (; i + 15 < len; i += 16) {
    __m128i chunk = _mm_loadu_si128(reinterpret_cast<const __m128i*>(data + i));

    // Checking that each byte matches one of the valid values
    __m128i eq_space = _mm_cmpeq_epi8(chunk, space);
    __m128i eq_tab = _mm_cmpeq_epi8(chunk, tab);
    __m128i eq_nl = _mm_cmpeq_epi8(chunk, newline);
    __m128i eq_cr = _mm_cmpeq_epi8(chunk, carriage);

    __m128i is_blank = _mm_or_si128(_mm_or_si128(eq_space, eq_tab),
                                         _mm_or_si128(eq_nl, eq_cr));

    // Obtaining the mask and checking it
    int mask = _mm_movemask_epi8(is_blank);
    if (mask != 0xFFFF) return false;
}

  // Processing the remainder
  for (; i < len; ++i) {
    char c = data[i];
    if (c != ' ' && c != '\t' && c != '\n' && c != '\r') return false;
  }

  return true;
}

Now, the results. Although 32-bit builds are no longer relevant, I ran it just for the sake of curiosity. Testing was performed on a 212-megabyte array filled with random space characters. Thread execution is bound to a single preheated core. If you're not sure what I'm talking about, check out the article "An eternal question of timing".

Win32:
1. The simplest option with a single loop:                          1.39 s.
2. The original "optimized code" with a nested loop:                1.86 s.
3. The original version but the || operators were replaced with | : 0.351 s.
4. Deepseek's implementation with bitmask optimization:             0.817 s.
5. Deepseek's implementation with SSE2 intrinsic optimization:      0.0449 s.

Win64:
1. The simplest option with a single loop:                          0.175 s.
2. The original "optimized code" with a nested loop:                0.309 s.
3. The original version but the || operators were replaced with | : 0.253 s.
4. Deepseek's implementation with bitmask optimization:             0.207 s.
5. Deepseek's implementation with SSE2 intrinsic optimization:      0.0396 s.

Clearly, the 64-bit code is much more efficient, except when SSE2 is involved. Even then, though, everything runs quickly.

The code Claude Opus generated for the markus project is the worst of all the options.

Not only is the simplest implementation with a regular loop faster, it's also shorter. The extra code lines only made things worse.

Although intrinsic code is in the lead, this comes at the cost of limited portability.

Some might say I'm worrying for nothing. Yes, Claude Opus chose a poor implementation, but DeepSeek offered a perfectly good, fast, and portable one.

I agree. However, we see some poorly written code in the project. It looks optimized, but it isn't. The issue remains unresolved. This case requires an expert who understands it and can come up with a different solution.

The issue will only get worse in the future. There will be more and more generated code, but the number of people who can review it will remain the same. Then, the systems will be trained using the same "optimized" code. It'll be a wild ride.

String comparison: the beginning

This PVS-Studio warning caught my attention: V590 [CWE-571] Consider inspecting this expression. The expression is excessive or contains a misprint. markus.h 5987

The code does contain a redundant check:

BlockNode ParseParagraph() {
  ....
  auto trimmed = detail::TrimLeft(line); // trimmed has std::string_view type
  ....
  if (trimmed.size() >= 2 && trimmed[1] == '!' && trimmed.size() >= 9) {  
  ....
}

It's really no big deal—just an extra check that the compiler will remove anyway. For the sake of readability, I'd suggest tweaking the code a bit, but no more than that:

if (trimmed.size() >= 9 && trimmed[1] == '!') // now we're talking

However, I noticed the code below the if statement. Now, this redundancy is worth a closer look:

std::pmr::string upper;
for (size_t j = 0; j < 9; ++j) {
  upper += static_cast<char>(
      std::toupper(static_cast<unsigned char>(trimmed[j])));
}
if (upper.starts_with("<!DOCTYPE")) {
  goto html_interrupt;
}

A check is performed here to ensure that the string begins with "<!doctype", regardless of whether lowercase or uppercase letters are used. To ignore the case, a temporary uppercase string is created and compared with the pattern.

It's not a very efficient solution. Even with the use of std::pmr::string, creating a temporary string is a resource-intensive operation. After all, the characters still need to be copied into memory one by one. By the way, simple std::string would work just as well here, since the string is less than 15 characters long and the Small String Optimization applies.

It's better to write a function that performs case-insensitive comparisons. For example, this one:

bool starts_with_insensitive(std::string_view str,
                             std::string_view prefix_lower_case)
{
  if (str.size() < prefix.size()) return false;

  const auto pred = [](unsigned char lhs, unsigned char rhs)
  {
    return lhs == std::tolower(rhs);
  };

  return std::equal(prefix_lower_case.begin(), prefix_lower_case.end(),
                    str.begin(),
                    pred);
}

This is just an example. We can implement the algorithm differently or create istring_view by writing our own char_traits, and so on. Most importantly, we avoid creating a temporary string and simplify the code that performs the check:

if (starts_with_insensitive(trimmed, "<!doctype")) {
  goto html_interrupt;
}

In the next chapter, we'll see even more clearly why we need to create a comparison function. As they say, this is just the beginning; the worst is yet to come.

String comparison: the worst

While looking through other PVS-Studio warnings, I noticed this string vector:

std::optional<HtmlBlock> TryParseHtmlBlock() {
  ....
  static const std::pmr::vector<std::pmr::string> type1_tags = {
      "script", "pre", "style", "textarea"
  };
  ....
}

The analyzer doesn't like it: V1096 The 'type1_tags' variable with static storage duration is declared inside the inline function with external linkage. This may lead to ODR violation. markus.h 4781

It makes no sense to discuss this warning in the article. What matters far more is how this vector is handled. An analyzer can't understand abstract concepts or recognize when something is off. However, a human can see right through it and express their thoughts on the nonsense.

The code below checks whether these tags appear in the string. But the tag still has the < angle bracket, so the AI creates temporary strings containing the tag with the bracket:

for (const auto& tag : type1_tags) {
  std::pmr::string open_tag = "<" + tag;

Next, we check whether this tag is in the string, ignoring case. Well, let's create another temporary string for this. Generating vibe code is a piece of cake.

std::pmr::string lower;
for (size_t j = 0; j < open_tag.size(); ++j) {
   lower += static_cast<char>(
       std::tolower(static_cast<unsigned char>(trimmed[j])));
}

All this mess looks like this:

static const std::pmr::vector<std::pmr::string> type1_tags = {
    "script", "pre", "style", "textarea"
};

for (const auto& tag : type1_tags) {
  std::pmr::string open_tag = "<" + tag;
  if (trimmed.size() >= open_tag.size()) {
    std::pmr::string lower;
    for (size_t j = 0; j < open_tag.size(); ++j) {
      lower += static_cast<char>(
        std::tolower(static_cast<unsigned char>(trimmed[j])));
    }
    if (lower == open_tag) {
      // ....
    }
  }
}

In the worst-case scenario (if the tag isn't in the text) eight temporary strings are created! The only silver lining is that the created strings are small, and the Small String Optimization in std::pmr::string will eliminate dynamic allocations.

It's really easy to make the code run faster. Firstly, we can create the necessary prefixes right away and store them in a vector. Secondly, we can simply replace the vector with the array of std:string_view, completely removing dynamic allocations.

using namespace std::literals;

static constexpr std::array type1_tags = {
  "<script"sv, "<pre"sv, "<style"sv, "<textarea"sv
};

Thirdly, we can now find the prefix using the starts_with_insensitive function created earlier. As a result, all the messy code shown above is shortened to:

using namespace std::literals;

static constexpr std::array type1_tags = {
  "<script"sv, "<pre"sv, "<style"sv, "<textarea"sv
};
for (auto tag : type1_tags) {
  if (starts_with_insensitive(trimmed, tag.c_str(), tag.size()) {

The code is now half as long and N times faster.

There's still room for improvement, though. For example, instead of creating a string with a tag enclosed in brackets like end_condition = "</" + tag + ">";, we can take one from the array. Okay, let's move on.

The price of beauty

When I first skimmed through the code, the code for serializing an object array into a string really impressed me. Everything is correct: various functions use the "visitor" pattern to iterate through arrays of options and create the necessary strings. The code is error-proof and concise.

There are four serialization functions: GetAltTextFromIds, GetAltText, RenderInlines, and DebugAst. For this example, however, I'll use the shortest one:

using InlineNode = std::variant<....>;

std::pmr::string GetAltText(const std::pmr::vector<InlineNode>& nodes) {
  std::pmr::string result;
  for (const auto& node : nodes) {
    std::visit(
        [&result, this](auto&& arg) {
          using T = std::decay_t<decltype(arg)>;
          if constexpr (std::is_same_v<T, Text>) {
            result += arg.content;
          } else if constexpr (std::is_same_v<T, Code>) {
            result += arg.content;
          } else if constexpr (std::is_same_v<T, SoftBreak>) {
            result += ' ';
          } else if constexpr (std::is_same_v<T, HardBreak>) {
            result += ' ';
          } else if constexpr (std::is_same_v<T, Emphasis>) {
            result += GetAltTextFromIds(arg.children);
          } else if constexpr (std::is_same_v<T, Strong>) {
            result += GetAltTextFromIds(arg.children);
          } else if constexpr (std::is_same_v<T, Link>) {
            result += GetAltTextFromIds(arg.children);
          } else if constexpr (std::is_same_v<T, Image>) {
            result += arg.alt_text;
          }
        },
        node);
  }
  return result;
}

It looks elegant. At first, because of this code, I thought about giving the article a less provocative title. After reviewing the flaws, I wanted to use this code as a positive example. Like, here, the AI wrote better code than an inexperienced C++ programmer could. Overall, some parts turned out better than others.

Naturally, before writing the praise part, I had to take a closer look at the code and figure out what was going on. Why did I ever do that... I could've stayed charmed by the patterns, the constexpr keyword, and the code neatly formatted in a column.

It turns out things aren't great here either. Let me tell you why.

The task is to store an array of elements that can be serialized into strings in different ways.

A simple approach would be to create a base class and have different entities inherit from it. The container will then store pointers to it. Serialization requires calling different virtual functions in different situations. The result would be something like the following class hierarchy:

using namespace std::literals;

struct Node
{
    virtual ~Node() = default;
    virtual std::string StrAltText() = 0;
    virtual std::string StrDebug() = 0;
};

struct SoftBreak : public Node {
    std::string StrAltText() { return " "s; }
    std::string StrDebug() { return " "s; }
};

struct HtmlBlock : public Node {
    std::string content;
    std::string StrAltText() { return content; }
    std::string StrDebug() { return std::format("HtmlBlock = {}", content); }
};

An array of such objects would turn into a string like this:

std::string GetAltText(const std::vector<Node *>& nodes) {
    std::string result;
    for (const auto& node : nodes)
        result += node->StrAltText();
    return result;
}

The code above requires manual memory management and is unsafe in general. We can fix this by storing smart pointers, such as std::unique_ptr, in the vector. Another option is to use std::any.

However, another issue remains: the serialization code is spread out among many different classes. You can put the processing in one place by determining the object type in the array using dynamic_cast. That's slow.

So, the standard approach is to store the object identifier in the base class so that its type can be quickly determined:

enum NodeType
{
    kSoftBreak,
    kHtmlBlock
};

struct Node
{
    const NodeType type;
    Node(NodeType t) : type(t) {}
    virtual ~Node() = default;
};

struct SoftBreak : public Node {
    SoftBreak() : Node(kSoftBreak) {}
};

struct HtmlBlock : public Node {
    std::string content;
    HtmlBlock() : Node(kHtmlBlock) {}
};

Now, we can put the processing in one place, even if it's not very elegant:

std::string GetAltText(const std::vector<std::unique_ptr<Node>>& nodes)
{
    std::string result;
    for (const auto& node : nodes)
        switch(node->type)
        {
            case kSoftBreak:
            {
                // There is no need to retrieve the object itself.
                // SoftBreak &n = *static_cast<SoftBreak *>(node);
                result += ' ';
                break;
            }
            case kHtmlBlock:
            {
                const HtmlBlock &n = static_cast<const HtmlBlock &>(*node);
                result += n.content;
                break;
            }
    }
    return result;
}

To achieve a more elegant solution, we can use the std::variant data type, as Claude Opus did. The std::variant type is a smart, type-safe version of union. There's just one catch, though, and a really big one.

For starters, AI has created a strange, redundant entity. It introduced the NodeType enumeration, which is required for the schema we discussed above:

enum class NodeType {
  ....
  kHtmlBlock,
  kBlockQuote,
  kList,
  kListItem,
  kText,
  kSoftBreak,
  ....
};

It added the meaningless numeric identifier, kType, to the structures:

struct SoftBreak {
  static constexpr NodeType kType = NodeType::kSoftBreak;
};

struct HtmlBlock {
  static constexpr NodeType kType = NodeType::kHtmlBlock;
  std::pmr::string content;
  int block_type = 0;  // CommonMark HTML block type (1-7)
};

The enumeration and identifier are redundant in the structures. kType isn't used anywhere, since it's declared as static and doesn't take up memory in every object.

The enumeration is used only once, in the NodeTypeToString function:

// Convert NodeType to string for debugging
inline std::string_view NodeTypeToString(NodeType type) {
  switch (type) {
    case NodeType::kDocument:
      return "Document";
    case NodeType::kParagraph:
      return "Paragraph";
    case NodeType::kHeading:
      return "Heading";
    case NodeType::kThematicBreak:
      return "ThematicBreak";
   ....
    case NodeType::kHtmlInline:
      return "HtmlInline";
  }
  return "Unknown";
}

The only unclear things are how and why to use this function. What's it for? How can it help? It doesn't seem like it will help anyone with anything. All in all, you can remove all of this and shorten the project code by another 100 lines.

It's just some redundant code, so it's no big deal. The worst is literally yet to come.

A key feature of the std:variant type is that it must be large enough to hold the largest alternative. In our case, the option should include the following classes:

using InlineNode = std::variant<Text, SoftBreak, HardBreak, Code, Emphasis,
                                Strong, Link, Image, HtmlInline>;

These classes vary greatly in size, starting with the smallest ones, such as SoftBreak:

struct SoftBreak {
  static constexpr NodeType kType = NodeType::kSoftBreak;
};

This class is 1 byte in size. Even though the class is empty, it still has to occupy at least one byte.

The largest class is Image:

struct Image {
  static constexpr NodeType kType = NodeType::kImage;
  std::pmr::string destination;
  std::pmr::string title;
  std::pmr::string alt_text;
};

In a 64-bit program, it can occupy 120 bytes. The thing is that std::pmr::string, for example, takes up 40 bytes in the STL implementation. Do you already see what that means?

The option also stores information about the type it currently holds. The total size of a single InlineNode object is 128 bytes! Take a look here.

Overall, the program works with arrays where each element is 128 bytes in size. The memory usage "efficiency" is ridiculous.

Even just storing empty classes that represent separators and usually convert to spaces requires so much memory:

} else if constexpr (std::is_same_v<T, SoftBreak>) {
  result += ' ';

Knowing where to print a space requires 128 bytes.

While memory overuse may not be a significant issue, it raises concerns about performance. The processor cache is also used less efficiently when working with such a spanned array.

One might argue that using smart pointers adds an extra layer of indirection when accessing an object, which also harms performance. It's also necessary to check the object type (see the example with switch above).

It's a no. Indirect access via a pointer isn't a big deal considering there will be a lot of memory accesses later on for reading and concatenating strings. Memory overuse sounds like a much more serious issue. The object type check is still there; it's just hidden within std::variant.

Just imagine how painful it is to extend the vector if the next element no longer fits in the reserved buffer. Here's an example:

std::pmr::vector<InlineNode> link_content;
for (size_t i = opener->pos + 1; i < result.size(); ++i) {
  link_content.push_back(std::move(result[i]));
}

When the vector is expanded, objects are moved to new locations. Yikes... The version using smart pointers to the base class std::vector<std::unique_ptr<Node>> is much lighter.

Once again, we have bad code wrapped up in a pretty package.

I'm not saying that smart pointers or std::any are the best solution here. There are other options as well. When the goal is to write efficient code, it's important to consider how to store objects and iterate over them for serialization.

What else?

I don't know. I've already spent more time reviewing the code and writing this article than I had planned.

This once again proves the growing value of reviewers. Generating code is getting easier and easier. My question is, where does one find the energy to review it and determine whether it turned out as expected? Who will take responsibility for the outcome? After all, this is C++, and the whole point of using it is efficiency. If someone doesn't need performance at all, what are they even doing here?

I'm finishing up the detailed review, but before concluding the article, I'll go over a few of PVS-Studio warnings.

Forgetfulness

The analyzer warning: V560 [CWE-571] A part of conditional expression is always true: !input.empty(). markus.h 2228

explicit LineBuffer(std::string_view input) {
  if (input.empty()) [[unlikely]] {
    return;
  }
  ....
  // input is not modified
  ....
  if (input.size() > line_start ||
      (!input.empty() && (input.back() == '\n' || input.back() == '\r'))) {
    line_offsets_.push_back({line_start, input.size() - line_start});
  }
  ....
}

The AI meticulously added [[unlikely]] to alert the compiler that the event is unlikely. However, after some time, it forgets that the string is never empty and ends up performing an unnecessary recheck with !input.empty().

You're only as good as the company you keep

The analyzer warning: V1048 [CWE-1164] The 'prev_line_had_content' variable was assigned the same value. markus.h 4090

void ExtractLinkReferences(Document& doc) {
  ....
  bool prev_line_had_content = false;
  ....
  if (prev_line_had_content) {
    prev_line_had_content = true;  // This line also has content
    Advance();
    continue;
  }
  ....
}

The true value is assigned to the prev_line_had_content variable, even though the check already confirms that this value is stored there. The analyzer is right—we're looking at a meaningless line of code. But the warning isn't exciting: I wouldn't have paid it any attention if it weren't for the comment.

Have you heard stories about programmers writing accurate but useless comments? It seems the AI had some "good" teachers. This is exactly the case where the comment simply describes the performed action without adding any new information.

See also "Terrible tip N53. Answer the question "what?" in code comments" in the book "60 terrible tips for a C++ developer."

Creating temporary proxy objects

The analyzer warning: V823 Decreased performance. Object may be created in-place in the 'result' container. Consider replacing methods: 'push_back' -> 'emplace_back'. markus.h 2597

std::pmr::vector<InlineNodeId> ParseInlines() {
  std::pmr::vector<InlineNode> result;
  ....
  result.push_back(Text(text_.substr(text_start, pos_ - text_start)));
  ....
}

A temporary object of the Text type is created and placed in a container. The first idea is to use emplace_back:

result.emplace_back(Text(text_.substr(text_start, pos_ - text_start)));

However, switching to emplace_back in this case will not improve performance at all, and it will also place an extra load on the compiler because it will have to instantiate the emplace_back function template. The created object will be perfectly passed in it and moved by the move constructor.

More sophisticated code is necessary here to ensure the content is placed directly inside the container. This is an container of std::variant, so we need to instruct it which alternative we want to create and pass it's std::string_view.

Here's what it'll look like:

result.emplace_back(std::in_place_type<Text>, text.substr(....));

In this case, we can perfectly pass the hint about the constructed type and its constructor arguments. Take a look at the fifth overload of the std::variant constructor.

With this change, you'll get rid of one call to the move constructor.

This isn't a big deal, but if code contains many similar fragments, it's best to get it right from the start.

V823 Decreased performance. Object may be created in-place in the 'result' container. Consider replacing methods: 'push_back' -> 'emplace_back'. markus.h 2610
V823 Decreased performance. Object may be created in-place in the 'result' container. Consider replacing methods: 'push_back' -> 'emplace_back'. markus.h 2632
V823 Decreased performance. Object may be created in-place in the 'result' container. Consider replacing methods: 'push_back' -> 'emplace_back'. markus.h 2650
V823 Decreased performance. Object may be created in-place in the 'result' container. Consider replacing methods: 'push_back' -> 'emplace_back'. markus.h 2733
V823 Decreased performance. Object may be created in-place in the 'result' container. Consider replacing methods: 'push_back' -> 'emplace_back'. markus.h 2751
V823 Decreased performance. Object may be created in-place in the 'result' container. Consider replacing methods: 'push_back' -> 'emplace_back'. markus.h 2754
V823 Decreased performance. Object may be created in-place in the 'result' container. Consider replacing methods: 'push_back' -> 'emplace_back'. markus.h 2855
V823 Decreased performance. Object may be created in-place in the 'result' container. Consider replacing methods: 'push_back' -> 'emplace_back'. markus.h 2931
V823 Decreased performance. Object may be created in-place in the 'quote_lines' container. Consider replacing methods: 'push_back' -> 'emplace_back'. markus.h 5239
V823 Decreased performance. Object may be created in-place in the 'quote_lines' container. Consider replacing methods: 'push_back' -> 'emplace_back'. markus.h 5241
V823 Decreased performance. Object may be created in-place in the 'item_lines' container. Consider replacing methods: 'push_back' -> 'emplace_back'. markus.h 5641
V823 Decreased performance. Object may be created in-place in the 'item_lines' container. Consider replacing methods: 'push_back' -> 'emplace_back'. markus.h 5643
V823 Decreased performance. Object may be created in-place in the 'para_lines' container. Consider replacing methods: 'push_back' -> 'emplace_back'. markus.h 6045
V823 Decreased performance. Object may be created in-place in the 'para_lines' container. Consider replacing methods: 'push_back' -> 'emplace_back'. markus.h 6047
V823 Decreased performance. Object may be created in-place in the 'delimiter_stack' container. Consider replacing methods: 'push_back' -> 'emplace_back'. markus.h 2729
V823 Decreased performance. Object may be created in-place in the 'delimiter_stack' container. Consider replacing methods: 'push_back' -> 'emplace_back'. markus.h 2746
V823 Decreased performance. Object may be created in-place in the 'line_offsets_' container. Consider replacing methods: 'push_back' -> 'emplace_back'. markus.h 2193
V823 Decreased performance. Object may be created in-place in the 'line_offsets_' container. Consider replacing methods: 'push_back' -> 'emplace_back'. markus.h 2196
V823 Decreased performance. Object may be created in-place in the 'line_offsets_' container. Consider replacing methods: 'push_back' -> 'emplace_back'. markus.h 2208
V823 Decreased performance. Object may be created in-place in the 'line_offsets_' container. Consider replacing methods: 'push_back' -> 'emplace_back'. markus.h 2218
V823 Decreased performance. Object may be created in-place in the 'line_offsets_' container. Consider replacing methods: 'push_back' -> 'emplace_back'. markus.h 2221
V823 Decreased performance. Object may be created in-place in the 'line_offsets_' container. Consider replacing methods: 'push_back' -> 'emplace_back'. markus.h 2229
V823 Decreased performance. Object may be created in-place in the 'result' container. Consider replacing methods: 'push_back' -> 'emplace_back'. markus.h 2637
V823 Decreased performance. Object may be created in-place in the 'result' container. Consider replacing methods: 'push_back' -> 'emplace_back'. markus.h 2947
V823 Decreased performance. Object may be created in-place in the 'result' container. Consider replacing methods: 'push_back' -> 'emplace_back'. markus.h 2958

A copy instead of a move

The analyzer warning: V820 The 'content' variable is not used after copying. Copying can be replaced with move/swap for optimization. markus.h 4670

struct Heading {
  static constexpr NodeType kType = NodeType::kHeading;
  int level = 1;  // 1-6
  std::pmr::vector<InlineNodeId> children;
  std::pmr::string raw_content;  // Temporary storage for inline parsing
};

std::optional<Heading> TryParseAtxHeading() {
  ....
  std::pmr::string content(trimmed.substr(i));
  ....
  Heading heading;
  heading.level = level;
  heading.raw_content = content;    // <=
  return heading;
}

The string in the content variable is copied, even though it could be moved, since it's no longer needed. We can write it like this:

heading.raw_content = std::move(content);

Or we could skip the temporary heading object altogether and go with something like this:

return Heading { .level = level,
                 .raw_content = std::move(content)
               };

Again, this is a minor issue, but little things like this accumulate over time.

V820 The 'info_string' variable is not used after copying. Copying can be replaced with move/swap for optimization. markus.h 4761
V820 The 'content' variable is not used after copying. Copying can be replaced with move/swap for optimization. markus.h 4762
V820 The 'content' variable is not used after copying. Copying can be replaced with move/swap for optimization. markus.h 5101
V820 The 'content' variable is not used after copying. Copying can be replaced with move/swap for optimization. markus.h 5821

Manual sunset

The analyzer warning: V837 The 'insert' function does not guarantee that arguments will not be copied or moved if there is no insertion. Consider using the 'try_emplace' function. markus.h 5274

using LinkRefMap =
    std::pmr::unordered_map<std::pmr::string,
                            std::pair<std::pmr::string, std::pmr::string>>;

std::optional<BlockQuote> TryParseBlockQuote() {
  .... 
  LinkRefMap* parent_link_refs_ = nullptr;
  ....
  for (const auto& [label, dest_title] : nested_doc.link_references) {
    if (parent_link_refs_->find(label) == parent_link_refs_->end()) {
      parent_link_refs_->insert({label, dest_title});
    }
  }
  ....
}

PVS-Studio issues a warning about inefficiency when an element with the same key is already included in the container. In our case, the protection against this was implemented manually, but it's inefficient. Two searches occur in the code:

First, we search for an element by key to check the condition.
We repeat the same operation when inserting, attempting to find the correct insertion position in the hash table.

In this case, calling try_emplace performs one search and inserts the element if it isn't already there:

for (const auto& [label, dest_title] : nested_doc.link_references) {
    parent_link_refs_->try_emplace(label, dest_title);
}

Conclusion

The conclusions are the same as those in the previous article, "Let's dg into some vibe code." No matter how you write your code, there are ways to ensure that your software is high-quality and reliable.

It's important to value architects and developers who know how to break down and design modular architectures.
Remember that security is an integral part of the system from the moment its design begins.
Praise developers who can distinguish between efficient and slow code, as well as between safe and dangerous code. Praise those who can determine whether the created code is suitable for inclusion in the project.
Use static code analyzers.
Use dynamic code analyzers and FAST analyzers for front-end applications.
Use software composition analysis tools. This is particularly relevant if you use AI, as its hallucinations can be exploited to attack supply chains.
Use coding standards. Nothing is worse than disorganized code.
Apply other SSDLC practices as needed.

PVS-Studio 7.42: Testing new analyzers, expanded MISRA C++ 2023 support, and more

Unicorn Developer — Fri, 17 Apr 2026 14:11:02 +0000

PVS-Studio 7.42 is now released. This version features expanded support for MISRA C++ 2023, a plugin for Qt Creator 19, official integration with CMake, and other useful improvements. Keep reading for details.

Testing JavaScript and Go analyzers

On April 6, we launched an open testing period for our new code analyzers for JavaScript and Go. Before officially releasing these new tools, it is crucial for us to thoroughly test them and collect user feedback.

The initial versions of JavaScript and Go analyzers each include twenty diagnostic rules, a command-line interface (CLI), and plugins for WebStorm and GoLand.

One month later, a TypeScript analyzer and a new version of the Visual Studio Code extension with support for the new analyzers will become available for testing.

Additionally, the PVS-Studio Atlas code quality management platform is also available for testing. It is a new solution for managing analysis results, which enables users to mark warnings.

To take part in the testing program, please fill out the form on our website.

MISRA C++ 2023

The previous PVS-Studio release introduced coverage for 86% of the MISRA C 2023 standard.

However, our implementation of MISRA standards remains in active development. Starting with this version, we initiated the implementation of the MISRA C++ 2023 standard.

We have adapted 22 existing diagnostic rules from the MISRA group to align with the MISRA C++ 2023 standard. Additionally, it is now possible to select the MISRA C++ version within PVS-Studio IDE plugins and command-line utilities.

You can learn more about MISRA standards support on this page.

Changes to the free licensing policy

We have discontinued support for the free usage of the analyzer via special comments in the code. If you have been using the analyzer this way, you will need to get an activation key via one of the other available methods.

Changes have also been made to the free usage terms for students and educators. The student licensing program is currently paused while we refine its updated terms and conditions. We will announce them when student license applications are open again. To stay updated, you are welcome to subscribe to our newsletter.

The terms for free licensing for open-source projects, public security experts, and Microsoft MVPs remain unchanged. You can read more about these terms at this link.

New integrations

Qt Creator 19

Support for the PVS-Studio plugin for Qt Creator versions 19.x has been added. The plugin enables running analysis, reviewing warnings, and working with code without leaving a familiar development environment.

Support for the plugin for Qt Creator versions 13.x has been discontinued. We strive to maintain backward compatibility for the latest plugin versions across all Qt Creator releases from the past two years.

Learn more about working with the plugin in the documentation.

Official integration with CMake

Starting with version 4.3.0, the CMake build system includes a built-in mechanism for working with PVS-Studio. This allows analyzer warnings to appear directly during the project compilation process.

You can read more about this in the documentation.

End of support for the 64-bit error diagnostic rules

Starting with this release, we have suspended further development of diagnostic rules from the "64-bit error diagnostic rules" group. These rules will no longer be enhanced and may be disabled in future releases.

If you rely on these rules, please contact our support team so we can assist you in finding a replacement or offer an alternative solution.

Analyzer improvements

The C and C++ analyzer has reduced analysis time for template-heavy code thanks to an improved handling mechanism. Evaluation and analysis of simple functions have also been enhanced based on the context in which they are called.

The C# analyzer now includes additional debugging mechanisms. A new warning, V053, is issued when the analyzer cannot obtain built-in .NET types. The --createBinaryLogs flag has been added to log the operation of Roslyn mechanisms. More details are available in the documentation.

In the C# analyzer, we have also fixed an issue that occurred when checking non-SDK-style .NET Framework projects following an update to Visual Studio 2026 version 18.4.0 or later.

New diagnostic rules

C and C++

V1119. Preprocessing directive is present within a macro argument. This leads to undefined behavior.

C

V3232. Use of externally-controlled format string. Potentially tainted data is used as a format string.

Java

V6133. Dereferencing the parameter without a null check. Passing the 'null' value to the 'equals' method should not cause 'NullPointerException'.
V6134. It is not recommended to throw exceptions from the 'equals' method.

Articles

Here is our traditional roundup of blog articles! Over the past two months, we've posted articles exploring vibe coding, breaking down various C++ code nuances, and much more. Here is a full list of articles covering various topics.

C and C++

C

Java

Closed-world assumption in Java

Go

Exponentiation != bitwise exclusive OR

Other

Webinars

Integrating SAST into DevSecOps

As software delivery accelerates, security must move at the same speed. In this webinar, we explored how to effectively integrate Static Application Security Testing (SAST) into your DevSecOps pipeline. The session covered strategies for identifying vulnerabilities early, reducing risk, and streamlining secure development processes.

Also, the session provided actionable insights for teams looking to modernize their security practices and optimize existing workflows.

Let's make a programming language. Intro

We're kicking off a webinar series on how to build your own programming language in C++.

In this first session, we'll break down—step by step and in plain terms—what's inside the "black box": the lexer and parser, the semantic analyzer, and the evaluator. We'll discuss what these components are, why they're needed, and what exactly they do.

All recordings will be sent to registered participants after the webinar is finished.

If you'd like to see more webinars, we invite you to check out upcoming events on the webinar page.

Conclusion

If you would like to receive news about PVS-Studio releases, subscribe to our newsletter.

If you haven't checked your project with PVS-Studio yet, start with a trial license!

How do compilers work?

Unicorn Developer — Thu, 16 Apr 2026 11:46:26 +0000

Even though we write code every day, we often view the compiler as a "black box." Today, let's explore how a compiler actually works, discuss its lifecycle, and see where trees come into play.

Compilers

To put it simply, a compiler is a translation program. It translates human-written text (source code) into machine code, which is a sequence of zeros and ones that the processor can understand.

A machine is, basically, a huge set of switches (transistors). The compiler generates instructions that enable program execution. It decides which switch to enable or disable and when to do so.

By the way, you can see the most basic form of such instructions in a Turing machine, which is a theoretical model where programs are created using only 0s and 1s. This model laid the foundation for modern computers.

If you like more challenging experiments, I invite you to check out our new webinar series, "Let's make a programming language." You'll learn what a programming language is and how to formally describe it so that a machine can understand it.

A language processing system

The compiler consists of multiple modules and is also part of a larger code-processing chain. It takes source code as input and returns binary code as output.

You can see the whole sequence in the diagram:

Let's walk through each stage to understand how the language processing system works.

Preprocessor. First, the source code is passed to the preprocessor that expands macros, includes header files, and removes comments. The code is ready to pass to the compiler only after this preparation.

Compiler. After receiving the processed code, the compiler starts its main routine. However, it doesn't output the machine code right away. First, it produces an intermediate result: assembly code that humans can understand but that is as close as possible to the processor's instructions.

Assembler. Then, the assembler comes into play. It translates commands that humans can understand into real machine code.

Linker. Large programs are usually compiled from many object files. To compile them into a single unit and link all function calls to their actual addresses, a linker is needed. It creates the final executable file.

Another approach to executing code is interpretation. Unlike a compiler, which translates the entire program, an interpreter executes commands line by line.

However, some modern languages, such as Java, employ a hybrid approach. Source code is first compiled into a special intermediate bytecode that is independent of the processor and OS. A special program, the Java virtual machine, executes it, acting as an interpreter.

What's interesting is that Java can also be compiled into machine code, bypassing the virtual machine. However, there are some nuances to this that we discussed in the article "Closed-world assumption in Java."

Today, however, we're going to talk specifically about how a classic compiler works.

How a compiler works

The compiler's work is divided into three stages: code analysis (creating a tree), code optimization, and code generation. Let's walk through each one.

Lexical analysis: From strings to tokens

When we look at code, we automatically break it down into words and see constants, variables, functions, and other parts. Lexical analysis enables the compiler to "read" the code in a similar manner.

Tokenization happens at this stage. The source text is broken down into the smallest meaningful units, which are called tokens. Each token is a pair consisting of a type and a value. A type is a number, an operator, or an identifier, while a value holds specific data, such as 12 or +. Spaces, comments, and line breaks are ignored at this stage because they aren't needed to understand the program structure.

After the lexical analysis, we get a token list instead of a long string of source code. For example, this one:

When parsing code, the lexical analyzer looks ahead by one or more characters. This enables it to accurately decipher the code for a specific language. For example, in the C language, when it encounters the > character, it must check the next character to distinguish the > operator from >= or >>.

Templates in C++ are even more complicated. The Foo<Bar> construct can refer to either a template with the Bar argument or comparison operators. How to tell the difference? The lexical analyzer can't tell on its own; it needs to know that Foo is a template name. To do this, a lexer hack is used, where the lexer uses results from a semantic analyzer that already knows which names are patterns. Modern C++ compilers integrate lexical and syntactic analysis: the parser provides the lexer with information on how to interpret the current token.

Syntax analysis: From tokens to a tree

Now we have a token sequence, but that's not a structure yet. We need to understand how they're connected. This is what a syntactic analyzer, or parser, does. It checks whether the token sequence complies with the grammar rules of the language and, in most cases, instantly generates an abstract syntax tree.

Grammar is a set of rules that describe how to put together expressions and instructions from smaller parts. For example, here's a rule for arithmetic expressions:

This is where the concepts of formal grammars come into play:

The start character is the topmost non-terminal that starts any correct code.
Terminals are the leaves of the tree, the endpoints of parsing.
Non-terminals are expandable tree nodes.

Terminals are actually tokens. In this case, number is a terminal, since it has been parsed into a token by the lexer. For a lexer, the terminal symbols are individual characters, but it groups them into larger units so that the parser doesn't have to parse them individually (for example, it groups numbers into digits).

The parser builds a hierarchy based on the grammar rules. The result is a concrete syntax tree (CST). It even has nodes for such little things as a semicolon or a comma.

Such a tree can be quite cumbersome, so compilers almost immediately convert it into a more compact form—an abstract syntax tree (AST). It contains no service nodes; only the essentials remain: operators, operands, and blocks. When discussing trees in compilers, people most often refer to ASTs.

How does a parser build a tree?

Once the lexical analyzer has converted the 42 + 10 line into the number { 42 }, op { + }, and number { 10 } tokens, the real fun begins. The parser must understand how these tokens are related to one another in order to construct a tree.

Several ways to build a tree exist, such as top-down and bottom-up parsing. They reach the same result from different sides and rely on their own grammar. However, if two different trees can be constructed for the same expression, then the grammar is considered ambiguous. These ambiguities are often resolved simply by the word order. For example, a declarative expression always takes precedence over an imperative one.

The top-down approach Parsing begins at the root (the start non-terminal) and attempts to expand it by selecting the appropriate grammar rules. Among compiler tools such as GCC, Clang, and MSVC, the most common approach is recursive descent: for each non-terminal, a separate function is written to determine which rule to apply.

The parsing process works like this: when the parser encounters the number { 42 } token, it recognizes it as literal-expr and applies the literal_expr() rule. Then, it encounters op { + } and applies binary_expr() to the + operator. After that, it does the same for the second number.

Each parsing type has a class of grammars that it can parse. Left-recursive parsing with leftmost derivation (LL(k)), with a lookahead of k (k is a constant), is a top-down parsing method. Left-recursive parsing with rightmost derivation (LR(k)), with the k lookahead, is a bottom-up approach.

The bottom-up approach This algorithm can handle a wide range of grammars and is most commonly used in BISON and YACC parsers. In this type of parsing, the parser doesn't try to "guess" the rule in advance. Instead, it accumulates tokens and, as soon as they form the right-hand side of the rule, the parser "collapses" them into a non-terminal. Parsing tables are usually used to implement such a parser. It reads the token, consults the table, and decides what to do: whether to move on to the next token or to stack the top few elements into the non-terminal.

Here's how it works, using 42 + 10 as an example:

We read number { 42 } and push it onto the stack.
We read op { + }. As the table shows, it's too early to fold, so we push + onto the stack.
We read number { 10 }. Now we see what we can fold into additive-expr. As a result, one non-terminal remains on the stack—the tree has been built.

If you're interested in seeing how modern C++ can simplify the handling of complex tree structures, I invite you to read the "How to climb a tree" article.

Semantic analysis: Giving meaning to the tree

Although the tree has been built, the compiler still needs to verify that the program makes sense from the language logic perspective. At this stage, it checks everything that grammar can't describe.

Scopes. The compiler must know which declaration each variable use refers to. It creates a symbol table as it traverses the tree. It adds an entry to the current scope when it encounters a declaration and searches for the name in the table when it encounters a usage. It returns an error if it doesn't find the name.

Type checking. Each operator must receive the correct types of operands. For example, the + operator in the 42 + 10 expression works with numbers—everything is fine. But if we wrote 42 + true, the compiler would throw an error, because Boolean values can't be added to numbers. Languages often allow implicit conversions, though. If types can be converted to one another, the compiler adds a special node into the tree, for example booltoint.

l-values and r-values. The left side of the assignment should contain the l-value, which stores the address in memory (a variable or an array element). The 42 constant doesn't have this property, so 42 = 10 is a semantic error. The semantic analyzer tracks this by checking to which node the assignment operator applies.

As a result, the tree "grows" by adding more information. Each node is assigned attributes, including the data type, a reference to the variable declaration, and conversion information. This tree is called an annotated syntax tree and is used for code generation.

The symbol table

During the semantic analysis, the compiler actively uses the symbol table. It's a data structure that stores all information about identifiers. Each entry includes a name, type, scope, and any other necessary information, as well as the memory address if it's known.

The most fascinating part is how the compiler locates names when it encounters the use of an identifier. For more information on name lookup in C++, check out the article "How far does lookup see in C++?"

IR generation

Once the semantic analysis is complete and the tree has been annotated with all necessary attributes, the compiler moves on to the next stage: generating the Intermediate Representation (IR).

IR is abstract code that is closer to machine code but isn't tied to a specific processor yet. It enables platform-independent optimizations that work on any target platform.

The most common IR type is the three-address code. It's a sequence of statements, each one performing a simple operation. Let's look at an example:

The traversal starts at the + root. The generator recognizes that two operands need to be added together. First, it generates code for the 2 left subtree, then for the * right subtree. A new temporary variable, t1, is created for the multiplication. Next, a second temporary variable, t2—which represents the result of the entire expression—is created for the + root. Here are the statements:

t1 = 4 * 3
a = 2 + t1

Optimizations

After parsing the syntax, verifying the semantics, and generating an intermediate representation, the compiler receives linear code that the optimizer can easily work with. At this stage, the compiler tries to optimize the program by making it faster, smaller, or more memory-efficient.

Let's look at this code fragment:

int a = some_complicated_function();
int b = a * 0;
std::cout << "value = " << b;

If the compiler were to simply translate the code, it would first have to evaluate a, then multiply it by zero, only then would it output the b value.

But the compiler knows arithmetic rules: multiplying by zero equals zero. This is true regardless of what a holds. So, the optimizer can fold the whole expression and replace the b variable with the 0 constant. Since a isn't used anywhere else, its evaluation can also be removed. In the end, what remains is:

std::cout << "value = " << 0;

In order to be applied, the optimization must meet the following requirements:

Correctness. The optimization shouldn't alter the program logic.
Performance boost. The optimization should actually improve the performance of most programs.
Reasonable compilation time. Optimization shouldn't make the compiler run for hours.
Executability. The required compiler task must be executable.

The compiler reorders instructions, replaces some constructs with others, and removes unnecessary elements. The result must be the same as if we had executed the source code.

This is where machine-dependent optimizations, such as register allocation, instruction selection, and instruction ordering, come into play to ensure efficient execution.

Note. In fact, static analyzers also create IR and search for redundant code during their execution, but for a different purpose. In some cases, redundancy may indicate a typo or logical error in the code. For example, PVS-Studio issues the V547 warning here, indicating that the last condition is always false.

void x(int a, int b, int c)
{
    if (a < b)
        if (b < c)
            if (c < a)
                foo();
}

Code generation

Once all optimizations are complete, the compiler finally moves on to the most critical phase: code generation. In this phase, the optimized IR is converted into actual machine instructions, including register loads, arithmetic operations, branch instructions, and function calls.

That's when the program transitions from an abstract tree to a sequence of zeros and ones, ready for execution.

Conclusion

At the beginning of this article, the compiler was a "black box" to us. Now, however, we know that it contains a whole pipeline of transformations. The entire process can be summarized as follows:

The intermediate representation lies at the heart of this entire chain. It's created from trees during the code generation phase and serves as the foundation for all further transformations. Optimization tools focus on IR, rewriting the code to make it faster, more compact, and more efficient for specific architectures.

Trees are created during syntactic parsing, assigned attributes during semantic analysis, and serve as the foundation for further transformations. Without them, the compiler wouldn't be able to "understand" the program structure.

If you want to understand the theory and learn how to build such trees yourself, check out our webinar series, "Let's make a programming language." In these coding sessions with Yuri Minaev, a PVS-Studio architect, you'll learn how to formally describe a language so that a machine can understand it.

Developing new static analyzer: PVS-Studio JavaScript

Unicorn Developer — Wed, 15 Apr 2026 13:00:03 +0000

PVS-Studio static code analyzer has been on the market for 18 years now. Over this time, it has grown to support C, C++, C#, and Java. We don't plan to stop at these languages. This article covers the development of a new JavaScript/TypeScript analyzer, which we release very soon.

Introduction

Given the enduring popularity of the ECMAScript language family among programmers, supporting an analyzer for one of the most popular language stacks was only a matter of time. As a stack grows in popularity, so does its ecosystem, and in the case of JavaScript/TypeScript, that ecosystem is the envy of many. As a programmer friend once said: "If you face some problem, there's already a library for JavaScript that solves it."

Competition from both paid and free tools is fierce. So, our goal now is to build a stable and reliable platform that we can steadily develop and expand, eventually catching up to other market solutions. That is one reason we intend to release early: the EAP has already started, and the MVP release of the analyzer is scheduled for this August.

In this article, we explain how the new analyzer works and what new architectural solutions we applied.

Language model

TypeScript tree

Every analyzer starts with a language model—more specifically, with an abstract syntax tree. After all, the analyzer needs some way to work with source code.

We began by tackling this very problem. The choice was clear: as we want both a syntax tree and a semantic model for JavaScript and TypeScript at the same time—plus support from the language developers—the TypeScript compiler has no competition. It can parse both languages, and its support is guaranteed as long as TypeScript itself evolves.

Look at the resulting AST using the factorial function as an example:

function factorial(n) {
  let result = 1;
  for (let i = 2; i <= n; i++) {
    result *= i;
  }
  return result;
}

For this, we get the following tree (see the spoiler).

AST for factorial

SourceFile:
  FunctionDeclaration:
    Identifier
    Parameter:
      Identifier
    Block:
      VariableStatement:
        VariableDeclarationList:
          VariableDeclaration:
            Identifier
            NumericLiteral
      ForStatement:
        VariableDeclarationList:
          VariableDeclaration:
            Identifier
            NumericLiteral
      BinaryExpression:
        Identifier
        LessThanEqualsToken
        Identifier
      PostfixUnaryExpression:
        Identifier
      Block
        ExpressionStatement:
          BinaryExpression:
            Identifier
            AsteriskEqualsToken
            Identifier
      ReturnStatement:
        Identifier
  EndOfFileToken

You can play with it yourself here.

You may also notice small differences between this AST and more "academic" ones. First, the tree contains tokens, even though tokens usually belong to a parse tree. Second, their names reflect visual representation rather than semantic meaning. In the example above, we have AsteriskEqualsToken, but the TypeScript compiler also has a token with the wonderful name DotDotDotToken for the spread operator.

Semantics

A syntax tree alone is not enough. Let's say we want to catch a missed assignment when replacing a character in a string:

function replaceFoo(variable: string): string {
    variable.replace("foo", "bar")
    return variable
}

Here, the result of replace isn't saved anywhere. The analyzer could issue a warning about every replace in the program, but that would produce too many false positives. To ensure that this is the replace we need, we have to verify that it is called on an object of the needed type and that the argument types match the parameter types.

How do we find out the type of the variable identifier? Manually looking up definitions for every identifier node is overkill, and outside such simple cases it's non-trivial—with hoisting it would be much more complicated.

This is where semantic code analysis comes in, helping us find variable types and scopes. And that's another reason we chose the TypeScript compiler. It can:

resolve identifiers and their types for TypeScript;
resolve identifiers and infer types for JavaScript when possible—when a literal was explicitly assigned or JSDoc was used.

In short, the compiler really has everything we need. Still, the adventure is just beginning.

gRPC

The Java team was assigned to develop the new analyzer. Perhaps it's because JavaScript matches Java by 50%. Just kidding. Or not quite kidding.

Anyway, the TypeScript compiler is written in TypeScript (as expected). Less expected is that it'll soon be completely rewritten in Go. This raises two major problems:

Total dependence on a third-party framework is a problem in itself. If the switch to Go caught us off guard, we would have to urgently rewrite the entire codebase in another language or stay on a legacy platform. Not to mention that over decades, open-source solutions may be abandoned.
As already noted, we are a Java team. Our expertise centers around this language—we've been writing in it and analyzing it for years. Switching to a new development language would erase all that expertise.

The solution was obvious—split the analyzer architecture into two applications.

A wrapper over the TypeScript compiler that builds and passes the model.
A Java-based analyzer requests first the AST from the wrapper and then semantic information when needed.

So, we wrap the model built by the TypeScript wrapper into protobuf and then pass it via gRPC. We've written two separate articles (first, second) about the intricacies of this process. Here are the key points:

When passing the model, we translate the original representation into our own.
We also perform normalization—simplifying the tree—to make the analysis simpler. For example, we ensure that ifbranches always have braces, even if the language makes them optional.
We automate the translation from a protobuf-serialized model using code generation—this makes it easy to react to changes and support new language versions.

With this approach, we managed to mitigate the drawbacks mentioned: most development happens in Java, and we can replace the current wrapper for the TypeScript compiler with any other. We'll have to do this when TypeScript 7 is released, at which point we'll rewrite our wrapper in Go to match the compiler.

Common abstract tree

Traditionally, we have built code analyzers by taking a framework in the analyzed language for that same language, and then building the analyzer infrastructure around it.

We used to reuse frameworks mainly for to the surrounding ecosystem—plog-converter and similar tools. Although in some cases we also borrowed analysis technologies, such as data-flow analysis from C++ into our own Java analyzer. The traditional approach had advantages:

It's quite fast: creating a proof of concept takes days if not hours.
When a developer writes an analyzer in the same language it targets, it improves both the analyzer quality and the developer's language knowledge.

But it also had disadvantages:

We would need people proficient in many different languages.
Duplicated functionality must be reimplemented multiple times.
Supporting new languages starts almost from scratch each time.

And that last point turned out to be decisive for us. Besides JavaScript/TypeScript and Go, there will be support for other languages? What? Yes! Stay tuned for updates :)

At this point, a thought occurred to us: why not build a common infrastructure for all languages? Well, most programming languages share many things: variables, control structures, operators, and so on. With a generalized language model, we wouldn't need to duplicate diagnostic rules, and with a common core, we wouldn't need to duplicate all the rest of the infrastructure.

CAT

The idea of a generalized tree is not revolutionary. It's usually called UAST, and JetBrains, for example, uses it for their IDEs. We liked the acronym CAT so much that we named our tree after it: Common Abstract Tree.

The idea is simple:

We don't abandon the AST for a specific language. We still need it if we don't want to lose language-specific details.
However, all nodes of a specific AST inherit common interfaces defined in CAT. If a diagnostic rule doesn't need language specifics, it can work only with these interfaces.
Since we don't want to compromise the analysis accuracy, and language nuances are often necessary, the diagnostic rules allow for extending the general rules with language-specific refinements.

I think we'll release more detailed material on this topic in the future, but for now we'll stick to general principles. We can illustrate the approach with a simplified analog of V6001, which detects identical operands in a binary operation—errors like a == a. Obviously, such a construct is valid in almost any language. It breaks down into typical language "building blocks":

The whole expression is called the same— an "expression".
The comparison operation here is a "binary operation" of "equals" type.
The left and right sides are also "expressions", which in our case have the narrower "identifier" type.

We can roughly understand what we're looking at, but it's not obvious what to do next. So next, let's look at error detection on the tree.

What is a diagnostic rule?

This is how diagnostic rules work.

A tree walker scans the AST of a specific language, stopping at each code element and running checks on them.
For optimization, checks have preliminary filtering based on the type of code element they should trigger on.
If a diagnostic rule finds a suspicious pattern, it issues a warning on that code fragment.

Let's get back to the error above. To find this error, we define a rule. It will check the binary expression's type (multiplication, for instance, is not of interest). It will also check that the left and right operands share the same type, and that these operands are the same. Handling chains of binary operands like a == 0 && b == 0 && c == 0 is less trivial, but the idea is roughly the same.

This pattern can find the error in any language, but that doesn't mean languages can't have their own specifics. In JavaScript, there is a foo && foo.bar && foo pattern. It appears in return statements where we return a variable value from a condition after a preliminary check.

For such cases, we provide several extension points for a general diagnostic rule: before it triggers; filtering intermediate results; and after the rule triggers. In our case, after the rule triggers on identical variable identifiers, we can check whether one of them is the last in the condition, thus eliminating false positives.

And the normal mode of operation—where we write language-specific diagnostics is still available. Given our strong focus on finding typos in code, we needed to keep that flexibility.

How Dr. Frankenstein assembled the analyzer from parts

As we took an unconventional path, our architecture turned out to be noticeably more complex than usual:

At the root, we have an ordinary CLI application written in Java.
The core contains the CAT model and rules for it.
For JavaScript/TypeScript, we have separate modules containing the specific language model and rule refinements.
We can substitute the JavaScript/TypeScript module with a module for another language, reusing the generalized core during the analysis.
The core and language layers also share the surrounding infrastructure, such as report generation.
An indispensable part of the new analyzer is the TypeScript server, which uses the compiler API to build the program model and provide us with the AST and semantics.

We can represent it simply like this:

Despite the increased complexity of the system, from the first tests it performed well.

The innovations didn't stop there. We also use compilation to a native image via GraalVM, which enabled us to switch to the latest Java versions. Also, we use DI based on Micronaut, and overall, we try to keep up with new industry trends.

By the way, this story is amusingly ironic. We have no continuity with the previous Java team that created Java analyzer—we didn't overlap in time. However, a spiritual continuity seems to exist. We independently came to a similar decision: not to follow the beaten path, but to explore new ways of creating analyzers and try to reuse existing work. Only they integrated data-flow analysis for C++ into Java, while we attempted to build a unified platform for analyzing different programming languages.

Plugins

To make it as easy as possible to integrate the static analyzer into the development process, we are developing plugins for the tools developers use. During the EAP, we provide a WebStorm plugin to run the analyzer from the IDE.

At this stage, the plugin allows you to:

run analysis on the whole project;
filter the issued warnings;
navigate through the code, viewing the code that triggered the warning;
view the most interesting warnings using the Best Warnings feature;
mark false positives.

Later, when the MVP is ready, you'll be able to run the JS/TS static analyzer using our Visual Studio Code extension. At the same time, the WebStorm plugin will gain more extensive functionality.

If you don't use WebStorm for development, you can still use the analyzer core via the CLI. You'll also be able to view reports—for example, in our PVS-Studio Atlas tool or in a browser.

Our testing system

For testing JS/TS analyzer, we reused our special tool called Self-Tester. It works with a base of open-source projects, performing regression testing of the analyzer. Here are the steps we follow:

download a specific version of the checked project from a GitHub repository;
build the project;
run the static analyzer via the CLI;
compare the generated report with a reference report for that project.

This approach ensures that useful warnings won't disappear as a result of changes to the analyzer's code.

Currently, the list of projects for the JavaScript Self-Tester is:

As for TypeScript analyzer, we're still working on the list of projects.

Here's an article where we describe in detail how we develop and test diagnostic rules. Overall, nothing has changed for the JS/TS analyzer.

Examples of errors

Well, what story about a new static analyzer would be complete without demonstrating what it can find? Next, we'll show you what the static analyzer found in our Self-Tester base and in various open-source projects.

TypeScript analyzer will be available later than the JavaScript one during the EAP, but we were able to test it ahead of time. Just don't tell anyone :)

So next, we'll look at errors in both JavaScript and TypeScript code.

Findings in ESLint

The first error comes from the JavaScript linter ESLint:

function isFirstBangInBangBangExpression(node) {
  return (
    node &&
    node.type === "UnaryExpression" &&
    node.argument.operator === "!" &&
    node.argument &&
    node.argument.type === "UnaryExpression" &&
    node.argument.operator === "!"
  );
}

The PVS-Studio warning: V7001 The operands of the '&&' operator are equivalent. space-unary-ops.js 109

The analyzer reports identical operands of the binary "AND" expression.

At first glance, it might seem like just an extra check, nothing critical. The method name and its JSDoc clarify the situation:

/**
* Check if the node is the first "!" in a "!!" convert to Boolean expression
* @param {ASTnode} node AST node
* @returns {boolean} Whether or not the node is first "!" in "!!"
*/

This method checks whether the expression is a unary ! operator that contains another unary ! operator. Such a construction of unary operators in JavaScript casts the expression to a Boolean type.

So, what goes wrong here? The expression !!1 at the AST level looks like this:

UnaryExpression (!)
└── argument: UnaryExpression (!)
    └── argument: value (1)

In the code snippet above, instead of checking the outer unary expression's operator, we check only the inner unary expression's operator ! twice.

Findings in Visual Studio Code

Let's move to our dear Visual Studio Code:

this._dispooables.add(
  Event.any<....>(
    _fileService.onDidChangeFileSystemProviderRegistrations,
    _fileService.onDidChangeFileSystemProviderCapabilities
)(e => {
  const oldIgnorePathCasingValue = schemeIgnoresPathCasingCache.get(e.scheme);
  if (oldIgnorePathCasingValue === undefined) {
    return;
  }
  schemeIgnoresPathCasingCache.delete(e.scheme);
  const newIgnorePathCasingValue = ignorePathCasing(URI.from(....);
  if (newIgnorePathCasingValue === newIgnorePathCasingValue) {
    return;
  }
  for (const [key, entry] of this._canonicalUris.entries()) {
    if (entry.uri.scheme !== e.scheme) {
      continue;
    }
    this._canonicalUris.delete(key);
  }
}));

The fragment is quite large, and it's hard to spot the error without hints. You can try to find it yourself if you'd like.

What does the analyzer say? The PVS-Studio warning: V7001 The operands of the '===' operator are equivalent. uriIdentityService.ts 63

To make it clearer, here's the exact snippet with a bug:

const oldIgnorePathCasingValue = schemeIgnoresPathCasingCache.get(e.scheme);
if (oldIgnorePathCasingValue === undefined) {
  return;
}
schemeIgnoresPathCasingCache.delete(e.scheme);
const newIgnorePathCasingValue = ignorePathCasing(URI.from(....);
if (newIgnorePathCasingValue === newIgnorePathCasingValue) { // <=
  return;
}
....

In the conditional statement, the same constant is compared with itself.

This may be the result of a failed refactoring. The changes appeared in this commit. There, similar code was part of the _handleFileSystemProviderChangeEvent method and looked like this:

if (currentCasing === undefined) {
  return;
}
const newCasing = this._calculateIgnorePathCasing(event.scheme);
if (currentCasing === newCasing) {
  return;
}

The erroneous fragment and this one are similar, only the naming differs. And the old snippet didn't have this error: it compared different constants.

That's not the only thing the analyzer found. Look at another code snippet:

private renderQuotaItem(
    container: HTMLElement, 
    label: string, 
    quota: IQuotaSnapshot, 
    overageEnabled: boolean = false
    ): void {
  const quotaItem = DOM.append(container, $('.quota-item'));
  const quotaItemHeader = DOM.append(quotaItem, $('.quota-item-header'));
  const quotaItemLabel = DOM.append(quotaItemHeader, $('.quota-item-label'));
  quotaItemLabel.textContent = label;
  const quotaItemValue = DOM.append(quotaItemHeader, $('.quota-item-value'));
  if (quota.unlimited) {
    quotaItemValue.textContent = localize('plan.included', 'Included');
  } else {
    quotaItemValue.textContent = localize('plan.included', 'Included');
  }
  // Progress bar - using same structure as chat status
  const progressBarContainer = DOM.append(quotaItem, $('.quota-bar'));
  const progressBar = DOM.append(progressBarContainer, $('.quota-bit'));
  const percentageUsed = this.getQuotaPercentageUsed(quota);
  progressBar.style.width = percentageUsed + '%';

  if (percentageUsed >= 90 && !overageEnabled) {
    quotaItem.classList.add('error');
  } else if (percentageUsed >= 75 && !overageEnabled) {
    quotaItem.classList.add('warning');
  }
}

As with the previous fragment, I suggest you find the error yourself first.

The PVS-Studio warning: V7004 The 'then' statement is equivalent to the 'else' statement. chatUsageWidget.ts 102

It refers to the following condition:

if (quota.unlimited) {
    quotaItemValue.textContent = localize('plan.included', 'Included');
  } else {
    quotaItemValue.textContent = localize('plan.included', 'Included');
  }
  ....
}

Both then and else branches are identical, so the check doesn't make sense. Only the project authors know what was intended here.

And we're moving on. Finally, let's look at two interesting spots in VS Code.

Here's the first one:

for (const namedImport of namedImports) {
  const isTarget = 
    namedImport.name.getText() === functionName || (namedImport.propertyName &&
        namedImport.propertyName.getText() === functionName);
  if (!isTarget) {
    continue;
  }
  const searchName = namedImport.propertyName 
                        ? namedImport.name 
                        : namedImport.name;
  const refs = service.getReferencesAtPosition(
    filename, 
    searchName.pos + 1
  ) ?? [];
  for (const ref of refs) {
    if (ref.isWriteAccess) {
      continue;
    }
    const calls = collect(
        sourceFile, 
        n => isCallExpressionWithinTextSpanCollectStep(ref.textSpan, n)
    );
    const lastCall = calls[calls.length - 1] as ts.CallExpression | undefined;
    if (lastCall) {
      localizeCallExpressions.push(lastCall);
    }
  }
}

The PVS-Studio warning: V7012 The conditional expression always returns the same value. nls-analysis.ts 186

It refers to this line:

const searchName = namedImport.propertyName 
                      ? namedImport.name 
                      : namedImport.name;

Regardless of the condition, searchName will be equal to namedImport.name. This fragment should probably look like this:

const searchName = namedImport.propertyName 
                      ? namedImport.propertyName 
                      : namedImport.name;

And the second spot — similar, but in a different place:

const passiveStyles = {
    borderColor: hcBorderColor 
                    ? hcBorderColor.toString() 
                    : observeColor(
                        editorHoverForeground, 
                        this._themeService
                    ).map(c => c.transparent(0.2).toString())
                     .read(reader),
    backgroundColor: getEditorBackgroundColor(this._viewData.editorType),
    color: '',
    opacity: '0.7',
};
const editorBackground = getEditorBackgroundColor(this._viewData.editorType);
const primaryActionStyles = derived(
    this, 
    r => alternativeActionActive.read(r) 
        ? primaryActiveStyles 
        : primaryActiveStyles
);
const secondaryActionStyles = derived(
    this, 
    r => alternativeActionActive.read(r) 
        ? secondaryActiveStyles 
        : passiveStyles
);
// TODO@benibenj clicking the arrow does not accept suggestion anymore
return ....

The PVS-Studio warning: V7012 The conditional expression always returns the same value. inlineEditsWordReplacementView.ts 222

Here it refers to this line:

const primaryActionStyles = derived(
    this, 
    r => alternativeActionActive.read(r) 
        ? primaryActiveStyles 
        : primaryActiveStyles
);

As we dug into the source code, we got the impression that this is the result of a failed refactoring. The following commit introduced many changes, and these lines are among them. Before the fix, this snippet looked like this:

const primaryActionStyles = derived(
    this, 
    r => alternativeActionActive.read(r) 
        ? passiveStyles 
        : activeStyles
);
const secondaryActionStyles = derived(
    this, 
    r => alternativeActionActive.read(r) 
        ? activeStyles 
        : passiveStyles 
);

Now, in the first ternary operator, then and else expressions are identical.

Findings in Overleaf

Let's move to the Overleaf project.

Remember earlier we touched upon the replace methods annotation? That wasn't for nothing. Look at the following code snippet:

/**
 * Sanitize a translation string to prevent injection attacks
 *
 * @param {string} input
 * @returns {string}
 */
function sanitize(input) {
  // Block Angular XSS
  // Ticket: https://github.com/overleaf/issues/issues/4478
  input = input.replace(/'/g, ''')
  // Use left quote where (likely) appropriate.
  input.replace(/ '/g, ' '')                       // <=
  ....
}

The PVS-Studio warning: V7010. The return value of function 'replace' is required to be utilized. sanitize.js 14

If you look at the line highlighted by the analyzer, it becomes clear that there's a typo: the changed value of replace in the second line of the method remains unused.

At first, this error seemed critical to us, as the comments and JSDoc show that this method sanitizes external data. But then it became clear that the line pointed out by the analyzer is only a cosmetic change. This replace formats quotes, replacing closing quotes at the beginning of a phrase with opening ones. Still, if the error had occurred one line earlier, the consequences would have been more severe.

The analyzer found another error in this project:

if (change.isIntersecting) {
  videoIsVisible = true
  if (videoEl.readyState >= videoEl.HAVE_FUTURE_DATA) {
    if (!videoEl.ended) {
      videoEl
        .play()
        .catch(error =>
          debugConsole.error('Video autoplay failed:', error)
        )
    } else {
      videoEl
        .play()
        .catch(error =>
          debugConsole.error('Video autoplay failed:', error)
        )
    }
  }
}

The PVS-Studio warning: V7004. The 'then' statement is equivalent to the 'else' statement. index.js 39

Here, the behavior in both then and else branches is identical. This is likely due to code copying, and the behavior in one of the branches should differ.

In a subsequent commit that touched this file, the behavior was changed, and the issue disappeared.

Finding in Prisma

The next project is Prisma.

The error appeared in the following code:

export function strongGreen(str: string): string {
  return `\u001b[1;32;48;5;22m${str}\u001b[m`
}

export function strongRed(str: string): string {
  return `\u001b[1;31;48;5;52m${str}\u001b[m`
}

export function strongBlue(str: string): string {
  return `\u001b[1;31;48;5;52m${str}\u001b[m`
}

The PVS-Studio warning: V7002 The body of a function is fully equivalent to the body of another function. customColors.ts 5

The analyzer reports that the bodies of the strongRed and strongBlue functions are identical. What's going on inside them?

These functions return specially formatted strings to display styled text in various terminals. They are called ANSI escape sequences. If you've never heard of them, let's see how it works using the return value of strongRed as an example:

\u001b[ is a command that the terminal interprets as a special signal: "a text formatting command is coming".

Then comes the string [1;31;48;5;52m. These are text display settings:

1 makes the text bold;
31 makes the text red;
48 indicates that the following settings will control the background color;
5;52 sets the background to a color from the 255-color RGB palette, corresponding to index 52;
m applies these styles to the text;
${str}is the text to which all these styles apply;
\u001b[m is a command that resets all previously applied styles for the subsequent text.

Let's get back to the error. Both the strongRed and strongBlue functions return the same red text color (31) and the same background color (52).

For strongBlue, the text color obviously should be blue (index 34), and the authors should also consider the background color.

If you're interested, you can read here more about what ANSI escape sequences are and how they work.

Findings in React

Our demonstration continues with the well-known React project.

Here's the code:

for (const property of value.properties) {
  if (property.kind === 'ObjectProperty') {
    effects.push({
      kind: 'Capture',
      from: property.place,
      into: lvalue,
    });
  } else {
    effects.push({
      kind: 'Capture',
      from: property.place,
      into: lvalue,
    });
  }
}

The PVS-Studio warning: V7004. The 'then' statement is equivalent to the 'else' statement. InferMutationAliasingEffects.ts 1771

The same warning we saw earlier, but now in TypeScript code. The expressions in then and else branches are identical. Either this is the result of a failed refactoring, which can be very misleading, or it's a real error.

Finding in jQuery

Finally, a simple error from the jQuery project:

var fullscreenSupported = document.exitFullscreen ||
  document.exitFullscreen ||
  document.msExitFullscreen ||
  document.mozCancelFullScreen ||
  document.webkitExitFullscreen;

The PVS-Studio warning: V7001 The operands of the '||' operator are equivalent. gh-1764-fullscreen.js 13

Here, document.exitFullscreen appears twice in the condition.

Such errors may indicate that, as a result of copying code, the condition contains the wrong value. In this case, it's likely just an extra check. Still, we need to be very careful with such fragments.

Conclusion

We've shown you our big effort—the new PVS-Studio analyzer for JavaScript and TypeScript. But in reality, what we have now is only the tip of the iceberg. Although, as you may have noticed, it can already find errors.

To make the analysis even more advanced, besides the AST and semantics, we still need to implement many more technologies inside the analyzer. There is a whole bottomless ocean of what an analyzer can do:

data-flow analysis;
function annotation;
interprocedural context-sensitive analysis;
intermodular analysis;
alias analysis;
taint analysis;
and much, much more.

In short, we have plenty to do, and the work may never be truly finished. But the more we do, the better and deeper our analysis will become.

However, we've made a great start: we've laid the foundation for JavaScript and TypeScript analyzers, a basic set of diagnostic rules, and a platform for implementing new analyzers. Besides refining the analyzer, we'll implement various integrations and generally improve the user experience.

As part of the EAP, the analyzer for the Go language is also available. We've already posted several articles about the errors we found with it:

Here's another article similar to this one on how to implement your own analyzer for Go.

If you want to try our new analyzers, you can try them here.

With that, we'll say goodbye. See you soon!

New webinar session on how to make a programming language with lexer

Unicorn Developer — Wed, 15 Apr 2026 09:36:59 +0000

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

In this session, we continue building our own programming language from the ground up. Previously, we covered how terminal symbols fit into a grammar. Now we move one layer deeper: the lexer.

The lexer is the part of the parsing pipeline that operates on terminal symbols. It takes a raw input stream and turns it into a sequence of tokens — classifying lexemes into meaningful units. This process, as you know, is called tokenization.

We won't stop at theory. During the webinar, we'll walk through how a lexer is actually implemented in code.

This session is aimed at developers who want to go beyond using languages and start understanding how they work under the hood.

If you missed our previous webinar sessions, don't worry! You can familiarize with them on our YouTube channel or our website.

First talk

Let's make a programming language. Intro on YouTube

Let's make a programming language. Intro on the official PVS-Studio website

Second talk

Let's make a programming language. Grammars on YouTube

Let's make a programming language. Grammars on the official PVS-Studio website

If you want to get the videos earlier, all recordings will be sent to all registered participants after the webinar is finished.

Don't miss the opportunity to create your own language with the experienced developer.

It's going to be engaging and approachable.

Join new webinar!

Let's make a programming language. Lexer

P.S. And don't forget your inbox to confirm the registration!

Changes to PVS-Studio's free licensing policy

Unicorn Developer — Fri, 10 Apr 2026 11:56:04 +0000

We have updated licensing terms regarding the free use of our tool. Here is a breakdown of the changes.

PVS-Studio static code analyzer offers multiple free licensing options. Let's discuss how they will change and what options are now available.

Previously, you could use the analyzer for free by adding special comments to the source code and entering an activation key. Since April 2026, this licensing option is no longer available. If you have been using the analyzer this way, please obtain an activation key via one of the other ways.

The changes affect the free access to PVS-Studio for students and teachers. We have suspended the student licensing program while we update its terms and conditions. Our goal is to create a new academic licensing system that is convenient and easy for individual users and educational institutions to understand.

We will notify you when academic licenses are available again. To make sure you don't miss the news, we recommend subscribing to our newsletter.

Free licensing terms for open-source projects, public security experts, and Microsoft MVPs remain unchanged. You can learn more about them here.

If you would like to check your project using PVS-Studio static analyzer, you can get a trial license.

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

Unicorn Developer — Thu, 09 Apr 2026 11:57:46 +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.

Why C++?

Despite its seemingly archaic nature and complexity, C++ remains the mainstream language for developing games and game engines. The reason lies in the unique balance between low-level control and high-level abstractions, which is critically game development.

On the one hand, C++ provides full control over system resources. Developers can manage every memory byte, optimize processor cache usage, and build synchronization and parallel execution systems tailored for specific architectures. C++ allows developers to create code that efficiently runs on low-end PCs, past gen consoles, or mobile devices. It also makes it possible to manually manage memory and data placement to maximize cache efficiency, which is crucial for achieving high performance.

On the other hand, modern C++ provides powerful high-level abstractions for building complex systems. Features such as classes, inheritance, templates, containers, smart pointers, RAII, and lambdas enable the development of large-scale architectures with modular logic, entity systems, and event-driven mechanisms. When used wisely—without excessive use of templates and metaprogramming—the code remains expressive and maintainable.

Other high-level programming languages, such as Python, JavaScript, C#, and Java, offer undeniable advantages, including automatic memory management, convenient syntactic sugar, extensive standard libraries, and significantly improved readability. This is why they are popular among designers, technical artists, and UI programmers for scripting tasks in games. However, these languages have serious drawbacks when it comes to developing game engines. Their reliance on virtual machines or managed runtime (JVM. CLR, etc), unpredictable garbage collector behavior that can block execution at the worst possible moment, lack of precise control over execution time, dependence on external solutions, and suboptimal memory layout schemes less suitable for performance-critical subsystems.

Such limitations are unacceptable in the realm of game development, especially at the engine level. Garbage collectors, extra memory overhead from virtual machines, or inefficient use of the processor cache can cause random freezes and frame rate drops. Physics simulations, rendering systems, netcode, and core engine logic require predictable performance, maximum resource efficiency, and low tolerance for latency spikes and instability.

C++ remains relevant in the gaming industry, not because it is the best option, but because the alternatives are too abstract to solve the real technical challenges of game systems. This is a conscious trade-off: the language is complex and potentially dangerous, but when used correctly, it offers the efficiency necessary for creating modern games. As long as performance and resource control requirements remain mission-critical, C++ will continue to be a key player in the game development industry.

What is a game engine?

Back in the day, when game engines were simple, writing your own was a no-brainer because if you didn't have an engine, you basically didn't have a game. Some people would buy someone else's engine and enjoy the beauty of reinvented wheels, while others would spend months or even years creating their own.

To understand how, and more importantly why, certain mechanisms are used within a game or engine to identify, locate, and eliminate performance and architecture issues, it's necessary to understand how game engines work and how they are created.

John Carmack once said, "The right move is to build your own engine," though many would argue that it's not that simple. However, Doom's "father" is widely known for his contributions to game engine development. He also frequently criticized off-the-shelf engines in general, advocating for in-house technological solutions. His philosophy is consistent: having an in-house engine gives developers complete control over the technology and the power to create solutions tailored to their projects' specific needs.

Well, everybody's got a point, and there's no single way to do things—it depends on the situation. Perhaps creating an engine isn't as difficult as it seems? But why bother doing it at all? What does it really mean to "create a game engine"?

I've worked with various game engines and built a couple of my own from scratch, two of which ended up in the trash. Three proprietary games were released on my third one but saw little success, and that engine was sold to a studio for some sum 15 years ago. I've seen developers using other off-the-shelf engines, complaining about issues, and devising their own solutions. I've studied—and continue to do so—the source code of other engines, both open-source and proprietary.

My experience may be somewhat biased, though: I've always wanted to create strategy games; however, most of the projects I've worked on have been shooters.

The first key question is: why do you want to do it?

Deciding to create a game or a game engine may seem like either a crazy idea or a genius one. Well, it's actually both. This is one of the cases when the journey is way more exciting than its destination.

...Firstly, secondly, and thirdly, it's a lot of fun, I promise!

Developing an engine is like playing with LEGO, but for adults and usually alone. You can add rendering, particle systems, and hot-reloading for scripts. You'll laugh, be amazed, and possibly even curse, but one thing's for sure: it won't be boring!

...Fourthly, companies will pay good money for such professional experience.

The fact you went through all the trial and error means you've gained something you can't learn in any textbook—a hands-on understanding of how a game engine works under the hood. Real-world experience is the greatest asset in the job market, and game studios are willing to pay handsomely for an in-depth knowledge of how game technologies work. While most people know how to use off-the-shelf solutions, when an issue pops up at the engine level, they need someone who's been there and done that—someone who knows where to look for the root of the problem.

...You'll definitely learn a lot along the way.

This will help you better understand not just engines, but other things as well. You'll develop real engineering intuition, grasp the concept of "heavy algorithms," learn why loading textures in a frame is a bad idea, and what are cache-friendly data structures designed to maximize the usage of processor cache memory.

This kind of knowledge comes from personal experience, not books. When you eventually stop working on your engine—which you most likely will—you will approach game and software development differently.

...By the way, speaking of a trash can...

Based on experience, that's where your first engine will end up, and so will your second one. This is okay—it's just how learning works. You might've heard of the "three systems" rule: the first system is a trial run, the second tries to do everything "right," and the third one actually works. So, don't be afraid to code, get rid of bad ideas, and start over. Each "failed" attempt doesn't waste your time; it gives you invaluable experience that brings you closer to creating that third system that will actually work.

...Your engine is as free as your spare time after work.

As it turns out, it's not free at all. These are hundreds of hours spent in the evenings and late at night. These are internal debates. These are refactorings of what you enthusiastically wrote two weeks ago. These are "nearly functional" prototypes, and while you may say, "I'll finish the UI later," what you gain in return is understanding and confidence in your decisions.

...You can and should change everything to suit your wants and needs.

Want to hot-reload JavaScript configurations? Then you'll need to learn how JavaScript and its virtual machine work. Tired of the old way to load textures? Create your runtime atlas directly from disk files. The only real limits here are your skills and the amount of time you have. Bizarre ideas are good—they create unique solutions.

...You have full control over all the inner workings.

What systems are involved, how the world update works, and what data structure stores game objects. You won't have a "black box," only a call stack and an urge to streamline everything.

...You can use your favorite programming language.

Like Rust? Use it! Prefer C++? Welcome to the pain club. Some people write game engines in Go. I've seen engines written in Lua, Python, Haskell, and even Erlang. I haven't seen one written in COBOL yet, but I bet it exists somewhere. What matters most is that you know why you picked the particular language.

...You can keep the distribution tiny.

For example, the binary file for my pet project is about 2 MB. It contains scripts, settings, and even some assets. The rest loads from the disk. For a small game, this is a luxurious dream, especially compared to engines where even a "Hello World" script weighs 200 MB.

...You can release your engine to the public.

And that's a great idea. Firstly, to see how others use it. Secondly, to find those who can actually compile it. Only a few will succeed—about 0.1% of those who downloaded the engine. They are the right people to bring into your team, though. By the way, Epic Games did something similar: active contributors to Unreal Engine were offered official jobs.

...You can even sell it.

Just be careful, because supporting an engine for other people's whims is a different kind of hell. They'll inevitably ask you to "make it just like in Unity, but different." This is an endless struggle.

...You'll never be disappointed that the engine developers didn't implement the feature you want!

You're the developer here. Want a new navigation system? Implement it. Need to expand the save system? Go ahead. You won't get turned down with these bug report replies like, "Scheduled for Q5 next year."

...Finally, about tech interviews.

Having your own game engine almost always sparks an interesting conversation. Now, instead of just answering questions, you can confidently ask some of your own: "How do you update game objects? How does asset loading work?" At that point, people start listening. They realize they're talking to an engineer who has created their own solution and isn't afraid to discuss it—not just a programmer.

For me, the first two points and the last one are the most important. Learning is fun, learning while creating a game is twice as fun. I also really enjoy programming, pushing the boundaries of what a language allows, and delving into the complex details and subtleties of algorithms and systems. Well, meaningful conversations during interviews are a nice bonus.

Game developers always complain about engines, no matter how powerful and convenient they are: this doesn't work, that is broken, this new feature doesn't support that old one thing, and that old feature was requested ten years ago, but still nothing has been added. Of course, this is all for a reason—if you've ever worked for a big company, you'll totally get what I mean. However, blaming someone else is always easier than taking responsibility. If you need some new feature, why not just implement it yourself? Well, you can't, the engine doesn't belong to you. It's someone else's, but the disappointment is still yours. This is hardly surprising. Just as it's hardly surprising that the desired feature will be added to your engine when you really need it.

By the early 2000s, the term "game engine" had become part of developers' vocabulary. However, most projects were still custom-built, and almost all of the technology was written from scratch, including custom rendering engines, animation systems, and physics engines. It used to be common practice to build an engine tailored to a specific game's genre, platform, and technical limitations. The industry has changed significantly since then: games have evolved into commercially viable, mass-market products, and development technologies have become more standardized and modular. Modern game engines, such as Unreal Engine, Unity, CryEngine, and Source, as well as the proprietary tools of major studios, have evolved into comprehensive SDKs that empower developers to create entire game franchises across various genres on a unified technological foundation rather than just a single project.

Although engine implementations can greatly vary, a relatively stable set of key subsystems had emerged by the mid-2000s: graphics, physics, animation, audio, AI, UI, system logic, replication and networking, in-game scripting, data systems, etc. Moreover, specific patterns and architectural approaches have begun to emerge within these components, recurring from project to project. These include ECS (Entity-Component System), behavior trees (BT), deferred rendering, and rollback-based concurrency control system. However, developers had to gather information on these topics piece by piece: an article here, a talk at GDC there, or a code snippet from GitHub.

There were books on graphics, physics, and AI architecture, but those were just scattered bits of knowledge. Almost no resources tied everything together by explaining not only what these things are, but also how they work under the hood and how to design game architecture while balancing technical limitations and production realities, as they did at GEA.

The second key question is: do you really need it?

Personal projects are always challenging and require crazy amounts of time. Of course, a lot depends on your end goals, but don't expect to build an Unreal Engine clone in a year. After all, it took a team of highly skilled engineers twenty years to develop the engine as we know it today, and the community has also contributed to its development. You'll always feel like something is missing in your own game engine. It takes many years of hard work to achieve even a fraction of capabilities and user-friendliness that mature tools offer.

A custom-built game engine can rarely compete with major industry ones such as Unreal Engine, Unity, CryEngine, or Godot. A game engine can compete only if there's a large, well-funded studio behind it. However, this book is probably not for those folks, since they've likely already got their own tool or are using one of the ones listed above.

Keep in mind that rarely pays off for small teams. There won't be a moment when it suddenly starts generating generous profit. No, it's unprofitable even for industry leaders. Games make money, not engines... According to Epic Games' report, the cost of developing Unreal Engine over the past four years alone exceeded $160 million. It's as if every year they release a new AAA game that we can't even play!

In 99/100 cases, game engine developers never make it to the actual game if their goal is to develop the engine itself. This path leads straight to the game being canceled. Most people may consider someone who wastes time developing their own engine to be a silly person.

Advice

If you want to release your game as quickly as possible, just go with a ready-made engine and use the features it offers. If you want to grow as a developer and lay the foundation for future projects beyond game development—and if you have enough time, energy, and patience—then go for it! A custom-built game engine is probably the best way to apply your knowledge. Plus, once you've created a solid base, you can reuse it as much as you want, improving it with each new game.

Libraries + cmake != Engine

Since you've read this far, I haven't convinced you to quit this thankless job. Well, let's move on then...

Can we call SDL/SFML/Allegro game engines, considering that tons of indie games have been made using them? Definitely not—these are libraries for wrapping platform code, although they do enable many of the basic game engine features. What about Vulkan/DX12? Absolutely not—these are graphics APIs. And what about FMOD/WWISE?

Again, no—however, they can be used to create a two- or three-dimensional scene, albeit an audio one. So, let's summarize:

Libraries + API != an engine either

Now, imagine a small project about exterminating spiders and building a base on another planet, which combines Allegro, DX11, and stb (a set of different header-only solutions for all kinds of situations) to draw moving sprites on the screen. You probably recognized Factorio from this description. It all started with the demo version on Allegro and just a few sprites:

Allegro + API + stb + talent == Factorio

Is it a game engine? The answer is still no, but we're getting closer: a game engine doesn't exist without a game (or games) built on it. Until a game is released, it's just a set of libraries glued together using CMake. Can a game engine be just a combination of graphics, animation, and user input processing? So, the conclusion is as follows:

Factorio != the engine && Factorio == the game

A game engine without a game is just a collection of tools, libraries, and other components designed to help create games. A game without an engine is still a game. If you think that such a definition of an engine without a game is vague and almost useless, you're right.

Do you really need complex material editors and miles of shaders, seamless geometry and global illumination for it, 3D physics with inverse kinematics, and network game support if you're making a 2D pixel-art platformer?

Unreal Engine has all these features, and they work pretty well, but do you really need them all? They require experience, time to get used to, and knowledge of how to configure and use them. A simple platformer game must only handle input, render sprites, maybe even display raw .png files on the screen, and play sound. You can learn all this in a couple of days from free tutorials on YouTube. You'll spend these evenings doing something useful, rather than struggling with the character controller in the editor. Finally, you've reached the main point of the whole endeavor—creating your game.

But what if you'd want to create an AAA blockbuster with next-gen graphics, physics, and so on? Well, then you'd need all these complex systems. It would also take a few decades of free time, or a team of talented engineers working full-time exclusively on the engine, to bring it all to life. Yes, modern game engines have indeed moved hopelessly far away from retro platformers.

Still, most game engines have an architecture that integrates all these subsystems into one framework. Not all of them—at least not yet—but it's important to understand that a game engine can contain only some of these features and still be considered a game engine. Not every game needs all these features at once; otherwise, no indie game would ever be released. You can design a small engine specifically for your game. But let's be honest—big game engine capabilities spoiled us, so we expect the same performance from everything else.

Some useful stuff

However, if the engine was designed specifically for a game, then having fewer features is perfectly acceptable. No matter how you develop games—whether on your own or someone else's engine, from scratch, or building on the ruins of a previous project—you'll start to notice recurring patterns. Everything that seemed like a "temporary solution" at first will eventually either become part of the foundation or be tossed in the trash. This is how the standard set of essential components emerges. First things first—when it comes to visual level and UI editors—no need to manually write levels, even if it's just a quick prototype in an evening.

When you already have something moving on the screen, the next issue inevitably appears—updating the logic. A rather simple approach is to put everything in the update function (Game::Update()), updating whatever reaches it in time. Then, you add the update priority, followed by the dependencies between systems, and then the question arises: if physics runs separately, what about the collision-based logic? Even if the game is small, it's better to design the logic as an independent system than as a series of "crutches" dependent on the array element order. Components work best if they know nothing about each other—they subscribe to events and don't care what invokes them.

Next comes the universal issue of the scene/level system. It seems obvious: you have a menu, gameplay, and cutscenes. However, when a level loads within another level, then one game mode switches to another without exiting to the menu; when it's necessary to "freeze" a scene, overlay a tutorial, and then return back—that's when the scene system falls apart if it wasn't designed for these cases. A scene isn't just a list of objects; it's a managed container of logic, data, dependencies, and transitions.

Speaking of objects, it's impossible to overlook the entity manager. Though it may seem useless and redundant at first, it proves to be the core of the entire architecture: It's responsible for creation, destruction, identification, tagging, access to components, and sometimes even debugging.

By the way, when it comes to saving, there's a game state serialization system. Some people think the only reason to use it is to save the game, but it's actually essential for everything. Auto-saving, passing states between scenes, saving configurations, replays, and rollbacks—it's amazing how many problems disappear when you can "put everything in a box and restore it."

And finally, the variable inspector. I'm not referring to a full-fledged debugger, but rather a panel where you can see variable values, ticks, and flags in real time. Where you can pause to check what a specific NPC is doing, change its behavior, enable debug information, and see how many bugs disappear simply because you finally noticed what's going on in the game logic.

Programming

It may seem strange, but traditional programming practices aren't mandatory for implementing game logic, and it'd be enough to explore visual programming systems (Blueprints, VisualScript, and ICS), which have been around for decades and allow developers to create complex mechanics without writing code manually. These systems are especially popular among designers and artists who want to prototype ideas quickly, without diving into the programming language syntax.

Designers do write code; visual programming is a legitimate form of programming, it's just that constructs like class, if, and for have another form. However, the essence lies not in forms, but in practical aspects. If you want to implement visual scripting in the game engine, you'll need to create specialized tools: node editors, visual debuggers, data-flow diagrams, optimizers, and much more. This significantly complicates engine development. For example, in Unreal Engine, Blueprints are backed by a huge amount of low-level C++ code, comparable in scale to the renderer or animation engine.

Classic code remains the most versatile and flexible way to implement logic, but it's gradually losing ground. It doesn't depend on the limitations of visual tools and allows working closer to system-level resources. However, the classic approach entails well-known problems, such as recompilation, halting the engine for rebuilds, and the time lost in these processes. And it's worth noting that training designers to work with different programming languages (for example, C++) results in high financial and time investment, and the cost of a mistake is the same as for a game programmer—an error can still crash the engine.

Main window

Most games need a window to run in—even browser games are no exception here. The window can be either the entire web page or a specific <canvas> element where the game is executed. Windows are usually created using platform-dependent mechanisms. These low-level interfaces are often cumbersome and inconvenient. What's more, you need to write separate code once for each platform (Windows, Linux, macOS, iOS, or Android) to create a window—but you rarely revisit this block afterward.

You need not only the window; there is also a graphics API context (OpenGL, Vulkan, or DirectX), which is also created via messy platform-dependent calls. Once again: you either implement them once yourself, or use a ready-made library (SDL2, GLFW, SFML, or one of many others). After creating the window, the next step is to set up the game loop—this is what will handle events, update the game logic, and render each frame.

Gameplay loop

The gameplay loop is what unites all games and game engines, although it may be veiled within the engine, replaced by abstractions or handler functions (callbacks). Ultimately, the gameplay loop code looks like this:

int main()
{
  createWindow();
  init();

  while (isRunning())
  {
    handle(inputEvent());
    updateFrame();
    drawFrame();
  }

  shutdown();
  destroyWindow();
}

The gameplay loop runs the game—without it, the main function would just end, causing the game to crash. There are many ways to expose a loop using the engine's API: it can be fully explicit, when the engine user writes something like while(engine::isRunning()) in their main function, or find it in the depths of the engine, for example, in some function like engine::run(), which in turn calls some user-defined functions (callbacks). Whatever you choose, you'll still need a gameplay loop.

User input

This is one of the foundations of any game, even if the player only has to click a pixelized cookie. The most basic input processing relies on platform-dependent APIs (WinAPI, X11, or Cocoa), which are often awkward to work with: they're not complex, but very verbose and require separate code for each supported platform. However, almost all of these APIs can extract events into an event-handling function (for example, Game::pollEvents()), which can be used to retrieve user events sequentially.

When it's time to integrate input into the game engine, you can use various approaches. One option is to provide users with direct access to the event system. In this case, the game developer calls events via pollEvent() and decides how to handle them. The basic structure of event processing usually looks like this: in the gameplay loop, the event-handling function is called at each iteration, parsing all incoming events are sequentially. Depending on the event type, the corresponding functions are called or appropriate actions are performed—for example, handling mouse movement, keyboard input, or window closing. This approach provides maximum flexibility but requires the developer to write numerous code lines and understand the event structure.

In practice, most game developers rely on cross-platform libraries or built-in input systems in game engines like Unity, Unreal Engine, or Godot. These solutions handle the low-level, messy interaction with the OS and expose a unified and user-friendly interface for processing keyboard, mouse, gamepad, and touch input. Here's an example:

while (engine.isRunning())
{
  Event event;

  while (engine.pollEvent(event))
  {
    switch (event.type)
    {
      case Event::MouseMove: 
        application.onMouseMove(event.mouseX, event.mouseY);
        break;

      case Event::KeyPressed:
        application.onKeyPressed(event.keyCode);
        break;

      case Event::WindowClose:
        engine.quit(); 
        break;
    }
  }

  engine.update(); // Game logic
  engine.render(); // Frame rendering
}

Another option is to integrate event handling directly into the engine and provide the user only with calls to handler functions. It accelerates and streamlines early development. However, it requires a well-designed architecture for registering these functions.

This approach makes life much easier for game developers, especially at the early stages of a project. Instead of manually querying input devices and processing complex event logic, developers simply register handlers for the events they're interested in—key presses, mouse movements, or screen touches.

The appropriate handlers are invoked at the right moment, with all the necessary event information about passed to them. This approach works well for simple games and prototypes, where rapid development is a priority and complex interaction logic isn't yet required. Popular libraries (frameworks) implement this event-driven model, but as a project grows in complexity, this architecture can become a source of problems. The main difficulty lies in creating a flexible system for registering and managing event handlers—callbacks must be easy to add and remove during execution, priorities may need to be set, and events may need to be filtered by game context. With many registered handlers, each event can trigger a chain of calls that were not initially anticipated. Here's an example of code:

void onMouseMove(MouseEvent event) {
  application.onMouseMove(event.mouseX, event.mouseY);
}

void onKeyPressed(KbEvent event) {
  application.onKeyPressed(event.keyCode);
}

void onWindowClose(AppCloseEvent ev) {
  engine.quit();
}

int main()
{
  engine.subscribe(onMouseMove);
  engine.subscribe(onKeyPressed);
  engine.subscribe(onWindowClose);

  while (engine.isRunning()) {
    Event event; updateFrame();
    engine.update(); // Game logic
    engine.render(); // Frame rendering
  }
}

Graphics

You got the main window and even teach your program to react on mouse and keyboard, but... You can't see its response—graphics comes to the stage. Honestly, I struggle with 3D graphics and am always jealous of my friend, @megai2, who can easily render everything for any platform, from consoles to mobile devices. Fortunately, most libraries for creating windows, like SDL, already provide support for 2D graphics. You can draw directly to the window, use textures, or even fill pixels with any colors. It's basic but honest.

Let's say the engine is optimized for 2D games built around tiles and sprites. Then, most likely, you'll have to implement something like drawSprite(image, x, y), possibly with support for all sorts of delightful features: scaling, rotation, blending, desaturation, and alpha blending. Internally, you can manually implement it either by directly copying pixels (with/without evaluations and blitting), or by relying on another library like Cairo. It turns out to be a very good renderer, capable of doing if not everything, then at least a great deal. You can also do it via OpenGL/DX/Vulkan, if your heart craves hardcore performance.

That's not the only option, you might also choose not to specialize at all and simply give the user a set of general-purpose APIs for the engine, as most SDL/SFML/Allegro libraries do—let them figure it out for themselves. In my implementation for the Pharaoh project, there is a wrapper over SDL (which supports native GAPI), but there is no full-fledged renderer in the usual sense. I wrote a new rendering system for each engine. On the one hand, it wasn't easy, but on the other, I had a chance to experiment with graphics to my heart's content.

No matter how the rendering system is built, sooner or later, you'll need to display text for the interface, debugging information, and other purposes. Yes, you can draw letters manually pixel by pixel, but it's better to use a standard library like FreeType. For eager fans of bizarre adventures and Unicode, HarfBuzz is worth exploring.

Resources

Once upon a time, you finalize another level, try to run the build, and... it takes about a whole minute to run. Then two. And then you notice that some stage "weighs" 2 GB, because each tree is an object with a unique copy of texture and models. That's when it becomes clear: it's time for resource management.

Resource management is hidden from users, but defines whether the game will be responsive and even run at all. First, it would be wise to pack resources into archives: opening a thousand files from a disk is a major drawback of OS interaction. The platform may be slow, the file system may not be very responsive, and the player's SSD might not match what you expected in the studio.

Therefore, everything gets packed: textures, models, sounds, levels, and scripts. Using a custom container format with indexing and compression is widespread, but some people use ready-made ones like Oodle, ZIP. Others create virtual file systems tailored to the engine's needs. Large commercial engines, by the way, usually follow this path. Archives are easy to distribute, easy to cache, and no one digs around... except the ones who really want to.

For example, you can compile all resources into one large binary blob and embed them into the executable file, as many games have done and continue to do. That's what Xbox and Sony did at first. What are the advantages? Everything is on hand and fast—no extra loadings, no paths to files—just grab a byte array and work with it as you would with a resource. In some projects, this approach quite literally saved releases and helped pass certification. Sure, that might leave you with a 700 MB binary file, but it's all because of the "my cat fell on the keyboard" moment and "the junior who wrote the templates crashed everything.".

Indeed, there are drawbacks: you can't change any asset without recompiling the entire game. Even if you just want to adjust a pixel color in a texture, you have to wait for a rebuild. It also makes modding virtually impossible: how would players add their funny custom hats if all content is "sealed" inside the .exe file?

You can store resources as regular files in the assets/ directory next to the executable file. Then the engine simply loads the necessary file when the level starts, if you haven't factored in performance. This is the best approach for development: it's fast, clear, and you can open the folder at any time, swap a texture, and see the changes in the game. And it's also a real gift for modders: they can just take it, tweak it, add to it—everything is open.

Regardless of how assets are stored, they still need to be converted from raw bytes into meaningful data. For this, you typically rely on format libraries—for example, stb_image to convert PNG to pixel arrays or various JSON libraries to extract information about entities from .json-like configuration files, if you haven't yet become disillusioned with JSON as a format for such files. At some point, the team realizes that a purely declarative configuration format is not enough, and then a VM (Virtual Machine) for JS/Lua/Squirrel/AngelScript is added to the engine. These are scripting languages, but in this context, they're used for parsing configurations.

In many projects, developers eventually move to custom formats or adopt a higher-level language, which, in practice, also leads to using a virtual machine or interpreter.

And you can—I would say you should—enable hot reloading of assets as a second step after the configurations, so that you don't have to restart the game a thousand times a day. You change the picture, sound, or configuration, and boom—they're right in your game. Pure magic? No, it's just another reason why the resource manager grows into a monster that affects the entire engine.

Resources aren't just a development concern—they also play a key role in the release process. The system must generate builds for different platforms: Windows, Linux, consoles, Steam Deck, and others. Each platform comes with its own constraints and requirements for data alignment, supported formats, and packaging rules. For example, some platforms do not allow MP3 files, while others do not support certain texture formats.

Finally, one of the trendiest and most important features is automatic updates and patches. The player must not have to download extra 10 GB if you changed one texture. My build system calculates deltas: which files have changed, how they can be compressed, and where to place them. The launcher checks versions and downloads only what is missing. And if something goes wrong, it can roll back. And honestly, players appreciate this more than almost anything else, when the game "updates itself and just works".

Audio output

In case you didn't know, audio output is a nightmare with platform-dependent APIs. They're ugly, unintuitive, and downright capricious; XBox has a habit of throwing exceptions if you write too much to the buffer, but... well, if you write less than the buffer's allocated size, it'll throw exceptions too. Audio output is just my hobby...I mean, I'm not an expert here, but even a little hands-on experience was enough to understand: if you just want to reproduce sound, get ready to suffer.

Or... you can just use a library that hides all this nightmare behind a clean interface, for example, OpenAL or SDL. Recently, I've been using the latter because it's very forgiving of mistakes, even if you blundered. These libraries usually expect the engine to provide the audio callback, a function that the system will call (usually from a separate thread) dozens or even hundreds of times per second.

Each call requires returning a small chunk of audio data. Maybe you just want silence. Maybe a single MP3 playing in the background. But most likely, you'll need a little more: music, effects, voice. Each in different streams, with different volume, with smooth fades, no clicks or pops, no tremors, add some reverb or other effects... well, you catch the point.

To ensure its stability, you need a mixer. Not a cooking machine, of course (though sometimes that wouldn't hurt), but an audio mixer—a library that will combine multiple audio streams into one, carefully control their volume, filter sharp peaks, apply effects, and prevent the sound from turning into a mess when a battle breaks out with 15 different unit sounds, fanfare, and alarming music.

A good engine usually implements its own audio mixer. It can be large and complex—with crossfading, reverb, effects, and post-processing—or it can be simple, with just a few channels and background music. But the idea is always the same: the mixer works with abstract sound streams, combines them, and produces a single output stream sent to the audio device.

Writing your own mixer at least once is a great way to understand how it works. Of course, you can also rely on existing libraries that already handle mixing, balancing, compression, and other audio processing tasks.

Physics

To be honest... most games don't actually need physics. I mean real physics—with forces, momentum, friction, and all that scientific stuff. Most people want something simpler: animations, logic, and scripts—things that look like physics without having much to do with it. For example, look at Civilization VI, one of the most complex strategy games of our time—the game has no need in physics implementation at all. Or take a peek at various city-building simulators (such as SimCity)—obviously, houses don't collapse, roads don't crack, and no one calculates the fall vector of a water tower because it's not necessary. So, why complicate things? Yet, somehow both Civ and Cities Skylines drag dependencies onto PhysX, maybe they actually use them, maybe not. Who knows.

Platformers or 2D RPGs don't need much physics too—it usually consists of character movement and simple collisions with walls, enemies, and boxes. You can write that in a couple of evenings, unless, of course, you get stuck on every line, as I did, trying to wrap my mind around it. The main thing is that everything will be under control: if you want the hero to slide like they're on ice, please do so. Enemies should bounce off when colliding like rubber ducks? Come on, give it a try.

If collisions start pilling up and performance drops, you can optimize it. Spatial hashing, quadtrees, and distance constraints from MC. But... if you're stubborn and know for sure that you need real physics, go for a ready-made library: Box2D for 2D or Bullet for 3D. Don't reinvent the wheel; you will have plenty of time to create them on the self-written engine.

And if you want to understand how such engines work under the hood, it's best to watch a YouTube video from the Box2D creator. He explains physics with impulses in a way that provides a rare insight into the mechanics. I used to think that physics was about mass, speed, and formulas, but now I know that real physics is when you're up at 3 a.m. trying to figure out why a character is stuck on a staircase because the collision mesh didn't load.

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.

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

Unicorn Developer — Tue, 07 Apr 2026 11:48:38 +0000

We're happy to present the first part in a webinar series on creating your own programming language. If you've ever wondered what it takes to build your own language from scratch, this series is for you.

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 creating your own programming language, step by step.

Why would you want to create your own programming language?

You may ask us or our speaker, "What's the point? There are plenty of other languages!"

First of all, it's fun! Plus, if you want to enhance your programming skills and truly understand how your favorite language works, building a programming language can provide foundational knowledge of compiler internals and foster a deep appreciation for language design and implementation.

What's in the "black box"?

The webinar outlines the entire structure of a compiler or an interpreter, focusing on the "black box" that transforms human-readable source code into executable output or runtime results. Yuri briefly covers its core components:

lexer that divides the input into smaller parts—tokens—and tags them;
parser that operates on grammatic rules to understand the input and uses those tokens to build a syntax tree;
semantics that gives the syntax meaning and recognizes function names, data types, etc.;
evaluator that is a part of an optimization pipeline.

In the first session, Yuri introduces these concepts at a high level; future webinars will delve deeper into all aspects of the language under the expert guidance of our speaker. Everything will be explained step by step, so you can easily follow along.

Want more?

If you want to familirize with other webinars or see the whole webinar, follow this link.

You can also sign up for our upcoming webinars, for example: Let's make a programming language. Lexer. During the webinar, Yuri will walk you through how a lexer is actually implemented in code.

If you'd like to look closer what we do, check out our website.

We hope to see you there!