Forem: Armaan Chahal

Coroutines & Concurrent HTTP and a Templating Engine in C++ (Part 2)

Armaan Chahal — Tue, 16 Dec 2025 04:18:49 +0000

Intro

Today we'll cover asynchronous programming in action with Boost.Asio and coroutines.
This will level up your server from lowly, blocking calls, to a snappy concurrent process.
As a bonus, we'll cover templating at the end, which is a nice and easy way to wrap up the series.
If you want to skip the lore dump, skip to the code.

Getting Started With Concurrency

If you haven't yet, read part 1 for more info on the fundamentals of raw HTTP in C++.

Yes, half of Boost.Asio is concurrency; the other half is I/O (networking in particular).
Therefore, you may assume that Asio would make concurrency easy.
And you'd be right! With the power of Asio and C++ Coroutines, writing concurrent networked code is relatively easy!

We'll end with the templating engine, as that is quite short and a fun way to wrap up this series.

The Idea

We're talking about coroutines here. Asio sorts of amplifies the power of coroutines but doesn't necessarily change the core philosophy.
Traditionally, in a multithreading environment, you have multiple hardware threads that each execute work in true parallel.
This number is limited by your CPU, usually from 4 to 24 threads on modern desktops (half as many cores, but hyperthreading!).
On the OS level, the number is much greater. But those aren't truly parallel threads. The OS performs context switching between threads,
essentially giving each thread a slice of time to execute. For example, if you have 1 thread that takes 1 second to execute,
you could split that up into 1000 OS threads that each take 1 ms to execute. However, your CPU doesn't actually have 1000 hardware threads,
so the OS gives each thread a slice of time to execute.

Coroutines are slightly different. Forgetting about Boost.Asio for a moment, C++ coroutines have nothing to do with threads.
They don't necessarily enable parallel work, but they do enable asynchronous and concurrent work.
Coroutines are a lightweight language construct in C++, not an OS or hardware level feature.

A popular analogy for coroutines is a chef in a kitchen. When a chef prepares a pizza, he must prepare the dough and ingredients first,
but then he puts it all into the oven. Once the oven goes, the chef waits for 10 minutes for the pizza to cook. Then, he takes it out and gives it to the waiter.
This is a traditional, single-threaded approach. There is a blocking event in the middle, waiting for the pizza to cook.
There is a way to optimize this even without threads. We limit ourselves to one chef, so that means only 1 thread.
When the chef puts the pizza, he can simultaneously start working on the next pizza. This can enable him to do orders of magnitude more work than before.
All without parallelism.

This is the essence of coroutines. The keyword co_await allows you to suspend the coroutine until some asynchronous event occurs.
Not only does it suspend the coroutine, it signals that we can start working on some other task until we receive the value from co_await.
This is analogous to the chef working on the next pizza after putting the pizza in the oven (the chef co_awaits on the result from the oven).

The other coroutine keyword is co_yield, which we won't need here. It is similar to co_return, except you can resume a co_yield later.
Imagine you have a for-loop, each iteration yields a value, but you can resume the for-loop if you wish after receiving a value.
co_yield is used commonly in generators, which we won't need to make. There is the aforementioned co_return, which
returns a value from a coroutine.

Specific to Boost.Asio, there is co_spawn, which spawns a new coroutine (techinically, it schedules a coroutine on an executor).
You may be wondering why we can't do this through regular C++.
C++'s coroutines are just a language feature with syntax and compiler hooks. The way to "spawn" a coroutine is to just call the function,
but without a schedular, nothing drives or resumes it.
However, there is no higher-level orchestration. What if the coroutine starts in a suspended state?
What about scheduling coroutines? What if we want to wait for multiple coroutines to finish? What if we want to cancel a coroutine?
What about thread safety?
These are all things that Boost.Asio provides.
Asio is the driver with co_spawn and io_context that orchestrates the coroutines. io_context is the main event loop. It has all the state and controls everything about the coroutines.

So, you may be wondering why we are doing asynchronous programming with Coroutines rather than parallel programming with threads.
Asynchronous is far more efficient for I/O bound work, which a network server is bound to.
In general, when you have 1 large task that can be broken down into smaller subtasks, use threads (CPU-heavy tasks).
If you have various different small tasks that aren't particularly connected, especially involving lots of I/O,
or you're bound by memory: use asynchronous programming.

Getting into the Code

We'll be building on the same code from part 1.

We'll start by making the tcp_server asynchronous.

src/tcp_server.cpp

// existing code
#include <coroutine>

// existing code

void tcp_server::run()
{
    // The normal accept loop, but now as a coroutine
    // We explicitly use m_IoContext here; alternatively, we could provide a specific executor
    boost::asio::co_spawn(m_IoContext,
        [this]() -> boost::asio::awaitable<void> {
            for (;;) {
                // the actual accepting of sockets
                tcp::socket socket(m_IoContext);

                // suspends this coroutine until a client connects and returns control to m_IoContext
                co_await m_Acceptor.async_accept(socket, boost::asio::use_awaitable);

                // launches a new coroutine for each connection
                // ownership of the socket must be transferred to the coroutine, otherwise the lifetime of the socket would be undefined
                boost::asio::co_spawn(m_IoContext, parse(std::move(socket)), boost::asio::detached);
            }
        }, boost::asio::detached); // detached allows us to fire-and-forget, with no result or exception being captured

        // this starts processing the coroutines
        // blocks the calling thread and runs until no more work exists
        m_IoContext.run();
}
// existing code

A question you may have is what is boost::asio::use_awaitable. Well, awaitables essentially allow you to replace callbacks with coroutines.
Old Asio code looks like this:

socket.async_read_some(buffer,
    // a callback function to handle the data after it is done reading
    [](boost::system::error_code ec, std::size_t n)
    {
        if (!ec)
            handle_data(n);
    });

But with coroutines, we essentially want an item to be returned that we can co_await on.
So, modern Asio with awaitables looks like this:

co_await socket.async_read_some(buffer, boost::asio::use_awaitable);

Note also that we don't have good error handling here. I'll leave that as an exercise for the reader. It really isn't that hard, just some try/catch blocks.
Just know that when a detached coroutine throws, the program terminates.

Now that server.run() is blocking and does an infinite loop, we no longer need the infinite loop in main.cpp.

src/main.cpp

// existing code

try
{
    http::tcp_server server(port);

    server.run();
}
// existing code

Now that we've established our main loop, it's time to get back to the tcp_server and make parsing asynchronous!

Asynchronous Parsing

We just have to replace the blocking read_some with async_read_some. If you added CORS handling, you'll need to do a co_return from there.

