I have limited experience with ranges, but I think I agree that views would be better off without caching. As a counter-argument to the committee for the case where a view is used twice, could we use the same subrange trick to eagerly compute begin instead of caching? I.e. in the rare case you want to re-use a view twice and want to cache begin, do it manually by wrapping your view in a subrange? I think it would be easier to teach too.

@Roibarkan

2 ай бұрын

I think the committee is concerned about “how should people write generic code” - if someone writes a template function that receives some range, and doesn’t know if it’s a filter_view (won’t know if begin() is cheap), they won’t know whether to wrap it win a subrange (and always wrapping in a subrange seems expensive). I believe there are/were suggestions to add something like “cache1” which acts like a subrange-wrapper if needed, and does nothing otherwise. I personally like the alternative Nico describes in slide 35 (use view by value and the all_view for containers- but it still might hit the jthread race condition if a reference is passed to the jthread)

@sddndsiduae4b-688

2 ай бұрын

i think correct behavior is always calculate begin, i.e. subrange build in into operation, otherwise there is no point to actually create view, in very rare cases when view is created but not used(no element used) dead code elimination in compiler would do the job, anyway i better learn Rust.

With all due respect , following-up the other comments, it might look like there are some old-school developers a bit grumpy to have to learn stuff. Regarding the logic of the talk, I can’t follow along why (1) begin MUST be O(1) generally, even more when taking into that there was something special with fwdlist before ranges already, (2) why begin in a view must have the same semantics than in a container. In other words, if one is applying a filter to a collection and then surprised that it needs to iterate through it… 🤷🏻‍♂️ In any case, excellent talk from Nico as usual, top learning material. It is essential to make these parts also visible and talk about them.

I would agree with the "prefer std::ranges over std::", however, there is std::ranges::less (and the other suite of comparators), which you definitely shouldn't use, and you should use C++14 deducing versions of std::less (and the rest of the comparators).

ok, after the joy of minute 58, i'll stay on std::partition to prefilter.

Yes.

Depressing is the only way to describe this. We've waited so long for ranges because they would make it so much harder to make programming errors, and instead they've gone and made it more likely to make errors. It's a shame they didn't make the easy case easy and the complex case possible and instead made the easy (common) case hard and the complex (rare) case easy. The only safe way to teach this is the simple "don't use ranges", which sucks.

That was depressing. Today I learned that ranges are a completely broken feature. It's so frustrating listening to others justify all the undefined behavior in the standard. They make it sound like it's necessary to not suffer undue performance loss on various platforms, but clauses like the one shown at 46:55 show how ridiculous that excuse is. We have to stop adding broken features into c++. And then we turn around and wonder why rust is gaining traction...

@paulmccartney2327

2 ай бұрын

Who is "we" lmao