(that is, without the boilerplate .begin and .end).
Even that is enough to make ranges useful in my mind, but in a codebase which has started to integrate some functional programming techniques, there are also applications for things like views and transforms.
This can make it easier to reason about iteration pipelines in ways you might already be familiar with from POSIX.
That all said, it's C++ so sometimes the error messages get a lot more 'interesting' than they would have with STL-style iterators, especially when mixed with constexpr expressions as you might do with std::format or fmt libs.
2) the map part is included in the accumulate lambda, so the map part cannot be parallelized either -> you'd have to split it out into a transform step (iirc)
`std::accumulate` is defined to have sequential semantics, so the analysis required to make it parallel is probably not that different than starting from the loop version. I guess you could have an alternate `accumulate_associative` that uses the same interface but assumes the reduction is associative and has unspecified evaluation order?
I really dislike the complexity of modern C++ language specs, but does it obscure much detail about FP ops?
TL;DR:
A vast majority of the programmers I've worked with don't understand the nuances of FP in general, nor the various extents of IEEE-754 support in different programming languages.
So for important numerical programming, I think clarity regarding the FP operations being performed can be crucial. I'm just unclear if modern C++ is a significant factor for that.
I’ve seen some terrible horrid nonsense from them and even the best compilers don’t use a third of the opcodes our modern CPUs boast of. Nobody understands the big compilers any more either, they’re all too huge. And soon AI will be “improving” hem too.
You want to see a beautiful compiler? Look at Plan 9’s compiler suite. A man could understand and even build on that.
How does the resulting code compared to what a modern compiler gives me. I don't maintain compilers for a living, I maintain other code, which is ultimately longer and more complex than a C++ compiler. And so if my compiler, by becoming a little bit more complex, can make my resulting code a lot simpler because I don't have to do inline optimizations of various sorts, that makes my life much easier and is a good trade-off since there's a lot more programs in the world than there are compilers.
Another name for compilers: invisible backdoor injectors. The more complex is the syntax the more it is likely to happen... I let you guess how the "sane" syntax from c++ and similar (LOL) does fit here...
Quit poking at the openbsd maintainers. Jokes aside (I mean maybe they are one I don't know), it is at least a coherent opinion that inherently complex but critical software infrastructure would ideally be kept as simple and understandable as possible with all the correctness and verification apparatus staying out of the way so you can see what is there to be backdoored. I use rust primarily and like using it, but there are well over a hundred crates just in the front end, and llvm isn't simple. I do miss the days when I could know what each line did.
The actual equivalent might be something closer to:
(that is, without the boilerplate .begin and .end).Even that is enough to make ranges useful in my mind, but in a codebase which has started to integrate some functional programming techniques, there are also applications for things like views and transforms.
This can make it easier to reason about iteration pipelines in ways you might already be familiar with from POSIX.
That all said, it's C++ so sometimes the error messages get a lot more 'interesting' than they would have with STL-style iterators, especially when mixed with constexpr expressions as you might do with std::format or fmt libs.
2) the map part is included in the accumulate lambda, so the map part cannot be parallelized either -> you'd have to split it out into a transform step (iirc)
TL;DR:
A vast majority of the programmers I've worked with don't understand the nuances of FP in general, nor the various extents of IEEE-754 support in different programming languages.
So for important numerical programming, I think clarity regarding the FP operations being performed can be crucial. I'm just unclear if modern C++ is a significant factor for that.
> std::visit over std::variant<A, B, C> is lowered to a switch over the active alternative.
> In this case, layout is probably doing more work than the dispatch mechanism itself.
Very likely because last time I checked visit lowers to a virtual call.
There are proposals to introduce better exceptions into C++. Like this: https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p07....
But until it's not in the standard, people should use std::expceted instead.
You want to see a beautiful compiler? Look at Plan 9’s compiler suite. A man could understand and even build on that.
Another name for compilers: invisible backdoor injectors. The more complex is the syntax the more it is likely to happen... I let you guess how the "sane" syntax from c++ and similar (LOL) does fit here...
You meant it is even worse nowadays with vibe coding! My bad.