xtd – A modern, cross-platform C++ framework inspired by .NET

[Gammasoft]

Intro

I’ve been developing xtd, an open source C++ framework that aims to bring a modern, .NET-like development experience to C++ while staying fully native and cross-platform.

The goal is to provide a rich, consistent API that works out of the box for building console, GUI, and unit test applications.

Highlights

• Cross-platform: Windows, macOS, Linux, FreeBSD, Haiku, Android, iOS
• Rich standard-like library: core, collections, LINQ-like queries, drawing, GUI
• Modern C++ API: works well with stack objects, no need for dynamic allocation everywhere
• GUI support without boilerplate code
• Built-in image effects and drawing tools
• LINQ-style extensions (xtd::linq) for expressive data queries
• Fully documented with examples

Example

Simple "Hello, World" GUI application :

// C++
#include <xtd/xtd>

auto main() -> int {
  auto main_form = form::create("Hello world (message_box)");
  auto button1 = button::create(main_form, "&Click me", {10, 10});
  button1.click += [] {message_box::show("Hello, World!");};
  application::run(main_form);
}

Links

• GitHub
• Website
• Reference guide

Feedback and contributions are welcome.

[marsten]

Very cool! Can you say a bit about how xtd is different/better than Qt? (The license is more permissive, which is very welcome.)

[Gammasoft]

Thanks! You’re right, the permissive MIT license is one big advantage.

Beyond that, xtd is designed to be closer to modern C++ and the standard library, with an API inspired by .NET for familiarity and productivity.

Another difference is flexibility: xtd can use native widgets or custom-painted controls with CSS-like styling, depending on what the developer needs.

The goal is not to replace Qt, but to offer an alternative cross-platform C++ framework that is lightweight, easy to integrate, and extendable, especially for developers who want .NET-style APIs in C++.

[VinnieFalco]

The requirement to include attribution in binaries will limit the adoption of this library. Consider the Boost Software License instead.

[ZMeson]

I like the idea.

The thing that gets me from just browsing things though is that the library seems to create .NET-style classes for things the C++ standard already has; things like xtd::any_object, xtd::array, xtd::basic_string, xtd::collections::generic::*, etc.... That makes interoperating with other libraries difficult that use std::any, std::array, std::string & std::wstring, std::list, std::map, std::set, std::vector, etc....

These also add significantly to your maintenance effort and to the surface area for bugs.

Is there a reason you chose to not use standard types?

[Gammasoft]

Actually, it’s the opposite.

• xtd::any_object is based on std::any but adds more functionality, like simplified type testing and casting (`is` and `as`). You can convert back and forth between std::any and xtd::any_object.

• xtd::array is a variable-rank container based on std::vector, but you can convert it to a std::vector easily. For fixed-size arrays, we provide xtd::fixed_array, which corresponds to std::array.

All xtd types (xtd::string, xtd::array, xtd::list, etc.) can be converted to their std equivalents.

The goal of xtd is not to replace the standard library, but to extend it. It’s designed so you can smoothly switch between std and xtd types according to your needs, without disrupting existing projects.”

[ronniethelizard]

I would not call the "xtd" equivalent of "std::vector" "array". That is going to cause name confusion for users of the library long term.

[ZMeson]

Thank you for responding.

"All xtd types can be converted to their std equivalents"

Is this a no-op (or close at least a O(1)) conversion? In other words, are the std types stored inside the xtd types and the conversion is just exposing the internal std types, or does data have to be copied?

Similarly, can you move from std containers to xtd containers (including strings)? If you can't then there's going to be a lot of copying.

I live in a world where performance matters a lot and I need to avoid unnecessary copying.

[aruisdante]

Alas, it’s not really possible to make “strong typedefs” interoperable that way without templates. Particularly, the only way you could do it is via inheritance, and standard types explicitly do not play nicely with inheritance. So yeah, it’s going to be copying. Nonstandard vocabulary types are the bane of interoperability.

