Live data from Hacker News

Cost of enum-to-string: C++26 reflection vs. the old ways

vittorioromeo.com

171–180 of 189 posts

Re: Cost of enum-to-string: C++26 reflection vs. the old ways

#171
post #159

Earlier quoted context omitted.

That doesn't look any better. Yes, xmacros have the best compile times, but you can't possibly argue that they are elegant to use compared to the alternatives.

It looks better to me than the other macro solution as it is more transparent what is done compared to DEFINE_ENUM. But I agree it is not as succinct as C++'s reflection syntax.

> It looks better to me than the other macro solution as it is more transparent what is done compared to DEFINE_ENUM.

Fair enough.

Re: Cost of enum-to-string: C++26 reflection vs. the old ways

#172
post #165

Earlier quoted context omitted.

So finally, it's NOT built-in, and the parent comment was showing that in other languages - it IS built-in. So your code example is NOT correct and comparison is NOT correct, because you just hid the most important part of it, which is the implementation, that the user has to either: a) write themselves, b) find somewhere on the Internet.

So? The original argument was about the "ugly" syntax that the user didn't want to interact with nor read. I proved that there's no need to do so to consume reflection utils.

XD.

Re: Cost of enum-to-string: C++26 reflection vs. the old ways

#173
post #170
post #168

Earlier quoted context omitted.

Reflection is built in, the support is there, anyone can make a left pad out such simple snippet.

> Reflection is built in Can you quote the C++ standard section that specifically talks about the `to_enum_string` function?

Some people like to really be obtuse on purpose.

It is on the same place as left pad on ECMA 262.

Re: Cost of enum-to-string: C++26 reflection vs. the old ways

#174
post #162

Earlier quoted context omitted.

Well, if you mean "as an official C++ syntax" then I agree, and I suspect Sutter would agree as well. He labeled one talk about it a "Towards a Typescript for C++", after all[0]. But I do think it is different than other "compile to C++" languages, because it seems to be more of a personal case study for Sutter to figure out various reflection and metaprogramming features, and then "backport" those worked out ideas t…

What Herb Stutter misses on his Typescript and Kotlin for C++ metaphor is the actual reality how those languages integrate, unlike cpp2. Typescript is a linter, nothing else, type annotations for JavaScript. The two features that aren't present in JavaScript, enums and namespaces, are considered design mistakes and the team vouched to focus only on being a linter,and polyfill for older runtimes, when possible (some J…

My point was that TypeScript isn't exactly about to replace JavaScript, which was what you were arguing. I'm honestly not sure what you're trying to argue now.

Like, yeah, what you say about TS and Kotlin is true about TS and Kotlin. But since you're not explaining what cpp2 does or plans to do differently, and why it matters, I'm not sure where you're going with that. It's probably obvious but I'm not getting it.

The metaphor Sutter was going for, as I see it, is that TS and Kotlin both added missing features to their host language. Most importantly reflection and decorators in TS, which are now becoming a standard in JS as well[0]. cpp2 mainly focuses on experimenting with reflection and metaprogramming as well, adding features currently missing in C++ by being a compiles-to-C++ language. Sutter has written C++ proposals what would allow give C++ similar reflection and metaprogramming capabilities based on what he discovered by working on cpp2. That's pretty comparable if you ask me.

[0] https://github.com/microsoft/reflect-metadata

Re: Cost of enum-to-string: C++26 reflection vs. the old ways

#175

> The header is the cost. Not the reflection. The reflection algorithm is fast – asymptotically ~0.07 ms per enumerator, essentially the same as the hand-rolled switch in the X-macro version (~0.06 ms). What makes reflection look expensive is : just including it costs ~155 ms per TU over the baseline. So speaking of old ways, I'm not a C++ dev, but a while ago saw someone comment that they still organize their C++ pr…

I've not been diligently keeping up with C++ recently but there's a C++20 feature called modules. Per Wikipedia, they're somewhat like precompiled headers.

https://en.wikipedia.org/wiki/Modules_(C%2B%2B)

Re: Cost of enum-to-string: C++26 reflection vs. the old ways

#176

Earlier quoted context omitted.

Erm... that's not just false. The point of templates is generic programming, reusable components. If you don't put them in a header, you're not reusing them much. And if you have to "selectively pick TUs where they're instantiated", you're basically admitting that you have to invest effort to reduce compile times. You are refuting the very point you're making. C++ templates _are_ slow to compile. They require running…

Alright, I'll bite. This is my `sf::base::Optional ` template class, a lightweight replacement for `std::optional` with same semantics: https://github.com/vittorioromeo/VRSFML/blob/master/include/... This is what ClangBuildAnalyzer reports: **** Template sets that took longest to instantiate: 833 ms: sf::base::Optional (911 times, avg 0 ms) Each individual instantiation of this class is sub 1ms. Including the header…

