DEV Community: Matthew Faithfull

The Flyer pattern and the saga of C++ error handling

Matthew Faithfull — Thu, 27 Aug 2026 00:59:28 +0000

Patterns are a familiar tool of software development for the past 20+ years. You'll have heard of Singleton, Bridge, Decorator and a couple of dozen more.
They cover a lot of ground and you can do years of software development using them as daily tools and probably never even use all of them.
However there are some everyday tasks for which they just don't seem to be directly all that helpful. Error handling is of those. Logging is another.

I will show a pattern and the outline of its implementation that make these tasks easier and more consistent, although they are only one application of the general Flyer pattern.

First however the motivating problem. Half a century of trying to do error handling without breaking everything.

Let's say you write a function that calls an API. It could be something like a file read or maybe this Windows network API call.

SOCKET WS2::accept( SOCKET s, sockaddr* addr, int* addrlen )
{
    static const Library::DefProc pFunc = 
reinterpret_cast<Library::DefProc>( 
 Kernel32::GetProcAddress( reinterpret_cast< ::HMODULE >(
  Kernel32::GetModuleHandleW(L"ws2_32") ), ( "accept" ) ) );

    SOCKET Result = Library::Call< 
 SOCKET, SOCKET, sockaddr*, int* >(
  pFunc, s, addr, addrlen );

    return Result;
}

The neat mathematical concept of a function as a mapping form its inputs to its outputs (in this case from a socket and an address to another socket) is ruined by the fact that this call can fail. What's worse is that is it can fail in a number of very different ways but we'll get to that.

What are our available strategies for handling failure:

Sentinel values

This one goes back at least 50 years and is pretty simple. We could reserve a value for the returned SOCKET which indicates that something went wrong.
For example -1. This is indeed what the socket API does, Windows copying BSD going all the way back into the dark ages.

The downsides of this are:

We're relying on the caller to actually check the return and to know that -1 means accept failed.

We have no way of indicating why it failed. For that the caller will need to call back into the API and there will need to be an error state held somewhere, which we'd better hope is per-thread and hasn't been reset by an intermediate call.

The upside is we can pretend that is still a mathematical style function which neatly maps inputs to outputs.

There are cases for sentinel values but their historic use for error handling causes problems as described above. All in all it's a poor solution that should probably stay in the mid 20th century where it originated.

Out parameters

We could change the signature of accept to take an extra parameter by reference.

SOCKET WS2::accept( 
SOCKET s, sockaddr* addr, int* addrlen, 
 WS2ErrorState& errState);

This solves the problems of how we inform the caller of why the call failed and of having to store and retrieve error state with a second call.
However it introduces new problems. We have to have an extra parameter on every call in our network API. Everything has to know what a WS2ErrorState is and now our caller has to manage the error state, making sure it's initialised before they pass it in. We've moved the problems around but haven't really solved them and everything is more complex and verbose as a result.
The 1980s can probably keep this solution. We'll move on.

Exceptions

By the 1980s the problems with Sentinel values and extra reference parameters for error handling were well understood and C++ brought out the big tools to solve the problem once and for all.
I'm not going to deep dive into how exceptions work and what the issues with them are here but briefly, they require explicit support in the language and the compiler and in some cases the OS as well. They're powerful, dangerous, maybe expensive, tricky to think about and completely unavailable in some embedded environments.
They're also somewhat unavoidable and deeply embedded in some OS APIs. For example our sample code itself calls Library::Call which looks like this:

template< typename ret, class ...MethodArgs >
static ret Call(const DefProc pProc, MethodArgs... args)
{
    typedef ret(*fPtr)(MethodArgs...);
    fPtr FP = reinterpret_cast<fPtr>(pProc);
    if (FP == nullptr)
    {
        throw("Missing library function.");
    }
    __try
    {
        return (FP)(
 std::forward< MethodArgs >(args)...);
    }
    __except(ExceptionFilterFunction(
 GetExceptionInformation()))
    {
    }
    ret _{};
    return _;
}

This uses two slightly different type of exception handling. One of which (structured exception handling) is Windows specific. We'll see later how that gets turned back into a platform neutral error.

Exceptions will always be with us, although many people dislike and avoid them whenever they can but surely modern C++ has some better answers.

It does and they all come in the form of a different approach to how to return error information.

Structured bindings

C++17 allows us to return a tuple< SOCKET, WS2ErrorStatus > and for the caller to assign the two elements of the tuple directly to separate variables without having to call std::get< >

tuple< SOCKET, WS2ErrorStatus > WS2::accept( 
 SOCKET s, sockaddr* addr, int* addrlen );

auto [ socket, error ] = accept( s, addr, addrlen);

This is great, however it still means we have to change the signatures of all our functions. We're still relying on the caller to actually check the error and not ignore it. At least we can generate the WS2ErrorStatus inside our accept function and error state is all nicely on the stack.

For a brief moment sometime in 2018 everyone thought this was the answer but it's still unsatisfyingly awkward and messy at scale.

std::optional

The modern standard library provides many ways to skin cats. Instead of structured binding we could return a std::optional< SOCKET >
This provides the caller a way to determine if we really returned a SOCKET or just an empty result. Essentially we're back to the sentinel but with all the sophistication of type safety. Now we don't have to reserve a special value within the type of SOCKET to indicate failure, we get a smart API on std::optional< SOCKET > to tell us it's empty.
However all the other problems of sentinels, like not being able to tell what went wrong without calling back to the API and the state management consequences of that are back. Plus ça change.

std::expected

"std::expected is a powerful feature introduced in C++23 that offers a modern, type-safe alternative to traditional error-handling methods."

Instead of wrapping up our SOCKET return value with a Boolean to say if it's empty or not std::expected wraps it up with a type of our choosing allowing us to return the SOCKET and an error.

std::expected<SOCKET, WS2ErrorStatus> WS2::accept(
 SOCKET s, sockaddr* addr, int* addrlen );

std::expected<SOCKET, WS2ErrorStatus> result = 
 accept(s, addr, addrlen);

if(result.has_value())
{
    //happy path
    use(result.value());
}
else
{
    report(result.error());
}

This does, technically, solve a lot of the problems and as we know that's the best kind of solution. However if you squint a bit you'll notice that this is incredibly similar to the structured bindings solution which fell out of favour pretty quickly, even thought it also, technically, works.

That's it then. We've exhausted the cat skinning options of the standard library and still the only way to get useful error information out of our accept function, without changing the signature or shuffling runtime responsibilities onto our caller, is to use exceptions. Sigh.

The Flyers are coming!

If I were doing that deep dive into exceptions which I'm not. One of the things we'd encounter is that way down at the base of the stack for every thread, on Windows at least, there is an exception control block which holds data required for exception handling on that thread. In other words exception support injects extra per-thread state that the runtime uses to do its dark magic. Can we do the same?
In short, yes. We can set up some per-thread state which maps a type to a pointer. I'll link to the full implementation at the end but this is outline of the FlyerMap

class FlyerMap final
{
public:
    inline FlyerMap() = default;
    FlyerMap(const FlyerMap&) = delete;
    inline ~FlyerMap(){ m_Map.clear(); }

    inline AnyObject Configure(
 const GUID* classID, AnyObject context){/*...*/}
    
    inline void Unconfigure(
 const GUID* classID, AnyObject context){/*...*/}

    inline AnyObject Lookup(
 const GUID* classID){/*...*/}

private:

    std::map< GUID, AnyObject > m_Map;
};

The Configure and Unconfigure functions allow us to set which instance of a particular type is the current flyer for that type. They're almost identical except Configure returns the previous instance in a type erased AnyObject.

The Flyer map gives us a place to 'remember' the current Flyer now we need something to remember.

template< class T, class baseT >
class Flyer : public baseT
{
public:
    Flyer() : baseT() { }
    virtual ~Flyer() = default;
    Flyer(const Flyer& src) = delete;
    Flyer& operator = (
 const Flyer& src) = delete;

    bool Push()
    {
        typename ref_of< T >::type 
 instance( dynamic_cast<T*>(this) );
        const GUID* luid = guid_of<T>::guid();
        TypedAny< T > wrapper(instance);
        m_anyPrevious = 
CurrentThread::GetCurrent().Context().
 GetFlyerMap().Configure( luid, wrapper);
        if(!m_anyPrevious.IsNull())
        {
            m_Previous = 
reinterpret_cast<const TypedAnyPointer< baseT >*>(
 m_anyPrevious.Ptr())->operator baseT *();
        }
        return true;
    }

    bool Pop()
    {
CurrentThread::GetCurrent().Context().
 GetFlyerMap().Unconfigure(
  guid_of<T>::guid(), m_anyPrevious);
        return true;
    }

protected:

    typedef baseT base_type;
    AnyObject m_anyPrevious;
    baseT* m_Previous{nullptr};
};

This gives us a base template for Flyers. The important details are the Push and Pop functions which interact with the Flyer map.
Push sets a Flyer into the map, while holding onto the previous item that was replaced.
Pop removes a Flyer from the map and puts back the previous item.

These functions are called from Flyer constructors and destructors.

template<class T>
class IssueHandler : 
 public Flyer< IssueHandler<T>, BaseIssueHandler >
{
public:
    IssueHandler()
    {
    Flyer< IssueHandler<T>, BaseIssueHandler >::Push();
    }

    virtual ~IssueHandler()
    {
    Flyer< IssueHandler<T>, BaseIssueHandler >::Pop();
    }

    virtual bool Handle(const T& /*Issue*/)
    {
    return false;//false here means failure to resovle the issue
    }
};

The CRTP template trickery is only necessary so that the ultimate base class can have a concrete type that we can attach ID to for differentiating Flyer types. BaseIssueHandler is essentially an empty type.

IssueHandler serves as a base for a broad category of Flyers, more than just errors but here's the entire specialization for error handling.

class DefaultErrorHandler : 
 public IssueHandler<ErrorBase>
{
public:
    virtual bool Handle(const ErrorBase& error);
};