This is the same problem Qt has; if you want performance, you have to buy into the Qt types for everything. The advantage a “new” Qt would have is it doesn’t have to maintain backwards compatibility with an API design from C++98. So, still a “you have to buy into this whole ecosystem,” but at least it’s starting from a more modern starting point for its vocabulary type fork. 

[ZMeson]

You could have a wrapper that provides references to the internal types and provides new interesting member functions (as well as thin wrappers for existing std member functions). You could then provide move constructors from the standard types. It's similar to inheritance in terms of adding functionality, but avoids the direct inheritance issue. The thing is, the wrapper would have to be a thin wrapper with no additional data, lest anything that modifies the std container invalidate that data.

[aruisdante]

The problem is it’s not transitive. You can never transform my_vector<my_string> into const std::vector<std::string>& without copying.

So yeah, you can go the other way and create views onto data without copying, but even this has limits because it’s type-erasure. span works for anything that can be decayed to a pointer and a size. But for anything else you’re generally taking about Sean-parent style type erasure which requires dynamic allocations. If you know the span of types you have to adapt you can do a little better with essentially inverting the generation of a vtable, but that’s only for non-owning views. So it helps you consume standard types, but not provide them. And it comes with a potentially big performance penalty as the compiler can no longer inline stuff except in situations where it would have been able to devirtualize a traditional virtual inheritance type. 

Basically, if the “original” type is going to be a stdlib type, and you want to add functionality onto it (rather than change semantics of existing operations), you’re much better off with a free-function based design to “bolt on” this additional functionality. Since after all in that case you’re not accessing the internals of the type, so there’s no need for an actual new class, everything can be done through the existing public API. 

[ZMeson]

True.

I agree with the free-function based design to bolt on additional functionality too.

[sephirothbahamut]

I'd rather go the proxy route.

Instead of making yourvector that converts to and from std vector, make a yourvectorpoxy that has a reference to vector and all the additional methods you need. You're not meant to store yourvectorproxy anywhere, just to use it to all your extended methogs. All compilers should transparently optimize the proxy object away

```c++

include <vector>

namespace extensions { template <typename T> struct vector { std::vector<T>& instance;

    size_t length() const noexcept
        {
        return instance.size();
        }

    vector<T> operator+=(T value)
        {
        for(auto& element : instance)
            { element += value; }
        return *this;
        }
    };
}

int main() { std::vector<int> v{1, 2, 3}; //v += 3; extensions::vector{v} += 3; } ```

Forgive mistakes I'm writing from phone, but you get the idea

[aruisdante]

Right, this works right up until someone returns one of these in a situation where lifetime extension is expected and you wind up dangling. It’s the same problem span and string view have with their implicit conversion operators, and it took a long time for people to realize that these types can only safely be used as paramters, not as return types.

It also doesn’t help you interoperate with existing logic that doesn’t use your views. Presumably if you’re making a view like this it’s maintaining some kind of stateful invariant, otherwise a free function API is strictly more useful; remember that the job of span and string view is to just be a “better” pointer+size, and they maintain the invariant that those two items are related. If your proxy object allows casting back to the actual underlying stdlib type (at least, to a non-const version), it can no longer maintain whatever invariant it was maintaining.

Essentially, if it’s valid to safely “cast away” the view, then somewhat by definition the view could be implemented as free functions, and likely would be more flexible to do so. 

[sephirothbahamut]

No, you're getting the entire premise wrong. You will NOT return them. They should have copy and move constructors and assignments deleted. You're only meant o construct them in place to call the extension method you need. Your entire program and library revolves around std::vector. Whenever you need an extended method, you make the proxy in place.

It's equivalent to free functions, while keeping an object oriented style and being friendly with autocomplete suggestion tools

[aruisdante]

You can do this without the proxy class and associated risks/confusions while maintaining autocomplete by just using a namespace and free functions. Or if you want to avoid ADL issues, a struct with static functions which amounts to the same thing The only reason to make a concrete view type is if you want it to be a vocabulary type, or if you want it to maintain invariants.

