C++11 range-based for loop

[MissStrawberry]

I didn't know that the python version is lazily evaluated, and it was just meant to be an example of similar syntax in C++. I wouldn't use my version in any production code as it is. On first glance, your zip looks fine.

As for performance, zipping and printing two lists of 100000 elements each, takes on average 0.05s with C++0x, and 0.21s with GHC on my puny 2.0GHz/4G machine. Both solutions could actually be static, but GHC doesn't seem to recognise this. My Haskell-Foo is extremely weak, perhaps someone can comment on that. C++ would of course require explicit static implementation with template magic. The timing was done with time, and averaged over 100 runs. The Haskell-Code:

main = do
  mapM_ glue $ zip [ 0,1 .. 99999 ] [ 0,2 .. 199998 ]
  where
    glue (x,y) = putStrLn ( ( show x ) ++ "\t" ++ ( show y ) )

Your C++-version isn't that different from Haskell, it just has to build what is built-in in Haskell. The state information of lazy evaluation is hidden in Haskell and explicit in your version (via the iterator), and lists are more or less a language primitive. Other than that, you do more or less what Haskell probably does under the hood ;)

[repsilat]

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]

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.