SuperV1234

303 カルマ登録 13 年前

C++ enthusiast, WG21 member, hobbyist gamedev.

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

コメント

3 日前議論

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

先月議論

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?

先月議論

How does this compare to frontier models?

先月議論

Data Oriented Design rocks. It was the subject for my CppCon 2025 keynote: https://youtube.com/watch?v=SzjJfKHygaQ

先月議論

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.

先月議論

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.

先月議論

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.

先月議論

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.

先月議論

Finally, a sane policy.

2 か月前議論

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.

2 か月前議論

Boxed, and needs complex incantations to avoid the boxing. Meh.

2 か月前議論

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.

2 か月前議論

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.

2 か月前議論

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.

2 か月前議論

I'm bullish on LLM-assisted development but this is just a very stupid way of performing such a critical migration.

2 か月前議論

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.

2 か月前議論

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.

2 か月前議論

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.

2 か月前議論

No, it objectively isn't objective.

2 か月前議論

Package? We're suggesting to copy paste 5 lines and stick them into a header.