Not slow to compile? 0,833 seconds extra compile time for a trivial utility class that doesn't do anything interesting other than make something perceived "safer"? Does that mean that each of the 911 instantiations took several million CPU ticks? You could convince me that it's not slow if it was 2-4 orders of magnitude less.

As I wrote elsewhere, 1 second is a timespan where we could aim to compile 1 MLOC of code on a single core.

> A more general use case is just reducing code repetition in a type-safe manner

As I said -- code reuse. And interestingly your Optional.hpp is a header...

Re: Cost of enum-to-string: C++26 reflection vs. the old ways

#177

Earlier quoted context omitted.

Alright, I'll bite. This is my `sf::base::Optional ` template class, a lightweight replacement for `std::optional` with same semantics: https://github.com/vittorioromeo/VRSFML/blob/master/include/... This is what ClangBuildAnalyzer reports: **** Template sets that took longest to instantiate: 833 ms: sf::base::Optional (911 times, avg 0 ms) Each individual instantiation of this class is sub 1ms. Including the header…

Not slow to compile? 0,833 seconds extra compile time for a trivial utility class that doesn't do anything interesting other than make something perceived "safer"? Does that mean that each of the 911 instantiations took several million CPU ticks? You could convince me that it's not slow if it was 2-4 orders of magnitude less. As I wrote elsewhere, 1 second is a timespan where we could aim to compile 1 MLOC of code on…

That's a strange dismissal. `Optional` isn't "perceived" safety -- it eliminates a whole category of bugs (null dereferences, uninitialized reads) at the type-system level, with zero runtime overhead versus a raw pointer or sentinel value.

If you think that's uninteresting, that's an aesthetic preference, not a technical argument.

But let's set that aside, because it's also irrelevant to the compile-time claim.

The point of the example wasn't "look at this fascinating class," it was "here is a real template, used 911 times across the codebase, in a public header -- exactly the scenario you said would be slow -- and it costs under 1ms per instantiation."

You can swap `Optional` for any non-trivial template of similar complexity and the numbers will look similar.

On your 1 MLOC/sec benchmark: that's a fair reference point for C-like code, but it's not the right yardstick for template instantiation, which is doing semantic work (overload resolution, SFINAE, constraint checking) that a C compiler simply isn't.

Comparing them is comparing different jobs.

The honest question is whether template compilation is slow relative to what it's actually doing, and in well-structured code, it isn't.

And yes, `Optional.hpp` is a header -- that's the whole point of the demonstration. I'm not claiming you should hide every template in a .cpp file. I'm claiming that even templates in headers, instantiated hundreds of times, are cheap when written with compile times in mind.

The "put templates in .cpp where it makes sense" advice is for the specific cases, not a blanket rule.

Re: Cost of enum-to-string: C++26 reflection vs. the old ways

#178

Earlier quoted context omitted.

You run your code before running tests? IMO that's bad practice. 1 second, seriously? Even the Linux kernel is based on C, and it doesn't even have compilation times approaching that. I guess I also work on a lot of big data projects, where getting results will take... 48 hours or so, so anything shorter than that is basically some sort of unit test or dry run... so in that context, compilation times do not even regi…

Running the code immediately after making changes is the first line of testing. To run a huge test suite full of tests that are completely unrelated to the current changes would be stupid, it's a huge waste of time and energy. Yes, seriously, have you ever written a project from scratch? A simple .c file with a thousand lines in it should easily build and start within 100ms. A compiler should be able to do basic pars…

Waiting 2 minutes for unit tests of the relevant module is not very long - using bazel helps to only run the relevant unit tests, not the full suite.

Re: Cost of enum-to-string: C++26 reflection vs. the old ways

#179

Earlier quoted context omitted.

Not slow to compile? 0,833 seconds extra compile time for a trivial utility class that doesn't do anything interesting other than make something perceived "safer"? Does that mean that each of the 911 instantiations took several million CPU ticks? You could convince me that it's not slow if it was 2-4 orders of magnitude less. As I wrote elsewhere, 1 second is a timespan where we could aim to compile 1 MLOC of code on…

That's a strange dismissal. `Optional ` isn't "perceived" safety -- it eliminates a whole category of bugs (null dereferences, uninitialized reads) at the type-system level, with zero runtime overhead versus a raw pointer or sentinel value. If you think that's uninteresting, that's an aesthetic preference, not a technical argument. But let's set that aside, because it's also irrelevant to the compile-time claim. The…

[deleted]

Re: Cost of enum-to-string: C++26 reflection vs. the old ways

#180
post #173
post #170

Earlier quoted context omitted.

> Reflection is built in Can you quote the C++ standard section that specifically talks about the `to_enum_string` function?

Some people like to really be obtuse on purpose. It is on the same place as left pad on ECMA 262.

The comparison was about `to_enum_string` example, so I'm asking for exactly that! You can't just make up different rules, that's not how comparisons work!
Post reply on HN