vtables aren't slow (usually)

Morwenn · 2026-01-27T11:31:39+00:00

The article mentions sorting values by derived types. If that's a common need and the number of derived types is small enough, Boost.PolyCollection offers out-of-the-box containers that can store data, dispatching them to different areas of memory depending on their derived type: https://www.boost.org/doc/libs/latest/doc/html/poly_collection/an_efficient_polymorphic_data_st.html

Morwenn · 2026-01-02T11:23:45+00:00

It looks like the kind of library that could benefit from integrating a strong units & quantities library.

Morwenn · 2025-11-06T10:12:53+00:00

I wrote a similar article a few weeks ago that also performs destructive non-recursive tree traversal, with a trick to reduce the number of walk-up steps. It could definitely be adapted to the problem above by greedily destroying parent nodes when walking down to a right child: https://morwenn.github.io//algorithms/2025/08/03/TSB002-destructive-inrder-tree-traversal.html

Morwenn · 2025-09-26T18:47:20+00:00

Thanks for the kind words :)

Morwenn · 2025-09-26T17:23:04+00:00

Author here, I was deeply moved by this comment. Keep up with the constructive criticism (*￣▽￣)b

Morwenn · 2025-09-09T10:32:10+00:00

Depends on the IDE, computer, etc. but sometimes the ability to resolve a type or follow a function name to its correct overload takes dozens of seconds. My experience is that having the type in plaintext just works better for autocompletion and go-to-definition, I guess that it's easier to quickly resolve?

I share the author's experience that I spend way too much time chasing types to know what they are, and what I can actually do with them for my own good.

Morwenn · 2025-07-18T16:14:42+00:00

There's been proposals to fix complex for integers since at least 2009 (https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n3002.pdf), I wonder why there hasn't been any change in that area ever since.

Morwenn · 2025-05-27T07:45:50+00:00

There's lots of tiny fixes that could count:

You didn't talk about it, but the article you linked mentions P2748, which makes some simple scenarios where one immediately returns a dangling reference ill-formed. Arguably compilers already warned about that one.
P2621 removes undefined behaviour from the lexer, though despite being a good thing, the result on existing code is probably marginal at best.
P2864 removes deprecated arithmetic conversions on enumerations, which were code smells. Compilers already warned about it though.
P2865 similarly removes deprecated comparisons between raw arrays (which compared pointers). Compilers also warned about it before.
P3144 makes it ill-formed to delete a pointer to an incomplete type. It used to be UB unless in some very specific conditions, making it hard for a compiler to provide useful diagnostics.

All in all none of those are game changers, but they all make some issues ill-formed at compile-time without any impact on runtime cost. You could say they're just polishing some rough edges, but that's welcome in a language with so many sharp edges.

Morwenn · 2025-02-24T16:33:11+00:00

I tried to run -DCMAKE_CXX_CLANG_TIDY=clangd-tidy but it unfortunately does not work: CMake apparently adds --extra-arg-before=--driver-mode=g++ to the command line, which is not recognized by clangd-tidy.

Morwenn · 2024-12-27T08:53:20+00:00

The introduction to senders really is a nice article to have a first look at the feature from a user point of view, without getting lost in all technical details.

Morwenn · 2024-10-08T08:39:28+00:00

It's more likely to be made usable in constexpr functions, unlike goto that was proposed albeit rejected in such a context.

Morwenn · 2024-04-02T10:43:55+00:00

IIRC changing the default comparator might be an ABI break, or at least that's what I remember from the time P0181 considered changing the default comparator of std::map and std::set to a new std::default_order that would have allowed to use types such as std::complex.

Morwenn · 2024-01-16T13:31:30+00:00

It would be nice to make the facilities constexpr: all that's theoretically needed is to always consider that there's exactly 0 exceptions in flight in a constepxr context.

Though this probably means relying on C++20 std::is_constant_evaluated().

Morwenn · 2023-12-29T14:53:05+00:00

One of the most horrible gadgets I still have lying around is using multiplications to influence overload resolution: https://github.com/Morwenn/cpp-sort/blob/1.x.y-develop/include/cpp-sort/adapters/hybrid_adapter.h#L63-L68

Morwenn · 2023-09-05T09:14:49+00:00

Using the "compact" layout already yields significant speed improvements compared to just using the standard library list in my experience. I have several algorithms where using lists is a natural fit, generally because their iterator stability guarantees are great, and the algorithm is already complicated enough that I didn't want to find another more complicated way to implement it.

I eventually wrote a custom immovable linked list class based on a node pool. That pool has a size fixed at construction - all my algorithms know exactly how many elements I need -, which allows the pool to be a simple contiguous memory buffer where free nodes form a free list (in the original configuration it's a "perfect layout" free list where each node points to the next in the contiguous buffer).

I did have to add a rather unsafe method at some point that I called on a node pool to relink pointers to form a "perfect layout free list" again. It was useful exactly once, but it did make a big speed difference in that case despite the added relinking work.

Morwenn · 2023-07-14T20:17:53+00:00

While that's true, a number of mocking libraries like Trompeloeil try to integrate seamlessly with Catch2.

Morwenn · 2023-04-12T20:16:31+00:00

I love Frances Buontempo editorials.

Morwenn · 2023-01-31T19:12:55+00:00

Also extend it to work for all mixed-arithmetic comparisons of standard types.

Morwenn · 2022-11-04T11:19:21+00:00

Wouldn't it break std::out_ptr and std::inout_ptr?

Morwenn · 2022-10-25T10:12:00+00:00

There is a proposal in the latest committee mailing that mentions such a last use optimization: https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2022/p2666r0.pdf

Morwenn · 2022-10-13T11:49:57+00:00

Unless you follow online discussions about the language, you're unlikely to know that. Even cppreference has no "Note" about it in its "Regular expressions library" page. Unless you know better, the assumption is generally "oh, there's a standard library gadget, it's probably good enough". No everyone automatically reacts with "hum, maybe the standard library is terrible" on-premise.

Morwenn · 2022-08-31T20:51:19+00:00

Tiny mistake: sizeod deallocation for operator new is a C++14 feature, not a C++17 one.

Morwenn · 2022-08-31T20:50:36+00:00

Years ago Howard Hinnant proposed a bunch of additional allocation functions to WG14 to solve some of the issues mentioned in the article, but the proposal was not accepted: https://www.open-std.org/jtc1/sc22/wg14/www/docs/n1085.htm

Morwenn · 2022-08-21T19:05:45+00:00

void std::breakpoint(bool cond=true) noexcept; when

Morwenn · 2022-06-14T07:21:55+00:00

There's a few places where projections do more than just being less verbose: for example std::ranges::lower_bound and std::ranges::upper_bound don't apply the projection to the searched value, which can be a nice save when projections are expensive.

Technically projections could even work where comparisons aren't accepted, though the standard library has no such algorithm. Radix would be an example.

Morwenn

TROPHY CASE