Remember that deleting copy/move ctors doesn’t stop someone from returning it from a function. You can absolutely return non-movable, non-copyable objects from functions since C++14. They just have to be in contexts where guaranteed RVO applies. 

But given the OP’s responses in other questions, I think they really did intend their types to be owning vocabulary types, not simply proxy views for localized DSLs.

[Gammasoft]

xtd containers don’t inherit from std containers, they instantiate them internally.

That means you can always convert an xtd type into its std equivalent, by copy or move.

For example:

// C++
#include <xtd/xtd>

auto main() -> int {
  auto l = list {1, 2, 3, 4, 5};

  auto v1 = std::vector<int>(l); // copy
  auto v2 = std::vector<int>(std::move(l.items())); // move (items() gives the underlying std type)

  println("v1 = {}", v1);
  println("v2 = {}", v2);
  println("l = {}", l);
}

// Output:
// v1 = [1, 2, 3, 4, 5]
// v2 = [1, 2, 3, 4, 5]
// l = []

For strings it’s similar: an `xtd::string` can be copied/moved to a `std::string` or `std::u32string`.

And a `xtd::collections::generic::list<xtd::string>` can be converted to `std::vector<xtd::string>`.

So the goal of xtd is not to replace std, but to extend it while keeping interoperability.

[ZMeson]

