Joaquin M López Muñoz wrote:

El 01/08/2025 a las 19:21, Vinnie Falco via Boost escribió:

...

Which Boost libraries would benefit from implementing C++26 reflection? For my libraries that includes:

Boost.JSON

what other libraries?

Boost.Describe. In fact I understand smooth transition to automatic reflection is part of the library's original vision.

Correct, and once Describe starts taking advantage of reflection when available, all libraries relying on it automatically will, too.

The repository https://github.com/bloomberg/clang-p2996 implements experimental support for P2996 reflection. To facilitate testing, this container "cppalliance/2404-p2996:1" includes a pre-built compiler, in the PATH. "clang" and "clang++" More info about CI with P2996: https://github.com/cppalliance/drone-ci/blob/master/docs/reflection.md On Wed, Aug 6, 2025 at 8:38 AM Ivan Matek via Boost <boost@lists.boost.org> wrote:

Hi all, Few things I wonder:

1. does anyone know if type_traits like logic using reflection will be much faster than before? 2. Is it legal for optional to detect the padding in structs that have it now and use that to save space? In Rust it seems they have explicitly decided to not do so <https://internals.rust-lang.org/t/missed-layout-optimization/20045> because they want to enable people to memcpy. On one hand I think it would be nice if boost::optional did this, but on the other hand it will certainly break people who memcpy if it is just introduced as default.

Regarding 1. : I have downloaded the clang fork, using godbolt infra repo <https://github.com/compiler-explorer/infra/tree/main>, and results seem promising. For 1000 different structs (so 1M is_same_v calls): *compile time * ~*4x* *faster* *memory usage *~*3x lower* Num structs 1000 compile tmp Time: 14.02 RSS: 1415864 kb compile refl Time: 3.49 RSS: 503808 kb

Now I do understand it is a bit silly to have 1M calls to is_same_v, although in some cases it is relatively easy to get into the situation where ton of calls are made, but that is the simplest quick test I could come up with. Even for smaller test case, 200 structs, 40k calls speedup is noticeable, although reduction in compile time is tiny in terms of seconds(~0.4). Num structs 200 compile tmp Time: 0.60 RSS: 137408 kb compile refl Time: 0.20 RSS: 94476 kb

So it certainly looks great, but hard to know what the performance of production clang will be. I choose to be an optimist and think speedup will be even greater. :)

There is also question of memoization, afaik compilers remember instantiations so subsequent calls are much cheaper, here we intentionally never call same template variable again but again this was just quick test.

Here is example how generated code looks for N==2 structs, py script attached ❯ ./gen_is_same.py 2 --tmp // num structs 2

#include <type_traits>

using namespace std;

struct S0000 { int a_; };

struct S0001 { int a_; };

void check() { static_assert( is_same_v<S0000, S0000>); static_assert(!is_same_v<S0000, S0001>); static_assert(!is_same_v<S0001, S0000>); static_assert( is_same_v<S0001, S0001>); };

int main() { } ❯ ./gen_is_same.py 2 --refl // num structs 2

#include <type_traits>

using namespace std;

struct S0000 { int a_; };

struct S0001 { int a_; };

void check_refl() { static_assert(^^S0000 == ^^S0000); static_assert(^^S0000 != ^^S0001); static_assert(^^S0001 != ^^S0000); static_assert(^^S0001 == ^^S0001); };

int main() { } _______________________________________________ Boost mailing list -- boost@lists.boost.org To unsubscribe send an email to boost-leave@lists.boost.org https://lists.boost.org/mailman3/lists/boost.lists.boost.org/ Archived at: https://lists.boost.org/archives/list/boost@lists.boost.org/message/Z5ZULHHJ...