template<class BidirIt>
void shift_right(BidirIt first, BidirIt last, unsigned int n = 1)
{
std::move_backward(first, last - n, last);
}
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-pr...@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/55df161b-f0c5-4d81-ad1d-882425e7bf8a%40isocpp.org.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposal...@isocpp.org.
To post to this group, send email to std-pr...@isocpp.org.
Yeah, you are right :)We should create the most general implementation and efficient implementation for any iterator type.
Also we should decide about type of shifting: circular and/or logical shifting ( https://en.wikipedia.org/wiki/Circular_shift ).
Indeed, circular shift is just std::rotate.For the 'logical' shift, I was thinking leaving them in the moved-from state. Filling them with some value would both 1) have a cost 2) not necessarily be desired.
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-pr...@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/df32b9a3-9215-4517-9bba-ba42654c55ee%40isocpp.org.
Hi,Would anyone be interested in adding std::shift to <algorithm>?It would be similar to both:- std::rotate, but without moving the head elements back to the tail. This would allow a more efficient implementation and clearer semantics in case rotation is not needed as well as correctness in case rotation is undesired.- <algorithm>'s std::move/std::move_backward (depending on the shift direction).std::shift should probably accommodate both left and right shifts by one of:- giving it either begin() and end(), or rbegin() and rend(), similar to how std::rotate works for both left and right rotations. The advantage is compactness of the implementation.- allowing the shift count parameter to be either positive or negative. The advantage is compactness, though it might not be clear which direction is which - to be consistent with rotate, positive integers should shift to the left.- having std::shift_right and std::shift_left functions. The advantage is clarity when calling the methods, although the same argument could be made for having separate std::rotate_left and std::rotate_right instead of std::rotate, which we don't have.
Here's a sample implementation of a shift to the right direction:
template<class BidirIt>
void shift_right(BidirIt first, BidirIt last, unsigned int n = 1)
{
std::move_backward(first, last - n, last);
}This demonstrates that while std::shift is implementable with std::move/std::move_backward,1) It isn't immediately clear from the code (at least to my eyes) that this is a shift right, unless you are intimately familiar with std::move_backward.2) Different calls, either to std::move or to std::move_backward, are required, depending on the shift direction.
//A
std::shift(rng.begin(), rng.end(), N);
//B
auto rrng = std::make_reverse_range(rng);
std::move(rrng.begin() + N, rrng.end(), rrng.begin());
//A
std::shift(rng, N);
//B
auto rrng = std::make_reverse_range(rng);
std::move(std::make_range(rrng.begin + N, rrng.end()), rrng.begin());
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposal...@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/c722a201-5c9c-4ac5-a1bd-e50beb6d7860%40isocpp.org.
B gets even more obtuse confusing in a range-based world:
//A
std::shift(rng, N);
//B
auto rrng = std::make_reverse_range(rng);
std::move(std::make_range(rrng.begin + N, rrng.end()), rrng.begin());
B gets even more obtuse confusing in a range-based world:
//A
std::shift(rng, N);
//B
auto rrng = std::make_reverse_range(rng);
std::move(std::make_range(rrng.begin + N, rrng.end()), rrng.begin());In a range-based world, I would write this asauto output = input | rng::drop(n);for a "left-shift", or... okay, the "right-shift" version is messy, at least in my version, because it involves concatenating ranges one of which needs to be created out of whole cloth, with n objects, each of which is in a "valid but unspecified" state. (I'd bet money you can't give me a use-case for that one.)I'd still like to see a use-case for O(n) "shifting" a sequence of elements in-place (as opposed to using one of these range-based approaches, or using a circular buffer, or "shifting the endpoints"). I agree that sometimes you do want to copy/move the second part of a sequence over the first part, but I would always express that in terms of "I'm std::copy'ing / std::move'ing data." Expressing it as a "shift" doesn't feel natural to me in any of the (extremely rare) use-cases I've thought of. Do you have a use-case?
–Arthur
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-pr...@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/99d55051-ad56-4386-8a0f-9d7627b63106%40isocpp.org.
Does anyone know if there was a specific motivation for adding std::move_backward() to <algorithm>? It seems that using std::move() with rbegin(),rend() iterators (for the basic use case) would have the same effect.
¹ Technically, in some cases std::move can be used with reverse iterators to implement a shift of elements forward, but not in all cases and it is also less efficient, see https://groups.google.com/a/isocpp.org/d/msg/std-proposals/I76om68B3t0/25bGu7O6AwAj and https://groups.google.com/a/isocpp.org/d/msg/std-proposals/I76om68B3t0/SPTeZdofAQAJ.
On Aug 10, 2017, at 4:04 AM, Dan Raviv <d...@soundradix.com> wrote:Hi Bryce,Thanks for the feedback! …
…Comments inline.
⋮
⋮
On Sun, Jul 30, 2017 at 5:56 AM, Bryce Glover <random...@gmail.com> wrote:Dear Mr. Raviv,Here are a thread lurker’s comments on your proposal. First, your first footnote reads:¹ Technically, in some cases std::move can be used with reverse iterators to implement a shift of elements forward, but not in all cases and it is also less efficient, see https://groups.google.com/a/isocpp.org/d/msg/std-proposals/I76om68B3t0/25bGu7O6AwAj and https://groups.google.com/a/isocpp.org/d/msg/std-proposals/I76om68B3t0/SPTeZdofAQAJ.Within this statement, the part saying, “std::move can be used with reverse iterators to implement a shift of elements forward,” should either read, “std::move can be used with reverse iterators to implement a shift of elements backward,” (emphasis added by me) or, “std::move_backwards can be used with reverse iterators to implement a shift of elements forward,” (emphasis here also added by me,) as only one of these alternatives could render the sentence self-consistent with both itself and the rest of your document.
Either you got it backwards (no pun intended), …
…or I did - in any case, this proves the proposal point of std::move[_backwards] being too confusing for implementing shift, which is great :)
…
…
Take a look at my sample implementation - you'll see that, assuming non-reverse iterators are passed to shift(), std::move_backward is used for implementing a right (forward) shift of elements, and std::move is used for implementing a left (backward) shift of elements.It can’t work correctly the other way around - if you try using std::move for implementing a right (forward) shift (with regular iterators) then the first moved element is going to overwrite an element which still hasn't been shifted.
⋮
⋮
Also, your use of ‘in some cases’ should be followed by a comma, though I acknowledge that two comma-suffixed dependent relative clauses (at least, I think that’s what they’re called; you can correct me if my grammar’s off) coming one after another at the beginning of a sentence can read somewhat awkwardly. A reasonable way around that stylistic issue would be to keep ’Technically, …’ at the beginning of the sentence, but move ‘in some cases’ later on within it — specifically, between ‘can’ and ‘be’ such that the resulting sentence fragment would, properly using commas as delimiters, read as, “…, std::move can, in some cases, be used….” (If the thought of splitting infinitives brings you distaste, I can explain myself: it turns out that the validity of the rule against doing so is actually a matter of dispute.)
How about this instead?Technically, std::move can, in some cases, be used with reverse iterators to implement a shift of elements forward, but not in all cases. It is also less efficient; see https://groups.google.com/a/isocpp.org/d/msg/std-proposals/I76om68B3t0/25bGu7O6AwAJ and https://groups.google.com/a/isocpp.org/d/msg/std-proposals/I76om68B3t0/SPTeZdofAQAJ.
⋮
⋮
Second, you might wish to reevaluate your use of fonts: some function names referenced within particular sentences are not in code font when they should be.
Done.
⋮
⋮
Other than these concerns and those parts of your proposal which you have yet to fill in, the document hosting it looks good so far.
Thanks!Dan--
You received this message because you are subscribed to a topic in the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this topic, visit https://groups.google.com/a/isocpp.org/d/topic/std-proposals/I76om68B3t0/unsubscribe.
To unsubscribe from this group and all its topics, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-pr...@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/344B1400-86F7-4D11-A7B0-ABB44D5AF397%40gmail.com.
Hi,
Attached an updated proposal draft.Would appreciate any comments, as well as opinions on any of the listed open issues.Thanks!Dan
On Aug 20, 2017, at 6:18 PM, std-pr...@isocpp.org wrote:On Saturday, 19 August 2017 14:48:26 PDT Bryce Glover wrote:
> Whoops, forgot to change the subject after copying the part I quoted from
> the digest…:
That is not enough. You have to copy the message's Message-Id to your email's
In-Reply-To header.