src/tcp_server.cpp

// existing code

// we need to change the return type to be an awaitable too
boost::asio::awaitable<void> parse(tcp::socket socket)
{
    http::HttpRequest request;

    boost::asio::streambuf request_buffer;

    // we suspend this coroutine and let some other work happen until we finish reading the request
    co_await boost::asio::async_read_until(socket, request_buffer,
        "\r\n", boost::asio::use_awaitable);
    // we're only parsing the request line
    // if you wanted to parse headers, use "\r\n\r\n"

    // existing code

    // replace line: http::response_handler::dispatch(socket, request); with:

    // we also suspend execution here until we finish dispatching, letting other work happen in the meantime
    co_await http::response_handler::dispatch(socket, request);

    // existing code
}

// existing code

And that's it! We've made parsing asynchronous. Now, we need to make dispatching asynchronous.

Asynchronous Dispatching

First, we need to make the dispatch function return an awaitable.

src/response_handler.h

// existing code
namespace response_handler
{
    boost::asio::awaitable<void> dispatch(tcp::socket socket, const http::HttpRequest& request);
}
// existing code

Next, let's modify the implementation.

src/response_handler.cpp

// existing code

namespace response_handler
{
    boost::asio::awaitable<void> dispatch(tcp::socket socket, const http::HttpRequest& request)
    {
        if (!path_handlers.contains(request.path))
        {
            const auto response = HttpResponse{}
                .set_version(request.version)
                .set_status(404, "Not Found")
                .set_body("Not Found");
            co_await response.write(socket);

            // first time we've seen co_return. It just allows us to return from a coroutine
            // implicity returns void (same as coreturn void)
            co_return;
        }

        auto response = co_await path_handlers.at(request.path)(socket, request);
        co_await response.write(socket);
        // we don't need to specify co_return here, it is implicit
    }
}

We escape execution at a few steps. Those are when writing to a socket and when executing the path handler function.
We escape the coroutine when writing to a socket because writing to a socket is asynchronous itself (blocking normally),
so we can just hand execution off to something else (io_context) until we're done.
We also escape the coroutine when executing the path handler function because the path handler function is also asynchronous.
Although path handling is not inherently asynchronous like writing to a socket, the path handler may have async code inside it.

Now, we need to actually make the HttpResponse.write() and path handlers asynchronous.

src/response_handler.cpp

// existing code

namespace
{
    struct HttpResponse
    {
    private:
        // existing code
    public:
        // existing code (set_* functions)

        boost::asio::awaitable<void> write(tcp::socket& socket) const
        {
            // existing code

            // we suspend execution until we finish writing the response
            co_await boost::asio::async_write(socket, boost::asio::buffer(message), boost::asio::use_awaitable);
        }
    };

    using path_handler_fn = boost::asio::awaitable<HttpResponse> (*)(tcp::socket&, const http::HttpRequest&);
    const std::unordered_map<std::string, path_handler_fn> path_handlers = {
        {
            "/", [](tcp::socket& socket, const http::HttpRequest&) -> boost::asio::awaitable<HttpResponse> {
                if (request.method != "GET")
                {
                    const auto response = HttpResponse{}.set_version(request.version)
                        .set_status(405, "Method Not Allowed")
                        .set_body("Method Not Allowed");
                    co_return response;
                }

                // I'll get back to stream files in a bit
                // For now, imagine it as being able to use a file with the same API as a socket
                // i.e., you can async_read and async_write to it like a socket
                boost::asio::stream_file file(socket.get_executor());

                boost::system::error_code ec;
                file.open("test_client/client.html", boost::asio::stream_file::read_only, ec);

                if (ec)
                {
                    const auto response = HttpResponse{}.set_version(request.version)
                        .set_status(500, "Internal Server Error")
                        .set_body("Failed to open client.html\n" + ec.message());
                    co_return response;
                }

                const auto size = file.seek(0, boost::asio::stream_file::seek_end);
                file.seek(0, boost::asio::stream_file::seek_set);

                std::string buffer(size, '\0');
                buffer.resize(size);

                co_await boost::asio::async_read(file, boost::asio::buffer(buffer),
                    boost::asio::use_awaitable);

                const auto response = HttpResponse{}
                    .set_version(request.version)
                    .set_status(200, "OK")
                    .set_body(buffer)
                    .set_header("Content-Type", "text/html; charset=utf-8");

                co_return response;
            }
        },
        {
            "/time", [](tcp::socket& socket, const http::HttpRequest&) -> boost::asio::awaitable<HttpResponse> {
                if (request.method != "GET")
                {
                    const auto response = HttpResponse{}
                        .set_version(request.version)
                        .set_status(405, "Method Not Allowed")
                        .set_body("Method Not Allowed");
                    co_return response;
                }

                const auto time = std::chrono::system_clock::now();
                const auto timeString = std::format("{:%Y-%m-%d %H:%M:%S}", time);

                const auto response = HttpResponse{}
                    .set_version(request.version)
                    .set_status(200, "OK")
                    .set_body(timeString);

                co_return response;
            }
        }
    }
}
// existing code

A few unique things you may notice. First, we are actually using co_return to return values. In this case, awaitables
of type HttpResponse are returned from the path handlers.

Second, we are using boost::asio::stream_file to read from a file. This is a modern feature of Boost.Asio that allows you to treat a file as a socket.
This makes asynchronous File I/O a breeze. You may get issues with including it in the build, though.
On Windows, you may need to add this macro to your build system compile definitions: _WIN32_WINNT=0x0A00.
On Linux, you may need to link to liburing. I'll leave these as exercises for the reader.
If you can't figure it out, look at my build system or post a comment at the bottom of this page.

Templating Engine

Firstly, we'll be using Inja for templating.
We'll be using nlohmann's JSON library for providing data to Inja.
You'll see what that means shortly.
Also, make sure you link your executable to Inja and nlohmann's JSON library in your build system.

With Inja, templating is really quite easy.
If you don't know what templating is, it's essentially a way to programmatically generate HTML.
Say you had an array in C++ that you wanted to transform into a list in HTML.
You could write a loop in C++ to generate the HTML, but that would be error-prone and inefficient.
Instead, we can use a templating engine to generate the HTML for us. The engine has knowledge of C++ structures.
Currently, we're building HTML ourselves. For example, in the /time path handler, we pass a raw string.
What if we wanted to add HTML elements like bold text or italicized text to that response?
We could manually write the HTML using C++ strings or have the templating engine do it for us.

