HackerTrans
TopNewTrendsCommentsPastAskShowJobs

SuperV1234

302 karmajoined قبل 13 سنة
C++ enthusiast, WG21 member, hobbyist gamedev.

https://vittorioromeo.com/ https://github.com/vittorioromeo

Submissions

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

vittorioromeo.com
3 points·by SuperV1234·قبل شهرين·0 comments

Stackless coroutines for gamedev in ~200 lines of C++

vittorioromeo.com
6 points·by SuperV1234·قبل شهرين·0 comments

The hidden compile-time cost of C++26 reflection

vittorioromeo.com
60 points·by SuperV1234·قبل 4 أشهر·42 comments

Building a lightweight ImGui profiler in ~500 lines of C++

vittorioromeo.com
4 points·by SuperV1234·قبل 9 أشهر·0 comments

More Speed and Simplicity: Practical Data-Oriented Design in C++ – CppCon 2025 [video]

youtube.com
2 points·by SuperV1234·قبل 10 أشهر·0 comments

comments

SuperV1234
·أول أمس·discuss
> The main problem, however, was code quality.

> The sleight of hand misdirects the reader away from the main way bugs are eliminated: by dedicating engineering resources to it.

Perhaps the amount of bugs comes from using a C-like language that requires meticulous manual care to avoid writing runtime bugs.

Even C++ would be a safer choice because of RAII.

When you have to dedicate significant resources to avoid/fix runtime issues that are made impossible at compile time by other languages, the programmer isn't entirely at fault.
SuperV1234
·الشهر الماضي·discuss
Is that all that Mythos did?

Did it find any real potential issue, optimization/simplification opportunities, or sparked any thought-provoking discussion within your organization?

Or was it purely a net negative experience?
SuperV1234
·الشهر الماضي·discuss
How does this compare to frontier models?
SuperV1234
·الشهر الماضي·discuss
Data Oriented Design rocks. It was the subject for my CppCon 2025 keynote: https://youtube.com/watch?v=SzjJfKHygaQ
SuperV1234
·الشهر الماضي·discuss
It's not that simple.

The grandma that would have phoned her nephew to fix the phone will still do the same thing now. She will not have magically switched to querying LLMs after a lifetime of technological illiteracy.

The tech-savvy person that uses AI today would have been more than capable than figuring out how to fix their router by using Google even without prior networking skills/experience 5-10 years ago.

Using AI to solve these problems is a novelty for a specific subset of the population. And the topic does matter.

Even the somewhat tech-illiterate mom would have been able to Google a recipe 10 years ago, or watch an Instagram reel 5 years ago. They were surely not going to call their friends to ask instructions on how to make an apple pie.

Pretending this is an AI novelty is indeed disingeneous.
SuperV1234
·الشهر الماضي·discuss
How'd you infer that I don't find AI useful from my statement? Of course I do. I am merely saying that the argumentation in the "poem" is not specific to AI.
SuperV1234
·الشهر الماضي·discuss
And if my router wasn't working 5 years ago, I would have first used a search engine and tried to figure it out on my own.

Pretending it's an AI novelty is... disingenuous.
SuperV1234
·الشهر الماضي·discuss
I found this quite cringy and an attempt at pulling at one's heartstrings due to the lack of a strong argumentation.

I wouldn't have called a friend for a meal plan or to figure out a hiking path 10 years ago, I would have used a search engine.

If I want to talk to a friend, I don't need an excuse to do so. And I'm not going to waste their time by asking something I can easily figure out on my own, today with AI, years ago with Google, and prior to that with printed material.

The anti-AI craze is just as bad as the "AI will solve everything" crowd.
SuperV1234
·الشهر الماضي·discuss
Finally, a sane policy.
SuperV1234
·قبل شهرين·discuss
Very interesting, this is the first time I hear about segmented iterators and hierarchical algorithms.

I faced a similar issue myself when implementing a chunked vector a la `std::deque`, but opted for callback-based internal iteration, i.e.

    void ChunkedVector::forEach(auto&& f)
    {
        for (auto& chunk : chunks)
            for (auto& item : chunk) 
                if (f(item) == ControlFlow::Break)
                    return;
    }
Where `ControlFlow` is just:

    enum class [[nodiscard]] ControlFlow : bool
    {
        Continue,
        Break
    };
This is massively simpler to implement, and can model simpler algorithms such as `for_each`, `fill`, `transform`, `count`, `accumulate`.

It's sometimes inferior in terms of ergonomics, and cannot express more complicated algorithms or iteration patterns (e.g. partial range, going backwards), but so far it has served me well.

Just something to consider if implementation simplicity is the priority and there's no need for a very generic suite of algorithms.
SuperV1234
·قبل شهرين·discuss
Boxed, and needs complex incantations to avoid the boxing. Meh.
SuperV1234
·قبل شهرين·discuss
That's a strange dismissal. `Optional<T>` 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.
SuperV1234
·قبل شهرين·discuss
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.
SuperV1234
·قبل شهرين·discuss
Alright, I'll bite.

This is my `sf::base::Optional<T>` 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 itself takes 3ms.

I'm sure I can optimize it even further if I wanted to.

---

Now to refute your other incorrect claims:

> The point of templates is generic programming, reusable components.

That's ONE use case. A more general use case is just reducing code repetition in a type-safe manner, which is extremely useful even within the same translation unit. Another use case is metaprogramming. And I'm sure I can come up with more. Templates are a versatile tool.

> 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.

...well, yeah? Of course you have to put in effort to reduce compile times. That doesn't undermine my point at all.

C++ templates are not slow to compile.
SuperV1234
·قبل شهرين·discuss
I'm bullish on LLM-assisted development but this is just a very stupid way of performing such a critical migration.
SuperV1234
·قبل شهرين·discuss
That's just false. Templates are not slow to compile at all, and you can selectively pick TUs where they're instantiated.

My entire VRSFML codebase compiles from scratch in ~4s and I liberally use C++ features, I just avoid the Standard Library most of the time.

Templates are not inherently slow, people just don't know how to use them and don't know how to control instantiation.

Most people still think that templates have to go in header files, which is also just plainly false.
SuperV1234
·قبل شهرين·discuss
This is a myth, C++ is not inherently slow to compile. It's the standard library that is very bloated and the main culprit for slow compilation.
SuperV1234
·قبل شهرين·discuss
Utter BS. Compilation times matter for productivity, developer motivation, iteration speed, CI turnaround time, and so on.

I'm sure you wouldn't say "it doesn't matter how long it takes to compile" it if took days. So where do you draw the line? Regardless, it matters.
SuperV1234
·قبل شهرين·discuss
No, it objectively isn't objective.
SuperV1234
·قبل شهرين·discuss
Package? We're suggesting to copy paste 5 lines and stick them into a header.