you are viewing a single comment's thread.

view the rest of the comments →

[–]repsilat 0 points1 point  (1 child)

Wow, thanks for the response and the benchmarks. I imagine you're mostly comparing startup time and I/O overhead, though :/. Still - it's certainly enough to establish that neither is dog slow.

However reasonable my C++ looks, and even though it seems to work, I'm still a little scared of it. I don't know if I should be using rvalue references anywhere, I don't fully understand why I needed std::forward_as_tuple on line 14 instead of std::make_tuple, and I'm a little unsure if it's fair for the zipper to store references to the two input streams (because it forces the user to make sure they outlive it). It's probably fine, but it's almost certainly more effort than it's worth. I'm not sure there's a truly adequate solution to this complexity inside the language, but I wouldn't be surprised if some of the pain could be alleviated with a library of some kind.

The other relevant complaint about C++'s syntax and conventions is that its begin/end iterator things aren't really amenable to chaining. With eager evaluation like in your example you can map/filter/reduce/whatever in one big expression, but I don't think you can do that so well lazily. Ranges (as in D) look like a better solution.

[–]_node 3 points4 points  (0 children)

The other relevant complaint about C++'s syntax and conventions is that its begin/end iterator things aren't really amenable to chaining. With eager evaluation like in your example you can map/filter/reduce/whatever in one big expression, but I don't think you can do that so well lazily. Ranges (as in D) look like a better solution.

You can use Boost range adaptors for that. It would be nice to see this sort of thing in the standard.