DEV Community: Unicorn Developer

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

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

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

About the speaker

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

The lexer in action

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

How the lexer works in C++

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

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

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

Want more?

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

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

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

See ya!

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

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

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

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

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

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

How does it work?

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

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

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

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

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

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

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

Let's put it into practice

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

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

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

Then, generate files for the Ninja build system:

cmake -B build -G Ninja

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

cd build
ninja tls

The build starts, and the analysis begins.

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

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

Some trickery

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Will the old analysis options remain?

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

Static code analysis and software time to market

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

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

How static analysis speeds up time to market

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

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

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

Why the quick approach is flawed

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

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

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

Economics of bug detection: the earlier, the cheaper

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

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

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

Static analysis does not replace other methods—it complements them

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

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

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

Real-life cases and measurable results

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

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

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

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

Applying the Shift Left approach

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

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

ROI

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

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

PVS-Studio tool as an example

Figure 3. PVS-Studio.

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

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

Conclusion

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

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

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

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

Error handling in Go: Common pitfalls

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

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

Introduction

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

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

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

Common approach to error handling in Go

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

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

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

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

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

But then why do we need panic and recover?

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

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

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

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

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

How to make mistakes when handling errors

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

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

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

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

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

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

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

So, the fix might look like this:

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

The second if block checks the error that Put returns.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

resp, err := c.List(opts)

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

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

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

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

Conclusion

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

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

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

Take care of yourself and your code!

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

What's new in Java 26

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

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

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

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

So, what's new in Java 26?

JEP 500 Prepare to Make Final Mean Final

The JEP link.

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

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

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

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

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

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

JEP 504 Remove the Applet API

The JEP link.

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

Here's the whole timeline of the applet removal:

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

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

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

JEP 517 HTTP/3

The JEP link.

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

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

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

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

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

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

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

The benefits of using HTTP/3 include:

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

JEP 526 Lazy Constants (Second Preview)

The JEP link.

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

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

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

In the second preview:

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

JEP 529 Vector API (Eleventh Incubator)

The JEP link.

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

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

What's vector computation?

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

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

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

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

The JEP link.

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

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

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

The after:

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

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

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

Here are some examples of uncompilable constructs:

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

Or:

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

Summary

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

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

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

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

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

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

Introduction

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

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

What is virtuality?

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

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

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

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

1. Static/early binding.

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

2. Dynamic/late binding.

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

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

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

Virtual functions

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

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

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

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

Full code fragment

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

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

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

};

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

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

Program output
Compiler Explorer

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

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

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

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

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

Full code fragment

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

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

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

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

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

Program output
Compiler Explorer

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

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

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

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

Virtual function table (vtable)

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

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

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

The chart below illustrates the process:

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

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

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

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

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

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

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

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

Note: all examples use the Clang compiler.

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

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

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

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

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

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

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

Full code fragment
Compiler Explorer

#include <iostream>

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

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

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

Base bs;
Derived dr;
Derived1 dr1;

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

Virtual pointer (vptr)

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

How the pointer works

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

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

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

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

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

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

You can see our code represented in the following chart:

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

Now we create a class instance via calling:

Base* bs = new Derived();

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

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

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

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

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

Full code fragment
Compiler Explorer

#include <iostream>

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

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

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

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

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

The alignment and vptr

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

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

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

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

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

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

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

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

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

Inheritance and virtuality

The diamond problem

Look at the following example:

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

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

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

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

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

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

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

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

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

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

hero.id = 1;

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

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

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

Full code fragment
Compiler Explorer

#include <iostream>

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

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

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

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

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

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

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

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

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

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

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

Full code fragment
Compiler Explorer

#include <iostream>
#include <cstring>

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

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

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

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