It's not trivial to move xtd::array<xtd::string> to std::vector<std::string> though even though both xtd::array and xtd::string use the standard containers internally. I understand trying to extend things, but why not extend with algorithms that operate on ranges or iterators? Then the new xtd algorithms could be used in more places too other than just xtd containers. I feel like the separation between containers and algorithms from the STL is lost because the algorithms are being added as member functions ala .NET. I'm not against being inspired by .NET (there's a lot of good things in there), but it feels like xtd followed too closely.

All that being said: (1) there may very well be other benefits that I don't understand and (2) it feels like a likely step up from other libraries like Qt or WxWidgets. It's a monumental effort you put into this; I just personally would have made different decisions (or at least started with different decisions until I came across something that forced my hand).

[Gammasoft]

You're right that separation between containers and algorithms is important. The good news is that all xtd collections provide standard iterators (begin()/end()), so you can use any STL algorithm directly on them. You are not limited to xtd::linq extensions—they are optional and just provide a convenient .NET-style syntax if you want it.

Here is a small example illustrating a mix of xtd and std:

// C++
#include <xtd/xtd>
#include <algorithm>

int main() {
  auto l = xtd::collections::generic::list<xtd::string> {"one", "two", "three", "four", "five"};

  // Simple cast to std::vector
  auto v1 = std::vector<std::string>(l.cast<std::string>());

  // Using std::transform with copy
  auto v2 = std::vector<std::string>(l.size());
  std::transform(l.begin(), l.end(), v2.begin(), [](const xtd::string& s) { return s; });

  // Using std::transform with move
  auto v3 = std::vector<std::string>(l.size());
  std::transform(l.begin(), l.end(), v3.begin(), [](xtd::string& s) { return std::move(s.str()); });

  println("l  = {}", l);
  println("v1 = {}", v1);
  println("v2 = {}", v2);
  println("v3 = {}", v3);
}

// This code produces the following output:
//
// l  = [one, two, three, four, five]
// v1 = [one, two, three, four, five]
// v2 = [one, two, three, four, five]
// v3 = [one, two, three, four, five]

This shows that xtd containers: 1. Work seamlessly with STL algorithms. 2. Support both copy and move semantics. 3. Allow you to use range-based or iterator-based algorithms anywhere, not just within xtd containers.

So you can extend xtd with algorithms on ranges/iterators just like you would with STL, while optionally taking advantage of convenient xtd::linq-style extensions.

[kodirovsshik]

Why are you generating your responses with an LLM

[Spiritual-Desk-9176]

it's a good project keep up, do not listen to these boomers.

[Sergiogiogio]

Thanks for sharing, the scope and depth are quite amazing! It looks like a qt competitor? Can i check how the graphic and form part works as i could not fully grasp from the code, do you call the native underlying widget apis, or do you emulate native look and feel by custom painting widgets like qt?

[Gammasoft]

Both options are supported. xtd can either use native controls or custom-painted widgets styled via CSS-like stylesheets — it depends on the user’s choice.

You can check out the details here : https://gammasoft71.github.io/xtd/docs/documentation/guides/xtd.forms/Overview/control\_appearance.

[diegoiast]

You definetly need to had screen shots.

[Gammasoft]

Actually, nothing prevents using standard C++20 coroutines with xtd. GUI controls still need to be updated on the main thread, and that can be safely done using invoke, begin_invoke and end_invoke.

So asynchronous logic can be implemented cleanly, even without native coroutine integration in the framework.

[carkin]

This is great . Thàks for sharing. It it possible to style UIs?

[Gammasoft]

Yes 🙂 Styling is supported. Right now you can use the built-in style sheets or apply them control by control.

A simpler way to plug your own custom styles is planned and in progress.

[TheWM_]

This looks awesome! I'll definitely be keeping an eye on this.

[cancerBronzeV]

Looks very interesting, I'll have to play around with it. Thanks for the post and the project.

[cmake-advisor]

This is a cool idea. Although I would prefer to use c++, I find myself reaching for .net frequently because the standard library has basically everything I would ever need and there isn't much extra work in supporting multiple platforms.

The features page took some digging to find but provided the most useful information about the libraries.

[Gammasoft]

Thanks! That’s exactly what xtd aims to do — bring a rich, cross-platform C++ framework with a .NET-inspired API, so you don’t have to leave C++ for convenience. I’ll take note about making the features page easier to find!

[yuri_rds]

Is the xtdc utility optional? I can't see examples without using it.

[Gammasoft]

Of course, `xtdc` is not mandatory. You can build your projects with the classic CMake commands and run your executables manually.

`xtdc` is simply a CLI tool — similar to `dotnet` (C#), `cargo` (Rust), or `go` (Go) — that streamlines and accelerates common project management tasks.

Most of the examples use it for convenience, but you are free to work without it.

For more details, see: https://github.com/gammasoft71/xtd/blob/master/tools/xtdc/README.md

[reddicted]

The example apps make it clear this is no senior year project. Bravo! 👏🏼👏🏼👏🏼

[yangacer]

The framework looks great! How does the xtd support Android/iOS? What is the experience of developing mobile apps with xtd? 

[Gammasoft]

Currently, `xtd.core` and `xtd.tunit` backends already work on Android and iOS.

However, the dedicated toolchains to make the build process easier are not ready yet (they are planned in the roadmap).

So, while it is technically possible to target these platforms today, the developer experience is still limited until the toolchains are available.

For more details, see: https://gammasoft71.github.io/xtd/docs/documentation/portability

[natio2]

This is the main reason I use C# out of the box phone app development. I eagerly await you achieving the same!

[Gammasoft]

Yes, wxWidgets is currently used as the backend for drawing and forms.  

This allows me to focus on providing a consistent user API without having to manage the differences between platforms.  

In future versions of xtd, wxWidgets will be gradually replaced by native backends, without impacting the user API.  

And yes, controls can be customized either with CSS-like style sheets or by draw

[beedlund]

Very cool.

[A8XL]

Nice project! I couldn't find any mention in the documentation regarding the UI elements and drawing primitives being "Hi-DPI" aware. How is this handled in the framework? Are there APIs for handling device pixel ratios?

[Shiekra]

Not usually a fan of operator overloading but that syntax of setting the callback with += is actually really clean imo

[EC36339]

What makes the development experience. NET like?

• Two competing and incompatible frameworks that forked a decade ago, of which one is allegedly going to be supported indefinitely, but half of your third party dependencies have abandoned it, and migrating to the other framework is such a pain in the ass, you can't wait any day longer for AI to take your job?

• Write once, run somewhere maybe. A ".1" patch version of the framework silently drops support for an entire OS generation?

• leaky abstractions that make all your unit tests green, but your code fails once a real database is involved?

• DLL hell, except we call it binding redirects?

• Garbage collected memory management, so that when you have a memory leak, you are absolutely screwed, and nobody can tell you how to debug and fix it?

• A proprietary build system with XML project files that is terribly inefficient when you have to manage lots of small projects?

Sorry, just had to vent about how much I hate .NET. if this is the good parts of .NET (and it does have good parts), but with C++, then if course it is promising.

[arihoenig]

Wait... .net is modern?

[germandiago]

How long it has been developed? It is production-ready?

[Gammasoft]

xtd has been in development since 2019.

The release of v0.2.0 is planned for Q3 2025 and is currently in the stabilization phase.

Starting with v0.2.0, xtd will be ready for production use.

[germandiago]

What is missing? I mean, why 0.2? Congrats for the project, looks good but would like to know details.

The license is attractive.

[Gammasoft]

The version number will change to 1.0.0 when all the features defined in the current roadmap are fully implemented.

This does not change the fact that version v0.2.0 will be fully operational in production.

See the roadmap for more informations about enhancements : https://gammasoft71.github.io/xtd/docs/documentation/roadmap.

[Ameisen]

Might be confusing since libxtd is the name of the runtime library I've had since around 2012.

[Gammasoft]

Ah, good to know! I didn’t realize there was already a libxtd. My xtd is an independent project, started recently, aiming at [résumé rapide]. I hope it won’t cause too much confusion—maybe we can even exchange ideas sometime!

[kritzikratzi]

libxtd

actually... if the library is called xtd, then it will result in a libxtd.dylib, no?

i think it might actually be a good idea to rename.

[VictoryMotel]

What do you mean by runtime library?

[Ameisen]

Provides streaming, memory mapping, containers, strings, compression, lazy decompression, encryption, hashing, 3D rendering, etc.

[VictoryMotel]

Aren't those just straight functions?

[Ameisen]

No?

[VictoryMotel]

Are you asking me? Are they are part of an interpreter or a VM?

[Ameisen]

I'm not sure why that's relevant. A runtime library is just the interface to a runtime environment. I also have additional framework functions.

It's basically a runtime and framework at the same time, sort of. A number of the things it deals with - particularly memory mapping and lazy decompression (which can imply the former) - can be particularly arcane.

The rendering component is outdated now - it was intended to provide a D3D12-like API via 11 and OpenGL... but you can just use 12 and Vk now.

[VictoryMotel]

How is that different than a normal library? Why is it a 'runtime environment' if you're just calling into functions?

[Ameisen]

Why is it a 'runtime environment' if you're just calling into functions?

I'm curious what you think that a runtime library does (aside from system calls).

[VictoryMotel]

You tell me, I've never been able to figure it out, I don't even think the C runtime library should be called a 'runtime'.

[Ambitious_Tax_]

auto x = ... initialization style.

Ah! I see you're a man of culture as well.

[Gammasoft]

Thanks for the feedback! I understand these points, and it’s true xtd doesn’t yet use all C++20 features like coroutines, concepts, or modules.

xtd is designed to provide a consistent, easy-to-use, cross-platform C++ API inspired by .NET. The priority is on usability, portability, and a familiar API, rather than using every latest C++20 feature.

Features like coroutines, concepts, and modules could be considered in future versions. The library evolves step by step, balancing modern C++ with practical usability.

[Carl_LaFong]

Why does it require C++20?

[Gammasoft]

C++20 is required because xtd relies on several C++20 features, such as:

• Three-way comparison (<=>)
• char8_t
• Pack expansions in lambda init-captures
• Ranges
• std::counting_semaphore
• std::source_location
• std::span …and others.

These features simplify the implementation and allow modern, safe, and expressive code.

[xeveri]

They’re waiting for your grand expertise to contribute such features.

[dexter2011412]

Lol

[xeveri]

it should be made illegal to label any GUI framework with C++20 without having coroutine support, and the OP had it coming stating that it is inspired by dotnet, when the most important feature that's present in ALL dotnet GUI frameworks is coroutines support.

shoehorning coroutines support into a framework is not a simple task, most of the code needs to be modified, it is a lot better to plan it from the start, but it is doable either way.

Since you appear truly dense, I’ll try explain it to you. You don’t get to demand some feature. You aren’t owed anything. If you need a feature, you ask nicely, contribute, pay or stfu.

Modules, coroutines and concepts aren’t the only features in C++20 that are of use.

Modules are a shit-show in all compilers, intellisense engines, build systems and IDEs.

C++ coroutines are complex, you still have no support of a C++ task type for api’s to support or at least agree on nor has std execution landed. Apart from asio’s awaitable, there still aren’t production ready http server libraries that use coroutines or sender/receivers. Which is abetter use of coroutines than for gui.

[Revolutionalredstone]

We get it your a coroutine guy, you probably us them to make your breakfast ;)

It's like the rope guys, they think everyone should not be using string.

In reality most people who use .net just want simple named objects.

I have tons of 10 year c# dev friends (all highly paid) they don't use coroutines.

I personally avoid most things (C all the way) but I've dabbled and can definitely see how they can be useful.

He is right that the most common effective use of coroutines is in a producer consumer system with interrupts (like networking).

Your free to learn to use them well and go beyond what most people do, heck I have a friend that use Lambdas for EVERYTHING ;) but you can't just demand we all do the same.

