Details
- Reviewers
huixie90 ldionne - Group Reviewers
Restricted Project - Commits
- rGead7302bbb14: [libc++][ranges] Implement `ranges::generate{,_n}`.
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
libcxx/test/std/algorithms/alg.modifying.operations/alg.generate/ranges_generate.pass.cpp | ||
---|---|---|
139 | bit: would it be possible to pass in uninitialized array instead ? |
libcxx/include/__algorithm/ranges_generate.h | ||
---|---|---|
47 | This is a weird constraint, I would have expected _OutIter to be an output_iterator instead. I don't think we are testing for this, and I'm not asking that you add tests for it. However, it looks like the Standard doesn't want implementations to assume that *it++ = expr is valid, and they want us to use *it = expr; ++it instead (which we do). | |
libcxx/include/__algorithm/ranges_generate_n.h | ||
42 | We should technically be using std::invoke here according to the concept requirements specified in the signature (all we have is invocable<_Func&>). However, I don't think there is any way to distinguish __gen() from invoke(gen) given that it's being called with no arguments. I tried finding a case but couldn't. So, nothing to do. |
libcxx/include/__algorithm/ranges_generate.h | ||
---|---|---|
47 | in fact, lots of algorithms are constrained with x_iterator and indirectly_writable. very few of them actually use output_iterator. I wonder what is the reason behind it. | |
libcxx/include/__algorithm/ranges_generate_n.h | ||
42 | I was about to say the same and actually tried very hard. but could not find an example where gen() does not work while invoke(gen) works. Although nothing to do here, I'd like to share how far I went. |
libcxx/include/__algorithm/ranges_generate_n.h | ||
---|---|---|
42 | Thank you! This idea is pretty ingenious, cool that calling it directly still works. |
This is a weird constraint, I would have expected _OutIter to be an output_iterator instead.
I don't think we are testing for this, and I'm not asking that you add tests for it. However, it looks like the Standard doesn't want implementations to assume that *it++ = expr is valid, and they want us to use *it = expr; ++it instead (which we do).