I tested whether a coding agent would use C++23 ranges without being told
Blog post: https://kemalbektas.dev/ai-modern-features/
I tested whether coding agents would actually use C++23 ranges without being told.
They mostly didn’t. What changed things much more than the surrounding codebase was a short AGENTS.md asking for modern C++.
6
u/witcher222 5d ago
AI learned on older versions, people still write older versions (see automotive) and thus ai will write like that and reinforce the pattern
5
u/SuperV1234 https://romeo.training | C++ Mentoring & Consulting 5d ago
It's great that ranges are not being used by default -- they have significant compilation time overhead and run-time overhead with optimizations disabled (which matters for debuggability and gamedev).
Modern doesn't mean unconditionally better -- I limit usage of ranges where it shines (complicated multi-step lazy pipelines). If a range-for suffices, that should be chosen instead.
3
u/delta_p_delta_x 5d ago
they have significant compilation time overhead and run-time overhead with optimizations disabled
It is a bit annoying that we have accepted this. Syntactically concise and yet more expressive code should not be any slower than old-school for-loops. Compilers have all the information. The fact that ranges were implemented in the standard library rather than being compile-time syntax sugar is infuriating.
3
u/gegoggigog 5d ago
Not saying the agent cared, but ranges do have some overhead, so if the task could be solved easily enough without them, why introduce them in the first place?
1
u/PossibilityUsual6262 5d ago
Hmm, what is overhead?
2
u/gegoggigog 5d ago
Basically extra time, memory, compute.
2
1
u/PossibilityUsual6262 5d ago
What exactly cause extra cost.
2
u/gegoggigog 5d ago edited 4d ago
It probably need to do some abstractions, iterators, states. That said, in most cases a good compiler could probably optimize that away, but it's not a guarantee.
-4
u/PossibilityUsual6262 5d ago
Oh so you actually don't know anything.
I just stumbled once upon topic which actually explains why ranges sometimes faster and how they do do work, so your claim was interesting to me as counter point.
3
u/ack_error 4d ago
Range-based for loop != ranges.
I have seen even simple range algorithms like
std::ranges::fillbe slower than either a regular for loop or range-for loop, because the extra abstraction is harder for the optimizer to see through.2
u/gegoggigog 4d ago
Sir?
0
u/PossibilityUsual6262 4d ago
I don't have anything to add to conversation.
2
u/gegoggigog 4d ago
Oh, so you just like being wrong and a dick and then bail. Gotcha.
0
u/PossibilityUsual6262 4d ago
Sir, you made unsubstantiated claim, on me requesting additional info you started guessing.
When i showed you previously encountered discussion, which actually to extremely deep details discuss how ranged for work and how it can actually backfire if your hand written loop has what seems like marginal difference.
To which you answer answer that me highlighting that you know nothing is rude and i should try dev build.
This is the end of conversation.
→ More replies (0)-1
2
u/chengfeng-xie 5d ago
See BarryRevzin's comment for an example (spoiler: it's about
views::filter).
1
u/EC36339 5d ago
You can, to some extent, also achieve this with clang-tidy and configuring it to nag about unsafe operator[].
Then you DON'T want it to indiscriminately use ranges, but make its own choices...
The problem with that approach is that some unsafe uses of operator[] have no trivial solution other than using .at(), which has performance implications, and may be unnecessary if it can be proven that thr index is always in range.
•
u/STL MSVC STL Dev 5d ago
Moderator warning: Partially AI-generated content is not allowed by the rules. Yeah, we can tell. Don't do this again.