I’ve implementation of UnaryOperation like this
struct Converter { Converter( std::size_t value ): value_( value ), i_( 0 ) {} std::string operator() ( const std::string& word ) { return ( value_ & ( 1 << i_++ ) ) ? word: std::string( word.size(), ' ' ); } std::size_t value_; std::size_t i_; };
And I use it like
std::vector v; // initialization of v std::transform( v.begin(), v.end(), std::back_inserter( result ), Converter( data ) );
My question is can I rely on my assumption that algorithm will call my ‘Converter operator ()’ in the order that ‘Converter::i_’ will correspond to number of element in ‘v’.
Please quote the standard in case I can’t rely on the order or put the stl-like solution that avoid possible problem if any.
Thanks.
Edit:
I am aware of ‘no Side effect’ requirements in the standard for the transform algorithm. I can’t find what is exactly ‘side effect’ for functors in the same standard.
Maybe there is some good-looking-boost-like solution for this task?
Qute from standard:
Side Effect ( wikipedia definition )
In your case we have next side effect:
You don’t have any guarantees for your algorithms, but I belive that it will works on almost all stl implementations.
Suggested solution
It seems I know one way to do what you need:
use boost::counting_iterator – for iterate over two containers;
it will looks like:
Also maybe if you will define bit iterator or will use some bit container you will can use boost::zip_iterator for iterate both containers.
EDIT:
Yestarday I found interest article which contain definition of Side Effect by standard.
EDIT:
I hope it will be latest edit.
I am always tought that ‘no have side effect’ mean:
f(a) should be equal f(a) always. ( f independed from execution environment: memory/cpu/global variables/member variables as in your case etc).
‘Not produce side effect’ mean – don’t changing execution environment.
But in c++ standard we have more low-level defintion for Side effect.
Thing what you do in your example named as Stateful functor.
Standard doesn’t say about ‘Statefull’ functors, but also doesn’t say about count of copies of your functor – you couldn’t use this trick because it is unspecified behavior.
See Standard Library Issues list ( similar issue for predicat ):
http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-active.html#92