To handle Windows specific errors we use a Win32ErrorHandler specialization with an identical signature.

Using an error handler is as simple as putting one on the stack.

SOCKET WS2::accept( 
 SOCKET s, sockaddr* addr, int* addrlen )
{
    Win32ErrorHandler _;
...

but how, you may ask, do we turn API specific sentinel values and OS specific exceptions into errors that can be handled by our error handler?

The answer (as Jason Turner will always remind you) is stronger types. But before we get there lets reroute the structured exceptions we caught in Library::Call as that's actually quite straight forward.

static int ExceptionFilterFunction(
 LPEXCEPTION_POINTERS exception_pointers)
{
    serious(
 "Win32 API Exception: Code {0}, Address {1}, Flags {2}, Info {3}, {4} parameters.",
        exception_pointers->ExceptionRecord->ExceptionCode,
        exception_pointers->ExceptionRecord->ExceptionAddress,
        exception_pointers->ExceptionRecord->ExceptionFlags,
        exception_pointers->ExceptionRecord->ExceptionInformation[0],
        exception_pointers->ExceptionRecord->NumberParameters
    );

    return EXCEPTION_EXECUTE_HANDLER;
}

Remember we passed ExceptionFilterFunction as our except filter in the __except clause in Library::Call

__except(ExceptionFilterFunction(
 GetExceptionInformation()))

So if we do get an exception we'll extract all the exception details and pass them along with a formattable string to the serious function.

template< typename... _p >
void serious(const std::string& message, _p&&... p1)
{
    issue<Serious, const std::string&>(
 std::vformat(
  std::string_view(message), std::make_format_args(p1...)));
}

This just formats the parameters into the string and calls the issue template function with the Serious class. That in turn will construct an instance of Serious for us and calls Handle() on it.

class Serious : public ErrorBase
{
public:
    Serious(const std::string& message);
    Serious(const Serious& src);
    virtual ~Serious() noexcept;
    Serious& operator = (const Serious& src);
    virtual void Handle();
    virtual void Escalate() const;
    virtual void Ignore() const;
};

Serious is a specialization of ErrorBase for errors in the serious category. In this implementation we categorize errors as Warning, Continuable, Serious or Fatal. With Serious errors being ones where the thread of execution can't continue as normal. It will need to clean up and close down.

void Serious::Handle()
{
    auto pSeriousHandler = 
 new_ref< IssueHandler<Serious> >();
    if(!pSeriousHandler.IsNull())
    {
    Resolve(pSeriousHandler->Handle(*this));
    }
    else
    {
    auto handler = new_ref< IssueHandler<ErrorBase> >();
    Resolve(handler.IsNotNull() ? handler->Handle(*this) : false);
    }
}

At first glance this looks as if Serious::Handle is creating a new IssueHandler< Serious > to hand off to but under the hood new_ref is actually looking up the Flyer Map for the current thread and returning a pointer to the Win32ErrorHandler we put on the stack earlier.
Here's part of the factory that does that lookup.

template< class T >
struct factoryFunctor< T, FlyerRef< T > >
{
    static void Destruct(size_t /*count*/, T* t);//...

    static FlyerRef< T > Construct(size_t)
    {
        AnyObject context = 
 CurrentThread::GetCurrent().Context().
  GetFlyerMap().Lookup(guid_of<T>::guid());            
        if (!context.IsNull())
        {
        FlyerRef< T > pCurrent(
 context.operator T*());
        return pCurrent;
        }
        return FlyerRef< T >();
    }
};

Once we have the address of the Win32ErrorHandler that get's called.

bool Win32ErrorHandler::Handle(
 const qor::ErrorBase& error)
{        
    switch(error.what().GetSeverity())
    {
    //...
    case Severity::Serious_Error:
    {                    
        std::string message = 
 GetLastErrorAsString();

        ::OutputDebugStringA(
 std::format("{0}. Windows error status - {1}",
  error.what().Content(), message).c_str());

        return false;
    }                
    break;
    //...

This now handles the otherwise annoying call back into the underlying API to get the details of the last error and outputs details through the kernel to any attached debugger.
The return false; is significant here. That means we didn't resolve the error, we just reported it. This result will get passed to the Resolve function on the specific Error type. In this case Serious which will Escalate the error because it wasn't successfully handled. For Serious errors that defaults to throwing an exception but this is highly implementation specific.

void Serious::Escalate() const
{
    throw(*this);
}

We could choose to fallback to a Flyer based retry handler or any other suitable behaviour.

Now for the that stronger type to catch non-exception errors from the Windows API. In other words to turn a sentinel value into an Error we can pass to a Flyer based handler.

For this we use a CheckReturn template.

template<class TReturn, class TCheck >
class CheckReturn
{
public:

    typedef CheckReturn< TReturn, TCheck > TType;

    CheckReturn() : m_bInitialised(false)
    {
        TCheck AutoCheck;
        TCheck::Init(m_Param, &AutoCheck);
    }

    CheckReturn(TReturn param) : m_Param(param), m_bInitialised(true)
    {
        TCheck AutoCheck;
        TCheck::Check(m_Param, &AutoCheck);
    }

    CheckReturn& operator = (TReturn& value)
    {
        m_Param = value;
        m_bInitialised = true;
        TCheck AutoCheck;
        TCheck::Check(m_Param, &AutoCheck);
        return *this;
    }

    operator TReturn()
    {
        if (!m_bInitialised)
        {
            continuable("Uninitialised parameter error");
        }
        return m_Param;
    }

protected:
    TReturn m_Param;            //Instance of parameter type
private:
    bool m_bInitialised;
};

This encapsulates the type we're returning and a check type. The check is operated when we assign to the CheckReturn from an instance of our return type and the CheckReturn auto converts to the return type on request (with an uninitialized check) so that when we return it we don't have to change our function return type.

Note: This only works for return by value. That's what almost all API calls do, so this isn't a limitation in practice but CheckReturn is not the kind of universal solution you'd find in the standard library. It's a situation specific utility class.

We need to plug in a check class to actually check our SOCKET return value.

template< typename TFailure, TFailure iFailure >
class TCheckWinsockFailureValue
{
public:

    virtual void DefaultInit(TFailure& value)
    {
        value = iFailure;
    }

    virtual bool Test(TFailure& value)
    {
        return (value == iFailure) ? false : true;
    }

    static void Check(TFailure& value, TCheckWinsockFailureValue* pInstance)
    {
        if (!pInstance->Test(value))
        {
            WSALastErrorHandler();
        }
    }

    static void Init(TFailure& value, TCheckWinsockFailureValue* pInstance)
    {
        pInstance->DefaultInit(value);
    }
};

WSALastErrorHandler() is another function to call back into the Windows API to get the last WSA specific error and, this time, raise it as a continuable error.

void WSALastErrorHandler()
{
    int wsaLastError = WS2::WSAGetLastError();
    //...message formatting
    continuable(errorDescription);
}

continuable is a free function, just like serious, that creates a specialization of an issue and calls Handle() on it.

Our accept function return type then becomes:

CheckReturn< SOCKET, 
  TCheckWinsockFailureValue< SOCKET, INVALID_SOCKET> 
 >::TType Result;

A self checking wrapper which checks against the INVALID_SOCKET sentinel value when it is assigned with a SOCKET value and decays to that socket value when it's returned. (Note: this probably does prevent RVO but it's not significant for the vast majority of Windows API calls.)

There's one more case we haven't covered. Back in the Library::Call function if the function endpoint isn't present we throw.

template< typename ret, class ...MethodArgs >
static ret Call(const DefProc pProc, MethodArgs... args)
{
    typedef ret(*fPtr)(MethodArgs...);
    fPtr FP = reinterpret_cast<fPtr>(pProc);
    if (FP == nullptr)
    {
        throw("Missing library function.");
    }
...

In this case we throw a const char*, not a std::exception or anything derived from ErrorBase precisely because we don't want this to be caught, except by a global fallback handler. We could just call std::terminate, which is what will likely happen anyway but as this is a library we allow the containing executable to do that along with any reporting it wants to do first.
Not having the required library loaded (The overwhelmingly likely cause) is fatal and we don't want program execution to continue in any case.
In a scenario where exceptions weren't supported we could swap this out with a call to fatal("Missing library function"); for a similar effect via the Flyer based system.

The final WS2::accept function, fully expanded looks like this:

SOCKET WS2::accept( SOCKET s, sockaddr* addr, int* addrlen )
{
    qor::FunctionContext _FContext_(
__FUNCSIG__, __FILE_, __LINE__, ThisModule().Name(), false, false);

    Win32ErrorHandler _;

    CheckReturn< SOCKET, 
 TCheckWinsockFailureValue< SOCKET, INVALID_SOCKET> 
  >::TType Result;

    static const Library::DefProc pFunc = 
 reinterpret_cast< Library::DefProc>(
  Kernel32::GetProcAddress(
   reinterpret_cast< ::HMODULE >(
    Kernel32::GetModuleHandleW(
     (L"ws2_32") ) ), "accept") );

    Result = Library::Call< 
 SOCKET, SOCKET, sockaddr*, int* >(
  pFunc, s, addr, addrlen );
    return Result;
}

Which reduces to the much more readable:

SOCKET WS2::accept( SOCKET s, sockaddr* addr, int* addrlen )
{
    qor_pp_fcontext;    
    Win32ErrorHandler _;    
    CheckReturn< SOCKET, 
     TCheckWinsockFailureValue< SOCKET, INVALID_SOCKET> 
    >::TType Result;        
    qor_pp_useswinapi(ws2_32, accept );
    Result = Library::Call< 
 SOCKET, SOCKET, sockaddr*, int* >(
  pFunc, s, addr, addrlen );
    return Result;
}

with the macros put back in.

Conclusion:

We've taken an error handling worst case scenario where we have OS specific exception handling and old fashioned sentinel values that require re-calling into the API to get error details.
We've contained both the exception case and the soft error cases within the existing function without changing the signature, while routing them differently to custom handlers. We've done this in the presence of an existing fatal exception flow which we've left untouched. We get to choose whether our unhandled errors turn into exceptions or not and we can categorize errors by as many severity levels as we need, treating each differently, or falling back to default handling.

The required Flyer infrastructure is non trivial. This is a solution for a larger scale project. Once it's in place though, it is trivial to use.
Win32ErrorHandler handler; being enough to create an error handler with automatic lifetime management and the warning, continuable, serious and fatal free functions being the entire rest of the error system API.

Flyer based error handling and logging is a QOR technology. Development is ongoing at https://github.com/mfaithfull/linuxQOR where you can get the complete reusable Flyer system as a small collection of cross platform libraries for Linux and Window, or the entire application development framework.

Polymorphic Experiments

Matthew Faithfull — Tue, 25 Aug 2026 14:24:41 +0000

Sandor Dargo recently wrote an excellent blog post on a new C++26 standard library feature std::polymorphic.

I felt when I read this as if the std::polymorphic authors must be pulling some language trick that's recently become possible or exploiting a loophole. It seemed like something would break if I tortured it. So I thought I'd investigate.

It turns out that implementing std::polymorphic doesn't require a C++26 language base. C++20 is sufficient and there's even a C++14 port. So I copied Johnathan B Coe's single source C++20 header and did some experiments.

Read Sandor's article for what polymorphic does and how to use it. Here I'm going to push the boat out and see if/when it breaks down.

Note: I'm using a C++20 implementation, not one from C++26 and I'm using it on MSVC with /std:c++20 set. The behaviour of the actual C++26 standard library is in no way guaranteed to be identical.

I had the following concerns:

Will polymorphic cope with classes which have multiple bases? (multiple inheritance)
Will it work when used directly with a multiple inheritance base rather than a specific derived concrete class?
Will it work even if that base is abstract, given that you can't instantiate abstract classes?

I'll need an inheritance monster to really test that. What follows is hopefully just enough so that you can see what is going on.

class Item
{
public:
    virtual ~Item() {};

    template< typename U > constexpr bool Is()
    {
        U* test = dynamic_cast<U*>(this);
        return test != nullptr;
    }        

    template< typename U > U* As()
    {
        U* as = dynamic_cast<U*>(this);
        return as;
    }
};

Item is the common base from which everything in the main hierarchy derives
We use virtual inheritance of course so that there's only one Item instance for each final instantiation. As it's stateless that's not too much of an issue although it does matter for the intermediate bases that have state.

class Compound; //forward decl

class Contained : public virtual Item
{
//...//handles having a parent
};

class Compound : public virtual Item
{
//...//handles having a vector of Contained items
};

class Scene;

class Renderer
{
//...//Out of hierarchy class to do rendering
};

class Renderable : public virtual Item
{
//...//Something that can be rendered
    virtual void Render(Renderer* renderer)
    {
    //...
    }        
};

class Scene : public Compound, public virtual Renderable
{
//...//A Compound that is Renderable
};

class Arrangeable : public virtual Item
{
//...//Handles interaction with layout algorithms
};

//base class for Widget
class Widget : public Compound, 
    public virtual Contained, 
    public virtual Arrangeable, 
    public virtual Renderable
{
public:
    Widget() = default;
    virtual ~Widget() = default;
};

Given what polymorphic is intended for and what Sandor showed I was pretty confident this first test case would work. Creating a polymorphic< T > of a concrete, derived class Widget and then treating it as one or other of its base classes.

polymorphic<Widget> widget;

std::vector<Renderable*> renderables;
renderables.emplace_back(widget.operator->());

Renderer renderer;

for(auto renderable : renderables)
{
    renderable->Render(&renderer);
}

std::vector<Arrangeable> arrangables;

arrangables.push_back(*widget);

for(auto arrangeable : arrangables)
{
    arrangeable.ComputeRequirement();
}

It does exactly as you'd expect, despite the slightly awkward syntax. widget.operator->() returns a Widget* which happily decays automatically to its Renderable* base. Calling through it confirms all is well.
Copying with push_back works without breaking the std::vector and I can get a std::vector of Arrangeable objects (as long as Arrangeable isn't abstract which would break the vector anyway.)

That is the easy part. What I'd really like is to have one or more polymorphic<Item> instances, probably in a homogenous container, and make calls through them.
This is the case that makes std::polymorphic valuable. You can treat a polymorphic<Item> as a value, just like an int or struct. Shunt it around in standard containers and pass it as an ordinary function parameter while it remains polymorphic when you call through it.

This works:

Widget* exampleWdiget = new Widget();
polymorphic<Item> item(std::move(*exampleWdiget));

As does:

polymorphic<Item> item(Widget{});

and it's safe due to the requires constrained template constructors and clever copying machinery in polymorphic.

However whether this works or not depends:

polymorphic<Item> item;

What if we make Item abstract?

class Item
{
public:
    virtual ~Item() {};
//...    
    virtual void make_base_abstract() = 0;
};

In that case

polymorphic<Item> item;

will not compile. I get a static_assert with a reasonably useful error message telling me I can't instantiate an abstract class.
What then of the common case of abstract bases in class hierarchies?
Well it turns out, remarkably, this still works:

polymorphic<Item> item(Widget{});

Even when Item is abstract.
Internally no Item is ever instantiated as we supply an in place constructed Widget instance so the abstract instantiation problem is dodged.

We must of course add implementations to prevent the classes we do instantiate from being abstract:

virtual void make_base_abstract(){ };

goes into Arrangeable and Widget.

The following move assignment case also compiles and executes correctly.

Widget* exampleWdiget = new Widget();
std::vector<Renderable*> renderables;

polymorphic<Item> item(std::move(*exampleWdiget));

renderables.emplace_back(item->As<Renderable>());
for(auto renderable : renderables)
{
    renderable->Render(&renderer);
}

The only thing polymorphic doesn't do for us it to upcast/downcast (I never know which it is) from Item* to the derived Renderable*.
Item itself handles that with the As< T >() function which is just wrapping a dynamic_cast.

YAGNI ?

It may seem like the use case above is esoteric (It was meant to be) and you might think you'll never need polymorphic but I suspect that a lot of use cases for the ever popular std::variant in current C++ codebases are actually candidates for std::polymorphic and you might get better memory usage and or better performance as a result. You'll need to experiment with a real C++26 standard library implementation to confirm.

Consider something like a JSON object model where you use std::variant to model the different possible types of a JSON value:

using JSONVariant = std::variant< 
std::nullptr_t, 
bool, 
int, 
double, 
std::string, 
std::vector<JSONVariant> >;

This could be replaced with

polymorphic<ValueModel> valueModel;

where ValueModel is a shared base class

enum class ValueType
{
    _false,
    _null,
    _true,
    number,
    string,
    array,
    object
};

class ValueModel
{
public:        
    virtual ~ValueModel() = default;
    virtual ValueType GetType()
    {
        return ValueType::_null;
    }
};

Definitely more code, as you also have to derive classes for each type of ValueModel but perhaps enough of a smaller memory footprint, for large models, to justify the extra code. You'd have to measure it on your platform to be sure.

Conclusion

std::polymorphic looks to be an excellent addition to the C++26 standard library and with a few minutes work you can use it now with C++20.
Just take care with construction if you have an abstract base.

What's the right way to multi configure CMake compiler flags?

Matthew Faithfull — Fri, 14 Aug 2026 23:16:56 +0000

I'm looking for the right way to set Compiler flags, per build type, with a multi platform build. In this case targeting Windows, MSVC is the part that's failing.

I currently include this flags.cmake into every subproject

if (CMAKE_CXX_COMPILER_ID STREQUAL "GNU")
    if(CMAKE_BUILD_TYPE STREQUAL "Debug")
        set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -std=c++2a -fcoroutines -fvisibility=hidden -fconcepts-diagnostics-depth=3 -Wno-attributes -Wall -Wextra -Wpedantic")
    else()
        set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -std=c++2a -fcoroutines -fvisibility=hidden")
    endif()
endif()
if (CMAKE_CXX_COMPILER_ID STREQUAL "MSVC")
    set(CMAKE_WINDOWS_EXPORT_ALL_SYMBOLS OFF)
    set(CMAKE_CXX_VISIBILITY_PRESET hidden)
    if(CMAKE_BUILD_TYPE STREQUAL "Debug")
        set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} /EHsc /GR /utf-8 /fsanitize=address")
    else()
        set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} /EHsc /GR /utf-8")
    endif()
endif()

set(global_defines -Dqor_pp_unicode)

And I have a lot of sub projects, 250+

The issue is that the if(CMAKE_BUILD_TYPE STREQUAL "Debug") line is effectively ignored and I get /fsanitize=address in non Debug builds.

This is apparently a known issue for which CMake blames Ninja and Visual Studio. i.e. they aren't going to fix it.

AI assisted search tells me I can use a Generator Expression to do the same thing and it will work. However it can't provide me with a working example or get the Generator Expression syntax right, even once. There clearly aren't a lot of examples out there.
CMake's documentation for Generator Expressions is massive and seems to show how to do everything except actually use them to set compiler flags.

The other alternative is apparently a CMakePresets.json which is yet another separate DSL that looks like I'd need to change all 250 sub projects. Is this the case?

My question is what is the right route to go?
I need to be able to set specific Debug, RelWithDebugInfo and Release flags for GCC & Clang on Linux and MSVC & Clang on Windows.
I need them forcibly consistent across all 250+ sub projects, so set in one place.

P.S. If your answer is use Basel instead then you're welcome to raise the working Basel build scripts as a PR on (QOR Github)[https://github.com/mfaithfull/linuxQOR]. Same with Jam or Scons or whatever. The CMake question stands.

Give a man a fish...

Matthew Faithfull — Thu, 13 Aug 2026 13:31:06 +0000

Let's say you write some code to read an image from a file. Better still you find a library that does that for you. You write some minimal wrapper code to call it. Now you have code that reads and writes that image format from a file. All seems well for now.

Later you need to transfer the image to another service that may not be on the same machine. Now you need to either send the image over the network, or write it out to a file, with your already in-use library, and then send the file.
The choice is obvious because you already have the library and know how to use it. You're going to write the modified image out to the slow, maybe also remote, file system and then read it all back again to transfer it over the network, wrapped in a protocol like FTP, to be unwrapped at the other side and written back to the file system, because that's what FTP does, read in again on the remote machine and voila, you've now got a product 100x slower than it needs to be.

So where did this go wrong? The decision to use the library was rational. The decision to reuse the library was probably even more so. You didn't make the first error, the library author did. They provided you a library to deal with a particular image format and in order to test it themselves they obviously had to write code to read and write their input and output to files. So they bundled that code into the library and made it their API. Now it's easy to use. So that's a good thing, right?

Wrong. The library author may be the worlds greatest expert on compressed image formats but files are just files, except when they aren't. They probably used the standard library API. Maybe shunted everything into a string stream and wrote it in one hit. Maybe they used OS specific file APIs and tied you to a particular OS for no reason. It works for demos but where they provided you with every nuance and configuration of image compression settings and fine grained control over your encoding and decoding, did they do the same with the File I/O?
Is it portable? Maybe.
Can you opt to use I/O uring on Linux? Unlikely.
Can you opt to read and write asynchronously? Almost certainly not.
Can you write to a network socket? Not a chance.

Now you may be able to unpick their file IO from their serializer, if it's really well written, and perhaps bodge in your own to send the images directly over a socket or as the body of an HTTP response.
In reality that's likely going to mean understanding almost all the library code, maybe forking it at source and by then you may as well have written it yourself. There may be compromise solutions with memory mapped files or domain sockets that with exactly the right incantation, give you enough performance.

However none of this is actually necessary. If the library author had left their file IO code in their test harness, where it belongs, and provided serialization as an interface you'd easily be able to adapt that interface to your networking needs or your existing way of interfacing with files. The library also would be smaller, more focussed and real world performance would be under your control.

The key to genuinely reusable code is real separation of concerns. If a library is in fact a codec to take data from format A to format B, then that's exactly what it should be. The storage medium for that data shouldn't matter. In fact where the data lives before it's encoded and where it lives afterwards are entirely none of the business of such a codec. It shouldn't even care about or need to do memory allocation. That's a separate concern. It should expose an interface where you provide the input data and one where you can get the encoded/decoded data back. Such a codec gains portability, reusability and simplicity while loosing nothing of value. It may not seem initially as easy to use because you'll have provide more external infrastructure but you'll be glad you chose it as your project grows.

With single purpose code libraries, less really is more. Much more. Library authors can work smarter by not coupling their implementations to particular systems or storage.
As consumers we need to be savvy about which libraries we choose. The easiest to get up and running isn't always the best choice. In fact it's often a fish with the hook left in.

Code Sfumato

Matthew Faithfull — Sat, 08 Aug 2026 14:39:00 +0000

sfumato, (from Italian sfumare, “to tone down” or “to evaporate like smoke”), in painting or drawing, the fine shading that produces soft, imperceptible transitions between colours and tones. It is used most often in connection with the work of Leonardo da Vinci and his followers, who made subtle gradations, without lines or borders, from light to dark areas; the technique was used for a highly illusionistic rendering of facial features and for atmospheric effects - Britannica

Importantly for our purposes this technique was executed by the application of many, thin, translucent layers. Leonardo used paint but I believe the technique applies equally well to the art of software.

This might also be thought of as, 'The power of leaving things out', 'Applied ignorance', 'No code is the best code' or just another positive form of laziness. In software development laziness has long been known to be a good thing. So long it has it's rules.

Don't put off till tomorrow what you can put off till next week.
If at first you don't succeed, get someone else to do it for you.
Cheat at every opportunity.

The rules of laziness are, of course, terrible advice for life but very good advice for writing code.

That's it. That's what I wanted to say. Code Sfumato is the way I write my best code. I guess you want an example though ;<}

Code Sfumato in practice

Occasionally you find yourself needing to write things that really should just exist already and be completely obvious and standard. Then you write them and realize why they're not. One example of this is a simple stream buffer. Easy right?

How big should it be?
How do we put things in it?
How do we get them out again?
What should we do when it fills up?
What kinds of things does it need to hold?
How do we make sure it doesn't leek memory?
What if you can't get the answers to any of these questions?

Suddenly a simple problem that seemed like

auto buffer = std::array< my_struct, MAX_BUFFER_SIZE>();

would solve it, doesn't seem so simple any more. Unless it is in which case just use std::array and move on.

Let's put sfumato and the power of our ignorance to work, lazily of course.

Layer 1: An almost entirely ignorant (and harmless) buffer interface

class Buffer
{
/*solution goes here*/
};

We don't know what kind of things our buffer needs to contain but ultimately we know it's all 1's and 0's organised into bytes. So we don't really need to know what type the things are, just how many bytes it takes to store one of them.

class Buffer
{
protected:
    size_t m_unitSize;
};

We're making an assumption here that all the items in the buffer are the same size. Quite reasonable as, if we need different sized items, we can just use different buffers. However we should remember this assumption because it becomes the first rule for using Buffer. The unit size is fixed and therefore needs to be set before we use the Buffer, so on construction.

class Buffer
{
public:
    Buffer() : m_unitSize(1)
    {
    //...
    }

    Buffer(size_t unitSize /*...*/) : m_unitSize(unitSize)
    {
    //...
    }

    size_t Buffer::GetUnitSize() const
    {
        return m_unitSize;
    }
    
protected:
    size_t m_unitSize;
};

Default construction is nice to maintain if we can and a default unit size of 1 byte seems reasonable. We'll make retrieving the unit size part of the API so clients can easily check against it.
This look pretty solid and difficult to break. Of course in real development we'd have a growing set of unit tests to make sure and most of them would still fail at this point as we don't actually have a working buffer yet.
We know that at some point we're going to have to keep track of how many units of m_unitSize the Buffer owns. What our Capacity is. So let's do that.

class Buffer
{
public:
    Buffer() : m_unitSize(1)
    {
        SetCapacity((size_t)0);
    }

    Buffer(size_t unitSize, size_t itemCount) : 
        m_unitSize(unitSize)
    {
        SetCapacity(itemCount);
    }

    ~Buffer()
    {
        SetCapacity((size_t)0);
    }
    
    size_t GetUnitSize() const
    {
        return m_unitSize;
    }
    
    size_t Capacity(void) const
    {
        return m_allocationCount;
    }    
    
protected:

    virtual void SetCapacity(size_t itemCount)
    {
        m_allocationCount = itemCount;
    }    

    size_t m_unitSize;
    size_t m_allocationCount;//Track item count we have space for.
};

Well that was easy. We were lazy of course and didn't do any actual memory management. Maybe later.
This is still pretty safe and difficult to break. We should however handle copying and assignment as users of Buffer are bound to want to do such things.

class Buffer
{
public:
    Buffer() : m_unitSize(1)
    {
        SetCapacity(0);
    }

    Buffer(size_t unitSize, size_t itemCount) : 
        m_unitSize(unitSize)
    {
        SetCapacity(itemCount);
    }
    
    Buffer(const Buffer& src)
    {
        *this = src;
    }    

    ~Buffer()
    {
        SetCapacity((size_t)0);
    }
    
    Buffer& operator = (const Buffer& src)
    {
        if(&src != this)
        {
            SetUnitSize(src.GetUnitSize());
            SetCapacity(src.Capacity());
        }
        return *this;
    }
    
    size_t GetUnitSize() const
    {
        return m_unitSize;
    }
    
    size_t Capacity(void) const
    {
        return m_allocationCount;
    }    
    
protected:

    virtual void SetCapacity(size_t itemCount)
    {
        m_allocationCount = itemCount;
    }    

    void SetUnitSize(size_t unitSize)
    {
        if(m_allocationCount > 0 )
        {
            SetCapacity((size_t)0);
        }
        m_unitSize = unitSize;
    }
    
    size_t m_unitSize;
    size_t m_allocationCount;//Track item count we have space for.
};

Calling the assignment operator from the copy constructor is sometimes frowned on but we're being lazy so we'll do that and not duplicate code.
Notice we've added a SetUnitSize function which is now called on assignment when we already have a size and an allocation count. That's OK though because we set the allocation count back to zero if we change the unit size. Making sure to do so before we copy the allocation count from the source.
That was tricky. I'm glad we didn't complicate things with actual memory management.

There's no point allowing anyone to read our Buffer until it's been written to so we should add Writing next.
That's an important rule actually. Write always goes ahead of Read or Read always follows Write if you prefer. We can use that to keep our implementation simple.

We'll add two variables for writing. A write beginning and write end on the grounds that for the buffer to be useful we want to able to write to it multiple times without overwriting what's already there but we might want to write more than one item at a time. Given that no one is answering our questions on the requirements for this buffer today, we'll support single and multiple unit write. There's another usage rule. The client will need to tell us how many units it wants to write. This will generate the gap between write_begin and write_end until the client tells us how many units it actually wrote.

class Buffer
{
public:
    Buffer() : m_unitSize(1)
...
    Buffer(size_t unitSize, size_t itemCount) : 
        m_unitSize(unitSize)
...    
    Buffer(const Buffer& src)
...
    ~Buffer()
...    
    Buffer& operator = (const Buffer& src)
    {
        if(&src != this)
        {
            SetUnitSize(src.GetUnitSize());
            SetCapacity(src.Capacity());
            m_writeBegin = src.m_writeBegin;
            m_writeEnd = src.m_writeEnd;        
        }
        return *this;
    }
    
    size_t GetUnitSize() const
...    
    size_t Capacity(void) const
...    
    void Reset(size_t itemCount)
    {
        m_writeBegin = 0;
        m_writeEnd = 0;

        if(itemCount != 0 && itemCount != m_allocationCount)
        {
            SetCapacity(itemCount);
        }
    }    
    
protected:

    virtual void SetCapacity(size_t itemCount)
    {
        m_allocationCount = itemCount;
        m_writeBegin = 0;
        m_writeEnd = 0;      
    }    

    void SetUnitSize(size_t unitSize)
...    
    size_t m_unitSize;
    size_t m_allocationCount;//Track item count we have space for.
    size_t m_writeBegin;
    size_t m_writeEnd;    
};

I've added a convenience API for Reset as that's a thing users might need. If I was truly lazy I might not bother until there's a specific need of course but it modifies m_writeBegin and m_writeEnd so it may as well go in now.

We need a way to know how much space there is left in the buffer to write into before we go doing anything too dramatic like actually letting the user write data.

size_t Buffer::WriteCapacity() const
{
    size_t result = 
        m_allocationCount - 
        static_cast<size_t>(m_writeEnd - m_readBegin);
    return result;
}

This calculation may not make any sense right now. You'll need to trust me for a moment and we'll need to add read variables to Buffer as it turns out WriteCapacity is dependent on how much has already been read.

class Buffer
{
public:
    Buffer() : m_unitSize(1)
...
    Buffer(size_t unitSize, size_t itemCount) : 
        m_unitSize(unitSize)
...    
    Buffer(const Buffer& src)
...
    ~Buffer()
...    
    Buffer& operator = (const Buffer& src)
    {
        if(&src != this)
        {
            SetUnitSize(src.GetUnitSize());
            SetCapacity(src.Capacity());
            m_readBegin = src.m_readBegin;
            m_readEnd = src.m_readEnd;
            m_writeBegin = src.m_writeBegin;
            m_writeEnd = src.m_writeEnd;        
        }
        return *this;
    }
    
    size_t Buffer::WriteCapacity() const
    {
        size_t result = 
            m_allocationCount - 
            static_cast<size_t>(m_writeEnd - m_readBegin);
        return result;
    }

    size_t Buffer::ReadCapacity() const
    {
        size_t result = 
            static_cast<size_t>(m_writeBegin - m_readEnd);
        return result;
    }
    
    size_t GetUnitSize() const
...    
    size_t Capacity(void) const
...    
    void Reset(size_t itemCount)
    {
        m_readBegin = 0;
        m_readEnd = 0;
        m_writeBegin = 0;
        m_writeEnd = 0;

        if(itemCount != 0 && itemCount != m_allocationCount)
        {
            SetCapacity(itemCount);
        }
    }    
    
protected:

    virtual void SetCapacity(size_t itemCount)
    {
        m_allocationCount = itemCount;
        m_readBegin = 0;
        m_readEnd = 0;
        m_writeBegin = 0;
        m_writeEnd = 0;      
    }    

    void SetUnitSize(size_t unitSize)
...    
    size_t m_unitSize;
    size_t m_allocationCount;//Track item count we have space for.
    size_t m_readBegin;
    size_t m_readEnd;
    size_t m_writeBegin;
    size_t m_writeEnd;    
};

Now that we've got ReadCapaciy things might start to make more sense.

size_t Buffer::ReadCapacity() const
{
    size_t result = 
        static_cast<size_t>(m_writeBegin - m_readEnd);
    return result;
}

The data available for reading is in-between where we're going to write next and the end of what we've already read or are reading.

NOTE: This is the key to how the whole thing works so don't skip this bit.

Here's a representation of our buffer

|?-?-read_begin - - - - read_end( # # # #) write_begin - - - write_end?-?-|

The ( # # # #) part in the middle is what's already finished being written but hasn't started being read yet, i.e. the available Read Capacity.

The Write Capacity is the total buffer size less everything that has already been written and hasn't finished being read yet. i.e.

m_allocationCount - (m_writeEnd - m_readBegin);

Just the ?-?- space on the beginning and ?-?- end of the line in the diagram.

The part between read_begin and read_end is being read. The part between write_begin and write_end is being written. Either or both of these might be zero sized.

Hopefully that's super clear. Buffer management should be simple right.

Now that we know how much space is available for reading and writing we're almost ready to let clients write.

virtual size_t Buffer::WriteAcknowledge(size_t& itemCount)
{
    if(itemCount > (m_writeEnd - m_writeBegin))
    {
        itemCount = 
        static_cast<size_t>(m_writeEnd - m_writeBegin);
    }
    m_writeBegin += itemCount;
    m_writeEnd = m_writeBegin;
    return WriteCapacity();
}

This function lets clients tell us how many items they wrote. If they say they wrote more than the available space we disbelieve them.
Then we move the write_begin marker along by the number of items and set the write_end marker to the end of the actually written space as the client may not have written everything between write_begin and write_end this might mean write_end moving back. but it's always >= write_begin.

We'll obviously need the analogous function for reading so we might as well add that in.

size_t Buffer::ReadAcknowledge(size_t& itemCount)
{
    if(itemCount > (m_readEnd - m_readBegin))
    {
        itemCount = 
        static_cast<size_t>(m_readEnd - m_readBegin);
    }
    m_readBegin += itemCount;
    m_readEnd = m_readBegin;
    return ReadCapacity();
}

This allows the client to tell us they're done reading itemCount items.
However they might just want to say they are rejecting the last itemCount items they previously requested to read. They'll still need to acknowledge the ones they do read to move the read_begin point forward.

size_t Buffer::ReadReject(size_t& itemCount)
{
    if(itemCount > (m_readEnd - m_readBegin))
    {
        itemCount = static_cast<size_t>(m_readEnd - m_readBegin);
    }
    m_readEnd -= itemCount;
    return ReadCapacity();
}

We're almost there I promise. Just two more functions on this class to go.
All that's left is functions for the client to Request to Read, i.e. move the read_end point forward and to Request to Write, i.e. move the write_end point forward.

virtual byte* Buffer::WriteRequest(size_t& /*itemCount*/)
{
    return nullptr;
}

virtual byte* Buffer::ReadRequest(size_t& /*itemCount*/)
{
    return nullptr;
}

What happened?
Well we can't actually write these functions because they need to return actual pointers to data. We could complicate the Buffer class by adding real memory handling but that wouldn't be sfumato.
Instead having gradually built up one layer and reached the point where the client facing interface is defined if not entirely implemented, we'll begin another layer.

Layer 2: All the pointer magic in one place

We'll use traditional Object Oriented extension by inheritance. A PODBuffer< pod_t > is a Buffer. We'll add a template parameter as still nobody has told us what goes in this Buffer.

template< class pod_t >
class PODBuffer : public Buffer
{
protected:

    pod_t* m_pAllocation{nullptr};
};

Let's add some standard class furniture and then deal with memory management

template< class pod_t >
class PODBuffer : public Buffer
{
public:

    PODBuffer(size_t itemCount = 0) : 
        Buffer(sizeof(pod_t), itemCount)
    {
        SetCapacity(itemCount);
    }

    PODBuffer(const PODBuffer& src)
    {
        *this = src;
    }

    virtual ~PODBuffer()
    {
        //This is needed. Remind me to write an article
        //about why virtual functions don't work
        //in base class destructors.
        SetCapacity((size_t)0);
    }

    PODBuffer& operator = (const PODBuffer& src)
    {
        if(&src != this)
        {
            Buffer::operator = (src);
            memcpy(
                m_pAllocation, 
                src.m_pAllocation, 
                sizeof(pod_t) * std::min(
                    m_allocationCount, src.m_allocationCount
                )
            );
        }
        return *this;
    }

protected:

    pod_t* m_pAllocation{nullptr};
};

When the pod_t type is determined it's size will be available to become the Buffer unit size. We could add a requires clause using type traits to ensure it's a fixed size type however std::is_pod is deprecated and I'm not sure which one to use in its place. std::is_standard_layout ? Let me know and I'll add it.

When we copy a PODBuffer, now we actually copy the contents as well. Taking care to use only the size of the smaller buffer.
However so far there are no contents. Lets fix that by overriding SetCapacity

virtual void SetCapacity(size_t itemCount)
{
    if(m_allocationCount == itemCount && m_pAllocation != nullptr)
    {
        return;
    }

    delete[] m_pAllocation;
    m_pAllocation = (itemCount > 0) ? 
        new pod_t[itemCount] : nullptr;

    memset(m_pAllocation, 0, sizeof(pod_t) * itemCount);
    Buffer::SetCapacity(itemCount);
}

That's it. One new and one delete. Now those SetCapacity((size_t)0) calls we did earlier don't look so silly. For added security we fill the Buffer with zeros.
Let's override the failed implementation of WriteRequest now with one that returns a valid pointer.

virtual byte* WriteRequest(size_t& itemCount)
{
    pod_t* result = 0;
    if (itemCount == 0 || itemCount > WriteCapacity())
    {
        itemCount = WriteCapacity();
    }

    if (itemCount > 0)
    {
        result = AddressOf(m_writeBegin);
        m_writeEnd += itemCount;//write_end moves here
    }

    return reinterpret_cast<byte*>(result);
}

It would be nice to return a pod_t* here but C++ doesn't do covariant return types so to override the truly ignorant Buffer::WriteRequest we have to return a byte*. The client can safely cast it back as they know what a pod_t is.

Note that a write request is just that. Requesting to write 65 items might get you space to write 5 or 0 if the buffer is full. the client will need to take note of the value of itemCount after the call. This is how many items they are allowed to write.

Requesting to read is very similar but first lets look at AddressOf

pod_t* AddressOf(size_t index)
{
    pod_t* result = nullptr;
    if (m_allocationCount > 0)
    {
        result = m_pAllocation + (index % m_allocationCount);
    }
    return result;
}

This gives an offset into the allocated space in multiples of sizeof(pod_t) which is always within the allocated space.
Remember the + operator here is using pointer arithmetic rules. As m_pAllocation is a pod_t* so it adds in sizeof(pod_t*) sized units. Exactly what we want. ReadRequest uses the same function:

virtual byte* ReadRequest(size_t& itemCount)
{
    pod_t* result = AddressOf(m_readBegin);
    if (itemCount > ReadCapacity())
    {
        itemCount = static_cast<size_t>(ReadCapacity());
    }
    m_readEnd += itemCount;//read_end moves here
    return reinterpret_cast<byte*>(result);
}

You may have wondered how we keep the read_begin, read_end, write_begin and write_end values within the allocated space. The answer is that we don't. We care that Read follows Write and that End is >= Begin but we don't care what the actual numeric values are. (index % m_allocationCount) gives the correct position in the buffer and limiting the Write Capacity to the allocation size is sufficient to ensure that write_end is never more than allocation count units ahead of read_begin so we don't don't tread on our own tail as the output of (index % m_allocationCount) wraps around.

This leaves us with just one problem. When we report Read and Write capacities to the client we don't take that wrap around into account. If the available space is split over the end of the buffer we can't give the client a contiguous block of memory to Read or Write. We could give them two but that would be a really weird interface. Here's most of the memory you asked for and here's the other bit which is usually null.

Instead we'll just behave as if the second part wasn't available. To do this we need to override WriteCapacity and ReadCapacity

virtual size_t WriteCapacity()
{
    size_t result = m_allocationCount - 
        static_cast<size_t>(m_writeEnd - m_readBegin);

    if(AddressOf(m_writeBegin) + result > EndOfBuffer())
    {
        result = EndOfBuffer() - AddressOf(m_writeBegin);
    }
    return result;
}

virtual size_t ReadCapacity()
{
    size_t result = static_cast<size_t>(m_writeBegin - m_readEnd);

    if(AddressOf(m_readEnd) + result > EndOfBuffer())
    {
        result = EndOfBuffer() - AddressOf(m_readEnd);
    }
    return result;
}

pod_t* EndOfBuffer(void)
{
    pod_t* result = nullptr;
    if (m_allocationCount > 0)
    {
        result = m_pAllocation + m_allocationCount;
    }
    return result;
}

That's really it this time. Here's the whole PODBuffer< pod_t > class along with streaming >> operators << to easily insert and extract items.

template< class pod_t >
class PODBuffer : public Buffer
{
public:

    PODBuffer(size_t itemCount = 0) : 
        Buffer(sizeof(pod_t), itemCount), m_pAllocation(nullptr)
    {
        SetCapacity(itemCount);
    }

    PODBuffer(const PODBuffer& src)
    {
        *this = src;
    }

    virtual ~PODBuffer()
    {
        SetCapacity((size_t)0);
    }

    PODBuffer& operator = (const PODBuffer& src)
    {
        if(&src != this)
        {
            Buffer::operator = (src);
            memcpy(m_pAllocation, 
                src.m_pAllocation,
                sizeof(pod_t) * std::min(
                    m_allocationCount, src.m_allocationCount
                )
            );
        }
        return *this;
    }

    PODBuffer& operator << (const pod_t& item)
    {
        size_t count = 1;
        pod_t* pWrite = reinterpret_cast<pod_t*>
            WriteRequest(count));

        if(pWrite && count == 1)
        {
            *pWrite = item;
            WriteAcknowledge(count);
        }
        return *this;
    }

    PODBuffer& operator >> (pod_t& item)
    {
        size_t count = 1;
        pod_t* pRead = reinterpret_cast<pod_t*>
            (ReadRequest(count));

        if(pRead && count == 1)
        {
            item = *pRead;
            ReadAcknowledge(count);
        }

        return *this;
    }

    virtual size_t WriteCapacity()
    {
        size_t result = m_allocationCount - 
            static_cast<size_t>(m_writeEnd - m_readBegin);

        if(AddressOf(m_writeBegin) + result > EndOfBuffer())
        {
            result = EndOfBuffer() - AddressOf(m_writeBegin);
        }
        return result;
    }

    virtual size_t ReadCapacity()
    {
        size_t result = static_cast<size_t>(
            m_writeBegin - m_readEnd);

        if(AddressOf(m_readEnd) + result > EndOfBuffer())
        {
            result = EndOfBuffer() - AddressOf(m_readEnd);
        }
        return result;
    }

    virtual byte* WriteRequest(size_t& itemCount)
    {
        pod_t* pResult = 0;
        if (itemCount == 0 || itemCount > WriteCapacity())
        {
            itemCount = WriteCapacity();
        }

        if (itemCount > 0)
        {
            pResult = AddressOf(m_writeBegin);
            m_writeEnd += itemCount;
        }

        return reinterpret_cast<byte*>(pResult);
    }

    virtual byte* ReadRequest(size_t& itemCount)
    {
        pod_t* pResult = AddressOf(m_readBegin);
        if (itemCount > ReadCapacity())
        {
            itemCount = static_cast<size_t>(ReadCapacity());
        }
        m_readEnd += itemCount;
        return reinterpret_cast<byte*>(pResult);
    }

    virtual void SetCapacity(size_t itemCount)
    {
        if(m_allocationCount == itemCount 
            && m_pAllocation != nullptr)
        {
            return;
        }

        delete[] m_pAllocation;
        m_pAllocation = (itemCount > 0) ? 
            new pod_t[itemCount] : nullptr;

        memset(m_pAllocation, 0, sizeof(pod_t) * itemCount);
        Buffer::SetCapacity(itemCount);
    }

protected:

    pod_t* EndOfBuffer(void)
    {
        pod_t* pResult = nullptr;
        if (m_allocationCount > 0)
        {
            pResult = m_pAllocation + m_allocationCount;
        }
        return pResult;
    }

    pod_t* AddressOf(size_t index)
    {
        pod_t* result = nullptr;
        if (m_allocationCount > 0)
        {
            result = m_pAllocation + (index % m_allocationCount);
        }
        return result;
    }

    pod_t* m_pAllocation;
};

and for completeness (because I'm not really very good at being lazy)

typedef PODBuffer< byte > ByteBuffer;

The two hard things that catch everyone out the first few times doing buffers are the memory management and preventing overruns. It turns out that actual memory management requires just two lines of code.

delete[] m_pAllocation;
m_pAllocation = (itemCount > 0) ? new pod_t[itemCount] : nullptr;

And buffer overruns are terminated forever by just one.

result = m_pAllocation + (index % m_allocationCount);

We used the power of our ignorance of the real requirements to create a semi circular buffer class for any number of units of any fixed sized type. We left it up to the client to decide everything we didn't know and we delayed all the hard parts until they weren't hard or we didn't have to do them at all. We separated the task into layers that deal with different problems. Keeping every step as simple as possible.

#include <cstddef>
#include <cstdint>
#include <cstring>
#include <cassert>
#include <string>
#include "podbuffer.h"

struct test_s
{
    bool b;
    const char* s;
    unsigned long long l;
};

int main()
{
    PODBuffer<test_s> aBuffer(15);
    test_s test{ true, "something", 100000000 };
    aBuffer << test;
    test_s result;
    aBuffer >> result;
    assert(memcmp(&result, &test, sizeof(test_s)) == 0);
    return 0;
}

Conclusion:

What are the costs and benefits of this sfumato approach to writing code?

The resulting code is certainly not compact. Although that doesn't matter as much in a compiled language like C++ as it would in Python or JS.
You can end up with many layers and it requires a well organised source tree not to loose track of them.

The performance has not been honed to the last clock cycle and cache line. I generally prefer to leave that to the optimising compiler which knows a great deal more about my hardware than I do. Is this buffer fast though? In practice you can count the nano seconds because they seldom reach 3 digits. Yes it's fast although you're welcome to make it faster and let me know how.

The functions are small and simple. You may have noticed that there's no single function in this article that's more than a handful of lines. This makes writing unit tests as you go along easy. This also makes tracking down bugs and generally understanding the code you wrote 5 years ago, easier.

You get reliable, readable, intentional, testable code with strong separation of concerns. So don't be afraid to write incomplete classes that only do part of the job. As long as the part they do is simple, safe and reliable. You can always add another layer of sfumato to solve the next problem. Abstracting each problem, or set of problems, into it's own thin layer leads to surprisingly pleasing results.

This PODBuffer< pod_t > class, or one very like it, is in use in the general data pipeline library of the QuerySoft Open Runtime. I wrote the first version of it more than a decade ago and it's changed very little. (That's why some of the code style is a bit out of date)

Do you have a favourite class or code snippet that you've been using for years across projects. Is it sfumato code? If you do please consider sharing it.

Here's a snippet of Buffer in real use. It was streaming JSON from a file to a parser at the time but you can't tell by looking.

bool Source::Pull(size_t& unitsRead, size_t unitsToRead)
{
    if(!unitsToRead)
    {
        return true;
    }

    Buffer* buffer = GetBuffer();
    if(buffer)
    {
        byte* space = buffer->WriteRequest(unitsToRead);
        if(!space)
        {
            log::debug("Buffer capacity: {0}, Write capacity: {1}, Read capacity: {2}, Unit size: {3}", 
                buffer->Capacity(), 
                buffer->WriteCapacity(), 
                buffer->ReadCapacity(), 
                buffer->GetUnitSize());
            continuable("Pipeline stall. No space in source buffer.");
            return false;
        }

        size_t bytesRead = ReadBytes(
            space, buffer->GetUnitSize() * unitsToRead);

        if(bytesRead > 0)
        {
            unitsRead = bytesRead / buffer->GetUnitSize();
            buffer->WriteAcknowledge(unitsRead);
            OnReadSuccess(unitsRead);
        }
        else
        {
            OnEndOfData();
        }
        return true;
    }
    else
    {
        return false;
    }
}

External Polymorphism

Matthew Faithfull — Thu, 06 Aug 2026 01:01:06 +0000

External Polymorphism - Ways of getting the same extensibility and composability of types you get with 'normal' inheritance based polymorphism but without virtual functions or thunks and their associated costs. Without changing the types that you're extending and composing or imposing heavy requirements on them.

The idea has been around for at least thirty years and there have been lots of C++ implementations over the years. Mostly they started out recreating vtables outside the target classes in an effort to implement type erasure. These days type erasure is common place but, useful as it is, it is only one form of external polymorphism.

I've recently been porting a std::function alternative library magic_func which uses type erasure over function pointers and also looking at Ilya Korolev's Contracts library which puts what could maybe be external polymorphism back into the types being adapted. That gives you access to all the internals of the target type and uses the encapsulation of the target type to encapsulate the contract machinery as well.
Can we do some of what Contracts is doing without modifying the target classes and at the same time do type safe external polymorphism rather than fully generic type erasure.?

Using the principles of code sfumato we'll see if we can gradually build something useful starting very simple.
Let's say we have some kind of business object...

namespace domain
{
    struct datatype
    {        
        unsigned int accno;
        float ammount;
        std::string name;
        std::vector<std::string> log;
    };  
}

Everything is public. Everything is a value type. This is just plain data.

There are two ways we could bind something external to a member of
domain::datatype in C++. Either by pointer or by reference.
Pointers are easy to type erase, they're all the same size and they don't have to be initialised. The downside is that because they don't have to be initialised, they do have to be null checked and because they are stored and have size they can't easily be elided by the optimiser.
References are somewhat more slippery to deal with but we'll give them try. Mostly because in the past I've always opted for pointers and I've never been super happy with the result.

template< typename T >
struct ValueAdapter
{
    ValueAdapter(T& t) : m_(t)
    { }        
private:
    T& m_;
};

Not bad as a first attempt. We can construct a ValueAdapter(x) on any value of type T and we have an object entirely external to T which can operate on x.
To make ValueAdapter useful though we need to extend it with the operations we want to perform on our captured T&.

When I first started messing around with external polymorphism it was extremely difficult to do. In 2003 tuples were a PhD thesis by a Finnish researcher and I may have been the first ever person to see
tuple::get<0>(t) compile under under a Microsoft compiler and execute correctly on Windows. It needed compiler specific template and macro hackery to make the port work (barely) with a maximum of 5 elements and it wasn't practical.
These days many extraordinary things are possible in modern C++. We'll come back to tuples. Lets try to improve ValueAdapter.

template <typename T, typename... Bases>
struct ValueAdapter : public Bases...
{
    using value_type = T;
    ValueAdapter(T& t) : Bases(std::forward<T&>(t))...
    { }        
};

A second attempt at ValueAdapter lets us provide it with a type for the value and a list of types to inherit from, each of which gets constructed with the T&, passed to ValueAdapter. We no longer need to hold a reference in this root object as each operation that needs one will hold onto one itself.

You might notice the Curiously Recuring Template Pattern (CRTP) hiding here in parameter pack form.

To make use of this we'll need to write a set of operations that can be composed into a ValueAdapter. Starting with a simple Read to get the value.

template<typename T>
struct Read
{    
    Read(T& t) : m_(t){ }

    T Get() const {return m_;}
    
private:
    T& m_;
};

Here's an equally simple Write to set the value.

template<typename T>
struct Write
{
    Write(T& t) : m_(t){ }

    void Set(const T t){ m_ = t; }    
    
private:

    T& m_;
};

These operations are so trivial and specific in what they do that they might even be considered bug free, maybe.

Now we can make an actual ValueAdapter type to eventually attach to unsigned int datatype::accno :

using AccNoAdapter = ValueAdapter< 
unsigned int, Read< unsigned int >, Write< unsigned int > >;

If we left out the Write we'd have a read only value and if we left out the Read we'd have a write only value. Both things we might want at some point. A practical library would certainly provide ReadOnlyValueAdapter as a type and many other operations we could plug in so we might end up with something like:

using AccNoAdapter = ReadOnlyValueAdapter< 
unsigned int, StreamOut< unsigned int >, 
ToString< unsigned int >, Name< unsigned int > >

This is fine but a bit tedious to type with the repetition of unsigned int, the type of the underlying thing we're binding to.
It should be possible to just say we want the ReadOnlyValueAdapter
type with an unsigned int and a list of operations, that also get the unsigned int automatically.

template<
    template<class...> class P,
    class T,
    template<class> class... L >
struct adapter_apply
{
    using type = P<T, L<T>... >;
};

With this beauty using template templates and pack expansion it is. We can now say:

using AccNoAdapter = adapter_apply<
    ReadOnlyValueAdapter, unsigned int, 
    StreamOut, ToString, Name >::type;

AccNoAdapter becomes a ReadOnlyValueAdapter templated on unsigned int and the expanded list of types, each templated on unsigned int exactly as we did before by hand.

That takes care of attaching almost anything we can think of to a single value type.

unsigned int accno;
AccNoAdapter accnoAdapter(accno);

attaches reading, writing, naming and streaming operations to accno so we can do things like.

accnoAdapter.SetName("Bob");
accnoAdapter.Set(163);
std::cout << accnoAdapter;

Here are a couple more ValueAdapter types we need to build to address the members of domain::datatype

using AmmountAdapter = adapter_apply< 
    ValueAdapter, float, 
    Read, EnhancedNumericWrite, 
    StreamIO, Name >::type;

using LogAdapter = adapter_apply< 
    CollectionAdapter, std::vector<std::string>,
    ReadCollection, Append, StreamOutCollection >::type;

We've painted the first layer of external polymorphism, Value Adapters.

Now we'd like to adapt entire objects at a time. In practice what we usually want is to provide specific interfaces over those objects that meet the requirements of something external to our domain.

template <typename... Args>
struct InterfaceAdapter : public std::tuple<Args...>
{
    using storage_type = std::tuple<Args...>;

    InterfaceAdapter(Args&&... args) : 
        std::tuple<Args...>{std::forward<Args>(args)...}
    { }
    //...

This is where tuples come in handy. Under the hood they are derived from all their arguments recursively and come with helpful and reliable standard library machinery like iteration and element lookup.
Otherwise the pattern is similar to what we did with ValueAdapter except that now the composed base classes are the ValueAdapter types we built up for the individual members.

using PaymentInterface = InterfaceAdapter< 
AccNoAdapter, AmmountAdapter, LogAdapter >;

These interface types are a kind of two dimensional class. A tuple of ValueAdapters, one for each member being referenced, with each ValueAdapter being a collection of operations attached to that member.

We need to bind this interface type to the underlying storage type domain::datatype that we started with. For this we'll need a binding adapter

template<class interface_t, class storage, typename field_enum>
struct Adapter : public interface_t, protected storage
{            
    template <typename... Args>
    Adapter(storage& src, Args&&... args) : 
        storage(src), interface_t(args...)
    { }

    //accessor for fields
    template<field_enum f>
    auto& at() { return std::get<static_cast<int>(f)>(*this); }

    template<field_enum f>
    struct type_of_field
    {
        using type = std::invoke_result_t<
            decltype(
                &Adapter<interface_t, storage, 
                field_enum>::template at<f>
            ), 
            Adapter<interface_t, storage,
            field_enum> >;
        };
    };

In order to map the elements from our ValueAdapter tuple to members in domain::datatype we also need to provide the adapter with an enum class

enum class paymentfields
{
    account,
    ammount,
    log
};

This just gives names to constants 0, 1 & 2 so that we can say things like

payment.at<paymentfields::account>().SetName("Account");

We'll get to that. First we need to combine our interface and enumeration types together to form a specific adapter type.

template<class storage>
struct PaymentAdapter : public Adapter<PaymentInterface, storage, paymentfields>
{
    PaymentAdapter(storage& src) : 
      Adapter<PaymentInterface, storage, paymentfields>(src,
        storage::accno,//the position in this list
        storage::ammount,//must match the enum value
        storage::log)//of the associated ValueAdapter
    { }
};

storage is still a template parameter here but we know it must have at least the named fields, in any order, for this template to be instantiated.
It's important to note that because Adapter inherits from storage PaymentAdapter is an instance of storage. The underlying struct will be copied when bound to PaymentAdapter and it will operate on the copy.
This is fine for outgoing adapters that read storage and provide an interface for something external but if we want to be able to modify the original storage type instance through the interface then we need a Port rather than an Adapter.

template<class interface_t, class storage, typename field_enum>
struct Port : public interface_t
{                
    template <typename... Args>
    Port(storage& src, Args&&... args) : 
        m_(src), interface_t(args...)
    { }

    //accessor for fields
    template<field_enum f>
    auto& at() { return std::get<static_cast<int>(f)>(*this); }

    template<field_enum f>
    struct type_of_field
    {
        using type = std::invoke_result_t<
            decltype(&Port<interface_t, storage,
                field_enum>::template at<f>),
            Port<interface_t, storage, field_enum> >;
    };

private:

    storage& m_;
};

A Port over the PaymentInterface and the same paymentfields enumeration gives us:

template<class storage>
struct PaymentPort : public Port<PaymentInterface, storage, paymentfields>
{
    PaymentPort(storage& src) : 
        Port<PaymentInterface, storage, paymentfields>(src,
        src.accno,//The refenced fields from the src
        src.ammount,//are bound to the ValueAdapters
        src.log)//in the order of the paymentfields enum
    { }
};

With all the type infrastructure we need in hand we can now do:

using adapter_t = PaymentAdapter<domain::datatype>;

domain::datatype data{ 20015678, 56.8f, "name" };
adapter_t payment(data);

payment is now a PaymentInterface bound to a copy of data. We can use the paymentfields enum to access the ValueAdapters and directly call the bolted on operations as if they were functions on members of domain::datatype.

payment.at<paymentfields::account>().SetName("Account");
auto a = payment.at<paymentfields::account>().Get();

payment.at<paymentfields::ammount>().SetName("Payment Ammount");
payment.at<paymentfields::ammount>().SetMinimum(0.01f);
payment.at<paymentfields::ammount>().SetMaximum(10000.0f);

payment.at<paymentfields::ammount>().SetOnChange(
    qor_pp_make_function(&OnPaymentAmmountChange));

payment.at<paymentfields::ammount>().Set(103.8f);

There's more though. I didn't show you the full implementation of
InterfaceAdapter above. It enables us to do things like applying a lambda template to each of the fields on an interface

payment.for_each_field([](size_t& index, const auto& x)     
{                        
    if constexpr(is_streamoutable<decltype(x)>())
    {
        if (index++ > 0) std::cout << ", ";
        if constexpr(is_named<decltype(x)>())
        {
            std::cout << x.GetName() << ": ";
        }
        x.operator << (std::cout);
    }
});

This iterates over the tuple of ValueAdapters on the PaymentInterface calling the lambda with each one. The lambda has to be a template because each ValueAdapter has a different type.
The is_streamoutable and is_named functions check whether the field being processed has particular operations attached to it. These are constexpr functions so the parts of the lambda that won't work never even make it into the binary.
In this way we can filter fields for ones that can be printed or read or written or whatever we need.

template<typename x>
constexpr bool is_named()
{
    using x_type = std::remove_cvref_t<x>;
    if constexpr(is_valueadapter<x>())
    {
        using v_type = typename x_type::value_type;
        return std::is_base_of_v<Name<v_type>, x_type>;
    }
    /*More stuff to handle Collections*/
    return false;
}

To use a Port that can modify our original object we wrap a PaymentPort around our domain::datatype.

using port_t = PaymentPort<domain::datatype>;
port_t pay(data);

pay.at<paymentfields::ammount>().Set(34.67f);
pay.at<paymentfields::log>().push_back("Set ammount to 34.67");

pay holds a reference to data so these lines modify the contents of data directly.

The types of individual fields can be retrieved with
interface_t::type_of_field< enum_index >::type
as seen here where we check if the account field is convertible into a string before attempting to write it out. is_stringable works just like is_named. It checks if the type is derived from the ToString<> operation.

if constexpr(is_stringable<
    adapter_t::type_of_field<paymentfields::account>::type >())
{
   std::cout << 
       payment.at<paymentfields::account>().toString();
}

That's it. There are undoubtedly wrinkles. Every implementation of external polymorphism I've come across has them but with this small library of templates we can build almost any functionality over a set of plain data objects without virtual functions and without modifying them.
There are no vtables. We don't even have to build artificial ones ourselves. The equivalent is the lookup done by std::get< i >( T ) to get a reference into our tuple of ValueAdapters.
We can have multiple specialist interfaces over the same type without any cross dependency or additional cost and we can add unlimited meta data, validation, etc to those interfaces. We can introspect the operations available on a data item and branch on the result with no runtime cost. Every custom operation is available for reuse on any interface without even having to derive from it.

When templates were still a non standard feature, liable to crash your compiler, and tuples were academic research we dreamed of being able to do things like this. What do you dream of being able to do that's just out of reach with C++ today?

Source code is available on the DomainInterfaceObjects branch of the QOR
If you think it's of value let me know and I'll pull it into main.

Fast Parsing

Matthew Faithfull — Fri, 31 Jul 2026 15:04:28 +0000

I've been attempting to optimise my state machine based text parser. As a precursor to making it do Unicode and act as a base layer for a JSON parser, HTML parser etc.
The internet tells me that Google's V8 can crunch through ASCII characters at ~1/10ns if you can believe that. I can't get closer than an order of magnitude with about ~1/150ns. At least that's down from ~1/1000ns this morning.

Here's what I've done so far:

I branched my basic state machine which uses std::function for it's events.
std::function has now been replaced with qor::tef (Type Erased Function) ported from Magic Function by Leandro Gracia Gil.
That should mean each call/event has half the overhead of std::function

I removed the suspend event from the new Workflow variant, Fastflow, altogether as the parser framework doesn't use.

The replacement Fastflow steps and all their derivatives now use a custom allocator, or in QOR framework terms they have a custom memory source policy.

template<> struct source_of< data::parser::text::utf8char >{ typedef memory::FastSource type;};

FastSource is a per-thread stack style arena which only free's when pages empty out. Perfect for large numbers of small allocations which go away when the parser is finished.

I also tried the per-thread SmallObjectSource which is a little more space efficient. The performance was identical to native but that's expected as this is a single threaded scenario so there's no contention for the global heap.

I had profiled the parsing of a 73KB file using the framework's built-in profiling. Hence the base line 1 microsecond per character.
When that couldn't tell me where the time was going I used the Visual Studio profiler to dig deeper into what was happening.

I'd already played about with the buffer size used to read the underlying file and surprisingly bigger was not better. Performance peaked at ~60-120 bytes and tailed off with a larger buffer. The buffers shouldn't get reallocated in use so this is odd and I'll need to dig deeper to determine why. I expected a single buffer big enough to consume the whole file at once would be optimal. Apparently not. I set it at 64 bytes.

For now I'm excluding the IO time and focussing on the parser where an
unexpectedly a large chunk of the time was spent pushing and popping to the std::stack<> of the state machine itself. I minimised this by using std::stack::top when mutating the top node rather than popping it and then pushing it back later. That wasn't enough so I overrode the underlying container over which std::stack is an adapter.

It now uses a std::vector instead of a std::deque

std::stack< ref_of<fastflow::Step>::type, std::vector< ref_of<fastflow::Step>::type > > m_StepStack;

So I can reserve space in the vector in advance.

std::vector< ref_of<fastflow::Step>::type > stepVector;
stepVector.reserve(64);
m_StepStack = std::stack< ref_of<fastflow::Step>::type, std::vector< ref_of<fastflow::Step>::type > >(std::move(stepVector));

With a simple parse tree for repeatedly tokenizing characters this should be more than enough to avoid reallocation completely.

Now the flame graph looks like this:

As you can see the parse is taking almost the same time as the I/O. The two together are ~22.5ms on a 4GHz Zen3 CPU Core.

I've had a look at the V8 source code for clues as as to what they might be doing to be 10x more efficient but it's certainly not obvious.

My code will be up at QOR experimental as soon as I've assessed what else all those changes have broken.
Running your own memory memory allocators tends to either work smoothly or blow up pretty spectacularly.

I'd welcome any suggestions as to what else I could optimise, how to get similar performance data on Linux or if you've been down a similar road.

I hope your day was as interesting as mine.

I asked Reddit what they wanted in a C++ application framework and their answers were...

Matthew Faithfull — Wed, 22 Jul 2026 17:28:16 +0000

In short their answers were useful and highly aligned, not just with with my thinking but with one another. There wasn't consensus, this is the internet, but there were was remarkable consistency.

"...painless cross-platform-ness, obviously. One should not need to dip into the underlying Win32 on Windows, say, basically ever to do typical things."

Agreed! We should be able to create substantial applications without consideration for which OS they're going to run on. Most of the languages our applications talk these days, from Unicode to OpenGL, to gRPC are standardised across operating systems and even across programming languages. With a little bit of work to smooth over the idiosyncrasies of individual operating systems we aught to be able to program in terms of these standards without worrying about the target platform on which they'll end up running.
In practice of course that 'little bit of work' could end up being rather large but perhaps it can be done.

"Must support CMake find_package vcpkg instrumentation..."

Agreed! We love to hate CMake but it is what the industry is settling around. We build with CMake and package with vcpkg. It doesn't solve all our problems or make delivering C++ software easy but it works well enough and will likely get the focus and feedback required to keep making it better.

"License must be something like BSD..."

Agreed! Boost license, MIT license and BSD licenses so that the project can be used commercially without caveats or concerns. Anyone can contribute, including companies and everyone who wants to commercialise their own fork can. No fuss, no argument licensing makes adoption much smoother and therefore much more likely.

"All C++...", "No DSL...", "No extra pre-processor stage..."

Agreed! C++ can do anything so if we're doing something, we're doing it in C++. Especially for a C++ framework. That includes Signals and Slots. DSLs are the temptation ever in the corner of the eye. Goading us make things look simpler while destroying discoverability and imposing new vocabulary on our users.

"Must not be header only..."

Agreed! Gigantic header only libraries are a menace. They slow build times, often hide bad code, leak definitions, have unclear APIs and all contain similar but not quite the same, boiler plate for platform and compiler support. Duplicated code that makes them inconsistent with one another and undermines your platform support from below while preventing you from centralising it.
Boost was originally intended to be a header only framework and it still suffers from the consequences today with header dependency chains reaching out across multiple libraries to things you never intended to depend on. It's getting better but their moving away from header only should be a lesson learned.

"Native C++ database (scalable)..with non SQL interface."

Not a big ask at all then ;-) However it is something we could do with. Many years ago I worked with a multi dimensional BI database written in Fortran that ran rings around Oracle and made SQL Server look silly. It was definitely non SQL although it did have it's own somewhat arcane query language. Something like that in modern C++ with simplified queries would be awesome.

Then there's the UI of course.

"MUST support a declarative GUI language that’s transpiled to a compiled language like C++, so no js framework in between."

"If you are going to have a separate WPF-style layout language (please don't use XML), allow the user to opt out of it. Don't make it mandatory. That is, allow the user to create UIs by just nesting together controls using normal C++ code if that is what they want to do."

"Make it possible, if not necessarily easy, to construct 100% custom controls."

"...support a dark theme out of the box."

"...supports WebAssembly ... so that we can create amazing ..native C++ websites."

"WinForms + designer but for C++"

So we want an optional declarative GUI language that can be generated from an interactive designer, hand written, or bypassed altogether to create completely custom controls, mixed in with the provided ones. The GUI that results must run natively and in a browser using WASM.

"Like Dioxus for Rust"

as someone noted.

Last but not least.

"...with the compile times of C#."

Of course, no problem ;-)

You'll notice that while there are a lot of big asks here and this is not every response I got. There is very little in the way of contradictory requirements. In principle we could have the C++ framework we want. Cross platform, comprehensive and flexible. We'd just have to write it.

So what are your MUST HAVEs and MUST NOTs for an all new, top of the line, C++ Application Framework?
Do you believe such a project is possible and would you be interested in contributing?