int main()
{
  Player hero;

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

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

Program output

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

Virtual inheritance mechanisms: vbptr, vbtable, VTT

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

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

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

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

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

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

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

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

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

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

The VTT operation follows this algorithm.

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

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

The pitfalls of virtual inheritance

Pointer casting

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

Look at this example:

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

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

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

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

Full code fragment
Compiler Explorer

#include <iostream>
#include  <cstring>

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

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

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

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

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

Program output

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

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

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

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

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

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

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

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

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

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

Casting to void*

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


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

Look at the program output.

Program output

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

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

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

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

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

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

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

}

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

Full code fragment
Compiler Explorer

#include <iostream>
#include  <cstring>

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

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

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

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

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

}

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

Empty Base Optimization with virtual

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

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

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

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

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

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

Let's check the size of the Base class.

Program output

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

We can put it like this:

Compiler Explorer layout

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

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

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

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

Full code fragment
Compiler Explorer

#include <iostream>
#include  <cstring>

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

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

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

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

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

Performance impact

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

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

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

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

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

Is virtuality worth it?

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

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

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

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

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

Conclusion

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

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

AI integrations: Rely or verify? Checking Semantic Kernel

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

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

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

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

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

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

Let's start breaking down suspicious spots!

Misplaced priorities

Code snippet 1

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

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

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

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

To fix it, the author needs to add parentheses:

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

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

Code snippet 2

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

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

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

Forgot something

Code snippet 3

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Code snippet 4

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

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

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

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

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

return new(results.ToAsyncEnumerable());

Code snippet 5

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

  this.Steps = [.. steps];
}

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

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

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

Array index out of bounds

Code snippet 6

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

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

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

  return truncationIndex;
}

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

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

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

Issues with null

Code snippet 7

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

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

public required KernelProcessStepState State { get; init; }

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

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

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

Code snippet 8

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

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

  var mediaTypeMetadata = requestBody.Content[mediaType];

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

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

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

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

Code snippet 9

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

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

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

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

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

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

Code snippet 10

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

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

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

The PVS-Studio warnings:

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

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

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

Conclusion

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

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

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

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

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

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

What's the talk about?

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

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

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

Learn more: How do compilers work?

Want more?

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

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

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

We hope to see you there!

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.

DEV Community: Unicorn Developer

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

About the speaker

The lexer in action

How the lexer works in C++

Want more?

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

How does it work?

Let's put it into practice

Some trickery

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

Will the old analysis options remain?

Static code analysis and software time to market

How static analysis speeds up time to market

Why the quick approach is flawed

Economics of bug detection: the earlier, the cheaper

Static analysis does not replace other methods—it complements them

Real-life cases and measurable results

Applying the Shift Left approach

ROI

PVS-Studio tool as an example

Conclusion

Links

Error handling in Go: Common pitfalls

Introduction

Common approach to error handling in Go

How to make mistakes when handling errors

Conclusion

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

What's new in Java 26

JEP 500 Prepare to Make Final Mean Final

JEP 504 Remove the Applet API

JEP 517 HTTP/3

JEP 526 Lazy Constants (Second Preview)

JEP 529 Vector API (Eleventh Incubator)

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

Summary

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

Introduction

What is virtuality?

Virtual functions

Virtual function table (vtable)

Virtual pointer (vptr)

How the pointer works

The alignment and vptr

Inheritance and virtuality

The diamond problem

Virtual inheritance mechanisms: vbptr, vbtable, VTT

The pitfalls of virtual inheritance

Pointer casting

Casting to void*

Empty Base Optimization with virtual

Performance impact

Is virtuality worth it?

Conclusion

AI integrations: Rely or verify? Checking Semantic Kernel

Misplaced priorities

Forgot something

Array index out of bounds

Issues with null

Conclusion

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

What's the talk about?

Want more?

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

The markus project

Vibe coding issues

Is an expert needed?

Why am I so strict about AI?

SIMD-friendly code

String comparison: the beginning

String comparison: the worst

The price of beauty

What else?

Forgetfulness

You're only as good as the company you keep

Creating temporary proxy objects

A copy instead of a move

Manual sunset

Conclusion