Recommendation for moving / shifting vector members?

[Linda A. Walsh]

Oleg Endo wrote:.
>>   It's not real clear why rotate is provided but not shift,
>>
>> Isn't it just a matter of moving something off one end vs.
>> to the other end of the list?
> 
> Yes... for lists that's the case.  It can be done with
> http://en.cppreference.com/w/cpp/container/list/splice
----
	Any idea why 'shift' wasn't provided any
place 'rotate' is (i.e. w/vector), since the same considerations
about simple or not, and such apply.

> Before doing that, I'd recommend measuring the performance of
> std::rotate first.  If you have lots of elements that need to be rotated
> std::list and splicing might be the better alternative.  If you don't
> like the free store allocations of std::list you can use a custom block
> allocator for the list, e.g. http://warp.povusers.org/FSBAllocator/
----
	Ah yes, the linked list -- that was one of the other
datatypes I thought of doing it in besides valarray: I'm almost
certain it will be faster when/if I get to that.

However, for now, I'm moving from 'shift' of a valarray
(the performance of which was fine, but I needed the capacity aspect).

On the offchance that memmove was causing problems, I put the
move of the samples in it's own routin and implemented a
lowest-common-denominator for-loop-move.  Oddly, it dies in it now,

I'm changing/hoping to change various things about an
inherited X-app, and trying to change things a bit at a time, as
some of the changes are rather convoluting to the original program
flow (i.e. going frompolled operation to event-(timer)-driven
operation) and  I'm already stuck in some seg-violations
due to my last change.

Moving to a linked-list implementation of the common-to-all-segments
is not something I want to add on top of the current chaos of changing
the io routines over to *some* more common structure (reading stat/proc
files for plotting resource usage values).

Thanks again for the info.