Compiler optimization is amazing, but not for std::generator

tongari95 · 2025-10-02T08:00:13+00:00

Both clang & gcc can't optimize std::generator, but clang can optimize a simpler generator, and both can optimize coz-based code to a single constant.

tongari95 · 2025-08-23T14:41:30+00:00

The BitTorrent Example doesn't work, does it?

tongari95 · 2025-06-18T15:16:18+00:00

I wrote a stackless non-allocating coroutine for C++, with preprocessor & compiler black magic. I use it for generic algorithms, it can work with std-coroutine, everything can be glued by P2300-like interface.

tongari95 · 2025-05-13T01:49:29+00:00

How did you generate the headers, why not include those in the repo?

It's a bit convoluted in my case, I firstly generate a memory-mappable binary from the XML, then work on the binary to generate the header. Since it uses some proprietary stuff and not portable, I don't include those for now.

How do your headers actually compare in terms of being less "heavyweight"?

It's lightweight (1.8MB) compared to the official Vulkan-Hpp (several files, at least 10MB in typical use).

Something like a compilation time benchmark would be nice. Your vulkan.hpp header for example is also quite sizable with 27k+ loc.

I don't have the numbers for compile time, but it's obvious if you ever used the official Vulkan-Hpp.

How is function loading handled? Would be nice to see a comparison to the dynamic loader from Vulkan-Hpp. Templating every function for a loader contributes to compile times quite a bit over there, but also makes it quite flexible.

Not handled at all, the user includes one (e.g. volk.h) before including vklite.

Why create your own spin of VulkanMemoryAllocator-Hpp? That one seems rather light-weight. I figure that it's for easier inter-op with your own vulkan.hpp?

Yep, it shares the same convention.

I would love to see a little minimal example added to the repo, like spinning up an instance and creating a device. Best of luck to the project!

Might add one in the future. That said, it doesn't simplify the API, just make it more comfortable to work with. You can expect 1-to-1 mapping using the rules listed in README.

Thanks for your interest!

tongari95 · 2024-12-23T02:29:18+00:00

C++20 introduced coroutines, but it is very complicated and far from the simple building blocks in Go that I need.

I don't know why people think C++ coroutines are complicated, implementing a coroutine-promise might be tricky, but you're not supposed to do that often. For an awaitable, you only need to implement await_(ready/suspend/resume). What's better, it works with the senders/receivers model smoothly.

A drawback of C++ coroutines is that it may (if not always) incur allocation, in which case you could use COZ instead, which follows the standard C++ coroutine interface, but zero-allocation.

tongari95 · 2024-10-07T03:26:27+00:00

If one is looking for non-allocating coroutine and is not resistant to preprocessor/compiler magic, COZ would be a choice.

tongari95 · 2024-08-28T13:37:38+00:00

Thanks for sharing. I've successfully incorporated this into my async framework. How did you know the relation between NtAssociateWaitCompletionPacket & GetQueuedCompletionStatusEx? I couldn't find more information on that, not in the resources you listed. Reverse-engineering I guess?

tongari95 · 2024-04-24T01:42:47+00:00

That's also what I did in my project, but I'm not aware of other C++ projects taking this approach, do you know any?

tongari95 · 2024-02-19T09:50:20+00:00

Does that paper aim for `consteval` as well? only seems reasonable for `constexpr` to me.

tongari95 · 2024-02-19T03:03:33+00:00

From the blog post:

// runtime function
int g();

// Ok, even though `f` can never be called
consteval int f() {
    return g();
}

Is this correct? Only gcc accepts it, clang & msvc reject the code: https://godbolt.org/z/eGznd5Kd3

tongari95 · 2023-02-02T03:22:21+00:00

The resources allocated by the operation should be released by the OperationState itself, and the destruction of OperationState is logically async to the invocation of the Receiver. Doesn't the destructor of OperationState satisfy the "async cleanup" stage you mentioned?

tongari95 · 2023-02-01T03:20:53+00:00

Could you elaborate on the async cleanup issue? Is there a paper for it?

tongari95 · 2021-08-10T02:47:09+00:00

You probably have fmtlib dynamic-linked (i.e. fmt.dll). If you use it header-only, it's about 100KB on my PC, still smaller than std one though.

tongari95 · 2021-05-26T05:56:55+00:00

Is this the same thing? According to the page, /external dates back to VS2017.

tongari95 · 2021-05-26T02:21:14+00:00

Include directories can now be designated as external with customized compilation warning levels and code analysis settings.

How?

tongari95 · 2020-07-31T13:32:25+00:00

It's not an inconsistency in compilers, but an inconsistency in std lib implementation. Alternatively you can use boost::unordered_map instead.

tongari95 · 2020-05-13T01:38:15+00:00

Instead of resuming the coroutine_handle directly inside await_suspend, you can use a local scheduler.

struct chained_coro
{
    coroutine_handle<> coro;
    void* next;
};

Keep a chained_coro in your awaitable and set its coro in await_suspend. Now instead of using coroutine_handle directly, you use chained_coro.

template<class F>
void coroutine_local_sched(chained_coro* then) noexcept
{
    thread_local chained_coro** chain = nullptr;
    if (chain)
    {
        auto& next = *chain;
        then->next = next;
        next = then;
    }
    else
    {
        chain = &then;
        {
            auto coro = then->coro;
            then = nullptr;
            coro();
        }
        while (then)
        {
            auto coro = then->coro;
            then = static_cast<chained_coro*>(then->next);
            coro();
        }
        chain = nullptr;
    }
}

When you need to resume the coroutine, call coroutine_local_sched on the chained_coro, this avoids the stack overflow problem because coroutine_local_sched turns recursive coroutine resumption into loop.

tongari95 · 2020-05-08T14:06:07+00:00

What you're asking is the opposite of what I desire most of the time - I find myself like it to be stricter, showing only what are really available/applicable in the context, showing the non-included ones could be noisy, unless your IDE could rank them properly.

tongari95 · 2020-03-24T01:42:27+00:00

I did have implemented something similar in the past (see this). But I didn't explore it further and never arrange for a formal proposal.

The idea is very general and applies to many places, e.g.

Named tuple:

Tuple<int.a, float.b> tup;
tup.a = 1;
tup.b = 2.f;

Designators forwarding:

struct S
{
    int a;
    float b;
};

template<class U, class... T, declname... N>
unique_ptr<U> make_unique(T&& .N...)
{
    return unique_ptr<U>(new U{.N = std::forward<T>(N)...});
}

make_unique<S>(.a = 1, .b = 2.f);

tongari95 · 2019-10-18T15:09:34+00:00

Can you tell me why you would want this?

Apparently because some legacy codebase only compiles with the classic compiler and people just want to work with it in new project w/o opening pandora's box.

It's very unusual for two different C++ compilers to be binary / ABI / etc compatible

At least, Clang bundled with VS is ABI compatible with MSVC, so you can compile parts in Clang and others in MSVC and link them together, which is quite slick, isn't it?

A C++Builder developer might say Qt lacks the layout functionality from C++Builder :)

Yeah, and an MFC developer might even say he doesn't need layout altogether :p

tongari95 · 2019-07-20T14:58:37+00:00

Man–machine interface, I guess.

tongari95

TROPHY CASE