Show HN: Beautiful Type Erasure with C++26 Reflection
ryanjk5.github.io
Try it on Compiler Explorer: https://godbolt.org/z/91dj5jeGW
Check out the source code: https://github.com/RyanJK5/rjk-duck
ryanjk5.github.io
Check out the source code: https://github.com/RyanJK5/rjk-duck
I see there's an issue in the tracker to get more accurate data, and since it's using an under dev feature in compilers, it's not going to be definitive, but any rough numbers?
One reason is that, like you said, the feature is still new. Additionally I made pretty liberal use of the std::ranges library in my implementation which has notoriously bad compile times. That could be an area to improve upon.
Another may be a bit more structural. If you want to call myObj.foo() via reflection, you have to linearly search members_of(myObj) for the one named "foo", and then call that. Actual compilers I assume use some kind of hash table.
The hand-waving solution is "put it in a PCH", but I am hoping to put some more effort into optimizing build time here in the future.
Compiler Explorer is not good for measuring anything in general, because there is also the issue of containers being allocated for specific languages, and compiler toolchains, and how many people are using it on a given moment.
As an aside, you may want to check out Jai's approach. I believe everything you generate statically gets turned into a file by the compiler for debugging purposes, which it provides references to in the output.
Those against IDEs, well they already voted against good tooling in first place.
...but, as they say, beauty is in the eye of the beholder!
I'm also glad I do not write C++ on the daily anymore: luckily my software does not need that kind of performance characteristics.
You can write pretty fast and reasonable code nowadays.
Either directly on top of a runtime/compiler written in C++, or as indirect dependency on a C++ compiler toolchain.
It’s a bit like a well-kept Victorian home. The amount of work, money, and dealing with discomfort that goes into maintaining one isn’t something I really want to experience for myself. But the amount of skill and craftsmanship that it takes to preserve one is still impressive, and I have to appreciate the respect for history and the care that goes into balancing it with modern concerns.
And talking to people who do live the life is always a great learning experience.
I had the same misunderstanding before I get to know CS. that was 30 years ago.
If there's something that C++ actually lacks, that's the elegance, grace and beauty. The rest, it's all already there or will be there shortly :)
Exception specifications, auto_ptr, C++11 GC, the way volatile works, uninitialised variables,...
I used to think that was a personal limitation, until I saw an interview with Bjarne explaining that he used to understand all of it but at this point it’s too big, no one can anymore.
People ended up getting celebrated for their cleverness and not horrified by the abuse of good taste, and many of these tricks appeared in core C++ libraries like Boost.
So doing stuff like this is unfortunately just part of C++ culture, and allows you to emulate proper features that using a C++ standard that's at least a decade older.
```
10: rjk::duck<Container> c{std::vector<int>{1, 2, 3}};
11: c.size(); // 3
12:
13: c = std::string{"hello"};
```
Does the assignment on line 13 call the destrucor for the vector of ints created on line 10?
As a bonus, if you tried passing in an lvalue, it will reject the input unless you add the "copyable" trait, so it ends up mitigating some hidden copies.
Thanks for the blog post.
Maybe you were asking if it implements custom destructors? GC?
yeah,
If variable c where of type void* instead of duck<Container>, the assignment on line 13 would leak the memory used by the vector<int>.
[0]: https://github.com/compiler-explorer/compiler-explorer/pull/...
[1]: https://github.com/compiler-explorer/compiler-explorer/blob/...
Or you just used void* and went on with your life
Some of us are professionals and like to understand our systems and how they work. I don't write assembly instructions by hand either, nor do I design CPUs much, but I want to - and likely need to - know how they work to make the best judgements.