Inja takes in data as JSON. Say we have the following template:
{{ time }}. Time could be anything, really. Inja recognizes through the {{ }} syntax that it should be replaced with some data.
We can pass data to Inja using JSON. We have a JSON key time that has a value of the current time.
Then, we can render to a std::string using Inja via inja::render().
We could give the template to Inja as a raw string, or we could pass it a file path.
For now, we'll just pass it a raw string.

Navigate to the /time path handler function:

src/response_handler.cpp

// existing code
{
    "/time", [](tcp::socket& socket, const http::HttpRequest&) -> boost::asio::awaitable<HttpResponse> {
        // existing code

        // replace the manual timeString stuff with this:
        nlohmann::json vm;
        vm["time"] = std::format("{:%Y-%m-%d %H:%M:%S}",
            std::chrono::system_clock::now());

        // we don't need an env for our use-case
        // but it is good to have one in case you want to render a file or something else
        Inja::Environment env;
        const auto html = env.render("{{ time }} with ❤️ from C++", vm);

        const auto response = HttpResponse{}
            .set_version(request.version)
            .set_status(200, "OK")
            .set_body(html);
        // this is still technically plain-text, not html, so we don't need to change the "Content-Type" header
        // if we had html elements, we would need to change it to "text/html; charset=utf-8"

        co_return response;
    }
}

The JSON is called vm because it is the view-model. It's the data that Inja will use to render the template.
It gives Inja the view into our data. It is also, at the same time, the model of the data itself.
It controls the shape and type of data.

At this point, we have a fully asynchronous server with a templating engine!

This is a fully featured C++ HTTP server.
Truly, the vast majority of features left for implementation are CORS handling (which is quite easy)
and architectural changes to make the server more scalable (not just a jump table of lambdas for handlers).
These are all QoL, the main foundations of the server are done and dusted.

Conclusion

We've made a fully asynchronous HTTP server in C++.
What does that mean?
It means it can scale to potentially millions of concurrent connections.
We don't even have any multithreading in play. Sure, we could use a thread pool to drive the io_context, but we're running it on a single thread.
Multithreading may introduce performance gains, but not as much as asynchronous programming.
Look into how you can use thread pools with Boost.Asio and io_context if you want to learn more.

The templating engine gives us a way to easily serve HTML from the server without having to manually form HTML
from C++ strings. Moreover, we've given the server some structure in how it manages data: JSON.
We don't necessarily need to use JSON as the model of our data, but having it as the view is certainly useful.
We could represent our data however we want.

Now, don't confuse our asynchronous server with asynchronous APIs.
Asynchronous APIs technically don't need to even execute on an asynchronous backend.
Basically, all an asynchronous API does is respond to the client saying that it will give back the true value at some point in the future.
Then, later, it sends another request with the final value.
This can be done through webhooks, emails, having the client poll the server on an interval, etc.
You could hobble together an asynchronous API using our current server, or even the one from part 1.

Our server isn't a production-grade HTTP server.
But you can certainly take it there using this as a solid foundation.

Some things for further improvement:

The jump table is intentionally simple; real servers use structured routers, middleware chains, and prefix matching
The server doesn't handle errors very well.
No logging
No tests
Authentication? (not inherently HTTP, but useful in a web backend)
Parsing the headers and body of an HttpRequest
- Handling partial reads and malformed requests
Backpressure and capping concurrent work (not just fire-and-forget)
Optimizing hot code paths

Building an HTTP Server in C++: From TCP to HTMX (Part 1)

Armaan Chahal — Sun, 14 Dec 2025 00:12:00 +0000

Intro

Welcome. We're gonna talk about how web servers actually work, in C++, without magic.
If you want to skip the conceptual lore dump, go right ahead to the code sections.
On the topic of theory vs practice, here's a phenomenal quite by Donald Knuth:

If you find that you're spending almost all your time on theory, start turning some attention to practical things; it will improve your theories.
If you find that you're spending almost all your time on practice, start turning some attention to theoretical things; it will improve your practice.

---Donald Knuth

This article walks through building a minimal HTTP/1.1 server directly on top of TCP using Boost.Asio.
The focus is not production readiness, but understanding how modern asynchronous C++ maps to real web protocols.
You don't need to be super comfortable with C++ or networking,
but it would certainly help. If you're trying to transition to C++ from a higher-level language, props.

If you want to skip straight to a concurrent HTTP server with templating, read part 2.

HTTP in C++... why?

The first question anyone with sense would pose, upon hearing of someone writing an HTTP server in C++, is why?
Perhaps with a few added exclamation points.