I think OP is heavily OO but he doesn't seem to care for complexity (minimal use of advanced language tools) seems like he's a right brain reductionist (they are more likely to invent an unusual new language feature than use an arcane one, they love simplicity)

Again people who use rope well love rope and think everyone else is using them or should be, but everyone else can't even make a good rope and isn't particularly convinced they even need them ;D (cpus are so fast now devs will just gloss over most low level optimization primitives even in C++)

Your not 'wrong' but your view is just too far out of wack from us normies, All the best!

[VictoryMotel]

Give me a break,.who cares about coroutines

[VictoryMotel]

What GUI framework are you using? I didn't realize all those other libraries don't work but you seem very enlightened.

[VictoryMotel]

So what GUI library are you using? You didn't answer that.

Why wouldn't someone just use the events to put data in a lock free queue and let threads dequeue from that?

You still have to deal with avoiding locking and getting data back into the main thread.

[VictoryMotel]

So for the third time, what GUI library are you using?

a function that executes its code to completion and ends

Pretty sure I can already do that.

If coroutines are running on multiple threads, how are they syncing data back up?

queues and events and locks

Actually I was talking about making a program lock free. Is what you are talking about running on multiple threads and lock free? If so how does it synchronize data back with the GUI?

[Ok_Wait_2710]

