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.
CPP has become infinitely easier to write for me. That’s an exact figure, my total output of usable CPP lines was zero prior to LLMs.
I do however need to at least be able to write basic CPP to evaluate the code I’m generating. It’s just so hard to comb through all the bad and over complicated code out there, bad advice and outdated opinions.
find more books from additional readings sections of books you end up liking.
Don’t use LLM for learning as it is useless compared to searching amazon or doing general web search to find books.
You can recursively learn anything you need by finding books about needed subjects.
to some degree it is already being replaced:
https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEj...
source: https://blog.google/security/rust-in-android-move-fast-fix-t...
This is a pretty poor post. It’s impossible to see what exactly they’re comparing but they seem to be comparing post LLM code to pre LLM code.
Just to add to the bait, I find CPP libraries much more terse and functional, Rust libs tend towards over complexity and feature flexing.
Because for most developers language is a religion rather than just a tool.
ain't nothing better than books and doing some real project