Now, there are a few reasons one would get started with such a feat. Primarily: learning!
For learning purposes, there is no better way to understand HTTP and how the web truly works than by writing an HTTP server in a language where the web isn't a first-class citizen.
(Or at least, where the web wasn't meant to be first-class...)

Moreover, there truly do come times when a very high-performance backend is necessary. It doesn't necessarily have to be for a website, though that is a common use-case.
If you want performance, it just isn't feasible with JavaScript or other high-level languages. For such an endeavour, I would honestly recommend using a language that has more support for HTTP in it's standard library.
For example, Go and Rust. Now, C++ is my bread and butter, but even the people on the standards committee can agree that networking is one place where C++ is lacking.
If you still want to use C++ for a production-grade application, check out libraries like Drogon or Boost.Beast.
They provide higher-level abstractions for HTTP (so you don't actually have to write an HTTP server from TCP sockets).

Where Does that Leave Us?

We're gonna use TCP sockets. There are certainly a few ways you can do that in C++, most people will point you to 3 different methods:

OS-specific sockets libraries (i.e. WinSock, POSIX/Berkeley sockets)
libuv (What Nodejs uses)
Boost.Asio

We're going to use Boost.Asio. From now on, I'm going to refer to Boost.Asio as Asio, but don't get confused with the older, standalone Asio library (whenever I refer to Asio, I mean Boost.Asio).

Asio is distributed under the generous Boost Software License, which is quite similar to other popular licenses like the MIT License, Apache, BSD, etc. Check it out here.

Why did I choose Boost.Asio over OS-specific options? Well, it has a nicer API and is cross-platform.
And why over libuv? For no particular reason other than I was already familiar with Asio and wasn't with libuv. Both are great libraries, and I would suggest you look at libuv for a wider perspective afterward.

What other dependencies will we need? In the future, we're going to need Inja and a JSON library. That's for a templating engine, like Jinja2, Go/Templ, etc.

The Theory

We all love whiteboard sessions, right? No... just me? Whiteboarding is both good and bad. I won't get into that here, but it is necessary to lay down some fundamentals of HTTP before we start coding the thing.

Firstly, let's define our client. Who will actually be sending the requests? We could write our own client in C++ or a higher-level language, but if you read the title, you already know that our client will be HTMX.
HTMX is a great library; if you're unfamiliar with it, it is essentially raw HTML, but you can attach HTTP requests to any element, not just <a> and <form>.
If we were to write an HTTP client in C++, that would be super boring. All we would see would be console logs like "REQUEST SENT!" and "RESPONSE SENT!" and "RESPONSE RECEIEVED!"

Instead, we can have a nice frontend in our browser! At the end of the day, the browser is doing the heavy lifting for the client-side application. But that means all we will have to write is some HTMX code.

HTTP

Now, let's define HTTP itself. An HTTP request is a text-based and consists of a few different parts. Well, technically bodies are binary and headers may encode data.
That means that we don't need any fancy serialization or deserialization logic. To be clear, we're going to write a server for HTTP/1.1, not HTTP/2.
That just makes life a little easier for us. To understand HTTP/2, you need to first understand HTTP/1.1.
HTTP is just a protocol, like TCP and UDP. It stands for Hypertext Transfer Protocol, so you can probably infer it has something to do with HTML.
That intuition is correct, as HTTP is most commonly used in websites (though it's not limited to that).

HTTP Requests have a few main parts:

Method
Path
Version
Headers
Body

HTTP Responses are slightly different:

Version
Status Code
Status Message
Headers
Body

The body and headers are optional in both requests and responses. An example request is this:

GET / HTTP/1.1
Host: developer.mozilla.org
Accept-Language: fr

And a sample response:

HTTP/1.1 200 OK
Date: Sat, 09 Oct 2010 14:28:02 GMT
Server: Apache
Last-Modified: Tue, 01 Dec 2009 20:18:22 GMT
ETag: "51142bc1-7449-479b075b2891b"
Accept-Ranges: bytes
Content-Length: 29769
Content-Type: text/html

<!doctype html>… (here come the 29769 bytes of the requested web page)

In this scenario, the user asks for a GET request to the path "/", essentially requesting the index.html file, which is the primary HTML document the browser is meant to show. The server then sends back raw HTML within the response body.
The headers simply contain additional details regarding the request or response; these are sometimes needed, such as Content-Type and Content-Length, especially when a body is present.

Yes, I got both of these from the phenomenal HTTP docs by mozilla. Definitely give them a read for more in-depth information about the HTTP protocol.

HTTP isn't magic, and if you still have some questions, they will certainly get dispelled once we reach the coding section. Or ask them at the bottom of this page!

TCP

So, Boost.Asio has no clue about HTTP. All it knows about is TCP (or UDP, but we HTTP requests need to be reliable, hence we use TCP).
Boost.Asio will handle all the low-level details about TCP. It delegates even lower-level TCP details like the 3-way handshake to the OS.
Boost.Asio exposes to us a TCP socket, from which we can read data (i.e., on the server we read the request) and write data (we write back to the client with our HTTP Response).
This dynamic enables us to worry solely about the HTTP data itself and not about the low-level TCP connections that actually underpin HTTP.

If you want to learn more about TCP and fundamental networking in general, I recommend the book TCP/IP Illustrated.
You only really need Volume 1. Whether you get the first or second edition doesn't matter.

From Humble Beginnings

We'll write our HTMX client now. Just so that we can get started. If you want an idea about the project structure, here's a link to the final project.
That is an old commit, but it's probably as far as we'll get to in this post. Check the main branch's HEAD for some more features.

Let's start with some HTML.

test_client/client.html

<!DOCTYPE html>
<html>
<head>
    <title>HTMX Client</title>
</head>

<body>
    <button>
        Get Time
    </button>

    <div id="time">Waiting for button click</div>
</body>
</html>

Neat, right? No? Oh... you're wondering where the HTMX is?
Wait, wait, I see it!

test_client/client.html

...
    <title>HTMX Client</title>
    <script src="https://cdn.jsdelivr.net/npm/htmx.org@2.0.8/dist/htmx.min.js" integrity="sha384-/TgkGk7p307TH7EXJDuUlgG3Ce1UVolAOFopFekQkkXihi5u/6OCvVKyz1W+idaz" crossorigin="anonymous"></script>
...

    <button hx-get="/time" hx-target="#time" hx-trigger="click" hx-swap="innerHTML">
        Get Time
    </button>
...

There we go. Now, we inject HTMX via a CDN, and we hook up the button to some HTML events. We're basically saying that when the button is clicked, sent a GET request to the path '/time' and swap the innerHTML of the element with id time.
That element is our div. The innerHTML of the div is just the text inside it.

Straightforward, I know, but enough to get us started!

Onto C++

Now, make sure your C++ build system is linking to Boost.Asio and is set to C++23 (you may be able to get by with older versions, but I haven't tested them). Again, if you want more info on the build system, see the GitHub repo I linked earlier.

Let's just start in the main function to see how we can actually use Asio.

src/main.cpp

#include <boost/asio.hpp>
#include <string>
#include <print>


static constexpr auto port = 3000u;

using boost::asio::ip::tcp;

int main() {
    try {
        boost::asio::io_context io_context{};
        tcp::acceptor acceptor(io_context, { tcp::v4(), port }); // the acceptor connects to a port and waits for a socket

        for (;;) {
            tcp::socket socket{io_context}; // the socket itself
            acceptor.accept(socket); // blocking function call that waits for a connection

            // this is intentionally blocking, we'll get to async code in part 2

            const std::string message = "hi from server";
            boost::system::error_code ignored_error{}; // we ignore the error of the write
            boost::asio::write(socket, boost::asio::buffer(message), ignored_error); // this writes a buffer to the socket, in this case just a string
        }
    } catch (std::exception& e) {
        std::println("Error: {}", e.what());
    }
}

Now, this is no HTTP, but interestingly enough, we'll have a very similar code flow for the actual HTTP server. We wait for a socket to arrive to our designated port, then read from it, then write to it!
Currently, we're not doing any reading from the socket, but we will soon enough.

Now that we have the basic understanding of how we can actually do networking stuff, let's consider what our http server will look like in code.

Project Design

We start at our HTMX client, the browser. That sends an HttpRequest to our server.

The server itself is composed of 4 layers.

TCP Accept/Connect Layer (acceptor.accept(socket);)
HTTP Request Parser
Router/Dispatcher
Handler functions

We'll go into more detail as we get to coding each part, but these are the 4 major parts of our project.

At layer 1, it's the same code we already covered, we wait for a TCP socket connection.
At layer 2, we parse the HTTP Request into 3 distinct fields for now: method, path, version. We don't necessarily need to keep track of the version, as we know it's going to be HTTP/1.1, but it doesn't hurt.
At layer 3, we see dispatch to the proper handler based on the path in the http request.
At layer 4, the handler functions will do some logic, build an HTTP Response, and eventually write them back to the socket.

Pretty simple, right?

Layer 1: Connections

Let's make a few new files for the sake of organization. First, though, let's modify main.cpp.

src/main.cpp

#include <print>
#include "tcp_server.h"

// rest of the code...

    try {
        http::tcp_server server(port); // we will make this class soon
        for (;;) {
            server.run(); // can you imagine what server.run() will do?
            // again, intentionally blocking, we'll get to concurrency in part 2
        }
    }
// rest of the code...

Now, a new file:

src/tcp_server.h

#pragma once

#include <boost/asio.hpp>
#include <cstdint>
#include <string>

namespace http
{
    using boost::asio::ip::tcp;

    // this struct represents all the data we'll parse out of the HttpRequest coming from the client
    struct HttpRequest
    {
        std::string method; // yes, these aren't string_views; these need to own the strings
        std::string path;
        std::string version;
    };

    class tcp_server
    {
    public:
        tcp_server(uint32_t port);

        // call this to actually run the server for 1 single TCP connection, hence the loop in main.cpp
        void run();

    private:
        // look familiar?
        boost::asio::io_context m_IoContext;
        tcp::acceptor m_Acceptor;
    };
}

So far, pretty self-explanatory. The tcp_server will handle layers 1 and 2, of connection and parsing.

Let's start with the run method, which we will define in a new file:

src/tcp_server.cpp

#include "tcp_server.h"

#include <print>

using namespace std::literals; // just some niceties

using boost::asio::ip::tcp;

namespace http
{
    tcp_server::tcp_server(uint32_t port)
        :
        // m_IoContext is default constructed before m_Acceptor automatically
        m_Acceptor(m_IoContext, tcp::endpoint(tcp::v4(), static_cast<boost::asio::ip::port_type>(port))) // the constructor for acceptor technically doesn't take in a uint32_t
    {}

    void tcp_server::run()
    {
        tcp::socket socket(m_IoContext);

        m_Acceptor.accept(socket);
        parse(std::move(socket)); // we'll get to this soon
    }
}

Nothing extraordinary yet, we've just reorganized the code we had before. But trust me, it's finally about to start to get interesting.

Layer 2: Parsing

Parsing HTTP, for our case so far, is surprisingly easy. We don't need to worry about headers or a body for our purposes today.
All we care about is the stuff defined in HttpRequest in tcp_server.h.

In case you're wondering what parse(std::move(socket)); was doing earlier, here we are.

src/tcp_server.cpp

#include "response_handler.h" // we'll get here later
// existing code...

namespace http
{
    namespace // a C++ anonymous namespace
    {
        // why do we take socket by value you may be wondering?
        // well, once we get to concurrency, the parser needs to take ownership of the socket for lifetime's sake
        // for now, we could just pass it by reference
        void parse(tcp::socket socket)
        {
            HttpRequest request;

            // this is the buffer we will read into
            boost::asio::streambuf request_buffer;

            // this is the magic
            boost::asio::read_until(socket, request_buffer, "\r\n"); // why is this our delimiter? read on

            // this stream just makes it easier to extract strings from our request_buffer
            std::istream request_stream(&request_buffer);

            // why can we just do this? it's because the method, path, and version are deliniated by spaces in between, so we can reliably just extract them using the c++ std::istream
            request_stream >> request.method >> request.path >> request.version;

            http::response_handler::dispatch(socket, request); // again, we'll get here later. make sure to add the include at the top of the file

            // we finally shutdown this socket
            // we don't have logic for reusing a socket, though it wouldn't be too difficult to add if you wanted to.
            boost::system::error_code ignored_error{};
            socket.shutdown(tcp::socket::shutdown_both, ignored_error);
            socket.close(ignored_error);
        }
    }
    // existing code...
}

Now, all the code comments should explain what's going on.
However, you may be interested that "\r\n" is our delimiter for reading the socket. That's because in HTTP, all new lines are separated by "\r\n" like CRLF line-endings on Windows.
The method, path, and version are all on one line.
Then, each header has its own line.
Then, before the body, there is an extra blank line.
Then, there is the body.

So, if we wanted to read all the headers as well, we could just change the delimiter in read_until to be "\r\n\r\n",
as the last header ends with "\r\n", then another "\r\n" after the last header for an extra blank line.
All of this is guaranteed by the HTTP/1.1 spec.
This is sufficient for our simplified parser, but production servers must handle partial reaads and malformed requests.

Layer 3: Router/Dispatcher

If you were wondering what the http::response_handler::dispatch(socket, request); was doing, here we are.
Now that we have parsed the information we need out of the HTTP request, we can finally get to executing our custom logic based on each route.

First, let's dispatch to those routes (routes are just paths).

Add a new file:

src/response_handler.h

#pragma once

#include <boost/asio.hpp>

namespace http
{
    // forward declaration. Would be cleaner to seperate out HttpRequest into a seperate file
    struct HttpRequest;

    using boost::asio::ip::tcp;

    // we don't need a whole class for this, so I just put it into a namespace
    namespace response_handler
    {
        void dispatch(tcp::socket& socket, const HttpRequest& request);
    }
}

Quite a short file. The implementation file will be a little more lengthy, though.
Let's get on to that.

Add a new file:

src/response_handler.cpp

#include "response_handler.h"
#include "tcp_server.h"

namespace http::response_handler
{
    void handle(tcp::socket& socket, const HttpRequest& request)
    {
        if (!path_handlers.contains(request.path))
        {
            const auto response = HttpResponse{}
                .set_version(request.version)
                .set_status(404, "Not Found")
                .set_body("Not Found");
            response.write(socket);
        }

        auto response = path_handlers.at(request.path)(socket, request);
        response.write(socket);
    }
}

This may seem a little foreign, for good reason, considering I didn't put in any code comments.
However, I hope you see the idea here.
We have path_handlers, essentially a jump table. It's an unordered_map with a key of std::string_view (path) and a function that does some logic.
That will be part of layer 4: handler functions.
We just execute the function that corresponds to the given path. If it doesn't exist, we respond with a 404 error.

Speaking of 404, in HTTP there are certain status codes that have given meanings. 200 means OK. 404 means NOT FOUND. If you want to see more, see the MDN docs for HTTP.
Status codes are only in HTTP responses, not requests.

Layer 4: Handler Functions

We're finally at the last layer. Let's wrap this up with a nice little bow.

Edit the file:

src/response_handler.cpp

// existing code

#include <unordered_map>
#include <map>
#include <string_view>
#include <chrono>
#include <format>
#include <fstream>

using namespace std::literals;

namespace http
{
    namespace // again, a C++ anonymous namespace
    {
        // this gives a nice API to build and write HTTP Responses
        struct HttpResponse
        {
        private:
            std::string version{}; // i.e. HTTP/1.1
            int status{0}; // i.e. 404
            std::string status_line{}; // i.e. "NOT FOUND"
            std::string body{};

            // some default headers we want
            std::map<std::string, std::string> headers{
                {"Content-Type", "text/plain; charset=utf-8"},
                {"Access-Control-Allow-Origin", "*"},
                {"Connection", "close"}
            };
        public:
            HttpResponse() = default;

            HttpResponse& set_version(std::string new_version)
            {
                version = std::move(new_version);
                return *this;
            }
            HttpResponse& set_status(int new_status, std::string new_status_line)
            {
                status = new_status;
                status_line = std::move(new_status_line);
                return *this;
            }
            HttpResponse& set_header(std::string header, std::string value)
            {
                headers[std::move(header)] = std::move(value);
                return *this;
            }
            HttpResponse& set_body(std::string new_body)
            {
                body = std::move(new_body);
                // Content-Lenght expects bytes
                // length == bytes for UTF-8
                headers["Content-Length"] = std::to_string(body.length());
                return *this;
            }

            void write(tcp::socket& socket) const
            {
                std::string message = version + ' ' + std::to_string(status) + ' ' + status_line + "\r\n";

                for (const auto& [key, value] : headers)
                {
                    message += key + ": "s.append(value).append("\r\n");
                }
                message += "\r\n" + body;

                boost::asio::write(socket, boost::asio::buffer(message));
            }
        };


        // typedef for a function pointer, in our case we'll use lambdas. You could use any sort of function pointer, though
        using path_handler_fn = HttpResponse (*)(tcp::socket& socket, const HttpRequest&);

        const std::unordered_map<std::string_view, path_handler_fn> path_handlers = {

            // the handler for the '/' path. The server will serve the whole html client html file
            {
                "/", [](tcp::socket& socket, const HttpRequest& request) -> HttpResponse {
                    // only the GET method is allowed at this path
                    if (request.method != "GET")
                    {
                        const auto response = HttpResponse{}
                            .set_version(request.version)
                            .set_status(405, "Method Not Allowed")
                            .set_body("Method Not Allowed");
                        return response;
                    }


                    // binary mode is useful, and we start at the end of the file so that we can easily tell its length
                    std::ifstream file("test_client/client.html", std::ios::binary | std::ios::ate);
                    if (!file.is_open() || !file.good())
                    {
                        const auto response = HttpResponse{}
                            .set_version(request.version)
                            .set_status(500, "Internal Server Error")
                            .set_body("Failed to open client.html");
                        return response;
                    }

                    const auto size = file.tellg();
                    std::string buffer(size, '\0');
                    file.seekg(0);
                    file.read(buffer.data(), size);

                    const auto response = HttpResponse{}
                        .set_version(request.version)
                        .set_status(200, "OK")
                        .set_header("Content-Type", "text/html; charset=utf-8")
                        .set_body(buffer);
                    return response;
                }
            },

            // the handler for the '/time' path (if you remember, its for when the button is clicked)
            {
                "/time", [](tcp::socket& socket, const HttpRequest& request) {

                    const auto currentTime = std::chrono::system_clock::now();
                    // nicely format the current time
                    const auto timeString = std::format("{:%Y-%m-%d %H:%M:%S}", currentTime);

                    const auto response = HttpResponse{}
                        .set_version(request.version)
                        .set_status(200, "OK")
                        .set_body(timeString);
                    return response;
                }
            }
        }
    }
    // existing code
}

Wow, that was a doozy. But with that, we've added handler functions. We also added the API for building HttpResponses and writing them back to the client via the TCP socket.

You've made the transition from a rookie understanding of HTTP to a solid, mid-level to senior-level understanding of HTTP.
We started from raw Boost.Asio TCP sockets, and made it to serving an HTMX frontend.

If you want to see your website, run the server and open http://localhost:3000 in your browser.

Now, there are a few things left to implement. Those being concurrency and a templating engine.
We also may have to handle CORS in the future. If you are encountering issues with CORS, see my up-to-date GitHub repo.
The templating engine is really quite straightforward.
Also, the Asio in Boost.Asio stands for "Async IO," so concurrency should be native to Asio.
We'll find out soon.

Read part 2

Notes On the Build System

Personally, I chose to use CMake for my build system.
CMake is the de-facto standard for C++. Once you get familiar with CMake, it's not too bad.
Build systems are the type of things you write once and copy paste into every new project you make (until it doesn't work).
Regardless, to install Boost.Asio, I used vcpkg, a C++ package manager made by Microsoft.
In my experience, it's been the most reliable and easy to use C++ package manager.

I would write out the build scripts here, but it's easier if you just look at the repo.
Look at the CMakeLists.txt file, the CMakePresets.json file, and the vcpkg.json file.

How to Hone Windows for Development

Armaan Chahal — Sat, 20 Sep 2025 00:16:00 +0000

Why Even Use Windows?

In a lot of professional software development, you'll be using Windows.
Fields like Game Development and Graphics Programming are the most prominent examples, but many SWE companies or teams just use Windows.
I too enjoy using Linux. I have Arch & Hyprland installed on my laptop, and Neovim is my preferred editor.

However, my main workstation is a Windows 11 desktop computer I built myself. I know I'm talking extensively about myself, but I feel
my own experience is fairly common among many of you. I do gaming on Windows, development on Windows, and most other tasks I do on Windows.

The Main Pain Points

I hear a lot of people say "Just use WSL" especially for tools like Git, Node, etc. But, for our case, we won't be using WSL or anything other than native Windows 11.
Yes, that includes MingW (a toolchain I used to use a lot).

On the topic of Git, I don't use Git Bash or any other special git client.

Git

I've simply just installed Git from the website and use it from Windows Terminal.
In Windows Terminal, I use PowerShell (the new version).
Git works perfectly fine for me. It really is that simple.
Actually, I'd recommend using a package manager like chocolatey or winget to install Git.

Package Managers

I use both chocolatey and winget for package management. To be honest, winget is excellent. It has come a long way since I first checked it out.
Both Winget and Chocolatey have a lot of packages. However, I prefer chocolatey for one specific reason:
It doesn't automatically configure itself with programs you installed using other installers.
Winget will pick up installed programs on your machine regardless of how you installed them. This is a huge disadvantage for me.
I don't want or need Winget to update Epic Games Launcher or Steam whenever I run winget upgrade.
Though, that could be a benefit for you.

There are also package managers like scoop which I've heard good things about. I've never used it, though, so I can't speak to its specifics.
It seems that scoop can install programs without Admin privileges, which may be good for people on work computers.

C/C++ Development

C/C++ development is often something people mention as being terrible on Windows.
I'm happy to inform you that that isn't true.

For any development workflow, make sure you install the latest version of Visual Studio.
Not just for the IDE, but for all the tools it includes, like MSVC.
You don't need to install CMake, Node, Python, etc. from it. I installed all of those separately.

I use CMake for the vast majority of my C/C++ projects.
Normally, I use CLion, but I'm going to cover just Visual Studio for now (as most jobs that require Windows require Visual Studio).

Visual Studio can work well with CMake. But, don't be afraid to use Visual Studio .sln files if your entire team is using Visual Studio.

With CMake, you don't even have to use the Visual Studio 17 2022 generator.
You can use Ninja as your generator, and just use MSVC (cl.exe) as the compiler.
Make sure you add cl.exe to your PATH.
In fact, the PATH is such an important part of your development environment that I recommend you add a lot of your tools to your PATH. Also understand what the PATH is.

For compiling since C/C++ files, you can still use cl.exe. For some reason, the Visual Studio Code docs recommend using MingW for development.
However, you can use cl.exe in your terminal for compiling single files.
I usually do something like this:

cl /EHsc /std:c++latest main.cpp /Fe:main.exe

However, if you can, you can also use MingW and gcc/clang for compiling single files.

MingW vs MSVC

To preface, if you're using MingW, use either the Clang64 or UCRT64 toolchains, not the MINGW64 toolchain.

The reason I don't use MingW anymore is that the compilation speed is incredibly slow. On my machine, the performance list goes like this:

(fastest) MSVC with Ninja -> MSVC with .sln -> MingW with Ninja -> MingW with MingW Makefiles (slowest).

MSVC, even with .sln, is around 40-50% faster than MingW in my own game engine project (moon engine).
Now, as a compiler, is MSVC better than gcc or clang?
It's comparable, but I do prefer gcc. I don't really use clang.
But MSVC is still good. It is not bad at all. My only slight annoyance is that it's errors and warnings are usually less strict than gcc/clang.
So, when I use something like all warnings and warnings as errors, code that compiles with MSVC may fail with gcc/clang.

Vim on Windows???

Firstly, I use Neovim on Linux. The only time I ever use Vim is when I'm SSH-ed on to a remote server that only has Vim installed.

It's not feasible to use Neovim on Windows. Vim with plugins probably isn't reasonable either (haven't extensively tested though).
Now, is it possible? Yes. But it doesn't work well. Many plugins are flat-out broken on Windows.
Aside from the plugin issue, the Neovim workflow on Windows just isn't that good.
Windows just isn't that good for terminal-based workflows. You can make it work, sure, but if you have any Windows-only tooling,
you're probably out of luck. For example, .sln files, just don't work with Neovim (no plugins I've found).

However, as I mentioned earlier, I use CLion for C/C++ development.
All Jetbrains IDEs have a plugin called IdeaVim which works very well. It uses .vimrc, not lua like Neovim, but its functionality is exceptional.
Check out my IdeaVim .vimrc.

Even with Visual Studio, there are Vim emulator plugins like VsVim that work decently well.
For VS Code, there are Vim and Neovim extensions, but I think the Vim extension works the best.

For me, I do have a heavily customized neovim config.
However, .vimrc based vim emulators work well. For me, them most important thing is just basic vim motions.

Other Programming Languages

If you use package managers, chances are there is little you'll have to do aside from just choco install <package>.
Even something like rustup is installable through the terminal.

The most common complaint of things just not working on Windows or requiring extensive customization just isn't true for 99% of things these days.
Just remember to have Visual Studio installed. It fixes a lot of problems with prereqs not being installed, or redists not being installed.

Conclusion

Don't fall down rabbit holes trying to make Windows just like Linux or some perfect platform.
Sure, you may have to find Windows-specific solutions, but they often work well.
Nor does that prevent you from writing cross-platform software, or make you reliant on Windows.
But remember that Windows is not perfect, but it is possible to do most things on it.

A lot of niche Linux commands may not have direct equivalents on Windows, but you can probably install cli tools that achieve those results.
i.e., fzf, fd, etc.
Even if you can't, you can still use WSL. Of course, I tried to make everything in this article as Windows-only as possible, but sometimes you need those tools.

Windows-specific tools usually work better than trying to force Linux tools into Windows, as shown with C/C++ development.

I've been using both Windows and Linux for a long time. You can get very efficient with both.

Harmony Between OOP and Data-Oriented Design

Armaan Chahal — Thu, 04 Sep 2025 00:00:00 +0000

OOP For the Uninitiated

Data-Oriented Design is something easy to understand but hard to implement. There are no clear rules with DOD, nor any clear models to follow.
Object-Oriented Programming follows the model of the world approach. You think about how something works in the real world,
and then you translate it into code. Take an example anyone can understand:
- You have a white chair
- You have a pink chair that is wider than the white one

Clearly, both of these things have something in common. They are both chairs!
This shared property is usually modeled with an abstract base class called Chair with properties such as width and color.
These properties can be overridden by the derived classes, such as PinkChair and WhiteChair.

class Chair {
public:
    virtual ~Chair() = default;
    virtual double getWidth() const = 0;
    virtual std::string_view getColor() const = 0;
};

class PinkChair : public Chair {
public:
    double getWidth() const override { return m_width; }
    std::string_view getColor() const override { return m_color; }
private:
    double m_width = 1.5;
    std::string m_color = "pink";
};

class WhiteChair : public Chair {
public:
    double getWidth() const override { return 1.0; }
    std::string getColor() const override { return "white"; }
};

Inheritance is not a given of OOP, but it is a common pattern.

Something that OOP does emphasize is having invisible data.
This means that you expose functions and hide the implementation details and state behind lock and key.
The client only uses your public API and generally has no idea of the underlying implementation.
Seems optimal, right?

DOD For the Uninitiated

Data-Oriented Design takes a different approach, focusing on the data itself.
When you model your code, you think about the data and the transformations of that data.
This is a very abstract concept to grasp, especially when you are new to DOD.
You may be thinking, "Okay, but what does that actually mean in code?"

I had the same question. Let's revisit the Chair example from above.
How would you have multiple chairs? You would likely do something like std::vector<Chair*>.
This is widespread in OOP, and it is called an array of structures, or AOS.

The alternate in DOD could look something like this:

struct Chairs final {
    std::vector<double> widths{};
    std::vector<std::string> colors{};
};

import microBenchmarkSOAAOS from "./micro_benchmark_soa_aos.png";

This is called a structure of arrays, or SOA.
As an aside, if you do a micro-benchmark on this, you will likely see varying results.
SOA won't be slower than AOS, but it will likely be very similar in terms of CPU cycles if you do something like this quick and dirty benchmark:

In this micro-benchmark, SOA is a little faster than AOS, but we aren't using polymorphism on the AOS (Chair*).
Check out this talk for details about polymorphism and micro-benchmarks!

The Abstraction

Abstraction is often times a point people new to DOD or traditional OOP programmers are confused with.
Are you even supposed to abstract? How do you abstract? Ultimately, the question should be:

"What is the philosophy of abstraction?"

The answer, as it always is with abstraction, is unclear. DOD purists will say that you should never abstract away the data,
and that the client should always be aware of the data transformations. This results in very traditional, C89-style code. Consider this:

int* data = new int[100000];

for (int i = 0; i < 10000; i++) {
    data[i] = (i + 1) * -3;
}

Can you spot any problems?

They are as follows:

The pointer to data is never deleted
The range doesn't go through all the data (100000 vs 10000), though that could be intended

This may not seem like a big deal, but the problem scales as the code scales.

There are four (five) horsemen of the apocalypse in low-level programming:

Bounds Safety
Type Safety
Lifetime Safety
Initialization Safety
(Undefined Behavior, sometimes)

The above example really doesn't account for any of these. At the very least, it doesn't use malloc, but you should never use new in C++, so initialization safety has a big X.
Obviously, bounds safety is not accounted for, we could copy-paste any bounds into the for loop. Lifetime safety is unaccounted for, we could forget to delete the pointer.
Type safety may not seem like a problem here, but it could become one. What if you are convert your data array to be a different type, like a uint8_t?
Sure, you may see that in this example, but what if you are getting data from a function that lives in a different file, where a different team works on it?

So, a better example is this:

std::vector<int> data(100000);

std::size_t i = 0;
std::ranges::for_each(data, [&](auto& n) {
    n = ++i * -3;
});

This is much better and satisfies all the horsemen. However, this is not pure DOD. The for_each is an abstraction,
and though it is safer, it is hiding some of the code path/data transformation.
Consider if we wanted to accumulate all the values. For that, we could use a for loop, which is pure DOD,
but we could also use std::reduce or std::accumulate which, though safer, hides the code path and data transformation.
However, this is far better code. Why?

The Harmony

The number one advice I would give you for when you decide to abstract is to always be aware of the code flow and see if your
abstractions are ever hiding important data transformations that the client would otherwise be unaware of.

The next most important thing, and this could even be more important depending on what you're developing, is to be aware of the CPU.
DOD is optimal because of the CPU cache. Check out this amazing talk by Scott Meyers for more details on the CPU cache.
If you want a brief explanation, the CPU cache is a small amount of memory that lives very close to the CPU.
It is the fastest memory to access, aside from registers, and is often used to store data that is accessed frequently.
How does the cpu decide what to keep in the cache? It uses a heuristic called locality of reference consisting of temporal locality and spatial locality.
Temporal locality is a tendency of a program to access the same data repeatedly in a short time frame.
Spatial locality is a program's tendency to access data nearby data already being accessed (think contiguous memory in an array).

The CPU cache brings in data in a cache line, which is usually 64 bytes on most platforms. Whenever you are accessing data,
know that you are using a cache line and don't waste the limited data (If you're wondering what happens when you access data larger than a cache line, the CPU uses multiple lines).
This is why SOA is so good, because it is optimal for the cache line. If you only need the colors of a Chair, you don't need to waste the cache line with the widths.
Keep in mind that accessing memory is orders of magnitude slower than doing something like division or square root.
Optimize for the hardware, as Mike Acton would say in his great talk on DOD.

Going back to the harmony, OOP is not mutually exclusive with DOD.
You can, and should, use both. DOD does not mean using only SOA, it means that in performance-critical code paths, you
code while being aware of the hardware. Ultimately, your code is always executing on hardware, and you have to be aware of what is happening.
That is the only way to write good, performant code.

Using traditional design patterns is not forbidden, and some of them are still useful. Sure, a std::variant isn't the most optimal way to have polymorphic data,
but it is still useful and a good abstraction. It may be just as good as a more DOD struct of function pointers that are initialized at runtime or compile time.

Conclusion

DOD is not a silver bullet. But it is a mindset that everyone should have. Even in the world of web development,
having fast websites is still important. Performance should be a top priority of everyone.
Back in the day, people would code specifically knowing basically what every line of code was doing, and how many CPU cycles it was taking.
Nowadays, we use tools with higher level abstractions. This isn't wrong. This is a good step. Otherwise, all performance-critical code would still be written in assembly.
Of course, that isn't the case. A core philosophy of C++ is Zero-Overhead Abstractions. Rust has Zero-Cost Abstractions, which means the same thing in essence. Use abstractions when they are more declarative, have clear data transformations (i.e., accumulate should clearly just loop through a range and add up the values).

On the topic of encapsulation, it is still necessary to encapsulate your data for the sake of separation of data, though encapsulation in DOD is different from OOP. You're not encapsulating or abstracting for the sake of hiding data, you're doing it for the sake of being able to scale up your data as your application scales up.

Forem: Armaan Chahal

Coroutines & Concurrent HTTP and a Templating Engine in C++ (Part 2)

Intro

Getting Started With Concurrency

The Idea

Getting into the Code

Asynchronous Parsing

Asynchronous Dispatching

Templating Engine

Conclusion

Building an HTTP Server in C++: From TCP to HTMX (Part 1)

Intro

HTTP in C++... why?

Where Does that Leave Us?

The Theory

HTTP

TCP

From Humble Beginnings

Onto C++

Project Design

Layer 1: Connections

Layer 2: Parsing

Layer 3: Router/Dispatcher

Layer 4: Handler Functions

Notes On the Build System

How to Hone Windows for Development

Why Even Use Windows?

The Main Pain Points

Git

Package Managers

C/C++ Development

MingW vs MSVC

Vim on Windows???

Other Programming Languages

Conclusion

Harmony Between OOP and Data-Oriented Design

OOP For the Uninitiated

DOD For the Uninitiated

The Abstraction

The Harmony

Conclusion

References