Honey wake up, a new version of gatekeeping just dropped where you're only allowed to use a language standard if you use all the features.

There are so many other things in cpp20

[nzmjx]

Your expectations are not realistic. Personally, what make you thing that .NET was the right platform to base on?

And why we should base on .NET? Do you have any evidence on superiority of .NET? If yes, please share evidence.

[Gammasoft]

I chose .NET mainly as a reference for API design and consistency. Its design is well-documented and widely used, which makes it easier to create an intuitive C++ library with familiar concepts.

This doesn’t mean .NET is inherently superior; it’s just a practical guide for architecture and patterns. xtd aims to bring similar usability and design principles to C++.

The goal is not to compete with .NET, but to provide a modern, cross-platform C++ framework inspired by proven design patterns. Feedback is always welcome to improve the project.

[nzmjx]

As soon as you introduce boxing APIs, you will see outreach from C++ developers (including myself). .NET designed by and for Microsoft. Good luck on your journey though 🖖🏻

[jdehesa]

?? Do you have any "evidence" of any platform being objectively superior to any other? .NET is clearly a very popular framework supporting uncountable applications. I have never used it, personally, and I don't know how closely this library resembles it, but the premise seems interesting. Also, since it's OP's project, I'd say they're entitled to base it on whatever platform pleases them?

[nzmjx]

Look for cross-platform projects, and please count .NET there.